The Artima Developer Community
Sponsored Link

Weblogs Forum
The departure of the hyper-enthusiasts

262 replies on 18 pages. Most recent reply: Dec 20, 2006 11:11 AM by Carlos Neves

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 262 replies on 18 pages [ « | 1 ... 11 12 13 14 15 16 17 18 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 10:08 AM
Reply to this message Reply
Advertisement
> James:
>
> > Um, I also don't think Java is necessarily better than
> > Ruby.
>
> Well, you're arguing that enterprise apps can only be
> implemented in a statically typed language like Java.
> Better is relative. In this regard, you think Java is
> better. But you haven't justified your view, and I don't
> think you can.

I never said that it could not be done. I just think that over the long term it will cause problems. I have worked with many older systems that were developed in a loose and fast way and they all suffer from extreme maintenance issues. It wouldn't suprise me at all if a few years down the road people start writing articles about similar issues with older Ruby code.

> This is your argument, not mine.

That's basically a bald-face lie. Show me where I made this argument.

> I didn't say Java was no
> good because that production enterprise app from one of
> the world's largest financial companies barfed a stack
> trace on me because of a null object reference. Static
> typing in no way helped to prevent this error, nor could
> it.

And what does static typing have to do with null-pointer exceptions or in the Ruby world, NoMethodExceptions?

> Remember when Java was supposed to save all us C
> programmers because it didn't have pointers?

No I don't remember that. I never thought that.

> We wouldn't
> be dereferencing NULL. Well, null is just as deadly for a
> Java app, static types and all.

This has nothing to do with static types or otherwise.

> Just so we're clear, a type to me is a set of values and
> operations on those values.

At a very simplistic level, yes. But in good OO code, a type is a set of operations with contracts for each. This type and it's associated documentation provide a layer of abstraction that allows for more complex systems by reducing coupling within the system.

> I simply don't understand how static typing will make
> these management and communication problems go away.

The types are communication. By defining an iterface, I provide my co-workers with a clearly defined contract for using the code I have developed and provided a road-map for them to follow in enhancing/fixing/modifying my code.

> Examples, please. And if static typing is all that, then
> why Java instead of Haskell, which has a far more
> sophisticated type system and referential
> transparency?

I don't think Java is the end all be all of languages. I think it's a very pragmatic choice because it is well understood and has a concise syntax. It's a very common language. It also provides the basic requirements for Object-Oriented design, albeit in a sometimes clunky and verbose fashion. Verbosity isn't a huge issue to me because very little of my development time is spent typing. If I used a language that was half as verbose, it would save me maybe 1 or 2% of my development time.

> I'll give you a counter-example. Rails. This was
> developed, after a number of folks started contributing
> heavily, across at least 3 time zones and at least 2
> languages (although David's English puts many native
> speakers to shame). I don't see how lack of static types
> hampered them. But you might ask them about it.

That's a decent example. It's still a rather young application though. The real test will be years from now. I'm not saying you can develop in a clean way with Ruby, it's just that my belief is that telling people not to use short-cuts is not effective. If they see the short-cut and think it saves them a little time, they tend to use it.

> I'd recommend looking over these slides by Jim Weirich on
> 10 things every Java programmer should know about Ruby
> (http://onestepback.org/articles/10things/index.html), if
> you're really sincere about learning something here. He
> happens to know _both_ Java and Ruby very well.

I looked at this and I also did a tutorial. It's just not doing it for me. I don't like voodoo code. I like clear obvious paths of execution. I don't want to be puzzling over why this call had that seemingly unrelated side effect.

> It's important to understand that types are not prominent
> in Ruby. Ruby is about classes, which are objects
> themselves, and instances of classes. There is no
> 'documentation' provided by a type label that cannot be
> provided by the class and it's documentation.

Great, here's the core of my concern. There are properies that are common across our system in that at basically any point of any transaction they are meaninful and useful. This properties are abstracted to a type. This type is defined once. From what you are describing to me, it sounds like you would redefine this type at many different points in the application. This seems to me to be a violation of DRY. Perhaps I misunderstand the point?

> And lest you
> think that duck-typing somehow introduces confusion, every
> object is indeed strongly 'typed' (in a sense): ask it
> it's class (obj.class) and you'll get a definite answer.
> You can also ask it what it's like (e.g.
> obj.is_a?(String)). These are things that can be tested
> for using good behavior driven development in a way much
> more sophisticated than a compiler type-checking your
> code. And the tests themselves provide immeasurable
> assistance with communication.

I think you misunderstand my concern. I do actually like the dynamic abilities of Ruby. I like that classes are Objects. I like the ability to create types at runtime. I've been convinced for years that dynamic-checking is as good as compile time checking. The innumerable casts in Java are evidince that it works fine. ClassCastExceptions in production code are exceedingly rare. I sometimes think it's stupid that the compiler forces you to say this class implements interface X when the call implements all the requirements of X.

What I dislike it the lack of clarity hat comes from not defining static types e.g. interfaces or abstract classes. I'm not saying it can't be done in Ruby (I imagine it can) but from all the evidence I've seen, it's not only not done, not doing it is celebrated. I don't like that. It's personal preference based on many hours of frustrating maintenance on sloppy code. When people write code without clear abstractions I want to grab them by their necks and smash their faces into the keyboard.

> I can't help but reiterate my main point in all my posts:
> people, especially self-professed experts, should know
> what they're talking about before shooting off at the
> mouth.

Is there something I have written that was factually inaccurate? Do you not feel that I am entitled to my opinions?

> I'm not trying to convert you, or yank away your
> little security blanket named Java, C#, Python, Lisp, or
> whatever.

I'm not trying to get your panties in a twist but apparently I have.

> So rather than all your 'apprehensions' and 'hard time
> imagining' and other hypothetical nonsense, why not learn
> Ruby and actually demonstrate, in particular, why it fails
> as an 'enterprise app' language.

Why don't you prove that is succeeds?

> If you did that, you'd be
> quite famous, and popular with the Java and Python
> fanatics at least. Otherwise, you just sound stupid to
> someone who knows better.

Stupid? An example of 'stupid' is making comments like this.

> And I always think it's more
> important to not sound stupid to people who know better,
> than to sound smart to people who don't know better.

I don't really can about how I 'sound' to you or anyone else. I don't feel I the need to prove myself.

All I have done here is bring up some questions and concerns. Instead of addressing them, you've basically gotten extremely defensive. If you really felt you were in a position of strength, you wouldn't do this.

Thomas Guest

Posts: 236
Nickname: tag
Registered: Nov, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 11:24 AM
Reply to this message Reply
[snip]

> I don't think Java is the end all be all of languages. I
> think it's a very pragmatic choice because it is well
> understood and has a concise syntax. It's a very common
> language. It also provides the basic requirements for
> Object-Oriented design, albeit in a sometimes clunky and
> verbose fashion. Verbosity isn't a huge issue to me
> because very little of my development time is spent
> typing. If I used a language that was half as verbose, it
> would save me maybe 1 or 2% of my development time.

The important point about verbosity is not the time you spend typing: it's about how difficult it is to read and understand the code.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 11:54 AM
Reply to this message Reply
> [snip]
>
> > I don't think Java is the end all be all of languages.
> I
> > think it's a very pragmatic choice because it is well
> > understood and has a concise syntax. It's a very
> common
> > language. It also provides the basic requirements for
> > Object-Oriented design, albeit in a sometimes clunky
> and
> > verbose fashion. Verbosity isn't a huge issue to me
> > because very little of my development time is spent
> > typing. If I used a language that was half as verbose,
> it
> > would save me maybe 1 or 2% of my development time.
>
> The important point about verbosity is not the time you
> spend typing: it's about how difficult it is to read and
> understand the code.

And verbosity makes code easier to read. I don't have to know anything to understand the code. Everything I need to know is there in front of me.

The verbosity of Java code also encourages developers to implement more abstractions and reausable components. The ease of coding in some languages often results in more code, in my experience. It's easier to just write more code than to stop and think about reusable solutions. In Java and other verbose languages), 'coding for the moment' is a losing strategy. It's actually a big reason why lots of Java projects have failed or have performed poorly. But I don't see this as a failure of the language, it's a failure of the developers to see the big picture.

Dan Shafer

Posts: 3
Nickname: dshafer
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 12:54 PM
Reply to this message Reply
"And verbosity makes code easier to read. I don't have to know anything to understand the code. Everything I need to know is there in front of me."

Agreed. Verbosity is a virtue for everything but code typing where it can be a source of slowdown and typos. But most editors have completion modes, so that shouldn't generally be an issue.

I come from Smalltalk where verbosity is a key language feature. Many years ago, Adele Goldberg (she of ParcPlace Systems, Xerox PARC and Smalltalk fame) wrote a wonderful paper called "Programmer as Reader" in which she argued that since most code spends most of its life in maintenance mode, readability was more important than is generally acknowledged.

Symbolic terseness is one of the few things that makes me queasy as I learn Ruby. But then I type REALLY fast and accurately, so maybe I'm just weird.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 1:30 PM
Reply to this message Reply
> I come from Smalltalk where verbosity is a key language
> feature. Many years ago, Adele Goldberg (she of ParcPlace
> Systems, Xerox PARC and Smalltalk fame) wrote a wonderful
> paper called "Programmer as Reader" in which she argued
> that since most code spends most of its life in
> maintenance mode, readability was more important than is
> generally acknowledged.

This is exactly what I am trying to get across. Everything that I read about how great Ruby is is about how fast you can get stuff done. But I don't see anything about how what is produced is easy for other developers to understand and maintain. I see about how testing the code is better than static typing but producing code that works isn't that hard. Producing code that works and doesn't cost a fortune to maintain is the trick.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 2:11 PM
Reply to this message Reply
My goodness, I'm a silly little man. Quarreling with snakes and hot cups of coffee is dangerous! I could get bitten, burned, strangled. What was I thinking?!

Alex,

My apologies for saying anything about you deserving a slap in the face. And who am I to question that you know what you're talking about? I mean, if I had only checked first, I would never have challenged you. IBM, awards, Python books; omg, how silly I am!.

I did read the two links you posted. I didn't think your comparison was particularly insightful or even-handed. Cool is different than 'cool', as I said. I haven't read everything you've written on the topic. I'm sure you do know what you're talking about. Who am I to challenge the Alex Martelli. How stupid. If you say it's all a matter of syntax, I should just accept it.

> This implies that "mere mention" means something utterly
> different for a method versus other attributes.

I was wondering, could you clarify something: is it, or is it not syntax when you have to juxtapose parenthesis to call a function? On the one hand, you say it is, on the other, you say that Python looks at all the attributes the same, regardless of whether the attribute is a callable. If Ruby looks at them differently, is this only a matter of syntax. Just want to understand your view on it. Admittedly, I think the "syntax" thing is a little gray, but who am I to say; I was just thumbing through Google "define:syntax".

BTW, I did not say there is no reason I like Ruby that is, essentially, a syntactic difference with Python. Of course, some things reduce to syntax, but all hardly do. Is single versus multiple inheritance a matter of syntax? Are closed versus open classes a matter of syntax? You are the one who said it's pretty much a matter of syntax, among other things, of course. My argument is that saying it's a matter of syntax obscures some important points. If you say it, with your air of authority, it has serious potential to mislead someone; so I think you should be careful about saying it.

And, lest we forget, you were responding to Bruce, who I think should be taken to task for labeling a broad group of people as hyper-enthusiasts in a derogatory fashion. For whatever reason, you don't feel compelled to castigate Bruce for what he says, but you are no-holds-barred in your over-wrought, emotional, egoist tirade against me. Am I not entitled to my opinions? How dare I challenge the great Alex Martelli?!


Vincent O'Sullivan,

Wow! The synopsis, the high-level view, the abstraction that is possible with a list of words without context. I'm in awe. Now I see it; before it was obscured by all those other words. The Ruby community really is awful.

> QED Bruce.
> Well done.

Two thumbs up for that review!


Gregg Wonderly,

> No, I'm not kidding. Druby and Pyro don't even come close
> to the power of the RMI programming model and Jini's
> expansion of that. Not even close. So, probably you need
> to go read about Jini and try and absorb the differences
> so that you can appreciate them.
>
> Number one is missing in both of these is mobile code
> support!

Okay, I'll read up. I definitely think the foundation is there in both Python and Ruby. I don't see anything like a technical barrier. Also, I think Rinda is interesting.

I really think the idea is valid that an API is better if it results from an extraction rather than being designed a priori. So, one question: in what domain have you found RMI and Jini to be indispensable? I'd like to look at that to see how these technologies address the issues.


Morel Xavier,

Thank you for your points. Again, I've never said there is nothing between Ruby and Python that reduces to syntax.

I'm glad you've taken the time to learn something about Ruby. I'd like to point out something about blocks: with Python, you either have to nest definitions of functions, or pass some number of args to get the value of the "closure" that you get with Ruby blocks. To me, this can become significant. One, the value of an anonymous bit of code is high. I don't have to worry about naming it, or how that might impact my interface, because the real focus is on what the code does, not the function identifier. Two, the bit of code in the block is visible in it's surrounding context.

It seems that you realize this, from what you wrote. So, while you may be able to accomplish the same thing in Python, it's definitely not as simple. This is a difference that may be huge or small, depending on the context. It's a difference that is important and shouldn't be obscured by someone saying it's all a matter of syntax. I'm pleased to see that Python will be implementing "blocks" of the type Ruby has. I think Python will be a better language because of it.

I'm glad Guido won't be removing map or filter. I thought I read that in a discussion on the python-dev list. At least one other person seems to have misunderstood as well: (http://www.advogato.org/article/846.html). Thanks for pointing out the error.

Another point: I really like Ruby's approach to the issues of multiple inheritance. Ruby uses single inheritance and mix-ins. Single inheritance keeps the class hierarchy a simple tree rather than a network. It's easier to understand. More importantly, using mix-ins preserves a more faithful is_a relationship. Consider the Enumerable or Comparable modules. Including these adds functionality to a class without stretching the is_a relationship beyond the breaking points. It's a great feature of Ruby, IMNSHO, that is more than just syntax.

Oh, and two other things I'd like to add to my list: regular expressions are first-class objects, and variables have public, protected, private scope. These may, or may not, be merely a matter of syntax (I've given up trying to understand the difference since it's so clearly defined), but I really like them in Ruby. Some folks prefer the module interface to regular expressions. Either way, it is a difference that could be highlighted because it could be important to someone.

James Watson,

Thanks for all your comments. I think we agree on one point: types, and in OOP the extension of those to classes, should be clearly defined in order to aid understanding, creating, and maintaining the code. We disagree on the best place to check that they are being used as designed. I don't think the value of compiler checking offsets the baggage that comes with static types: i.e. the trouble to decide (should it be in byte, int, long, long long), define them, cast them, etc.

> Great, here's the core of my concern. There are properies
> that are common across our system in that at basically any
> point of any transaction they are meaninful and useful.
> This properties are abstracted to a type. This type is
> s defined once. From what you are describing to me, it
> sounds like you would redefine this type at many different
> points in the application. This seems to me to be a
> violation of DRY. Perhaps I misunderstand the point?

No, I'm definitely not saying you redefine them at many different points. I'm saying that code that only relies on what an object "looks like, acts like" (duck-typing) is more flexible than code that must explicitly specify a type. A good example is in GUI programming. In some systems, every GUI widget is something like a "drawable" (hypothetically). If I'm working with a few of these, I have to declare a variable of a some type (probably a more general one) and then cast it if I want to call a function defined on a derived type. Or I have a bunch of variables each declared to be the appropriate type. This latter approach doesn't work great for iterating over a collection of these.

I think we understand each other more than it appears. I think we should be looking at how to enforce something like compile-time type checking (realizing that it can only ever check a very limited set of "compliance" aspects) without the baggage of types.


> I'm not trying to get your panties in a twist but
> apparently I have.

I checked, no twists. ;)


> What I dislike it the lack of clarity hat comes from not
> defining static types e.g. interfaces or abstract classes.
> I'm not saying it can't be done in Ruby (I imagine it
> t can) but from all the evidence I've seen, it's not only
> not done, not doing it is celebrated. I don't like that.
> It's personal preference based on many hours of
> f frustrating maintenance on sloppy code. When people
> write code without clear abstractions I want to grab them
> by their necks and smash their faces into the keyboard.


Shh! Don't say that too loud. If Alex hears you and thinks it's directed at him (although, I'm sure he's never been guilty of writing anything but sterling code), he'll call for the entire Java community to denounce you, or he'll never look at Java again!


> Why don't you prove that is succeeds?

Okay, I'll be working on that over the next several years. Perhaps as time goes on, if people can tease out what are true difference between languages, and at the same time more clearly define what exactly is an "enterprise" app, we will have a better basis for comparison. I am quite confident at this early stage that enterprise apps are not only possible in Ruby, but that they would be highly successful as well. I'll keep in mind what you have expressed as your concerns in this regard.


To All,

Please do take what I say with a grain of salt. I'm no where near the expert that most of you are, definitely not anywhere near the great Alex Martelli. If I offend, please consider the source: I'm a Ruby uber-hyper-super-duper-enthusiast.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 3:48 PM
Reply to this message Reply
> No, I'm definitely not saying you redefine them at many
> different points. I'm saying that code that only relies on
> what an object "looks like, acts like" (duck-typing) is
> more flexible than code that must explicitly specify a
> type. A good example is in GUI programming. In some
> systems, every GUI widget is something like a "drawable"
> (hypothetically). If I'm working with a few of these, I
> have to declare a variable of a some type (probably a more
> general one) and then cast it if I want to call a function
> defined on a derived type. Or I have a bunch of variables
> each declared to be the appropriate type. This latter
> approach doesn't work great for iterating over a
> collection of these.

Just so I am clear, you are talking about static typing above, right?

> I think we understand each other more than it appears. I
> think we should be looking at how to enforce something
> like compile-time type checking (realizing that it can
> only ever check a very limited set of "compliance"
> aspects) without the baggage of types.

I'm not sure that I completely follow you. I'm not really saying that I want to stick with compile time checking. What I would prefer is that methods have a defined 'type' that basically says what methods Objects passed in must implement. This type should be easily cataloged and retrievable to developers for reference and reuse. Objects passed in as this 'type' could be coerced by the compiler to fit that type. If the compiler can tell me at compile time that my object cannot possilbly implement the proper methods at runtime, that's great. Saves me a test cycle. However, it's not a requirement AFAK.

I believe that all of this can be done in Ruby. The problem is that I don't think you have to do this (I could be wrong.) Maybe I could be convinced that this isn't a necessecity (though, I keep thinking about the crap code I see all the time) but the other thing I really don't care for is operator overloading. Operator overloading is good in extremely small doses but the temptation to abuse it has proven too great for many developers. I want to see one way and one way only to pass messages to Objects. I don't want to define my own syntax even though it can be really nice in rare circumstances.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 4:45 PM
Reply to this message Reply
James,

> Just so I am clear, you are talking about static typing
> above, right?

Yes, something along these lines:
void foo(Window w)
{
Button b;
List l;

b = w.getWidget("button1");
l = w.getWidget("list1");

if (b.needsUpdate)
b.update();
if (l.needsUpdate)
l.update();
}

This is just an example. If I wanted to iterate a collection of widgets that the window contains and call a method that isn't defined in a common ancestor, I have to cast. That's one of the issues with static types that has been, in my experience, difficult. Maybe a better class model would simplify this.

> I'm not sure that I completely follow you. I'm not really
> saying that I want to stick with compile time checking.

LOL. "But I thought you were going to buy me a Sierra Mist Free." (have you heard the commercial?)

> What I would prefer is that methods have a defined 'type'
> ' that basically says what methods Objects passed in must
> implement. This type should be easily cataloged and
> retrievable to developers for reference and reuse.
> Objects passed in as this 'type' could be coerced by the
> e compiler to fit that type. If the compiler can tell me
> at compile time that my object cannot possilbly implement
> the proper methods at runtime, that's great. Saves me a
> test cycle. However, it's not a requirement AFAK.

Okay, I'm kinda following, I think (my fault, not yours). All Ruby classes/objects have methods like respond_to?, public_methods, public_instance_methods, private_methods, private_instance_methods. Of course, Ruby being very dynamic, you can add methods at run-time, so I'm not sure how/when this would be check/enforced, other than through testing.

> I believe that all of this can be done in Ruby. The
> problem is that I don't think you have to do this (I could
> be wrong.) Maybe I could be convinced that this isn't a
> necessecity (though, I keep thinking about the crap code I
> see all the time) but the other thing I really don't care
> for is operator overloading. Operator overloading is good
> in extremely small doses but the temptation to abuse it
> has proven too great for many developers. I want to see
> one way and one way only to pass messages to Objects. I
> don't want to define my own syntax even though it can be
> really nice in rare circumstances.

Look at this and tell me if it's along the lines you are thinking: http://raa.ruby-lang.org/project/strongtyping/

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 4:49 PM
Reply to this message Reply
> And verbosity makes code easier to read. I don't have to
> know anything to understand the code. Everything I need
> to know is there in front of me.
>
somebody has to say it: this is what justifies COBOL. moreover, enterprise java systems are largely indistinguishable from COBOL. most signifcantly, java folk try (with undue success, alas) to turn RDBMS into VSAM files. it's a shame. but, in the final analysis, a java bean isn't much more than a COBOL COPYBOOK. sad. java had such promise. the bean paradigm just hasn't much to do with OO.

on the other hand, one might argue that the UI language is irrelevant. the UI can be generated from the RDBMS, whose constraints are fully readable. whether the UI is Ruby, java applets, html|css|javascript, it's all just an artifact of the data constraints.

of course, the closet COBOL-ers really, really love to read-a-record(object)-write-some-output, rinse and repeat. well, then let's just do sequential batch processing like we (well some of us) did in the 60s. yeah, that's the ticket.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 5:27 PM
Reply to this message Reply
I see Ford can't do sarcasm or irony any better than he can do "raving lunatic". Ah well, sad -- pathetic, really -- but, his problem, not mine. Let's still try to address some issues:

> If you say it's all
> a matter of syntax, I should just accept it.

I understamd that reading comes very, very hard to you, poor dear, but DO try harder, please. My first mention of syntax on this thread was in the phrase "almost all the syntax choices". See that little, innocuous word *ALMOST*, baby? It *modifies* the meaning of the following "all", asserting that there ARE one or more counterexamples. Here, I was discussing my preferences, rather than the nature of differences (syntax) vs otherwise; specific examples I gave in the same paragraph covered both syntax cases in which I preferred Ruby's choices (more rigid capitalization, dollar stropping for globals, "open classes" syntax of which more later) and non-just-syntax ones (the flexibility of blocks).

Other posters have argued that blocks are also just a syntax issue, but there ARE also non-just-syntax differences, e.g what code is allowed to rebind which variables. Admittedly, this isn't a big practical problem; to quote Ian Bicking, "Syntactically Ruby is better in this respect; Python's functions are not as convenient as Ruby's blocks, though they are mostly equivalent in functionality". Again, note the word MOSTLY; it IS important.

Just as when I use the same word in another post of mine to this thread: "the difference is mostly one of syntax sugar". Get it? MOSTLY, not ENTIRELY.

So, if from among your many favorite lies you might be so exceedingly courteous as to remove this particular idiocy, that I ever said that it's ALL (as opposed to MOSTLY0 a matter of syntax, that would be a big, bold step forward for you; why, a few thousand big steps like that, and the kind people in the white smocks might even start consider taking you off a few of your meds, and wouldn't that be swell?


> > This implies that "mere mention" means something
> utterly
> > different for a method versus other attributes.
>
> I was wondering, could you clarify something: is it, or is
> it not syntax when you have to juxtapose parenthesis to
> call a function? On the one hand, you say it is, on the

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 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.


> other, you say that Python looks at all the attributes the
> same, regardless of whether the attribute is a callable.
> If Ruby looks at them differently, is this only a matter
> of syntax. Just want to understand your view on it.

When syntax is context-sensitive (you need to look around more widely than just the local statement in order to parse something correctly), it can be handled by many tricks that may not _feel_ like they properly belong in a parser, because ordinary parsing techniques are best at handling context-free grammars, and often stumble on context sensitive constructs. A classic bad example is in good old humble C, where you cannot possibly tell "locally" (i.e., in a context-free way) whether 'x*y;' is to be parsed as "multiply value x by value y and ignore the result', or 'define y as a pointer to a value of type x'... it all depends on whether a 'typedef' for 'x' is in scope; a C compiler typically kludges around that by incrementally maintaining a symbol table during parsing and having the parser (indeed even the lexical scanner!) rely on that. Similarly, you could use an incrementally maintained symbol table to deal with Ruby grammar's context-sensitivity (and there may be other good approaches, such as compiling "lookup name y" to different operations/bytecodes depending on whether y is allowed to be either variable or method, must be a method, or must be a variable).

Still, even though some parsing kludge or other can almost always be found to work around parsing problems with context-sensitive syntax, one good thing about context-free syntax is that it makes things easier for a human reader: an expression or statement can be parsed by the reader WITHOUT needing to study potentially-unbound amounts of context. Being able to parse the code unit may of course not tell the reader all they'd like to know -- e.g., even if one knows that "x=y" syntactically means "bind a reference &c", it may still be useful to know what, *semantically*, y is expected to refer to at this point. Still, the ability to parse the code is a good start, and sticking to context-free grammar helps with that;-).


> BTW, I did not say there is no reason I like Ruby that is,
> essentially, a syntactic difference with Python. Of

And I never said you didn't: on the contrary, most examples you gave ARE such syntax differences.

> course, some things reduce to syntax, but all
> hardly do.

Bingo! That's exactly why I said MOSTLY instead of saying ENTIRELY. I understand that you have no personal experience with something known as "common sense", but I earnestly assure you that anybody with even the slightest touch of it would not feel a need to keep repeating the very point I make even while trying to attack me (be it with ferocity, as previously, or with attempted sarcasm, as here).

> Is single versus multiple inheritance a matter
> of syntax?

No, of course: this is an actual semantic restriction of Ruby when compared to Python. Most people program in Python, most of the time, with single inheritance and maybe a touch of mixins, as you can have in Ruby; but when some rare situation really calls for "full" multiple inheritance, it's right there -- not just in syntax, but in semantics -- like in Lisp, Eiffel, or C++. I do understand somebody preferring a language which lacks a powerful tool that is rarely required, of course.

> Are closed versus open classes a matter of
> syntax?

Of course, what else? I explained the Python syntax you need to use in order to add a method to an existing class in my very first post to this thread, and I quote: "you have to 'def' the method's function and then assign it to TheClass.methodname" (I did that in the context of explaining that this is one of the few cases where I like Ruby's syntax choice over Python's).

For example, consider the example at http://www.rubygarden.org/ruby?AdaptorPattern where a radius method is added to existing class SquarePeg:
class SquarePeg
def radius
Math.sqrt( ((width/2) ** 2) * 2 )
end
end
I think this syntax is wrong and they mean @width, but, hey, THEY are the Ruby experts, I'm just copying and pasting;-).

The normal Python syntax for this would be:
def radius(self):
return math.sqrt(self.width**2/2)
SquarePeg.radius = radius

Some would prefer a different syntax in Python:
SquarePeg.radius=lambda self:math.sqrt(self.width**2/2)
but I find the normal def+assignment more readable.

What else are we seeing here, except for syntax differences and variations, pray?

> You are the one who said it's pretty much a matter
> of syntax,

If you're referring specifically to the two languages' different approaches to "how do I add a method to an existing class", I did in fact say it's JUST a matter of syntax, and I have just shown an example.

> among other things, of course. My argument is
> that saying it's a matter of syntax obscures some
> important points.

What "important points" does it obscure to mention that Ruby's "open classes" vs Python's "assign function to class attribute" IS indeed a matter of syntax?

If you're referring to the overall language difference between Ruby and Python, saying it's JUST a matter of syntax would be a tad too strong, but saying it's MOSTLY syntax, or NOT MUCH MORE than syntax, which are exactly the phrases I used, is smack on target. In my posts in this thread, and otherwise, I have repeatedly mentioned some other minor differences, for example that [Ruby's] "inheritance is single (most will hate this, some will love it)", and also the "philosophical difference" as well as my hope that pragmatism by sensible people on both sides makes the latter nearly irrelevant.

> I think you should be careful about saying it.

Considering your over-the-top hostile reactions, and the sarcasm you so unsuccessfully you attempt now, it's obviously useles, where YOU are concerned, for me to use my habitual large amount of care in expression (saying ALMOST all, *not* ALL; saying MOSTLY, not ENTIRELY; saying NOT MUCH MORE, *not* NOTHING MORE; and so on, and so forth): I am describing exactly and precisely my observations, preferences, and opinions, and yet you take fire like a short-fuse ballistic rocket. Clearly, thus, you are a hopeless case, and your recommendations are just as useless as the rest of your rants or your feeble attempts at irony.


> And, lest we forget, you were responding to Bruce, who I
> think should be taken to task for labeling a broad group
> of people as hyper-enthusiasts in a derogatory fashion.

I think he is quite accurate in his characterization of some people who show over-enthusiasm for some "new" technology or other, yet are quite prone to jump from one to the next. He never said nor implied that the characterization applies to ALL who like Ruby -- and I'm sure, for example, that he holds Andrew Hunt in just as much esteem as I do -- it really takes a warped brain like yours to misread Bruce's well-expressed words in such a distorted way.

> For whatever reason, you don't feel compelled to castigate
> Bruce for what he says,

What about the fact that he's said things I may agree with, and has expressed them with his usual precision and elegance, in any case?

> but you are no-holds-barred in
> your over-wrought, emotional, egoist tirade against me. Am

Well, YOU are the one who attacked me personally, insulted me, and even claimed I deserved being slapped, a claim for which you have now ``apologized'' only in a context of weak, sadly misfiring irony and sarcasm. Does it surprise you that personal attacks like this can easily make the people you're assaulting, and their friends, into sworn enemies of yours, *most particularly* when they are so utterly baseless and unjustified as I've carefully them to be, over and over again, not least in this reply...?

> Ruby. I'd like to point out something about blocks: with
> Python, you either have to nest definitions of functions,
> or pass some number of args to get the value of the
> "closure" that you get with Ruby blocks. To me, this can

You can equally well pass args to Ruby blocks as to Python functions, that's a wash. Instead of writing the "block's" code in braces or do/end right after the call to which you want to pass the block, you write the code in a def just BEFORE the call, then pass it in the call. E.g., it's:

j=23
zip.zop(1,2,3) do |i|
i+j
end

versus

j=23
def _block(i):
return i+j
zip.zop(1,2,3,_block)

or, as lambda-lovers would have it (not me...),

zip.zop(1,2,3, lambda i:i+j)

The "closure" effect is the same in both cases -- variable 'j' defined "outside" the block is visible "inside" it. The one non-syntax difference (that doesn't show in this case) is that if the block assigns something to j this directly affects the "outside" variable, while in Python it would HIDE it and define a new local variable. One more example of the fact that Ruby's not "afraid" of context-sensitivity: inside a block, "j=55" means "j is a local variable bound to value 55" *IF* there is no OUTER variable named j, but if there is it means "rebind outer variable j to 55". Inside a Python function, "j=55" defines a local variable, period, no need to look at surrounding context ((save for the deuced "global" statement, which I've often mentioned as the worst aspect of Python;-)).

> become significant. One, the value of an anonymous bit of
> code is high. I don't have to worry about naming it, or

I never could understand this obsession with anonimity, though it's shared by a highly vocal minority of Pythonistas currently fighting to make "lambda" remain in the language.

Naming a "throwaway" object, such as a local function or a loop control variable, never caused ME any worry in my life...

> how that might impact my interface, because the real focus
> is on what the code does, not the function identifier.

Use a function-name starting with underscore ("private" by Python convention) and nobody will FOCUS on it at all;-).

> It seems that you realize this, from what you wrote. So,
> while you may be able to accomplish the same thing in
> Python, it's definitely not as simple. This is a

It's TRIVIAL, except for the ability to rebind local variables of the surrounding scope, and that of having anonymous blocks that aren't just expressions -- which aren't "make-or-break" language features.

> difference that may be huge or small, depending on the
> context. It's a difference that is important and

It's TINY, therefore it's NOT important at all.

Anybody so crazy as to base their language choice, EITHER WAY, solely on "X lets my block be anonymous, Y requires me to name them", instead of pragmatics (richness and availability of libraries, tools, ports -- performance characteristics -- etc etc), as I've been advocating in this thread, would be making a really weirdly-based choice.

If a specific guy know he's so utterly idiosyncratic that such minutiae, rather than pragmatic considerations, are going to drive his choices, he really has no alternative to studying every single minute, obscure, microscopic language detail (and specific language versions, too, because such things may well change in minor versions) -- who else but such a weirdo could possibly predict that, say, he's liable to fall so madly in love with Python's 3-argument 'pow' (i..e, pow(a,b,c) meaning the same as (a**b)%c) that they will refuse to use any other language evermore?-) To most people, it's a tiny thing, relevant only if you do a LOT of modulo-arithmetic [it allows super-fast implementation of "raising to power" even when b is huge, as long as c is reasonably small -- hardly an issue most programmers CARE at all about...]. Minutiae such as the ability to keep blocks anonymous, rebind outer-level local-variables, or even having full multiple inheritance, are roughly at the same "most people, quite sensibly, care microscopically much" level of importance, i.e., close to nothing.

This is completely different from comparisons between, say, Java and Python (or Java and Ruby, or C# and Python, etc). Here, the dynamic versus static typing makes the choice much more important (and, unless you have strong opinions on this specific issue, difficult); syntax considerations are the least of your worries (and in many cases, funny enough, so are pragmatics, since if it's the pragmatics of running on JVM or CLR that you crave, Jython or IronPython [and, I imagine, the Ruby equivalents to those] let you have those pragmatics while using Python as the _language_...!-).


> shouldn't be obscured by someone saying it's all a matter
> of syntax. I'm pleased to see that Python will be
> implementing "blocks" of the type Ruby has. I think Python
> will be a better language because of it.

I'm not sure where you got this impression, not even of what exactly you mean by this "Python will be implementing blocks of the type Ruby has", but I'm pretty certain you're most likely entirely wrong in this matter.


> I'm glad Guido won't be removing map or filter. I

Again, I fear you've been misinformed; for the current plans, see <http://www.python.org/peps/pep-3000.html#built-in-namespace>
(of course, what will happen is that they'll be moved away froM *built-ins*, since LCs and genexps do essentially the same jobs; they may well move into a suitable 'functional' module in the standard library).

> regular expressions are first-class objects, and variables

They are first-class objects in Python, too -- assign them to any variable, pass them as arguments, put them in containers, return them from functions, and so on, and so forth. You use re.compile to *build* re objects, just like, say, you use array.array to build array objects, set to build set objects, etc, etc.

Maybe you mean that what you appreciate is that in Ruby regular expressions are *built-in*, so you don't need to import anything, and may use global variables such as $~ and $& and $' (etc) to study a match.

Of course, though this enrages you, this IS a syntax level distinction, you know;-).

> a difference that could be highlighted because it could be
> important to someone.

Everything could be important to someone, if that someone is enough of a weird fanatic; therefore, by your reasoning, any comparison between two languages must consist in posting the entire reference manuals for both languages, and presumably their libraries too. *PUH-LEEZE*.


Alex

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 7:51 PM
Reply to this message Reply
Alex Martelli wrote:

> I understamd that reading comes very, very hard to you,
> poor dear, but DO try harder, please. My first mention of
> syntax on this thread was in the phrase "almost all the
> syntax choices". See that little, innocuous word
> *ALMOST*, baby? It *modifies* the meaning of the
> following "all", asserting that there ARE one or more
> counterexamples. Here, I was discussing my preferences,
> rather than the nature of differences (syntax) vs
> otherwise; specific examples I gave in the same paragraph
> covered both syntax cases in which I preferred Ruby's
> choices (more rigid capitalization, dollar stropping for
> globals, "open classes" syntax of which more later) and
> non-just-syntax ones (the flexibility of blocks).
>
> Other posters have argued that blocks are also just a
> syntax issue, but there ARE also non-just-syntax
> differences, e.g what code is allowed to rebind which
> variables. Admittedly, this isn't a big practical
> problem; to quote Ian Bicking, "Syntactically Ruby is
> better in this respect; Python's functions are not as
> convenient as Ruby's blocks, though they are mostly
> equivalent in functionality". Again, note the word
> MOSTLY; it IS important.
>
> Just as when I use the same word in another post of mine
> to this thread: "the difference is mostly one of syntax
> sugar". Get it? MOSTLY, not ENTIRELY.
>
> So, if from among your many favorite lies you might be so
> exceedingly courteous as to remove this particular idiocy,
> that I ever said that it's ALL (as opposed to MOSTLY0 a
> matter of syntax, that would be a big, bold step forward
> for you; why, a few thousand big steps like that, and the
> kind people in the white smocks might even start consider
> taking you off a few of your meds, and wouldn't that be
> swell?

...and on and on, miles and miles of frothing-at-the-mouth ranting...

I just wanted to distance myself here from Alex Martelli's posts, for the simple reason that my name is also Alex, and I've been activelly participating in this thread.

Please, try and make an effort not to confuse the two Alexs:-)

Thanks.

Alex Bunardzic

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 8:03 PM
Reply to this message Reply
> somebody has to say it: this is what justifies COBOL.
> moreover, enterprise java systems are largely
> y indistinguishable from COBOL. most signifcantly, java
> folk try (with undue success, alas) to turn RDBMS into
> VSAM files. it's a shame. but, in the final analysis, a
> java bean isn't much more than a COBOL COPYBOOK. sad.
> java had such promise. the bean paradigm just hasn't
> t much to do with OO.
>
> on the other hand, one might argue that the UI language is
> irrelevant. the UI can be generated from the RDBMS, whose
> constraints are fully readable. whether the UI is Ruby,
> java applets, html|css|javascript, it's all just an
> artifact of the data constraints.
>
> of course, the closet COBOL-ers really, really love to
> read-a-record(object)-write-some-output, rinse and repeat.
> well, then let's just do sequential batch processing
> ng like we (well some of us) did in the 60s. yeah, that's
> the ticket.

Hey! Don't dis what is, after all, bread-and-butter for many programmers in the world today.

What's wrong with reading a record, writing some output, rinsing and repeating? Isn't this exactly how all financial, HR, payroll etc. applications work?

I've spent more than 7 years teaching COBOL programmers how to make the transition to Java. For corporations, it turned out to be cheaper to run their business on *nix than on mainframes. Consequently, the big migration path was set to make sure that COBOL programmers make the transition to *nix without having to become really technical. Java was just the perfect medicine for that.

It worked beautifully, so what's wrong with that?

I shudder to think what would've happened if, 10 years ago, the guys in the corporate ivory tower made the decision to replace COBOL with Ruby. It would've been a veritable disaster. Not because Ruby itself is not well suited for replacing COBOL, but because COBOL programmers are not well suited for grasping Ruby. In my 7 years teaching career, I can't recall even a single COBOL programmer who truly managed to master the OO concepts. Today, these people write mostly procedural code under the thin veil of Java's 'objects'.

Can you imagine how much traumatic the transition would've been to Ruby? In Ruby, it would be much harder to smuggle procedural code under the cloak of objects.

So please, let's be realistic and allow Java its important place in the history of corporate computing.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 29, 2005 12:10 AM
Reply to this message Reply
> Still, even though some parsing kludge or other can almost
> always be found to work around parsing problems with
> context-sensitive syntax, one good thing about
> context-free syntax is that it makes things easier for a
> human reader: an expression or statement can be parsed by
> the reader WITHOUT needing to study potentially-unbound
> amounts of context. Being able to parse the code unit may
> of course not tell the reader all they'd like to know --
> e.g., even if one knows that "x=y" syntactically means
> "bind a reference &c", it may still be useful to know
> what, *semantically*, y is expected to refer to at this
> point. Still, the ability to parse the code is a good
> start, and sticking to context-free grammar helps with
> that;-).

Well, Alex Martelli, I disagree with you. I don't find that you will pragmatically have to study a potentially unbounded amount of context to understand whether the attribute is a method or not. And since both Python and Ruby are dynamic, you won't necessarily know by looking at the code that y in x=y is a "value" or a callable (to use, I believe, the Python word for it). A callable is different, fundamentally, because you need to call it to get what most people want, I think, from it: the value computed by it (generally speaking and not being concerned for the moment about distinctions between "functions" and "procedures"). Even in C, it is much more common to call a function, than to reference it. Therefore, to me, it makes more sense that naming a method, as in obj.method, calls it.

But again, this is potentially an interesting distinction between the languages, and the consequences of it are of, perhaps, more import than a dry ivory-tower discussion might uncover. I think that the method calls without parentheses are used quite effectively, and a little easier on the eyes, in DSL's and even with Ruby module functions like:
class Foo
attr_reader :bar, :baz
...
end

> The normal Python syntax for this would be:
> def radius(self):
> return math.sqrt(self.width**2/2)
> SquarePeg.radius = radius
>
> Some would prefer a different syntax in Python:
> SquarePeg.radius=lambda self:math.sqrt(self.width**2/2)
> but I find the normal def+assignment more readable.
>
> What else are we seeing here, except for syntax
> differences and variations, pray?

Well, there is the little difference that now radius is a bound symbol in that namespace in Python. Ruby's way is simpler and cleaner, and results in a more clear conceptual landscape when it comes to classes.

> I never could understand this obsession with anonimity,
> though it's shared by a highly vocal minority of
> Pythonistas currently fighting to make "lambda" remain in
> the language.
>
> Naming a "throwaway" object, such as a local function or a
> loop control variable, never caused ME any worry in my
> life...
>

Well, perhaps your inability to understand why others find anonymous functions so useful explains why you so quickly trivialize them in discussion. The fact that you do doesn't make it so.

> Use a function-name starting with underscore ("private" by
> Python convention) and nobody will FOCUS on it at all;-).

And this is one place where Python really shines. I mean, implementing scope with underscores, double underscores, name mangling, whatever. The problem is dictionaries, probably; although, I'm no expert ;) Just don't look at the functions that start with an underscore. *roll eyes* Now, that's a feature, right?

>
> > It seems that you realize this, from what you wrote.
> So,
> > while you may be able to accomplish the same thing in
> > Python, it's definitely not as simple. This is a
>
> It's TRIVIAL, except for the ability to rebind local
> variables of the surrounding scope, and that of having
> anonymous blocks that aren't just expressions -- which
> aren't "make-or-break" language features.
>
> > difference that may be huge or small, depending on the
> > context. It's a difference that is important and
>
> It's TINY, therefore it's NOT important at all.

Well, Alex Martelli says it NOT important; I guess I'll just quit worrying about it.

Again, I disagree that the difference is so trivial. The fact that the closure in Ruby ensures that an assignment to a variable that exists outside the scope of the block is altered by an assignment in the block firmly places that block within the context of the surrounding code where, I believe, it most properly belongs conceptually. And, it is useful in a nontrivial way. You have argued for understanding code in context being so important, but here you seem to trivialize it. Arguments with you seem mostly ad hoc justifications of whatever way Python does something.

> I'm not sure where you got this impression, not even of
> what exactly you mean by this "Python will be implementing
> blocks of the type Ruby has", but I'm pretty certain
> you're most likely entirely wrong in this matter.

I don't know. PEP 342, 343, both, neither? All I want to do when I read a PEP is weep. I'd rather read Japanese any day. Even without having studied the language, I'm sure it would make more sense. But if we just repeat 'Python is simple' long enough, I'm sure we can even convince ourselves of it.

> They are first-class objects in Python, too -- assign them
> to any variable, pass them as arguments, put them in
> containers, return them from functions, and so on, and so
> forth. You use re.compile to *build* re objects, just
> like, say, you use array.array to build array objects, set
> to build set objects, etc, etc.

But you can't do:
puts "Alex Martelli is a boob" if "boohoo" =~ /oo/

> If you're referring to the overall language difference
> between Ruby and Python, saying it's JUST a matter of
> syntax would be a tad too strong, but saying it's MOSTLY
> syntax, or NOT MUCH MORE than syntax, which are exactly
> the phrases I used, is smack on target.

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.

The features differences in Python and Ruby are more than a point by point comparison of syntax and a few side issues that you say are hardly important. There is this concept of Pythonic out there that people feel and try to capture in a concrete way. Similarly, it is reasonable to assume there is a similar flavor to Ruby. The import of this is not so simple to figure out.

What I see, Alex, is that you are committed to Python and would prefer to obscure rather than emphasize difference between it and Ruby. That's great. And it would be great if everyone who came across some advice had perfect knowledge so they could easily evaluate its merit on their own. Sadly, that's not the case. So, to me, it's important for people to pull away the rug when someone like you prefers to sweep the difference under it and obscur them, all with the overt air of an even-handed comparison.

Alas, someone of your stature I would presume to be more able to handle criticism. Not so. As someone mentioned, we hardly build fortresses around our strengths.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 29, 2005 5:27 AM
Reply to this message Reply
> @Alex
> > ... or, rather, whether it's Ruby as a
> > whole which, net of technical considerations, should be
> > entirely avoided in order to eschew the risks of
> > entanglement with a horde of crazed face-slapping
> zealots.
> > I'm listening, and I'm sure I'm not the only one, but,
> > , even if it was just me...:
>
> The thing about this entire discussion is that it kind of
> makes my point: the people who were formerly
> hyper-enthusiasts about Java have moved to Ruby. The
> comments from Ruby folk seemed to be mostly, "The fact
> that you haven't said Ruby is the most wonderful thing in
> the world, and is the solution to all problems, and that
> anything Ruby does (such as provide multiple names for
> idential operations) isn't by definition the superior
> solution -- well, I take this as a personal insult and
> pass gas in your general direction!" (that latter, by the
> way, is a reference to a Monty Python sketch, and is
> something we often do in the Python community to lighten
> things up. Perhaps if Ruby adopted its own comic theme
> then that community could follow suit).
>
> These comments seem to take anything except
> hyper-enthusiasm about Ruby as a personal affront, and I
> think make my case for me. I have said that Ruby and Rails
> are making contributions to the programming community, and
> I still think that. But as Alex pointed out, the ferocity
> of what we've seen here of the community doesn't draw me
> in. In contrast, the people commenting about both Java and
> Python have had, to me, a reasonable perspective, and have
> argued with examples and experience rather than on faith.

The ferocity seen here is weird. I have a sgrong aversion to using technology produced by a community that conducts discussion in a defensive unpleasant fashion. I remember "checking out of" the JBoss project after exasperation at the regular dramas that seemed to accompany thatt one project. That choice eft me no second doubts.

The argumentativeness I have observed in this diuscussion has come from both sides as has the defensiveness. My limited exposure to Ruby (eight trivial programs over three years) left me with mixed feelings about the lamguage: enthusisam about the possibilities and frustration about the difficuty in getting questins answered or how immature technologies have a shortage of reasoned documentation. WHen peopel ar efighting for a technology to erxist its hard to also be honest about its failures. Its easy to criticize Java because Java has won. I haven't seen the same defensiveness in Ruby mailling lists ro newsgroups so I'd be hesitant about drawing the conclusions you draw about the sociology of the "Ruby phenomenon."


> It's too bad. As I've said, I think some very interesting
> things are going on in the Ruby world. The book by "Why
> the Lucky Stiff" is one of the most creative things I've
> seen; it's really wonderful. And Rails appears to have
> forced people to really rethink what the essence of web
> programming is about. And some aspects of Ruby appear to
> have simplified some things that we may not seen that way
> before. All good things.
>
> I will continue to try to learn Ruby by bits and pieces.
> But from what I've seen here, I have to be rather careful
> about where my information comes from. Yes, I know Alex
> and I know how careful he is, so I will trust his
> comparisons between Ruby and Python. I hope that he will
> do more such comparisons, but because of the comments made
> to him here I wouldn't be surprised if he doesn't.
> I am certainly less inclined to study and write
> about Ruby based on what I've seen here. This, I think,
> ends up being counterproductive to the Ruby community.
>
> And although I criticized some of Bruce Tate's work, I
> still got more information from his book than I've gotten
> from the comments posted here. He at least argued for Ruby
> based on its merits.
>
> I have to agree with Alex; the comments posted here have
> not encouraged me about the Ruby language community, and
> I've learned that the community is what makes the biggest
> difference to me, because those are the people you are
> going to have day-to-day contact with, and will decide
> whether you want to go to the conferences, etc. My
> experience with the Python community has been of a group
> of people who are thoughtful and generally treat people
> well. And who are generally happy with themselves and the
> people around them.
>
> The impression I'm left with from the comments posted here
> is of the difference between going to a British soccer
> match and going to Burning Man. Maybe a British soccer
> match isn't all that bad, because after all people still
> seem to attend, but from what I've heard -- including
> first-hand accounts -- it's not something I'd want to go
> to. Even if the police do search people for weapons
> on the way in, the fact that they have to makes it
> seem like more of an aggressive place than I want to be.
> I'd rather go to Burning Man.

Phillip J. Eby

Posts: 28
Nickname: pje
Registered: Dec, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 29, 2005 9:46 AM
Reply to this message Reply
> What I see, Alex, is that you are committed to Python and
> would prefer to obscure rather than emphasize difference
> between it and Ruby. That's great. And it would be great
> if everyone who came across some advice had perfect
> knowledge so they could easily evaluate its merit on their
> own. Sadly, that's not the case. So, to me, it's important
> for people to pull away the rug when someone like you
> prefers to sweep the difference under it and obscur them,
> all with the overt air of an even-handed comparison.

Um, I read your list of things you liked better about Ruby, and about each one of them had reactions of the form, "So what?" or "But I like the Python way better." I haven't seen you yet propose any reasons why the things I *like* about Python are bad, or why blocks are actually better than functions outside of extremely rare situations, etc.

I've got nothing *against* Ruby. But I don't really see what's going *for* it, except that it appears slightly easier to create readable DSLs (domain-specific languages) in Ruby, due to the availability of blocks and implicit calls. That's the only place where Ruby seems to have a *real* benefit over Python.

If you want to sell Ruby to Python developers, I'd say you should focus on that strong point; a *lot* of the things Ruby advocates say about Ruby are, from a Python developer's point of view, just plain wrong and/or FUD, like the "Python's not OO" nonsense or the "we gotz the open classes and Python don't" fallacy. And a lot of the rest are unattractive to many Python developer for other reasons; e.g., explicit "end" looks redundant to me, and Ruby's magical hidden parameter seems too confusing to me.

These are not "Python is better than Ruby" arguments; these are, "Give me reasons to switch that appeal to *me*" arguments. Presumably, most of the people who like the things you like about Ruby have already switched. The rest presumably either don't like the same things, or don't care enough to invest the time to switch.

So, if you want to win over Python developers, you should emphasize Ruby-embedded DSLs like Rake. Make more of them, and highlight how Ruby's syntax choices trade off in the direction of allowing better DSL creation, so that it's worth dealing with Ruby's idiosyncracies (as seen from a Python programmer's POV).

Flat View: This topic has 262 replies on 18 pages [ « | 11  12  13  14  15  16  17  18 | » ]
Topic: The departure of the hyper-enthusiasts Previous Topic   Next Topic Topic: Java Applets + Ajax = ?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us