Well, I'm sorry that because I effectively said "Ruby and Rails are making valuable contributions to the programming community" rather than "Ruby/Rails are the way and the light and only through them shall you achieve salvation" that this whole thing has devolved as much as it has. But as I said before, I think that the vitriol from the Ruby hyper-enthusiasts proves my point -- I'm not seeing that kind of aggression so much in the Java community anymore, so I'm theorizing that those folks have moved on from Java, and as far as I can tell (and from the flames appearing on this discussion) they have moved to Ruby. I never cared for that attitude in the Java community, and it doesn't attract me to the Ruby community. And I've personally seen very little of it in the Python community.
And attacking Alex -- especially without paying any attention to his deep understanding of programming languages in general and Python in particular, and his contribution of two of the best books on Python (when I travel light and I need Python books, "Nutshell" and "Cookbook" go in first) -- and then claiming he behaves badly after you piss him off (although, Alex, you have to admit that it's like throwing gasoline on a fire; it almost looks like you're enjoying the process of cranking these people up) is juvenile.
I certainly don't think everyone in the Ruby community is a hyper-enthusiast who migrated there from Java. And I don't think Ruby is "bad," but I want to try to understand it more deeply than I'm getting from "If it's in Ruby, then it is by definition good" (for example, saying that because having two different methods that do exactly the same thing is in Ruby's list class, it must by definition be brilliant, rather than observing that it was probably an early mistake -- after all, it violates Dave & Andy's DRY principle). For example, the fact that Ruby might make metaclass programming easier than it is in Python is quite interesting to me.
I'll also point out that I know Dave and Andy and respect their (ordinary, not hyper) enthusiasm about the language; their interest (and Martin Fowler's) is what made me become interested in the language in the first place.
I do want to know more about it, but I want to know the REAL stuff, not the religious dogma. For example, THIS is the kind of useful gem that it's been worth having this discussion for:
> Yep. Essentially, a statement such as "x = y" in Python > always parses to "bind name 'x' to the same object to > which 'y'" is now bound. In Ruby, it can parse to that OR > to "call method y without arguments and bind name 'x' to > the object that is the result of that call"; you cannot > tell without looking more widely beyond that statement, in > order to learn whether y is a method or a variable. > Similarly, in Ruby you cannot know, without looking more > e widely, if 'x=y' or 'x=y()' mean the same thing or not; > if y is both a local variable and the name of a method, > then both syntax forms are correct, and mean different > things -- if y is just a variable, the second form is > incorrect -- if y is just a method, both forms are correct > and mean the same thing.
This points out something essential about the language, and gives me a sense of the fundamental philosophy. And I think it could be something that will cause problems in code as things scale up (don't bother replying with an argument if all it amounts to is "no it won't."). This is the kind of thing that I'd like to see in a fundamental analysis of Ruby, ideally in a comparison with Python.
PS: My apologies to your employers at Google, Alex, if this whole thing has impacted your productivity.
This has been an interesting series of comments, despite the vitriol, flaming and ad-hominem attacks. I've learned a lot. I probably would have learned even more if I hadn't started ignoring the most rabid of the writers.
As to the putative subject, I'll say more in a moment, but first a few comments about typing and syntax.
I'm a programming languages researcher who has programmed 20K+ lines of code in each of a handful of languages, including C, Scheme, ML, Java and a few assembly languages, and at least a few thousand lines in each of a dozen other languages (including Ruby and Smalltalk). I like some aspects of statically-typed languages and I like some aspects of dynamically-typed languages. Unfortunately, because of the covariance/contravariance problem, all OO languages are ultimately dynamically typed (although generics/parametric-polymorphism can help). While in a powerful static-typed language like ML (SML, CaML) you can't get type errors, you can still get subscript (and other) range errors. So because even the best type systems can't give me absolute guarantees about run-time errors, I've become a huge fan of unit tests - and then static typing can become pretty irrelevant.
What's generally called syntax is essentially what can be recognized by a context-free-grammar in a compiler. Syntax differences are, in some sense irrelevant (syntactic sugar) but one of the areas that programming language people focus on is cognitive-load - how much crap you need to keep in your head to implement the algorithm that's in your head. From this perspective, Ruby has one of the lowest cognitive loads that I've come across. Even the @ for instance variables and @@ for class variables that I would normally complain about actually seem to have the right level of assistance with that mental load. The only thing I have a problem with is the interaction between implicit variable definition and scopes, although it sounds like Python gets it much more wrong.
I don't know Python, although I've learned quite a lot about it and gotten a lot of the flavour of it through this discussion. I've been using Ruby since the summer, and I quite like it. Despite (or perhaps because of) my 30 years of programming experience and plethora of languages, I found the learning curve for Ruby+Rails to be surprisingly steep (but then, I like to understand a language before I start using it, rather than a just-in-time acquisition).
As for the hyper-enthusiasts: who cares??? They're mostly what I'd call the yammering classes... book authors, magazine columnists, and consultants; all of whom, by definition, need to be on to the New And Improved in order to sell books or magazines or be seen as having valuable knowledge.
But I think that most of the people that got caught by Bruce's wide net are just enthusiasts who have found a productive new way to get their jobs done. The Ruby fans probably don't know Python and vice versa. That's a shame. It sounds like there's a few good ideas in each language that may or may not be easily added to the other. Perhaps we do need a new language that captures the best of all of these languages, but in the meantime, let's enjoy programming with the best tools we can find.
> Syntax or not, the difference between Python and Ruby are > more than trivial. You could argue that English and > Spanish are equivalent because it's possible to translate > an expression from one into the other. But that's hardly > the end of the story. For example, to say, "I dropped my > watch" in Spanish, you might say, "se me cayo el reloj". > You won't appreciate the nuance of that phrase without > understanding Spanish. And that nuance may or may not be > important in context. >
If the translation is well done, "se me cayo el reloj" means that it's un-intentional. If it was intentionally done, it would be "tire el reloj".
> If the translation is well done, "se me cayo el reloj" > means that it's un-intentional. If it was intentionally > done, it would be "tire el reloj".
Exactly. ;) And Spanish seems to capture more simply than English, in this construction that is used in many contexts, the intentionality.
An interesting comparison between Python and Ruby is how the languages look at objects. It's been said that "everything's an object in Ruby", and of course, Pythonistas respond, "yeah, same as in Python". Here's the difference that I see: in Ruby, the object is, arguably, primary above control structures; not so in Python. Let me illustrate.
In Ruby, iteration is very commonly performed by:
obj.each { |arg| do_something }
and there are other ways of iterating like
10.times { |arg| do_something }
or
1.upto(10) { |arg| do_something }
We know that in a sentence, there are two places of natural emphasis, the beginning and the end. In Ruby, by placing the object in a natural place of emphasis, I think it encourages the programmer to think of the object first, and think of interacting with objects and how objects interact. Iteration is no longer a special control structure, but just another way of interacting with an object or collections of objects.
Remember when Python got generators? The way to interact with those was the for loop construct. In this way, to me, Python seems to emphasize the control structure over the object.
As a previous poster has pointed out, there is the concept of congnitive load. In the way that, to me, Ruby emphasizes objects and harmonizes the way of viewing them conceptually, it reduces the cognitive load vis-a-vis Python or Java or C, etc.
> We know that in a sentence, there are two places of natural emphasis, the beginning and the end.
Natural? Languages (spoken and computer) are completely artificial. There is nothing natural about them. However, that isn't really relevant, since your analogy falls apart completely. None of the three examples you gave even close to how such a thing would be verbalized. "Ach! The air is low in my bike tire. I guess I should 10.times { |the_pump (or the tire?)| } pump }." Well, gosh, yes, I suppose you are right after all.
Anyway, the whole "my language is more object-oriented than yours" is a silly computer-nerd kind of argument. In some cases (like native types in Java), there is a some very annoying friction caused by the fact that you have to treat types differently, but this argument is a non-starter between two languages like Ruby and Python (or were you talking about Python 1.5.2?).
Your whole argument here is 100% subjectivity. For example, maybe it seems to me that a more natural way of thinking of things is as processes, not objects. A lot of really clunky stuff you see in OOD is around trying to encapsulate processes in objects. (These are usually the cases where you get really strange and ill-fitting object names, too.) Getting too fixated on making everything an object versus making good software is going down the wrong path.
> In some cases (like native types in Java), > there is a some very annoying friction caused by the fact > that you have to treat types differently, but this > argument is a non-starter between two languages like Ruby > and Python (or were you talking about Python 1.5.2?).
Even in Python 0.9.2 ( released 1991 ) you noticed the difference between types and classes only when you tried to inherit from "types". There was no lack of interoperability: you did not have to wrap an int by hand in order to put it into a vector ( i.e. list, tuple ) as you have to do in Java. Serialization didn't fail because only objects can be serialized but not elementary types etc. Inheritance needed a workaround that is still reflected by now legacy classes UserList, UserDict etc. in the standard library. I started using Python with v1.5.2 and at that time I did not even noticed the type/class difference to be a wart. It did not have a large impact on my programming practice.
I have learned a lot from reading these posts in spite of the personal nature of some of them. Alex M.'s attacks on Brian seemed to be particularly vicious -- rather uncalled for, in fact. I'm not a Ruby programmer, but I can easily see where someone would see the "hyper-enthusiast" label and the original article as being derogatory and even incendiary.
Witness this: "The Java hyper-enthusiasts have left the building, leaving a significant contingent of Java programmers behind, blinking in the bright lights without the constant drumbeat of boosterism. [...] Where did the hyper-enthusiasts go? To Ruby, apparently."
and this: "...we know the hyper-enthusiasts have moved to Ruby because of the howls of protest at Harold's opinion [...] We can identify hyper-enthusiasts because the arguments have a strongly faith-based flavor to them..."
Not exactly a positive portrayal, certainly.
Still, it sparked an interesting discussion that has been useful to me.
I appreciated Brian's comments, actually, and do not see where they warranted such vituperative responses. From an objective standpoint (I know none of these people), I do not see that his posts have been as negative or injurious as some seem to think.
For someone to assert they would not want to learn a language because they disliked the posts of an individual or even several individuals on a single thread of a given bulletin board is bizarre.
> For someone to assert they would not want to learn a language because they disliked the posts of an individual or even several individuals on a single thread of a given bulletin board is bizarre.
Yeah, he was a little bit tart, which is not uncommon in internet forums, but it did seem like the reaction was disproportionate.
It is kind of strange from a sociological point of view that people often seem to be more aggressive/assertive/arrogant when posting to forums than they would be in person. Kind of like how the same person who will be very courteous when on foot (holding the door for you when it isn't really necessary), will be very rude (even ruthless) when behind the wheel of a car.
> A lot > of really clunky stuff you see in OOD is around trying to > encapsulate processes in objects. (These are usually > the cases where you get really strange and ill-fitting > object names, too.)
This is an excellent point. Objects appear to be designed around a single-process model, and much pain has ensued when trying to combine objects and processes. Threads, for example, are a low-level C-ish construct that have been shoehorned into OO languages because some people already knew threads, so that seemed the logical step to take. But you get a sense of orthogonality about threads in, for example, Java. There's an abrupt shift between objects playing nicely with each other vs. threads tromping around and causing havoc. Most (all?) OO languages seem to have acquired processes by assimilation rather than through insight.
The only thing I've seen that shows promise as an OO process model is Active Objects/Actors. On the other hand, I haven't seen how Erlang deals with objects -- or does it support objects?
> Natural? Languages (spoken and computer) are completely > artificial. There is nothing natural about them. > However, that isn't really relevant, since your analogy > ogy falls apart completely. None of the three examples > you gave even close to how such a thing would be > verbalized.
Well, natural language is a term used to distinguish what we usually use in communicating from something more artificial, like a computer programming language.
Perhaps "we know" was too strong. I'll restate: congnitive psychology suggests that there may be, in arrangements of things, say words forming a sentence, places where our brains perceive or remember something more clearly. In writing courses, we're taught that those places are, usually, the beginning and end of a sentence.
Now, for the big leap that completely falls apart: when I program in Ruby, writing or reading (but not necessarily verbalizing, although I've found Ruby to verbalize pretty good), I find that thinking object then method helps me focus on the objects over control structures. I find the opposite mostly, but not always, true in Python.
> > Anyway, the whole "my language is more > object-oriented than yours" is a silly computer-nerd kind > of argument.
I think you missed my point. I was trying to say this wasn't an issue of 'more object oriented' but rather an issue of how you think about objects and control structures in the two languages. It's an area where I definitely perceive, however subjectively, a difference between Python and Ruby. I like exploring those differences to better understand this thing we create called languages.
> Your whole argument here is 100% subjectivity.
Yes, of course, 100%. I wouldn't claim otherwise.
> For example, maybe it seems to me that a more natural way of > thinking of things is as processes, not objects. A lot > of really clunky stuff you see in OOD is around trying to > encapsulate processes in objects.
What have you found useful in addressing this in terms of languages, design processes, etc.?
> > For example, maybe it seems to me that a more natural way of > > thinking of things is as processes, not objects. A lot > > of really clunky stuff you see in OOD is around trying to > > encapsulate processes in objects. > > What have you found useful in addressing this in terms of > languages, design processes, etc.?
The typical thing that I see is that process control is lumped in with the objects themselves. As participants, they are interfaced with the system as controllers rather than players.
I found an instance of this in a system critical procedure associated with a telephone switch as described in my blog http://www.artima.com/weblogs/viewpost.jsp?thread=4350. That's a very old issue, but I still see the same thing. Because a control structure doesn't exist. We tack on little bits and pieces to existing objects to do new things, instead of having a process control structure with players from the start.
I don't provide any real details in the blog about what the designed system did, but basically it provided the ability to declare sequences of steps that you would provide objects to carry out. There was no visibility between steps of any programatic linkages/references.
This really simplified the ugly control structure that was in place, and it made it a lot easier to do simple procedures.
After I left (in 1997) the control system was reused for a number of procedures related to maintainence and upgrading hardware. I still saw it in use last year when I went back to visit some old friends, so that made me feel good about doing something that really did work.
I've been thinking about creating a new process control system in Java for some human based process control that I need.
On another related note, the upcomming availability of the scripting engine in Java, will likely cause people to start using that facility for process control because of it's perceived simplicity in mutability and simplicity.
Thanks for the link to Andrew Glover's piece. I wrote Andrew the following:
----- I found your Ruby-Java comparison interesting (http://www-128.ibm.com/developerworks/library/j-ruby/?ca=dgr-lnxw06RubyOffRails), however I have to point out (Im sure Im not the only one) that your Java example is artificially verbose and thus the comparison is not quite realistic. I do recognize that some of the verbosity is inevitable the declaration of getters and setters instead of the attr_reader syntax (really elegant), and the lack of default parameters in Java (a step backwards from C++) which forces us to overload more often than necessary. But apart from those two nontrivial differences, the Java example neednt be as long. Here are my suggestions:
1. import java.util.*; // instead of three imports 2. private Collection definitions = new ArrayList(); // instead of an extra line in the constructor 3. The null checks in Java are your choice, they are not mandatory. You could leave them out, just as you could add them to your Ruby code. 4. Your validateRelationship() method doesnt validate anything. You could replace it with def.setWord(this); , just as in Ruby. The check def.getWord() != this is redundant, too (in both examples). 5. You left out the addExampleSentence() method in Ruby. 6. Most of your this references in Java are optional.
As mentioned above, the surplus code in Java is due to the getters and setters and to the overloaded constructors. The first are inevitable, except that some setters may be redundant immutability is often sounder. However, most java coders just write all the setters without thinking (spoiled by Mr. Bean, I guess). Writing them is no pain thanks to IDEs but they do clutter the code, in my eyes.
As to the constructors, they are also a matter of choice. Sometimes you just have to code so many constructors but often, it is a better choice not to provide them. Is it probable that a word will be initialized already with a ready list of definitions? It depends on the semantics of your use cases (where you get the data from and in what order) but I suspect in this example you would rather go for the add method, which also provides control over input types (Im leaving J5 generics aside for now).
Collections: Ruby's collections handling is amazingly simple too -- The << syntax is overloaded to mean add. If you look back to the Definition class in Listing 2, you'll see that the corresponding code in the Java language is a much bigger mouthful. Excuse me?
@definitions << definition (Ruby) versus definitions.add(definition); //Java Now thats a big difference! That almost convinced me to go into the desert and repent my Java sins ;-)
There is really no difference, add() in Java is overloaded too, as is addAll() (instead of the + operator in Ruby). So I think, at this point you really have let yourself take away by the hype. If Ruby collections are done right, so are Java collections. -----
Andrew's response: "Thanks for the feedback. You are correct, the mouthful comment was a bit of an exaggeration. Happy New Year! "
"WRT the last post, I find that most of the difference is from Java requiring that there's type declarations everywhere."
In my post, I was taking issue with the claim that Ruby syntax is more "terse". The author clearly exaggerated this by making the Java code unnecessarily verbose. Of course you are right concerning type declarations, however, this doesn't count as verbosity for me. In my feeling, code doesn't take longer to read because of type declarations. Proponents of dynamic languages tend to identify the readability/complexity issue with number of characters, which is plain stupid. What is important is the number of logical entities that you have to keep in mind in order to understand the code, not the number or lengths of words to read. Type declarations actually reduce complexity because the reader doesn't have to try to infer what the code is about. Whatever may be the benefits of dynamic typing, readability is clearly not among them. I wish that we could get at least that one straight.
Flat View: This topic has 262 replies
on 18 pages
[
«
|
12131415161718
|
»
]
Previous Topic
