The Artima Developer Community
Sponsored Link

Weblogs Forum
The departure of the hyper-enthusiasts

262 replies on 3 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 3 pages [ « | 1 2 3 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 21, 2005 3:30 PM
Reply to this message Reply
Advertisement
> > As a developer, you are in the role of a technician not
> a
> > user.
>
> See, I disagree with that, right off the bat. Seems like
> all the possibilities of having a meaningful dialog with
> you end right here.

I didn't ever think I could really have a meaningful dialog with you. I'm just mocking you. Your entire premise is foolish and so is your argument for it.

> > What would you do if asked to write in
> > assembly? Curl up in the corner and weep?
>
> No,I would tell the person who asked me to do that to go
> fly a kite, or take a hike (or, I'd tell them to go to
> hell, depending on the mood I'd be in on that particular
> day). I would never, ever, under any circumstances, stoop
> again to the level of writing anything in assembly. Same
> as I would never again use punched cards (believe it or
> not, I was using punched cards for my first information
> processing job back in 1987).

You mean 'punch cards' right? Why were you using punch cards in 1987? I was writing programs on a mac plus.

> Same as I would never use a kitchen knife as the only tool
> to build a bike shed.

Talk about faulty analogies.

> > No, no it doesn't. By defintion, in order for
> something
> > to be possible, it's only necessary that there be one
> way
> > to accomplish it. Having more ways t acomplish it
> doesn't
> > make it any more (or less) possible.
>
> Again, I feel like I'm talking to a machine. Is there a
> human being at the other line?

Is there a brain on your end? I tend to follow this paradigm, perhaps you've heard of it, called 'logic'. If you aren't familiar with logic (seems possible from your argumentation) you should definitely try to learn about it before debating.

> > You think this is a crucial part of the thinking
> process?
> > Are you kidding?
>
> As always.
>
> > > These things should not be confusing.
> >
> > They aren't. I can't fathom why you find them
> confusing.
> > Do you get confused when going to a public bathroom in
> a
> > a seafood resturaunt? "Buoys? Oh no, I'm so confused!"
> > How long do you sit there confused about this? If it's
> > s more than a couple seconds, are you stoned?
>
> Faulty analogy. Real world objects are not dimensionless,
> like the virtual ones are. Having physical dimensions,
> they are not confusing for the common-sense observer.

Nor is figuring out that you use size in one context and length in another. All language is dimensionless. My analogy was about a word, not a physical Object so your claims are, yet again, completely nonsensical.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 21, 2005 3:42 PM
Reply to this message Reply
> It's a kind of
> conservative closure by introducing a little redundancy
> just if a language permitted using both "and" and "&&" to
> assign a boolean operator.

This may not apply to your point but just in case, let's all be clear that & and && are not redundant boolean operators in Java. They have distinct meanings.

Marcelo Barbero

Posts: 5
Nickname: mbarbero
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 21, 2005 7:59 PM
Reply to this message Reply
> > Not being a "totally" English speaking human (that's to
> > say, I'm not a native English speaker), if I see two
> > functions: one called "size" and the other "length", I
> > would suspect that there may be a difference that I
> can't
> > see without reading the documentation. For instance,
> the
> > first time I saw that two functions mentioned, I
> thought
> > that "length" was like Python's "len", and "size" like
> C's
> > "sizeof".
> >
> > I think it's confusing.
>
> What you need to do is place the words in the context.
> Outside of the context, anything can be confusing.
>
> If, for example, you see the following two statements:
>
> 1. customers.size()
>
> 2. customers.length()
>
> would the above be confusing to you?

Yes, it would be, but maybe because I'm not an English native speaker. If I see two different words (or function names) I expect they do different jobs. I don´t know if they are EXACTLY sinonymous or not because I am not a native speaker. Do you see my point of view?

But maybe this is my problem (or fault... are they exact sinonymous?) because of my lack of understanding on a foreign language (mine is Spanish).

Shalabh Chaturvedi

Posts: 5
Nickname: shalabh
Registered: Jun, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 21, 2005 9:58 PM
Reply to this message Reply
Ruby is good for Python

Because it offers more proof that dynamically typed, loosely coupled languages can more productive in creating robust solutions than statically typed, stricter languages with deeply nested class hierarchies. Java and C# essentially lead us through the same path for tackling problems. One may be a better version of the other (I like C# more) but the methodology is very similar. In fact the release of C# only validated the Java-style methodology by emulating it (albeit offering a more productive way to follow it).

Enter Python or Ruby, both different from the Java/C# style. Both producing 'enlightening' expreriences in ever growing list of seasoned, fairly well known static-style developers (Bruce Eckel, Bruce Tate, Martin Fowler...). As the knowledge spreads, it pokes holes in the strong Java/C# meme in peoples minds. Then people start to explore and experiment, and discover the Python (or Ruby) productivity gain. Some may prefer one, some the other. Ruby, in the end, validates the fact that Java/C# style methods may not be the best for everything, something the Python advocates have been saying for quite some time.

(copy from my posting at http://www.advogato.org/person/shalabh/diary.html?start=46)

Neal Norwitz

Posts: 2
Nickname: neal
Registered: Jan, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 2:21 AM
Reply to this message Reply
> The person I want to hear from is the core Python expert,
> someone who knows that language incredibly well ...

Ok Bruce(s). I'm not sure I qualify as your "core Python expert". I'm a core Python developer, though: http://sourceforge.net/project/memberlist.php?group_id=5470

I've taken you up (well kinda), here are my rambling thoughts. http://nnorwitz.blogspot.com/2005/12/confessions-of-language-bigot.html

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 2:50 AM
Reply to this message Reply
> Again, I have to implore people to stop thinking like
> machines and return to thinking like humans.

You keep repeating this but I don't think I know what it actually means. As developers we are tasked with solving real world problems by mapping them to formal representations that a machine can execute. Depending on the problem, there are different aspects of the way machines work that we have to take into account (of course it's very important to know which aspects are irrelevant in a particular context). The value of our work lies in our ability to translate between these two worlds, so we have to be able to "think like machines" and think like those humans who are domain experts in a particular field.

I would argue that the productivity of using formal languages is not increased by introducing more redundancy and that introducing redundancy doesn't necessarily make these languages more human. As you yourself argue, our ability to cope with large amounts of information is very limited, so I don't see how redundancy helps if it doesn't reduce information overload elsewhere.

Using both size and length for the same thing makes it easier to guess but I for one would not rely on such a guess. I would try to find out what the difference is before I use it, and that would cost me a lot of time if this kind of useless redundancy was a predominant principle in a programming language (which it is not in Ruby as far as I can tell).

It's important not to confuse this kind of redundancy with the redundancy introduced by utility methods. This is not the debate about minimal interfaces. Utility methods are there to cover the most frequent cases. That is, they do something many people would have to write anyway. But I don't have to write length whenever I use size or vice versa. This is not utility, this is just bloat. It suggests a difference where there is identity.

We could have a discussion about programming languages that adapt to human language if Ruby would collect statistics about natural language use and automatically infer methods (names and semantics) according to those statistics. A programming language that tries to translate natural language into machine language. People have been trying these things for decades, without much progress. It's still worth doing further research in this direction. But this is a wholly different matter than having a plain old programming language pretending to be more human by duplicating methods under different names.

The one thing that has increased productivity most in the past 20 years or so has been the introduction of automatic memory management into mainstream programming platforms. It makes us more productive by taking something away, not by adding further names for it. Equally, relational databases take away the need for us to devise and manually optimize access paths, do index maintainance, make sure actions are atomic when they need to be, etc. Rule based systems infer facts so we don't have to express them. Dynamic method dispatch infers methods to call so we don't have to. I'm not aware of a single case where the introduction of additional names for the exact same thing has reduced complexity.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 3:08 AM
Reply to this message Reply
> Using both size and length for the same thing makes it
> easier to guess but I for one would not rely on such a
> guess. I would try to find out what the difference is
> before I use it, and that would cost me a lot of time if
> this kind of useless redundancy was a predominant
> principle in a programming language (which it is not in
> Ruby as far as I can tell).

Well said. I'd been trying to put a decent reply together to this spurious argument but you've said it all for me.

Lars Stitz

Posts: 2
Nickname: stitzl
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 3:10 AM
Reply to this message Reply
The "hyper-enthusiasts", as they are euphemistically called by the article, are no more (and no less) than a bunch of consultants who want to advertise their expertise in order to gain more consulting gigs. They are not that outspoken because they know more or are brighter than other developers, but because their blogs and websites like Artima or TheServerSide grant them the benefit of publicity promotion at no cost.

Now, as mainstream development has moved to Javaland for good, these consultants are not needed anymore. Everybody and their dog can write a good Java application that uses decent frameworks and OR mappers and thus performs well in most tasks. So, more enthusiastic propaganda for Java does not pay the bill for these folks anymore -- they have to discover a new niche market where their service is still needed. In this case, what could be better than a language that only few people know yet? Instantly, the consultant's services appear valuable again!

My advice: Don't follow the hype unless you have good reasons to do so. "A cobbler should stick to his last," as we say in Germany. Sure, PHP, Perl, Ruby, C# have all their place in software development. But they are not to replace Java -- for now. For this, their benefits over Java still are too small.

Cheers, Lars

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 3:37 AM
Reply to this message Reply
> > What would you do if asked to write in
> > assembly? Curl up in the corner and weep?
>
> No,I would tell the person who asked me to do that to go
> fly a kite, or take a hike (or, I'd tell them to go to
> hell, depending on the mood I'd be in on that particular
> day). I would never, ever, under any circumstances, stoop
> again to the level of writing anything in assembly. Same
> as I would never again use punched cards (believe it or
> not, I was using punched cards for my first information
> processing job back in 1987).
>

A little research sometimes goes a long way.

How about performing time-critical operations on a crappy
old processor? OK. you might say, well why do so when
better hardware is now affordable?

How about accessing Hardware instructions (operations of
which some Highlevel languages have no equivalent)?

In this case would it be reasonable to fire you after
you've given your stated response and the request had
come from your boss?

Szymon Drejewicz

Posts: 1
Nickname: fffreedom
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 5:28 AM
Reply to this message Reply
Bruce, I think you are goodselling-books-maker rather than guru for coders. People are moving to Ruby because that language is very practical. In other words, book about Ruby by Bruce Eckel should be titled "Thinking" :-) and there is no need to add " in Ruby".

best wishes
--
Szymon Drejewicz

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 5:44 AM
Reply to this message Reply
Sorry man its X-mass kind of slow so I went over this post
again and when I read the above, some team members thought
I was nutts coz I burst into tears laughing (I hadn't
initially read the whole post.

Quote:
"> Again, I feel like I'm talking to a machine. Is there a
> human being at the other line?
>"

You talk to machines??!! Do you live anywhere near a
mental institution?

"Common kom laugh with me, this is hilarious
don't you understand that kom?" (sorry I was talking
to my desktop, he's called kom).

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:17 AM
Reply to this message Reply
> Yes, it would be, but maybe because I'm not an English
> native speaker. If I see two different words (or function
> names) I expect they do different jobs. I don´t know if
> they are EXACTLY sinonymous or not because I am not a
> native speaker. Do you see my point of view?
>
> But maybe this is my problem (or fault... are they exact
> sinonymous?) because of my lack of understanding on a
> foreign language (mine is Spanish).

Thanks for bringing this up. I apologize for not being sufficiently sensitive to consider your arguments seriously enough the first time around. Now I think I see where your bafflement is coming from.

Back to our example. If we see the concept called 'customers' associated with the concept 'length', what conclusion do we draw from it? That 'length' refers to something an undertaker would be interested in once each individual customer from the collection 'customers' is dead? Undertakers view dead people in terms of their 'length', so that they can organize appropriate coffins for the ensuing funeral.

If that's how we see it, what would be the 'length' of a collection of customers? Their sum total, or their average 'length'?

Let's now look at the other side of our example, 'size'. What would the 'size' of a collection of customers indicate? Is it referring to their collective shoe size?

I bring these elaborations to illustrate how non-nonsensical purely machine-centric way of thinking would be in this context. Of course it doesn't make any sense to talk about 'length' or 'size' of 'customers' in any other terms but in terms of how many items (i.e. how many individual customers) there are in the collection called 'customers'.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:19 AM
Reply to this message Reply
> I bring these elaborations to illustrate how
> non-nonsensical purely machine-centric way of thinking
> would be in this context.

Oops, my mistake, the above should read 'non-sensical' instead of the double negation 'non-nonsensical'.

Owen Densmore

Posts: 2
Nickname: backspaces
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:38 AM
Reply to this message Reply
Its simple: As wonderful as Java is, it has grown to violate the 80/20 rule, or the "normal programs should be easy and hard ones possible" rule.

Enumerations, as they currently stand, are now just plain silly! Those who care which of the myriad lists and maps should be able to manage them, but for the casual program, just List and Map should be fine.

I can go on as can all of us, but the attempts to tame Java (Groovy, JPython, JRuby, PNuts, etc) have taught us that its time for Java 3.0 .. a sensible Java with the goal of serving simplicity, not specialists. (As a friend once said: I could whittle you a more friendly language than Java!)

Owen

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:14 AM
Reply to this message Reply
> Yes, it would be, but maybe because I'm not an English
> native speaker. If I see two different words (or function
> names) I expect they do different jobs. I don´t know if
> they are EXACTLY sinonymous or not because I am not a
> native speaker. Do you see my point of view?
>
> But maybe this is my problem (or fault... are they exact
> sinonymous?) because of my lack of understanding on a
> foreign language (mine is Spanish).

No they are not synonymous. Size is a more general term with no specific dimension. Length is a type of size relating to a single dimension. Size can be volume, length, area, or even related to abstract concepts e.g. the size of a problem.

For an array, length is equivalent to size as an array has one dimension in Java. My best guess as to why length is not used in regard to Lists is that they wanted to keep it consistent with the Map interface (Vector and Hashtable orignally) where length isn't as clear. What's the length of a Map? That's up for interpretation. Yes, they probably should have used size for the array too but it's really not that big of a deal.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:38 AM
Reply to this message Reply
> Its simple: As wonderful as Java is, it has grown to
> violate the 80/20 rule, or the "normal programs should be
> easy and hard ones possible" rule.

Which part of that rule do you think Java violates?

> Enumerations, as they currently stand, are now just plain
> silly!

How is that?

> Those who care which of the myriad lists and maps
> should be able to manage them, but for the casual program,
> just List and Map should be fine.

ArrayList and HashMap. All List and Maps are either Lists or Maps.

> I can go on as can all of us, but the attempts to tame
> Java (Groovy, JPython, JRuby, PNuts, etc) have taught us
> that its time for Java 3.0 ..

I agree but not because Java is untamed, rather, mistakes were made that can't be rectified without potentially breaking old code.

> a sensible Java with the
> goal of serving simplicity, not specialists. (As a friend
> once said: I could whittle you a more friendly language
> than Java!)

This I completely disagree with. How is Java unfriendly? It has a really narrow syntax. It may not be friendly to the hacker who expects the language to feel his meaning but it's friendly to those who have to work with other people's code.

This is the problem with the loosey-goosey syntax approach where everything goes. People will naturally fall into a subset of that syntax. If the rules are really wide-open, hardly anyone uses the same subset. This means there's effectively many dialects of the same language. I might understand your code with some concetration, but it's not like I understand my own code. For the most part, Java mitigates this problem greatly. When I look at a snippet of Java, I know what it does. I don't need to know what templates are used. I don't need to look for overloaded operators. I don't need to know what compiler is being used. It just read it and know what it means. That's simplicity.

Nicola Musatti

Posts: 2
Nickname: nmusatti
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:44 AM
Reply to this message Reply
[...]
> You talk like a machine when arguing the above point.
> Don't you realize that for all English speaking humans, it
> is obvious beyond a trace of a doubt that 'size' and
> 'length' of an array are equivalent? You should allow some
> meaning, some semantics to enter the picture when parsing
> a computing language statement. Allow yourself to go a bit
> beyond syntax.

No he does not, he simply has a different point of view from yours.

Moreover, it's not a given fact that 'size' and 'length' mean the same thing for a programming language's 'array'; they just mean what the language designer and/or library developer decided they should mean.

A reasonable interpretation could be:
- lenght is the number of items in the array
- size is the number of byte it occupies

So this redundancy comes at the expense of a little, but pointless effort from the part of the programmer. You call it beauty, I call it nuisance.

> This is exactly why we cannot compare Ruby with Perl,
> Java, C#, C++ et al. Those other languages are strictly
> formal. Ruby is common-sense oriented, and thus much less
> formal. Java, C# et al. are High Level Languages (HLL).
> Ruby is a Very High Level Language (VHLL). Comparing HLL
> with a VHLL is like comparing apples to oranges. It's like
> comparing Low Level Languages (an Assembler) to HLLs.

Just because it has two names for the same thing? You seem to forget that programming languages serve a different purpose than natural ones, and while this kind of redundancy may be fine in poetry, it is not so clearly advantageous in a programming language.

You like Ruby? That's absolutely fine with me, and although I don't know it I suspect there are more compelling reasons to appreciate it than it having two ways to find the number of elements in an array (in the C++ community the very same issue is considered an unfortunate case of bad design).

Pretending however that there are objective reasons to prefer Ruby to other languages only makes you appear as one of the hyper-enthusiasts (others would say zealots) Bruce wrote about in his original post.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:53 AM
Reply to this message Reply
> You like Ruby? That's absolutely fine with me, and
> although I don't know it I suspect there are more
> compelling reasons to appreciate it than it having two
> ways to find the number of elements in an array

Exactly. I have seen much more compelling arguments from smart people that made Ruby sound very interesting. This 'I can call the same method with two different names' argument makes it sound like a joke.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:53 AM
Reply to this message Reply
> You keep repeating this but I don't think I know what it
> actually means. As developers we are tasked with solving
> real world problems by mapping them to formal
> representations that a machine can execute. Depending on
> the problem, there are different aspects of the way
> machines work that we have to take into account (of course
> it's very important to know which aspects are irrelevant
> in a particular context).

This is a very nice description of what I would describe as a typical "thinking inside the box" attitude. Taking for granted that things are 100% already boxed-in for us and then rolling up our sleeves and tackling the given problem is indeed an activity that does not require sophisticated tools. In that light, all languages are, indeed, created equal.

Luckily, there are also other breed of developers, people who I'd like to call "thinking outside of the box" guys. These are the people who question the boxiness. They don't take things at a face value that easily.

Instead of taking the given problem and then working on solving it, the outside-of-the-box thinkers are more interested in examining the problem itself. Pick the problem apart. See if you can transform it into something else. Maybe in the process you'll discover that the problem is actually not there, that it was a false alarm, that somebody cried wolf in vain.

Or, by examining the given problem, maybe you'll discover some new, way more interesting and way more important problems. Then your solution will be that much more valuable.

Now, the big issue with the thinking-outside-of-the-box approach is that it really requires sophisticated tools. Java, C#, Perl, C, et al. won't be of much assistance there. These languages are not exploratory by their nature. They are run of the mill languages, for tackling run of the mill scenarios.

But that's not where our value as developers lies. Run of the mill stuff can be (and it already has been) solved by using run of the mill methods (such as code generators, be it the generators that run on local machines, or the generators that run on rupis in India).

> The value of our work lies in
> our ability to translate between these two worlds, so we
> have to be able to "think like machines" and think like
> those humans who are domain experts in a particular field.

Why not use the 'middle men' who will think like machines on our behalf?

> I would argue that the productivity of using formal
> languages is not increased by introducing more redundancy
> and that introducing redundancy doesn't necessarily make
> these languages more human. As you yourself argue, our
> ability to cope with large amounts of information is very
> limited, so I don't see how redundancy helps if it doesn't
> reduce information overload elsewhere.

You seem to be confusing qualitative aspects with quantitative aspects.

> Using both size and length for the same thing makes it
> easier to guess but I for one would not rely on such a
> guess. I would try to find out what the difference is
> before I use it, and that would cost me a lot of time if
> this kind of useless redundancy was a predominant
> principle in a programming language (which it is not in
> Ruby as far as I can tell).

This is because you've already been formally trained to think a la machine. What you've described above is exactly how a machine would approach the problem space.

> It's important not to confuse this kind of redundancy with
> the redundancy introduced by utility methods. This is not
> the debate about minimal interfaces. Utility methods are
> there to cover the most frequent cases. That is, they do
> something many people would have to write anyway. But I
> don't have to write length whenever I use size or vice
> versa. This is not utility, this is just bloat. It
> suggests a difference where there is identity.

Again, blurring quality with quantity.

> We could have a discussion about programming languages
> that adapt to human language if Ruby would collect
> statistics about natural language use and automatically
> infer methods (names and semantics) according to those
> statistics. A programming language that tries to translate
> natural language into machine language. People have been
> trying these things for decades, without much progress.
> It's still worth doing further research in this direction.
> But this is a wholly different matter than having a plain
> old programming language pretending to be more human by
> duplicating methods under different names.

You don't cure the disease by removing the symptoms. You cure it by removing the causes.

The problem is not in trying to force formal systems to behave informally. That would be ludicrous. Formal systems are cool, they are incredibly useful, they have their place, and there isn't anything dehumanizing about them. I would never argue that a great mathematician who thinks in strictly abstract, formal terms is thinking and behaving like a machine.

I don't know where you got this wrongheaded idea that Ruby is focused on trying to emulate natural languages? That was never the case, and never should be the case. I personally don't believe that mimicking natural languages would be a good approach to creating sophisticated programming tools. I firmly believe that programming is a strictly formal activity, and that it should forever stay that way.

What I was talking about is not the language, but the fundamental bias in thinking. You can choose to lean toward machine-centric world-view in your thinking, or toward human-centric world view. In both cases, you will remain confined to a strictly formal world of constraints, but your underlying bias would lead you in completely different directions.

Thus, a machine-oriented developer would naturally prefer using Java, C, C#, Assembler, because these languages reflect how the machines work. A human-oriented developer would prefer Ruby, because it reflects the way humans think (the way humans formally think, of course).

> The one thing that has increased productivity most in the
> past 20 years or so has been the introduction of automatic
> memory management into mainstream programming platforms.
> It makes us more productive by taking something away, not
> by adding further names for it. Equally, relational
> databases take away the need for us to devise and manually
> optimize access paths, do index maintainance, make sure
> actions are atomic when they need to be, etc. Rule based
> systems infer facts so we don't have to express them.
> Dynamic method dispatch infers methods to call so we don't
> have to. I'm not aware of a single case where the
> introduction of additional names for the exact same thing
> has reduced complexity.

Quantity vs. quality?



Posts: 1
Nickname: rexpop
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 11:00 AM
Reply to this message Reply
Good article. A couple of points worth making though:

- Part of the reason that there is less enthusiasm about Java is that the enthusiasm isn't really needed anymore. Java has established itself as enterprise programming language de-jour for non Microsoft shops and will remain so for the forseeable future. Ruby and Python don't tend to play much in this space and so won't have too much impact.

- As you correctly point out, most of the hyper-enthusiasts you talk about were most likely the Smalltalk crowd who seem to embrace any OO language that they feel might re-capture the glory days of Smalltalk. Once the next great OO langague comes along, they'll be jumping ship again.

- I agree with the points made that simple is better. However neither Ruby or Python really satisfy this mantra. Ruby code (like Perl) while terse can get really nasty to understand if you are not 100% familiar with the syntax. This makes mantainablilty a worry as new developers are transitioned in. Python is better in this regard.

- Rails has some great ideas, but its still immature and like Java 1.0 its advocates are promising the moon and the stars and it remains to be seen if it will move out of the web development niche and into a wider area.

Sam Gendler

Posts: 1
Nickname: ideasculpt
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:02 PM
Reply to this message Reply
I try to buy into the hype of the latest and greatest, but it always fails me, usually sooner rather than later. I've been doing web programming since 1996 or so, and I've used just about every technology available for doing so (except for ASP.net). I've written raw cgi in C and perl and apache modules in C. I was a very early adopter of Zope. I've written entire web servers. I've written a dynamic content assembly language that was built on top of the python C library. I've done several web projects in raw python. And I've done a fair amount of java, using a multitude of frameworks, mostly struts, but now a Spring/Hibernate/Tapestry combination.

The thing that ALWAYS seems to fail me when I use frameworks in the interpreted languages is SCALABILITY. Not just execution scalability, but development team scalability, too. At least with raw code, you can have as many programmers as you want on the project, you can use source code control, track revisions and bugs, and you can find talent in the labour pool that is familiar with your technology platform. Zope has never allowed easy (or any) integration with revision control, and it was a pain in the neck to work in for teams of developers, even when the bulk of the work was built as a pure python 'Product.' Ruby looks to have similar issues. And if you need a high performance web application that could scale across many hosts and databases reliably, forget it. Finding talented python developers, in general, can be a challenge, let alone finding ones with zope experience. The same issues are true of Ruby/Rails. It doesn't lend itself to team development, there is absolutely no scalability built into the system, and you will definitely find yourself writing a lot of buttress code yourself, as there is no ecosystem of available libraries and best practices in place. If you are at home building convenience apps for yourself, it isn't such a big deal to have to modify the development framework itself in order to get the job done. But when you are developing commercial software or services, the last thing I want to be doing is modifying my development environment to suit.

Rapid development platforms like Zope and Rails are great for workgroup apps that are developed by one or two people and which evolve slowly over time. They are a royal pain in the neck for robust enterprise wide or large public website development. Imagine building MySpace, or even my.yahoo in rails, for instance.

The same was certainly true of Java when it came out. I remember playing with Java in 1996 and being impressed with the language syntax and object orientation. Then i tried to write something that was fast in it and realized it was hopeless. It also didn't support functionality I needed, such as asynchronous I/O or Multicast until at least 2000. At the time, I was writing very high performance web and proxy servers for a fortune 500 company, and there was no way in hell that Java was up to the task. The same was true for a number of years. Even the whole J2EE thing didn't work that well for high performance apps initially, even if you didn't use EJBs.

Slowly but surely, however, the web development ecosystem was built up in Java (in large part by the efforts of open source developers. All the best java tools and frameworks are open source, in my opinion), and now, it is my platform of choice for large scale development, and nothing else comes close.

One of the early reponses mentioned Spring, and I have to say, the difference between web app development with and without Spring is extraordinary. Throw Hibernate into that mix and the Java platform is transformed. I can't imagine needing actual EJBs for the bulk of my projects. Not when Hibernate provides 90% of the EJB functionality, integrates will with J2EE features, and gives a whole lot more control over the mapping process than EJBs do. Sure, you still write a fair amount of code that you wouldn't have to in other languages, but it isn't an enormous difference (and I still code in vi, not with eclipse, so nothing is doing my typing for me), and it certainly isn't prohibitive. With Spring (and suporting frameworks) providing most of the connecting code for common patterns, DAO, transactions, logging via AOP, web service abstractions to the service layer, Hibernate providing ORM easily and effectively, and a clean ui framework (which I'm still waiting for. Tapestry gets the job done, but I'd rather see something like Wicket become fully mature. It's just not there yet), Java isn't lacking much over any other language. More importantly, it executes at least an order of magnitude faster than the interpreted solutions AND has very effective support for real clustering solutions.

Maybe eventually, something like Rails or a Python equivalent will catch up or even surpass Java's functionality for large scale development, but right now, they are no closer to being useful than Java was in 1998 or 1999.

So you talk about the hyper enthusiasts leaving, but the pragmatic programmers, who just want to get the job done as easily and effectively as possible are still relatively new converts to the language, as it is only recently that it has been worth getting enthused about. Prior to the first model 2 web frameworks (struts) becoming available, Java didn't offer enough functionality to make me leave the RAD environment of python or zope and it didn't offer enough performance to make me leave C/C++ programming behind for the high performance/scalable stuff. Now, the feature set is so much stronger than anything available in the C world that it is worth the very small execution efficiency disadvantage, which is irrelevant in any context I can think of, these days. That same feature set also makes it a great platform to jump to for rapid development. Sure, it isn't 100% as effective in that arena as something like Rails might become, but it is nearly there (with about the same margin there as Java has with C on the performance side), and it offers real scalability to boot. Right now, Java offers the absolute best of all worlds - developer efficiency, runtime efficiency, scalability, a large talent pool, and a ton of supporting software and I don't see that changing any time soon.

In late 1999, I thought Zope was going to revolutionize web development. It was so much better, faster, and easier to use than anything else out there - until you tried to solve a really hard problem with it, when it became a royal pain in the neck. The Z-shaped learning curve was no joke. I tried so hard to use it for several years and it almost always let me down eventually. At best, Rails is where Zope was in 1999 in terms of maturity, and it is not at all clear that it will ever have more of an impact than zope did. It's a really neat idea, but CAN IT SCALE???? I hope so, cause someday, I'd like to use it. For me, the last 2 years working mostly in Java have been revelatory, and I'm not going anywhere anytime soon.

--sam

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:16 PM
Reply to this message Reply
How about a more apt example. Suppose you have a String object that has both length and size. In this case it ambiguous. One may be the number of characters while the others is the number of bytes. There are many more variations, but the effect of having two methods is the impression that there is a reason for it, so one would imagain they are somehow different.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:28 PM
Reply to this message Reply
> How about a more apt example. Suppose you have a String
> object that has both length and size. In this case it
> ambiguous. One may be the number of characters while the
> others is the number of bytes. There are many more
> variations, but the effect of having two methods is the
> impression that there is a reason for it, so one would
> imagain they are somehow different.

Sorry, the example is faulty. The size/length example is applicable only to array. Anywhere else it would be insane to shove it like that.

That's the thing -- avoid foolish consistency. Just because Rubyists like the size/length dubiosity in an array, doesn't automatically mean that now it should start popping up anywhere.

Now, if machines were designing the language, and if they came across this useful little thingy, they'd probably think in a linear fashion, similar to your way of thinking, and would insist that we enforce this size/length everywhere. That would ve a perfect example of maintaining foolish consistency.

Luckily, Ruby creator was a guy who didn't think like a machine.

Sriram Sunder Raman

Posts: 1
Nickname: srirams
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:03 PM
Reply to this message Reply
> Sure, we've been refining the development process
> over that time and development techniques like the
> 'Waterfall Model' and procedural programming' have slowly
> given way to newer versions of the same things such as TDD
> and 'functional programming'. Underlying this though is
> the fact the developing software still requires a geek, a
> keyboard and unfeasible amounts of coffee coding in the
> same old commands.


I agree with your point in your post, however, functional programming has been around for a long time and (maybe even) pre-dates any of the imperative programming languages. Lambda Calculus is considered to be a functional programming language and dates to the 1930's. (it required coffee back then as well ;) )

Sriram

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:19 PM
Reply to this message Reply
> > How about a more apt example. Suppose you have a
> String
> > object that has both length and size. In this case
> it
> > ambiguous. One may be the number of characters while
> the
> > others is the number of bytes. There are many more
> > variations, but the effect of having two methods is the
> > impression that there is a reason for it, so one would
> > imagain they are somehow different.
>
> Sorry, the example is faulty. The
> size/length example is applicable
> only to array. Anywhere else it would be insane to
> shove it like that.

Instead of just making ad hominem attacks, why don't you explain when you make method synonyms and when you do? Calling it insane implies that there is some sort of logic behind when to do this. Though, it's interesting to note that 'insane' is a description that only applies to human (or animal) thinking. Machines can't be insance. So in your 'thinking like a human' strategy, insane thought shouldn't be excluded otherwise you are teetering towards machine like thought. I believe insane thought is very much a part of your approach.

> That's the thing -- avoid foolish consistency. Just
> because Rubyists like the size/length dubiosity in an
> array, doesn't automatically mean that now it should start
> popping up anywhere.

Ha ha! Dubiousity is a great word for your philosophy.

Dubiosity: (n.) The state of being doubtful; a doubtful statement or thing.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:25 PM
Reply to this message Reply
Sam Gendler, you've certainly got a lot of experience. Unfortunately, just like Bruce, you tend to speak on a topic you apparently do not know.

Does it scale? Hmm, according to this, http://www.oreillynet.com/pub/wlg/8274, "the second largest online record store in the world ( second only to Amazon)" is being rewritten to run on Rails. (But, you might want to double-check that as it's asserted by a Ruby-friendly guy; he might not be a source for accurate information.) Keep an eye out for scalability issues. And, have you seen http://www.basecamphq.com et al? The authors might be able to answer some questions about scalability.

BTW, Rails is a framework written in Ruby (http://www.ruby-lang.org). You write Ruby by putting Ruby code in files. You can put files in a CVS. In fact, it appears they use subversion for the framework.

Now when you get to actually using the framework, you, uh, write some more Ruby and some SQL and stuff. You put that into some weird objects called, uh, files. And of course, you can put those into, uh, a CVS. I use subversion, but I thing monotone and darcs look interesting, too. So, why exactly can a big team not work on a Rails project?

I too have written apps in Zope. Zope is unfriendly to CVS if you use ZODB. There is little merit in drawing more than the broadest comparisons between Rails and Zope.

I realize I'm being extremely sarcastic, but really, why not study up on a topic before talking trash discounting it. You might unduly misguide someone who mistakes your 'knowledge' and 'experience' for something of merit, although, you have apparently not learned much from them.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:57 PM
Reply to this message Reply
> Now when you get to actually using the framework, you, uh,
> write some more Ruby and some SQL and stuff. You put that
> into some weird objects called, uh, files. And of course,
> you can put those into, uh, a CVS. I use subversion, but I
> thing monotone and darcs look interesting, too. So, why
> exactly can a big team not work on a Rails project?

Not to speak for Sam but in general I would be apprehensive about devloping in any dynamically-typed language with a large team. I suppose you can avoid serious issues with lots of testing but it just seems very sketchy. I doubt that he thinking about source control. That's just a neccesary condition for team development. In no way is it a sufficient one.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 3:06 PM
Reply to this message Reply
James:

> Not to speak for Sam ...

I was specifically referring to this in Sam's post:

> Not just execution scalability, but development team
> scalability, too. At least with raw code, you can have
> as many programmers as you want on the project, you can
> use source code control, track revisions and bugs, and
> you can find talent in the labour pool that is familiar
> with your technology platform. Zope has never allowed
> easy (or any) integration with revision control, and it
> was a pain in the neck to work in for teams of
> developers, even when the bulk of the work was built as
> a pure python 'Product.' Ruby looks to have similar
> issues.

which, arguably I guess, was referring to the lack of versioning control with Ruby apps. Again, I assert Sam should know what he's talking about.

But you raise a good point: Could you tell me what makes you apprehensive about a team developing in a language that is not statically typed? In particular, for which errors introduced by lack of static typing would your behavior driven development fail to test?

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 3:29 PM
Reply to this message Reply
James:

An additional point, just because the tone of arrogance of your previous posts regarding Java is plain annoying:

Recently I had the great experience of interacting with Chase's newly redesigned credit card website. Can anyone guess in which language this 'enterprise' app is written? Upon logging in, I was greeted with a Java traceback at least 100 calls deep.

The error?--A method call on a null object. Now I realize that is different than a incorrect method call on a static type, but it was no less of a catastrophe for that enterprise Java app that could not render the page, not to mention the great embarrassment for those enterprise Java engineers as I looked at interesting details of the system revealed in that traceback.

The great benefits of statically typed languages and 'compile-time' errors are over-rated. Use good behavior driven development and learn about duck typing, then show me how your enterprise apps fail because your language doesn't support static types.

Jan Ploski

Posts: 8
Nickname: jploski
Registered: Aug, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 4:01 PM
Reply to this message Reply
> Ruby simply says: "Hay, 'length', 'size', same difference.
> I hear you. And I know what you mean!"

And then, one wonderful day, your code goes kaboom.
You still have some time to write a best-selling book
about Intuition-Oriented Programming (IOP) before it
happens! Or read up on why software makers more commonly
aspire to engineering than poetry. Good luck.

nikolaus heger

Posts: 1
Nickname: orthorim
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 6:48 PM
Reply to this message Reply
"It may be true that Ruby's metaclasses are easier to grasp and use than Python's, but Python has had the capability for many years."

This is not an argument that you can make when comparing languages. Anything is possible to do in any language - what is insteresting is how easy to use and grasp the feature is. It's all about how easy to grasp and use something is.

In this respect, I see the main weakness of Python: OO programming is awkward and full of exceptions and strange constructs like 'self'. Python is perfectly fine for OO programming - but awkward.

You can also see it this way: We hyper-enthusiasts move on when we see something better. Java was great when it came out, then Sun failed to improve it in any significant way. IMHO they have hit rock-bottom with the new syntax in version 5.
c# is tainted by de-facto MS ownership and really only an option for people who either believe in Mono or who are windows-only.
Python was amazing and clearly showed in great detail just how flawed Java was. Ruby then clearly showed Python's weaknesses.

If tomorrow something better comes out, I will be enthusiastic about it too. In the meantime, Ruby is it.

Marcelo Barbero

Posts: 5
Nickname: mbarbero
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 8:49 PM
Reply to this message Reply
> > But maybe this is my problem (or fault... are they
> exact
> > sinonymous?) because of my lack of understanding on a
> > foreign language (mine is Spanish).
>
> Thanks for bringing this up. I apologize for not being
> sufficiently sensitive to consider your arguments
> seriously enough the first time around. Now I think I see
> where your bafflement is coming from.

Thank you.

>
> If that's how we see it, what would be the 'length' of a
> collection of customers? Their sum total, or their average
> 'length'?
>
> Let's now look at the other side of our example, 'size'.
> What would the 'size' of a collection of customers
> indicate? Is it referring to their collective shoe size?
>
> I bring these elaborations to illustrate how
> non-nonsensical purely machine-centric way of thinking
> would be in this context. Of course it doesn't make any
> sense to talk about 'length' or 'size' of 'customers' in
> any other terms but in terms of how many items (i.e. how
> many individual customers) there are in the collection
> called 'customers'.

Would you think that customers.length or customers.size is not a machine-centric way of thinking?

If I have customers, and if I don´t misunderstand the meaning of the word, I would prefer "count()" or choose something better. It's the quantity of customers, not the lenght (or size) of an array or list.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:12 PM
Reply to this message Reply
> Its simple: As wonderful as Java is, it has grown to
> violate the 80/20 rule, or the "normal programs should be
> easy and hard ones possible" rule.

I still use the same java language features I always have. I still just write J2SE only code, don't touch J2EE. I wrote my own broker back in 1998, before there was a JMS or J2EE. It's a container based system that I can plug things into to solve problems that don't involved brokering. I created my own status monitoring and control software before there was a JMX.

The problems with J2EE are not indicative of any problems with J2SE. There are things that I don't like. But, I chose to change the language of programming in Java be recasting APIs into domain specific language. I fail to understand how come people think that Java or any other language should solve all their problems out of the box.

It's kinda like the stereotypical democrat vs republican in the U.S. The stereotype is that democrats think that the government should do everything for them. They depend on people looking out for them, and just can't manage to make a decision on their own. Whereas, republicans think that you should be able to plan and act for yourself. Again, that's the stereotype.

Having those kinds of skill is invaluable in sitations like natural disasters where you need to know to LEAVE!

I sense this kind of difference in software developers. Some just don't know how to decide that they need to take action. Others are like lemmings. They get into whatever line is moving the fastest, and smack their face against the wall with everyone else when that line reaches the end of the road. They don't look ahead and they don't look back.

They are just in line yammering about today...

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:53 PM
Reply to this message Reply
> Would you think that customers.length or customers.size is
> not a machine-centric way of thinking?

That's a damned good question, Marcelo. Again, context is king. The machine-obsessed engineers would jump head first into treating customers.size() in a machine-centric way. We already saw an example of that in this thread earlier today, when one participant insisted that, for him, customers.size() plainly means size of the customers collection expressed in bytes. Could anyone be more machine-like?

But people have been using concepts such as 'size' and 'length' long before they ever made those first primitive machines. So, no, I would not think that a concept such as customers.size() is a machine-centric way of thinking (unless you insist that it's exclusively about the size, expressed in bytes, of the computer memory occupied by the instantiated customers).

> If I have customers, and if I don´t misunderstand the
> meaning of the word, I would prefer "count()" or choose
> something better. It's the quantity of customers, not the
> lenght (or size) of an array or list.

I tend to agree with you, although I'd argue that 'count()' could be very misleading. To me, 'count()' indicates a command, as in 'go ahead and do something, like count things and maybe even report your findings somewhere'.

A syntax like 'customers.how_many()' would make more sense. Such method implies that nothing, aside from merely reporting back to the client how many customers there are in the collection, will take place upon sending the message.

A propos feeling antsy about sending a message whose consequences we might not fully understand, another thing that Ruby brings to the table and where it really shines is in supplying us with an exclamation point ('!') appended to the end of the message, if that message is not idempotent.

For example, in Ruby a message such as customers.triage! signals that the state of the customers collection is going to most likely change upon the receipt of the message. It could be that the triage! message is going to inactivate all the customers that haven't made any orders in the past year or so, or maybe some other, undisclosed business logic is going to take over.

So, if anything, we've been alerted by Ruby that we're about to attempt to do something potentially destructive if we go ahead and send the message with a '!' appended to it.

Getting back to the imperfections of the 'size' and 'length' messages, Ruby retains those slightly contentious terms simply as a concession to the inertia of typical programming community. The thing is, we've been using these concepts ('size' and 'length') for generations. By now, they are ingrained, warts and all. It would be utterly arrogant of Ruby to ignore the customs.

Peter Bowyer

Posts: 1
Nickname: reywob
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 2:20 AM
Reply to this message Reply
> in RoR, there is the concept/implementation called
> Scaffolds, in which the engine generates soup to nuts from
> the database schema. if you think about Model Driven
> Architecture or Database Driven Design, then RoR looks
> like a lightweight way to get there. Then you later find
> that the developer team view Scaffold as a throwaway.

That's what I can never understand. I spend a heck of a lot of time having to write forms to do CRUD (usually using PHP). This is what makes Django look so nice - a presentable, autogenerated admin area.

The hype of rails put me off, but I keep meaning to get back and have a proper look. However, lack of presentable CRUD forms will I think put me off, no matter how great the rest is - just because this is something every website I code needs!

Marcelo Barbero

Posts: 5
Nickname: mbarbero
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 2:44 AM
Reply to this message Reply
Alex, finally we agree. And you read my mind (I also thought that how_many() was better than count() in the same sense you point).

Thanks, you were very kind. I will take a look at Ruby.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 3:08 AM
Reply to this message Reply
>
> This is a very nice description of what I would describe
> as a typical "thinking inside the box" attitude. Taking
> for granted that things are 100% already boxed-in for us
> and then rolling up our sleeves and tackling the given
> problem is indeed an activity that does not require
> sophisticated tools. In that light, all languages are,
> indeed, created equal.
>
> Luckily, there are also other breed of developers, people
> who I'd like to call "thinking outside of the box" guys.
> These are the people who question the boxiness. They don't
> take things at a face value that easily.
>
> Instead of taking the given problem and then working on
> solving it, the outside-of-the-box thinkers are more
> interested in examining the problem itself. Pick the
> problem apart. See if you can transform it into something
> else. Maybe in the process you'll discover that the
> problem is actually not there, that it was a false alarm,
> that somebody cried wolf in vain.
>
> Or, by examining the given problem, maybe you'll discover
> some new, way more interesting and way more important
> problems. Then your solution will be that much more
> valuable.
>
> Now, the big issue with the thinking-outside-of-the-box
> approach is that it really requires sophisticated tools.

Not at all. It doesn't require any tools at all. That is, if you are willing to attribute any real meaning to "thinking outside the box" other than just recognising that it is one of those phrases frequently used by politicians and marketing people as a rethoric means to put themselves on the right side of an argument without actually saying something. You know, like "one size doesn't fit all" or "unleashing the power of xyz" or "following international best practices".

Anyway, if all you want to say is that one should not blindly solve a problem as presented but sometimes question the problem and why it is a problem in the first place, then I completely agree with you. This is pretty self-evident, isn't it? And it has nothing at all to do with programming languages.

> > The value of our work lies in
> > our ability to translate between these two worlds, so
> we
> > have to be able to "think like machines" and think like
> > those humans who are domain experts in a particular
> field.
>
> Why not use the 'middle men' who will think like machines
> on our behalf?

I'm afraid we are these middle men. If not, who are they?

> > I would argue that the productivity of using formal
> > languages is not increased by introducing more
> redundancy
> > and that introducing redundancy doesn't necessarily
> make
> > these languages more human. As you yourself argue, our
> > ability to cope with large amounts of information is
> very
> > limited, so I don't see how redundancy helps if it
> doesn't
> > reduce information overload elsewhere.
>
> You seem to be confusing qualitative aspects with
> quantitative aspects.

If you think about it long enough, you will come to a point where you will not be able to draw a clear line between quality and quantity. In general, that's probably a philosophical question. But with regard to languages and APIs, it's pretty obvious that quantities and quantitative distributions of syntactic and semantic language elements together constitute qualities of that language or API.

Quantitative differences can "leap" into qualitative differences. Just think about sound frequencies. If the wave length is too short or too long, we can't hear them any longer. To hear or not to hear is a qualitative difference caused by a quantitative difference. Equally, if company grows beyond a certain size, its processes will have to change qualitatively to cope with that growth. It's the same with the speed of growth, the speed of change, and so on. You get what I mean. So the amount of bloat in a language and its APIs, syntactic or semantic, does have a severe effect on quality.

> > Using both size and length for the same thing makes it
> > easier to guess but I for one would not rely on such a
> > guess. I would try to find out what the difference is
> > before I use it, and that would cost me a lot of time
> if
> > this kind of useless redundancy was a predominant
> > principle in a programming language (which it is not in
> > Ruby as far as I can tell).
>
> This is because you've already been formally trained to
> think a la machine. What you've described above is exactly
> how a machine would approach the problem space.

No, the urge to find out how things work is distinctly human. A machine would typically be perfectly happy to "know" that size() does what it wants. A machine would not start to wonder what it means that there is another method with a similar meaning of the word and why it's there.

> > It's important not to confuse this kind of redundancy
> with
> > the redundancy introduced by utility methods. This is
> not
> > the debate about minimal interfaces. Utility methods
> are
> > there to cover the most frequent cases. That is, they
> do
> > something many people would have to write anyway. But I
> > don't have to write length whenever I use size or vice
> > versa. This is not utility, this is just bloat. It
> > suggests a difference where there is identity.
>
> Again, blurring quality with quantity.

Whether or not an API contains methods with different names but identical semantics is a qualitative feature of that API. How many such methods there are is a quantitative measure. If there are a lot and we get bogged down by the bloat, it slips back to a qualitative issue at some point. As I pointed out above, quality and quantity are related in rather complex ways and connot be kept strictly apart.

> > We could have a discussion about programming languages
> > that adapt to human language if Ruby would collect
> > statistics about natural language use and automatically
> > infer methods (names and semantics) according to those
> > statistics. A programming language that tries to
> translate
> > natural language into machine language. People have
> been
> > trying these things for decades, without much progress.
> > It's still worth doing further research in this
> direction.
> > But this is a wholly different matter than having a
> plain
> > old programming language pretending to be more human by
> > duplicating methods under different names.
>
> You don't cure the disease by removing the symptoms. You
> cure it by removing the causes.
>
> The problem is not in trying to force formal systems to
> behave informally. That would be ludicrous. Formal systems
> are cool, they are incredibly useful, they have their
> place, and there isn't anything dehumanizing about them. I
> would never argue that a great mathematician who thinks in
> strictly abstract, formal terms is thinking and behaving
> like a machine.

I'm glad that you recognise that.

> I don't know where you got this wrongheaded idea that Ruby
> is focused on trying to emulate natural languages?

I never said that Ruby tries to do that. What I take issue with, is your rather blurry concept of thinking like a machine or outside the box or whatever. You seem to consider it more human for an API to have two methods with identical semantics. I think that's misguided.

> What I was talking about is not the language, but the
> fundamental bias in thinking. You can choose to lean
> toward machine-centric world-view in your thinking, or
> toward human-centric world view.

Sorry, I still don't know what that means with regard to APIs or formal languages.

> In both cases, you will
> remain confined to a strictly formal world of constraints,
> but your underlying bias would lead you in completely
> different directions.

I what way?

> Thus, a machine-oriented developer would naturally prefer
> using Java, C, C#, Assembler, because these languages
> reflect how the machines work. A human-oriented developer
> would prefer Ruby, because it reflects the way humans
> think (the way humans formally think, of course).

I'm honestly interested in understanding what you mean there. Maybe you could reveal the science that is the basis for your assertions about human nature, Java, C# and Ruby. Or is it just your personal feeling? Maybe my brain was taken over by machines so I'm unable to feel the same dispite the fact that I used to be human as well.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 6:28 AM
Reply to this message Reply
> James:
>
> An additional point, just because the tone of arrogance of
> your previous posts regarding Java is plain annoying:

I didn't mean to be arrogant. I don't think Java is neccesarily 'better' than Java. I'm just not a big fan of plethoras of syntax. For example Perl is the worst language that I've ever used.

> Recently I had the great experience of interacting with
> Chase's newly redesigned credit card website. Can anyone
> guess in which language this 'enterprise' app is written?
> Upon logging in, I was greeted with a Java traceback at
> least 100 calls deep.

That's not really relevant. If a machine fails and it's made of steel, do you say all steel is at fault? I never said Java applications are bulletproof. I will note however that a large number of sites on the Web run with Java back-ends.

If I can point out a Ruby site with an error, would that prove Ruby is not good?

> The error?--A method call on a null object. Now I realize
> that is different than a incorrect method call on a static
> type, but it was no less of a catastrophe for that
> enterprise Java app that could not render the page, not to
> mention the great embarrassment for those enterprise Java
> engineers as I looked at interesting details of the system
> revealed in that traceback.

Bad development is bad development regardless of the language. Do you not have stacktraces in Ruby?

> The great benefits of statically typed languages and
> 'compile-time' errors are over-rated. Use good behavior
> driven development and learn about duck typing, then show
> me how your enterprise apps fail because your language
> doesn't support static types.

I'm not saying it can't be done. I just have a hard time imagining how we would support a team of a dozen or so full-time developers in three time-zones with the periodic introduction of dozens more in a fourth for short times all adding and modifying code and deploying changes concurrently wiithout clearly defined types. We have lots of code that is used in many different processes that are constantly expandaing as we interact with hundreds of distinct extenal entities.

I'm not saying that it can't be done succesfully without static typing but it seems to me that without clearly defined types, it would be extremely difficult to pull off without constant communication between all the players which just isn't feasible in a large team that is spread out across time-zones that work days that just barely overlap. I understand that you can define types but you don't have to. The point is we are always going to want to and I don't see the point of not enforcing what we require. Perhaps I am missing something. If you feel that you have something to provide me that will educate me, please do. I am always open to new ideas.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 6:31 AM
Reply to this message Reply
> I didn't mean to be arrogant. I don't think Java is
> neccesarily 'better' than Java.

Um, I also don't think Java is necessarily better than Ruby.

Rinie Kervel

Posts: 26
Nickname: rinie
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 6:36 AM
Reply to this message Reply
>Smalltalk's
> the most pure, Python the most approachable, and Lisp the
> most powerful. It's just that as a consultant at
> conservative Java accounts, I need to also consider market
> penetration.
Well nobody seems to like PHP in this discussion (although the original post mentions it once). But for market penetration PHP is liked by Oracle (http://www.zend.com/core/oracle/) and IBM (http://www.zend.com/core/ibm/).

But then again I like curly braces: PHP on server, javascript on the client (and SQL for storage although I don't like the syntax)

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:40 AM
Reply to this message Reply
> Here is a quick question to make the case that Python is
> not really OO, then: why do I need to pass "this" (sorry,
> "self") to each method?

That's a good point.

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:54 AM
Reply to this message Reply
>> I also dislike how crowded the code becomes when you read
>> "self" everywhere, which is very non-pythonic. I like
>> significant space indenting for that reason (it saves you
>> from all these "end" keywords that I dislike in Ruby) but
>> the omnipresence of self ruins a lot for me.
>
> Yes, implicit "this" could be said to gain more than explicit "end" does.
> It will be interesting to see what happens in Python 3000.

Good luck waiting for that.

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Kay Schluehr Posted: Dec 23, 2005 8:09 AM
Reply to this message Reply
Gotta love that python community, instead of shits and giggles it's FUD and flames:

mike bayer wrote:
> hey alex, you talk a lot about not being the "machine's
> bitch" and all, but once your Ruby site needs to handle half
> a million transactions a day, ohhh youll be that computer's > bitch again, just you wait.

Kay Schluehr wrote, after posting a personal flame:
> According to the legend of saint Matz it was Perl creator
> Larry Wall who was his personal hero and it is actually
> Larry Wall who never became tired to speak about the
> postmodernism of Perl, it's relationship to natural
> languages the many ways to express things etc.

mike bayer wrote:
> If we want to say, as someone mentioned, "well Ruby/Rails
> is not for big enterprise apps ! its just for all the
> little things I do all day", that would be consistent with
> my impression of it....and this fact should be more openly
> admitted.
> One additional note, the plethora of web frameworks in
> Python has granted us one fantastic thing that a tool with
> Rails' hype-machine would utterly obliterate: room for new
> approaches and architectures. The Ruby community has
> plenty of room for tons of new eager developers looking to
> write blogs and other small applications with Rails; but
> for people looking to build communities around
> architectural notions divergent from Rails, pretty much
> none.

Kay Schluehr wrote:
> What I still don't get is this strategy of immunisation
> against critiscism by mystification.
> ( isn't Matz Japanese? Wouldn't it be better if he taught
> average american children kanji to enlarge their cultural
> background? )
> It's a kind of conservative closure by introducing a
> little redundancy just if a language permitted using both
> "and" and "&&" to assign a boolean operator. A great leap
> for mankind? A step aside from rude Dijkstra towards the
> incredible wisdom of Yoda? Maybe, but it's also a little
> ridiculous to make a new age religion from this.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:03 AM
Reply to this message Reply
First of all, kudos to Bruce for hitting the collective nerve of the community. This is a compelling discussion because there is a huge difference between using the best tool for the job and enthusiasm.
Over the last couple of days, I have been helping somebody debug some C++ ATL/COM stuff and it has been challenging and a total blast!

I got into software development because it was so geeky cool. C was a language for wizards.

Java came along and it was a trade-off, it was a little less cool but it was easier to do networking and stuff and the applet concept was kind of neat. But, I had to cleanse myself with a little C/C++ after a while.
But we and our industry began to mature. Stuff like schedules, costs, maintainability, the lack of experienced developers and constant turnover became issues.

Web development became the thing and with it came a geeky cool language for wizards - Perl. Geeky cool and productive, and curly braces and semi-colons - Katie bare the door!

Perl made me lose patience with compilation. But I knew that Perl was like a sexy thing from the wrong side of the tracks. But with an open mind, I began to investigate the world of scripting languages.

First I checked out Python. Python would have to suck, there are no curlys or semis and it looks like pseudo-code. Lets face it - it seems like Basic (oops I can't believe I said that). However, it only took a short while before I was cranking out solutions that I felt good about. I knew that Python was for real when I realized that I was using Python syntax as psuedo-code on my UML diagrams at work. And Python made me realize that the minute or two spent every day to align curly braces was a total waste of time.

My restless and compulsive soul cannot rest so I continued to investigate - checking out Ruby. I coded up some stuff in Ruby and from 60,000 feet, it seems a lot like Python. Ruby has a tad cleaner OO approach and is more expressive however it takes a tad longer to learn.
Ruby brings enough Perlisms over to make it geeky cool and I think that is what makes it a winner by a nose.

We don't just care about the ilities and ivities. We want to be wizards casting incantations to the machine - and see it respond to its master.

Or we could agree to stop all this progress because eventually they won't need us anyway. Some technology will render us obselete. So lets just pick a spot and freeze advancement. I vote for turning the clock back to the C/C++ days.

Roy Pardee

Posts: 2
Nickname: rpardee
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:15 AM
Reply to this message Reply
> That said, I was struck early on by the oddness of
> accepting self in method declarations (you don't
> have to pass it; it is declared only in the def,
> not in the argument list of a method call) and python
> rightly passes self automatically when you call an object
> member function. Coming from oop via C++ I didn't
> understand why this wasn't just automatically
> available and googled for a reason. Very reasonably,
> somebody on a mailing list (see
> http://www.python.org/tim_one/000152.html) explains that
> methods of classes in python are just functions (that
> could be dynamically added) and so self is not a reserved
> word but just the convention that the first argument to a
> method is a reference to the instance. Methods are not any
> different than functions and this allows for easily adding
> functions to an object...

So do I read that post correctly to indicate that the reason you've got to pass a 'self' variable in as the first parm to method defs is that Guido doesn't like creating new reserved keywords?

It's a nitpick but... that seems like a bad compromise to me. Ruby has dynamic method 'injection' (is that the right term to use?) too (see the 'mix-ins' discussion here: http://www.rubycentral.com/book/tut_modules.html) and IMHO, knowing that 'self' will always refer to 'this here instance' makes the code way more readable.

But that's just one person's opinion of course...

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:31 AM
Reply to this message Reply
> Alex, finally we agree. And you read my mind (I also
> thought that how_many() was better than count() in the
> same sense you point).
>
> Thanks, you were very kind. I will take a look at Ruby.

My pleasure, Marcelo. A word of warning: make sure you think twice before looking at Ruby. For a person so obviously bright and intelligent as you are, looking into Ruby is like taking the red pill (remember the "Matrix" movie?) One look, and there is no going back! One bad side effect of that is that it'll make you positively hate your day job.

So don't say I haven't warned you.

Roy Pardee

Posts: 2
Nickname: rpardee
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:01 AM
Reply to this message Reply
> Actually, there is a good point in here -- my guess is
> that someone on the Java team wasn't communicating with
> someone else when array was given the read-only
> length "field" and all the containers use
> size(). I would have liked Java's array to use
> size() as well (the compiler could have optimized
> away the call to produce the same efficiency as length).
> That would give me fewer things to have to know about,
> which is what I prefer when programming.

I think that's the point--ruby's occasional synonyms give you fewer things you have to remember. The interpreter 'knows what you meant', even if you didn't say it in the exact right way.

I remember an unpleasant experience trying to learn oracle's pl/sql. This sort of thing wasn't working:

if <something> then
<do some stuff> ;
else if <some other condition>
<do some different stuff> ;
end if ;

That's not valid code--"else if" wouldn't compile (not that the error message I got was particularly helpful at pointing out that line of code, mind you). Nor is "elseif", which would be valid basic (and php?). No, in pl/sql, you've got to use "elsif", as I discovered after staring at my seemingly elementary code for like 20 minutes. Ooooh the bitterness. Oooh, the swearing. I've got to misspell "else" in this frickin' language!!??

In ruby, you can use either "else if" or "elsif" or "elseif". Aaaah--nice.

There's a place for precision in the definition of a word--but some concepts are just synonymous, and IMHO the language does not benefit from pedantic insistance on particular forms.

And sure--the newfangled IDEs mostly now have intellisense type features to take some of that burden off the programmer. But I still appreciate being unburdened if I choose to use a plain text editor.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:16 AM
Reply to this message Reply
From a Ruby user's point of view, trying to tag it with a Perl bad image is just lame.

The first time I saw Perl code I tried to read it. It was like a walk in the park, until I met one of the famous Perl's regular expressions. I gave up on it, because I said to myself and to my surrounding friends: "if I can't even understand what it's doing to a string...". And that was my first and last try at Perl.

In contrast, when I started programming in Ruby, I could understand everything, including the Ruby's approach to regular expression. Regular expression in Ruby gave me one of those "aha!" moments. In Ruby, it's rare to see truly huge regular expressions like you can see in Perl, and the reason is that Ruby provides many easy ways to do things that Perl people would use RE for, I think. That said, as Ruby is used for much more than text processing, we just rarely find regular expressions in people's code, and repeating, when we find them, they are generally short and easily comprehensible.

Ruby is a divine gift, indeed. It does not have any match, even in Python. But we are yet to find "the perfect language", which is way harder because we can't even agree on the "basic features" that the perfect language should have. That said, by delegating the responbilities of being a perfect language, to the tools, like IDEs, you just try to hide the imperfections of your languages. By adopting XML as a standard to programming languages, you just make the languages even worse.

Think about this: if you don't like coding solutions from scratch, it does not mean that it wouldn't be useful if you could code them. But your solutions would be way more useful if they could be easily reusable. So, if other people take the task of creating reusable components, they can choose any language, but they won't necessarily choose the language that the users prefer, like Python. Python can be THE scripting language, which is generally the way to "glue" programs and libraries, because it has a minimalist syntax and semantics. On the other hand, people need to create what you want to glue with Python; and people might choose more comfortable tools when creating their own tools, libraries, etc; if there are more comfortable tools, why not use them to "glue" the things instead of Python's minimalist approach?

Think about this: what if many of the Python's libraries were based on components which you could easily reuse in your own programs?

With Ruby you can do all that, today. So, in my opinion, Ruby wins by more than a nose. Maybe, by a whole body. :-) Too bad I can't write a thoroughly comparison between Ruby and Python, but maybe a book-writer could.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:22 AM
Reply to this message Reply
Re: thinking outside of the box:

> Anyway, if all you want to say is that one should not
> blindly solve a problem as presented but sometimes
> question the problem and why it is a problem in the first
> place, then I completely agree with you. This is pretty
> self-evident, isn't it?

Now I feel real silly. You took my meandering tirade and gave it a much better articulation in only one simple sentence. Man, what a bravado! I feel so stupid, having to resort to all those politicisms and bullshit language.

Thank you for showing me how to think more clearly (less muddled, I suppose:-)

The only thing I'd change in your sentence above is replace the word 'sometimes' with 'always'.

> And it has nothing at all to do
> with programming languages.

This is where we disagree. My thinking is that it has all to do with programming language.

Two people, two differing worldviews, what's new, eh?

> > Why not use the 'middle men' who will think like
> machines
> > on our behalf?
>
> I'm afraid we are these middle men. If not, who are they?

Ever heard of Model Driven Architecture? Ever heard of Bangor?

Ever heard of Ruby?

> Quantitative differences can "leap" into qualitative
> differences. Just think about sound frequencies. If the
> wave length is too short or too long, we can't hear them
> any longer. To hear or not to hear is a qualitative
> difference caused by a quantitative difference. Equally,
> if company grows beyond a certain size, its processes will
> have to change qualitatively to cope with that growth.
> It's the same with the speed of growth, the speed of
> change, and so on. You get what I mean. So the amount of
> bloat in a language and its APIs, syntactic or semantic,
> does have a severe effect on quality.

The above is the best thing I've read in a long time! I hope you won't mind if I borrow your brilliant analogies and make a habit of using them in my teaching engagements from now on?

I will make sure that I always attribute them to Alexander Jerusalem (that is, of course, if these analogies are, indeed, yours and not borrowed from another source?)

> No, the urge to find out how things work is distinctly
> human. A machine would typically be perfectly happy to
> "know" that size() does what it wants. A machine would not
> start to wonder what it means that there is another method
> with a similar meaning of the word and why it's there.

But the machine may get stumped by the ambiguities. Common sense specializes in quickly resolving ambiguities, which is something machines are sorely lacking.

> Whether or not an API contains methods with different
> names but identical semantics is a qualitative feature of
> that API. How many such methods there are is a
> quantitative measure. If there are a lot and we get bogged
> down by the bloat, it slips back to a qualitative issue at
> some point. As I pointed out above, quality and quantity
> are related in rather complex ways and connot be kept
> strictly apart.

Absolutely correct. The saving grace, for Ruby, is that this bloat you talk about is ridiculously small (and hence 'bloat' is a misnomer) -- a couple of synonymous methods in a vast sea of straightforward ones. Hardly a scenario where quantity gets a chance to produce new unanticipated quality, wouldn't you agree?

> I'm glad that you recognise that.

I'm sure everyone recognizes that. Formal thinking is one of the basic characteristics that makes us human (it would be hard to argue that animals posses the ability to think in a strict formal sense).

> I never said that Ruby tries to do that. What I take issue
> with, is your rather blurry concept of thinking like a
> machine or outside the box or whatever. You seem to
> consider it more human for an API to have two methods with
> identical semantics. I think that's misguided.

I was using that example (a rather quirky and gimmicky one, I must admit) in order to try to illustrate the fundamental difference in Ruby's philosophy. It's a nice showcase for Ruby's leanings toward the human programmer, and away from the dictatorship of the underlying machinery.

But if that particular incident (which is rather isolated in Ruby's API) does not sit well with you, I suggest we forget about it and move on. There are numerous other, much more brilliant (but also much more involved) aspects of Ruby's philosophy that makes it a completely different beast from other programming languages.

> > What I was talking about is not the language, but the
> > fundamental bias in thinking. You can choose to lean
> > toward machine-centric world-view in your thinking, or
> > toward human-centric world view.
>
> Sorry, I still don't know what that means with regard to
> APIs or formal languages.

It has to do with the kind of thinking the tool encourages in its user. For example, if I'm using a hammer, that tool encourages me to view everything around me as if it is a nail. If hammer is my favourite tool, I'll spend most of my working hours feeling like nailing something.

If I then switch the tool, and fall in love with a saw, then this newly found fascination will encourage me to view pliable things around me as something that could, and should, be cut in half.

It is the tool that has the power to shape our imagination, the way we think about the problems we encounter. I think it would be foolish to ignore this power, as it directly influence what we perceive as being a problem in the first place.

Ruby is a tool. It is a very, very peculiar tool, and it possesses tremendous power to completely change the way we, its users, look at reality. That's why it's so intoxicating.

> > In both cases, you will
> > remain confined to a strictly formal world of
> constraints,
> > but your underlying bias would lead you in completely
> > different directions.
>
> I what way?

In the way I've described above. Staying with the simplest possible examples, both the hammer and the saw are formal tools. But depending on which one we side with, our choice will lead us in different direction. With the hammer, our direction will be toward nailing things, hitting them on the head. With the saw, our direction will be toward cutting things in half (we won't feel any urge to start hitting things on the head with a saw).

I know this is almost insultingly simplistic illustration, but please bear with me.

In the world of software, the choice of tools also influences how we perceive and think of problems.

> > Thus, a machine-oriented developer would naturally
> prefer
> > using Java, C, C#, Assembler, because these languages
> > reflect how the machines work. A human-oriented
> developer
> > would prefer Ruby, because it reflects the way humans
> > think (the way humans formally think, of course).
>
> I'm honestly interested in understanding what you mean
> there. Maybe you could reveal the science that is the
> basis for your assertions about human nature, Java, C# and
> Ruby. Or is it just your personal feeling? Maybe my brain
> was taken over by machines so I'm unable to feel the same
> dispite the fact that I used to be human as well.

I do have extensive experience in the area of cognitive sciences study. I could write tomes about these issues. If interested, I invite you to peruse my blog, where I'm keeping an ongoing stream of consciousness exposing these and similar matters:

http://jooto.com/blog/

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:42 AM
Reply to this message Reply
> > According to this Ruby doesn't scale well because it's
> > threads are not implemented at a hardware level:
>
> Make that, 'threads are implemented in the interpreter'.
> Assuming this is accurate (a quick Google search suggests
> s it is), it's a huge disadvantage vs. Java. Java's
> threads can be implemented in the VM, on the OS level or
> both without making the developer it's bitch, so to say.

James,

How thoroughly did you read the post that you quoted? It didn't state that Ruby doesn't scale well. It stated that Ruby used a very different model for scale out than Java, one that has weaknesses and strengths. You linked to an excellent article but seemed to misunderstand its subtleties.

If you consider concurrent distributed systems you'll see that the gap between state of the art and state of the practice is tremendous. State of the art is single processes handling greater than 10,000 clients (see http://www.kegel.com/c10k.html .) Java struggles to do this which is why BEA , for instance, use a native layer in their Weblogic server. With NIO or NBIO some Java systems can compete at this level. Far more systems use a product liek Weblogic server and either don't tune it or misconfigure it and get 100s of clients, or implement a thread per request model whose scalability is limited by choice of OS, version and configuration.

Ruby's use of fast CGI trades ease of development for lower theoretical scale. I say theoretical because the fact that Java *can* support 10k connections is no solace to a team that doesn't know how to do this. The fast CGI model is a dumber, simpler aproach that can, for naive users, sometimes scale *better* than the more flexible an dpowerful Java approach. How many Java developers understand that JVM threads map to OS threads through a NxM , Nx1, or 1x1 model depending on OS choice and OS configuration, and that "OS threads" (in some cases LWPs) will have a second mapping to kernel threads, and that discrete instructions will be pipelined, multiplexed on hyperthreaded CPUs, dual core CPUs and multiCPU hosts. Thesed are subtle, hard issues and understanding them is necessary to achieve the theoretical scalability that Java offers with correct behavior.

Scalability is an important issue and with Ruby the groundrules are different. This doesn't mean that Ruby apps will inherently be l;ess scalable than Java apps. Thinking that is similar to the "Java will always be slower than C++" or "C will always be slower than Assembler" oversimplifications. Tempting thought but wrong.

I agree that anyone planning to deply a Ruby on Rails app across thousands or hundreds of thousands of users would be smart to spike a "proof of architectural approach" test.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:48 AM
Reply to this message Reply
> > > I'm definitely trying to understand Ruby by putting in
>
> > > minimal effort and leveraging what I already know. My
>
> > > normal approach to learning a language, as you've
> > > observed, takes a huge amount of time and effort.
> >
> >
> > Bruce,
> >
> > It's too bad you're willing to make a lot of assertions
> > about Ruby without, apparently, understanding much of
> the
> > language. I'd almost go as far as to say that it's a
> bit
> > unethical for a person of your stature to behave this
> > way.
> >
> > I'd highly recommend this tutorial to anyone, even to
> all
> > those professional programmers with years of Java and
> > Python programming under their belt.
> > (http://pine.fm/LearnToProgram/ --soon to be a book
> from
> > those pragmatic guys:
> > http://www.pragmaticprogrammer.com/titles/fr_ltp/) You
> > will only learn well if you put yourself into the
> mindset
> > of an amateur (consider zen and the empty cup
> metaphor),
> > rather than bashing all the new concepts with your
> weighty
> > 'knowledge' and 'experience'.
>
> What I still don't get is this strategy of immunisation
> against critiscism by mystification. When I read that Ruby
> used length and size synonymous I didn't had the
> impression that this reflects the naturalness of english
> language ( isn't Matz Japanese? Wouldn't it be better if
> he taught average american children kanji to enlarge their
> cultural background? ) but the unification of conventions
> that are all around in the PL area. It's a kind of
> conservative closure by introducing a little redundancy
> just if a language permitted using both "and" and "&&" to
> assign a boolean operator. A great leap for mankind? A
> step aside from rude Dijkstra towards the incredible
> wisdom of Yoda? Maybe, but it's also a little ridiculous
> to make a new age religion from this. We are not alike and
> that's for sure.
>
> Kay

When I read this (I'm a Ruby nubie) I thought "OK that's a design error. I hope it's not the first in a long list." It doesn't seem typical but claiming it as a strength seems defensive to me. Maybe I'm still brainwashed by Java?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 12:18 PM
Reply to this message Reply
"When I read this (I'm a Ruby nubie) I thought "OK that's a design error. I hope it's not the first in a long list." It doesn't seem typical but claiming it as a strength seems defensive to me. Maybe I'm still brainwashed by Java?"

Particularly, I only use "size". On the other hand, historically (in other languages), I needed to use size, length, len, count, etc. Please, understand that Ruby was not created to "please its users". Ruby was created as I would create a language: "to please me!" So, when people talk about language design, I view it as rather irrelevant as I already settled with Ruby and maybe C as a supporting language (RubyC is a specific layer which is great when you create C extensions for Ruby). On the other hand, when people discuss language design, it's like they can use anyone which does the job for them, so if the current one sucks, they will keep using it until a better one, which they can use for their jobs, comes around. So, for people discussing language design, it's like "everything sucks if I can't use it", be it because the language really sucks or because they can't use it for their jobs.

So, these synonyms that may appear in Ruby are rather irrelevant for people who don't even use Ruby and never will. So, obviously, these synonyms "sucks", for them. :-)

I particularly like the "and" which defaults to logical operations instead of bitwise operations. I like a lot the logical operations in Ruby, as "nil" is used like "false" for negation, and in Ruby it fits like a glove. That's part of the defaults that I like in Ruby. Basically, if I were to create a language for ME, I would create a language like Ruby, without forgetting the support of C, which is one of the things that make me "Choose" Ruby, as it lends to Ruby a future-proof shield.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:37 PM
Reply to this message Reply
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.


> That's not really relevant. If a machine fails and it's
> made of steel, do you say all steel is at fault? I never
> said Java applications are bulletproof. I will note
> however that a large number of sites on the Web run with
> Java back-ends.
>
> If I can point out a Ruby site with an error, would that
> prove Ruby is not good?

This is your argument, not mine. 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.

Remember when Java was supposed to save all us C programmers because it didn't have pointers? We wouldn't be dereferencing NULL. Well, null is just as deadly for a Java app, static types and all.


> I'm not saying that it can't be done succesfully without
> static typing but it seems to me that without clearly
> defined types, it would be extremely difficult to pull off
> without constant communication between all the players
> which just isn't feasible in a large team that is spread
> out across time-zones that work days that just barely
> overlap.

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

I simply don't understand how static typing will make these management and communication problems go away. 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'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.

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.

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. 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 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. I'm not trying to convert you, or yank away your little security blanket named Java, C#, Python, Lisp, or whatever. But if you are a programmer, and you value your intellectual capacity and problem solving skills, you do yourself a grave dis-service by discounting Ruby and spouting FUD about hype, scalability, maturity, enterprise app, or whatever other topic is popular. And the reason for that is simple: FUD propagates a hundred times faster and farther than the truth. We already live in a world where stupidity and stupid decisions abound. Why contribute to them?

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. 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. 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. But I could be wrong; after all, Bush did get 51% of the vote.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:08 PM
Reply to this message Reply
> We already live in a world
> where stupidity and stupid decisions abound. Why
> contribute to them?

Brian,

You cannot ask someone who is stupid not to be stupid. If such person could do that, he wouldn't be stupid to begin with.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 9:02 AM
Reply to this message Reply
> > Generally, I go to
> > a professional if I want something done right. I don't
> > hire an amateur plumber or electrician, nor do I go to
> an
> > amateur doctor.
>
> You make a great point. Yeah, if you happen to have some
> extra money in the bank and it's posing you considerable
> problems so that you can't wait to dispose of it, there's
> hardly a better way to promptly get rid of it than hiring
> a professional. Be it a plumber, or an electrician, or a
> lawyer, an accountant, a dentist, a doctor, etc., all
> these professionals know how to relieve you of extra cash
> in no time flat. They are the real experts in that domain.

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." (Red Adair)


Alex

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 9:35 AM
Reply to this message Reply
> > I still don't understand why self was made mandatory,
...
> I think it's because of the "explicit is better than
> implicit" philosophy. As I've said, I'm probably more
> ambivalent about this issue than anything else.

The idea came right out of Modula 3: you define a FUNCTION (which like any other function has all of its parameters explicit, of course), you may set that function for use as a METHOD of one or more classes. Even the word "self" comes to Python from Modula 3 (exactly in the same usage).


> > Also, I'm still bothered by the fact that you declare a
> > method with n arguments (self being the first one) but
> > invoke it with n-1 arguments.
>
> Yes. Slightly non-implicit, that.

Indeed: totally explicit, thus the very reverse of implicit. When you GET a method from an object (that's BEFORE you "invoke" it, possibly long before), the "getting" operation may pre-bind some arguments (a concept also known as "currying", though there's endless debate on whether that name is appropriate or "partial binding" should be used instead) in the resulting callable. This mechanism is exposed through the concept of a descriptor and the special-method __get__ of descriptors; functions are descriptors.

Ruby, like Smalltalk, strongly separates methods from other attributes; just mentioning a method calls it (if you need to get "an object wrapping the method" you'll have to go the long way 'round). Python, like C/C++, does not: just mentioning a function or method does not implicitly call it, it just gets a reference to the callable object, like for any other object. You may call a callable object by applying the call-operator, spelled 'parentheses'. So, say, building a sequence of callables can be as simple as:
fs = a, b.c, d(), e.f()
where some callables are obtained by simple reference to a name, others by attribute lookup, others yet are returned by calls to higher-order functions such as d or other higher-order functions such as e.f. Some of the callables may have bound arguments while other don't -- it doesn't matter. When you want to call each callable in the sequence, in turn, that's as simple as:
for f in fs: f()

If you take a callable with N arguments and bind one of them, you obviously end up with a callable with N-1 arguments -- you'll have to supply N-1 more arguments each time you call it. In the example, I'm assuming that any arguments that the callables in fs might have had have been bound, so that each callable in fs can be called without arguments.

This rasonably strong connection with functional programming ideas is part of what makes Python multiparadigm -- not to the same extent as, say, Lisp, or even more Mozart (which almost looks DESIGNED to teach multiparadigm programming) -- but it may be part of why many Lisp experts, such as Norvig, Graham, or the reddit folks, appear to find Python reasonably comfortable and usable; or why EuroHaskell was held the day after EuroPython and in the same venue (at least in 2004 -- dunno 'bout 2005 as I was unable to attend).


> > I also dislike how crowded the code becomes when you
> read
> > "self" everywhere, which is very non-pythonic. I like

Personally, I don't see much difference in readability between, say,
@attribute = 23
and
self.attribute = 23

The former (Ruby) is more compact, but also more visually invasive. Leaving the scope locally ambiguous by omitting both markers, of course, is wisely eschewed in both Ruby and Python (and most coding-style guides for, say, c++, which require you to spell the name as, say, 'my_attribute' to make it clear it's an instance attribute). The advantage of the 'self.' form is conceptual: it does not require adding one more rule, it totally follows from the general rules defining the meaning of anyobject.attribute ...


> Yes, implicit "this" could be said to gain more than
> explicit "end" does. It will be interesting to see what
> happens in Python 3000.

My prediction is that 'self' is here to stay, just like, say, blocking by indentation.


Alex

mike bayer

Posts: 22
Nickname: zzzeek
Registered: Jan, 2005

Re: Kay Schluehr Posted: Dec 24, 2005 11:09 AM
Reply to this message Reply
> Gotta love that python community, instead of shits and
> giggles it's FUD and flames:

hey if I were tasked with deploying a ROR site to a large-scale envionroment with ~.5 million TPD, I would most certainly be fearful, uncertain, and doubtful. You'd be just fine ?

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 11:46 AM
Reply to this message Reply
> > The person I want to hear from is the core Python
> expert,
> > someone who knows that language incredibly well ...
>
> Ok Bruce(s). I'm not sure I qualify as your "core Python
> expert". I'm a core Python developer, though:

My qualifications are roughly similar to Neal's -- for example, the knowledge of Python's "nooks and crannies" embedded in his pychecker is somewhat similar to the kind embedded in my "Python in a Nutshell". We're both Python committers, PSF members, Google employees, etc, etc. I think I'm more of a "gadget lover" by nature, which may explain why I keenly look into lots of programming languages -- e.g., for Ruby, I got a Andrew Hunt tutorial, read through the first edition of their book -- basically, "dived into" the language, over five years ago, even though I had no specific _reason_ to do so. OTOH, I haven't looked that deeply into Rails.

Anyway, you can find a lot of posts of mine comparing Ruby and Python, although I don't necessarily agree now with all I wrote then -- for example, the (theoretical) mutability of builtin types doesn't feel to me like a big problem any more, just one small extra trap for the unwary (and both Ruby and Python have other such small traps, anyway -- they byte less in practice than you would expect them to in theory;-). But essentially, I would still say "it's a wash" -- the two languages have more similarities than differences, when compared to other widespread languages. When it comes to differences, there are a lot of small things I prefer about Python, such as almost all the syntax choices, keeping REs in their own module, treating callable attributes like any other rather than having a chasm between attributes and methods, etc; and a few I prefer about Ruby, such as the more rigid capitalization conventions, the flexibility of blocks, the idea of marking globals with the $ of infamy;-) [much better than Python's "global" statement], the ability to "reopen" an existing class to add a method with more "obvious" syntax [you can get the same effect in Python but not in an equally obvious way - you have to 'def' the method's function and then assign it to TheClass.methodname]. I don't think any of these are "make or break" issues, and neither are the "legacy" issues of each language (the horrid implicit $_ in Ruby, the many Python builtins which should be in some separate module if they must keep existing at all, etc etc).

In terms of language philosophy, Python's push towards simplicity (only one obvious way to perform a task, etc etc) is far closer to my preference than Ruby's "not quite perlesque but almost" reveling in richness -- it can certainly happen, for legacy reason, to have two approaches ('x in d' vs 'd.has_key(x)"), but Python *sees* these as legacy baggage and yearns for the 3.0 "allowed to be backwards incompatible" release to drop the old way; the fact that Ruby advocates intensely DEFEND their synonyms (length/size, for example) makes my skin crawl with horror, to the point that it may impede me from ever being a card-carrying member of the Ruby community. But in the end, beyond the fanatics on either side, PRAGMATIC is the key word for the philosophies of both languages -- neither, despite the excesses of some of the fans in their respective communities, are "ideological" in foundation.

Which leads me to conclude that pragmatics is a great basis for language choice. When Ruby 2.0 increases performance dramatically, making Ruby way faster than Python rather than slower, or pypy meets its ambitious goals, that may be ample reason to "switch" -- or similarly, if Jython has a better JVM integration than the Ruby equivalent (I assume there must be one, and that I just haven't heard about it), or IronPython for dotNet fans, or Python's scipy.core makes for better numerical programming, or Ruby's Rails for better web apps, or there are Python but not Ruby ports to your cellphone or iPod, or PIL lets you treat images better in Python, or gmpy proves ideal for your number-theoretical manipulations, etc, etc, any of these may be a great reason for choosing one language, more sensibly than it would be to base your choice on "@foobar=23" vs "self.foobar=23" one way or the other;-)


Alex

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 3:08 PM
Reply to this message Reply
Thanks, Alex -- nicely put. Could you give the URL(s) where you talk about Ruby and Python. I would certainly be interested in your analysis.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 4:14 PM
Reply to this message Reply
Ruby supports multiparadigm also. I like OOP for the backend and I'm deciding if I go with DSL (functional) like "plugins" for the frontend; so far, I'm enjoying it a lot, though I still have 3 days of programming to make it work fully like I want. Basically, I want as a clean programming for the frontend as I can get, and it's becoming very neat due to the flexibility allowed by Ruby.

Example:

---file[ db_table.rb ]------
require 'cgr/cgr'
start(:GTK){|w|
w.pack button('database login'){ start_file('db_login.rb') }
}

---file[ db_login.rb ]------
require 'cgr/cgr'
start(:GTK){|w|
w.pack 'DB path: ', [tf_path = textfield, true, true]
w.pack 'DB interface: ', [tf_interface = textfield, true, true]
w.pack 'DB login: ', [tf_login = textfield, true, true]
w.pack 'DB password: ', [tf_password = textfield, true, true]
w.pack [1, true, true], button('connect'), ' ', button('cancel')
tf_path.text = '/home/dewd/t_/fb/aaa.fdb'
tf_interface.text = 'Firebird'
tf_login.text = 'SYSDBA'
}

------
So, the first file calls the second file with the "start_file" method. Both files can be run independently on of the other. Both files create GTK+ Windows and show them to the user. Next on my todo list:
1. create a callback so the events can be returned from the second window to the first one. # I like this approach because it keeps the code where it belongs, rather than allowing spaghetti programming;
2. support modal windows;
3. support deletion and recreation of windows;
4. ...

The above code works similarly for Fox-Toolkit and wxWidgets, I just need to change from "start(:GTK)" to "start(:FOX)" or "start(:WX)", respectively.

The code above is only the tip of the iceberg, though it's rather pretty for a frontend programming.

PS. even though I have worked a lot on it, I still have a lot of work ahead; I still am not sure about when it will be open sourced, though I hope to be able to open source it in the future.

That's Ruby to me. :-)

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 7:32 PM
Reply to this message Reply
> Thanks, Alex -- nicely put. Could you give the URL(s)
> where you talk about Ruby and Python. I would certainly be
> interested in your analysis.

There are many, such as:

<http://groups.google.com/group/comp.lang.python/msg/f9c570e9376c7cf3?hl=en&>

<http://groups.google.com/group/comp.lang.python/msg/7256adbbc7f79afe?hl=en&>


Alex

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 7:40 PM
Reply to this message Reply
> Remember when Java was supposed to save all us C
> programmers because it didn't have pointers? We wouldn't
> be dereferencing NULL. Well, null is just as deadly for a
> Java app, static types and all.

What most Java developers fail to realize is that it doesn't have to be deadly. What you have to understand is that any long lived thread should be protected by a try {}catch block that makes sure that RuntimeException doesn't kill the thread. This is the first rule of Java Threading in my book.

The Java language lets you protect the software from the programmer in this way. If you don't take advantage of it then you will experience some dismay and amazement at how
quickly things come to a screeching halt when RuntimeExceptions are not caught to protect the main threads from untimily death. Depending on the depth of the call tree that the thread is used for and the complexity of the task, you may find it important to Thread.sleep() for a
second or so before the next task to keep a runaway situation from developing.

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

Yes, and that implies a contract which should be checked and validated as early in the runtime of the application as possible. Compile time static type checking is just an earlier validation of the contract that makes it easier to feel comfortable about what will happen at runtime.

> I simply don't understand how static typing will make
> these management and communication problems go away.
> 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?

The primary reason I use Java is that interfaces in concert with mobile code let me create real services whose implementations are distributed at runtime, rather than in a deployment task. This is the "the power" of Java. If you aren't using this feature, then you probably have a wide choices of languages that will solve the problems you are solving.

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

The only fair comparison compared all of this amazingly biased dialog would be to have two equaly capable teams with equal experience in each langauge to be given the same application to develop, and then microscopically track every single task, thought and subsequent action. Time them all, and then correlate the data back to some "cost". That would be pretty much impossible!

Every language has features. Every language has warts. What you have to decide is that if a particular feature enables your application, then that is why you might choose that language. If you fail to recognize the other benefits of another language which might provide some other feature, down the road, then you'll be stuck without that feature, perhaps, forever.

The Jini platform is a specification that can interact with a wide range of transports and languages because it has a large number of service provider style mechanisms. All the things in Java that deal with the humdrum programming of add/subtract/multiply/divide, class hierarchies, packaging etc are not the power of Java. The power of Java comes at the point that you really understand the power of mobile code. The smart proxy concept is paramount improvement on remote procedure call mechanisms. The abilty to change how the client uses the servers, on the fly, without the client being changed is extremely powerful.

If all you're doing is building web servers that ship out web pages, then you may not need mobile code. But, look at the Jini usage in Orbitz's platform, and you'll see how they take a core set of services and dynamically and continuously evolve the service platform using dynamic code downloading and classloader mechanisms for version management.

Version management through the change in class implementation is interesting. But, it still is not up to par with the use of classloader based changes. With classloaders, you can put the same interfaces into a piece of software and use multiple versions, with the same names inside of the same software. You don't have to change everything, everywhere to get one thing to work in one place.

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

Any language comparison, when aimed at the right features can make one look better than the other, right?

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

The question is what is the best way to test type compatibilty. When is it easiest to do and what is the most return on investment. Compile time type checking is a built in test. I don't have to write it over and over for each class/object. I don't have to understand flow control through a method/function/module to correctly implement all possible tests that will prove that I have compatible objects.

Further, new users/uses of the same code get to use this free testing. They don't have to implement it either. Thus, my test construction is limited to tests that cover semantic behaviors where I cover the vast majority of issues that a human constructed test should have to deal with.

> 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. I'm not trying to convert you, or yank away your
> little security blanket named Java, C#, Python, Lisp, or
> whatever. But if you are a programmer, and you value your
> intellectual capacity and problem solving skills, you do
> yourself a grave dis-service by discounting Ruby and
> spouting FUD about hype, scalability, maturity, enterprise
> app, or whatever other topic is popular. And the reason
> for that is simple: FUD propagates a hundred times faster
> and farther than the truth. We already live in a world
> where stupidity and stupid decisions abound. Why
> contribute to them?

I think it is impossible for everyone to know everything about every language. Such knowledge is not free, and in the grand scale of software development progress, adds little value! What developers need to know if whether a particular problem is being solved by their language of choice or not. If the problem is being solved, that's the end need. Effeciency (time, space etc.) of the solution is part of the "is solved" answer, if that is part of the solution space.

What is most necessary in this day and age is to stop solving the same problems over and over with a new language that does one particular thing different than the others with no added value in other forms. That type of progress is extremely expensive. Look at the vast number of developers who have contributed the vast array of python and ruby software we have to date. I think that's productivity focused on many things that are just recreations of what we already have.

To some degree, it's the ignorance of some of those developers that are causing them to recreate existing solutions, in much the same way as there is allusion that Java developers are ignorant of Ruby and Python. For most developers, the ignorance of another language and platform is expected because they are solving problems that their language of choice handles for them.

For some, they've learned how to use the features of their language of choice to create new domain specific APIs that make their software simple to create and maintain.

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

I guess I'd have to have a language based platform, such as Jini, which provides distributed leasing and distributed transactions, plus a language built in security model, mobile code and method overides "int max(int,int)" vs "double max(double,double)" and finally binary data serialization between instances of the language runtime, over the network to consider a language enterprise worthy.

I don't do web services and I don't create web sites. Those are the features that I use the most often in Java and which I don't see available in Ruby, Python or many of the other non-statically typed languages which I've looked at.

Point me to these kinds of solutions for Ruby and/or Python.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:25 AM
Reply to this message Reply
Java is: "Jack of all trades, master of none."

Or, master of the "Enterprise", though 99% of the financing for Java development comes from the boring day-to-day common software creation.

Yes, I need "day-to-day common software creation". Maybe most people need that! :-) I don't need a cluster of Java servers and clients, though I would like Ruby in little appliances so I could create user interfaces and exchange of data in Ruby itself.

I don't think it's a waste of time to want to use alternatives to Java, because Java isn't even available in most operating systems out of the box. Why is that? Why is that that Java's Swing had problems accented characters on Linux and I couldn't even use Java Swing editors because they had problem with my Portuguese? Yes, Java did support unicode, though its Swing interface didn't work very well on Linux. Maybe to help Java we only needed to use Windows and Solaris...

Well... I'm thankful that there are alternatives to Java. I'm thankful to all the people who have helped to create the open source alternatives to Java. Without them I would be using Windows right now...

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:36 PM
Reply to this message Reply
> > Just so we're clear, a type to me is a set of values
> and
> > operations on those values.
>
> Yes, and that implies a contract which should be checked
> and validated as early in the runtime of the application
> as possible. Compile time static type checking is just an
> earlier validation of the contract that makes it easier to
> feel comfortable about what will happen at runtime.

If you don't already know this, you won't likely benefit from me explaining it in depth: the type-checking the compiler can do is extremely limited. Therefore, the onus is on you again to demonstrate why the baggage that comes with static typing is outweighed by this very limited benefit.

> > 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.
>
> Any language comparison, when aimed at the right features
> can make one look better than the other, right?

See, you can put an advanced cerebral cortex in a monkey, but you can't make him use it. Did you read the slides? No, you didn't because Jim put one whole big slide in there to assure you he wasn't going to tell you Ruby is better than Java. All he did was point out important things that a Java programmer should now about Ruby.

> The question is what is the best way to test type
> compatibilty. When is it easiest to do and what is the
> most return on investment. Compile time type checking is
> a built in test. I don't have to write it over and over
> for each class/object. I don't have to understand flow
> control through a method/function/module to correctly
> implement all possible tests that will prove that I have
> compatible objects.
>
> Further, new users/uses of the same code get to use this
> free testing. They don't have to implement it either.
> Thus, my test construction is limited to tests that cover
> r semantic behaviors where I cover the vast majority of
> issues that a human constructed test should have to deal
> with.

All the compiler can do is ensure that you are executing a well defined operation on a set of values (a type). That's it. Guess what, that is just as automatic if you write tests for your code. There is no extra work required. If you were just writing tests to mimic a compiler doing type checking, that would be stupid. When you test semantic things, boundary conditions, etc. you get that compiler-like 'type' testing for free. Oops, there I went and explained it in more depth. You do know how to write tests, yes?

> I guess I'd have to have a language based platform, such
> as Jini, which provides distributed leasing and
> distributed transactions, plus a language built in
> security model, mobile code and method overides "int
> max(int,int)" vs "double max(double,double)" and finally
> binary data serialization between instances of the
> language runtime, over the network to consider a language
> enterprise worthy.

Um, the only reason why you need int max(int, int) and double max(double, double) is because of types. It's a lot of baggage for nothing gained (unless you don't test your code anyway). And of course, you have to have a cast operator so you don't need a separate double/int(?) max(double, int), and on and on. Now, what happens when you get happy with that cast operator?

And you still haven't, or perhaps didn't intend to, answer why static typing makes communicating about the program more clear.

> I don't do web services and I don't create web sites.
> Those are the features that I use the most often in Java
> a and which I don't see available in Ruby, Python or many
> of the other non-statically typed languages which I've
> looked at.
>
> Point me to these kinds of solutions for Ruby and/or
> Python.

Hmm, you're kidding, right? Okay, probably not considering this post: check out druby and pyro. Service locators are trivial (as are the rest of distributed objects) when you have a dynamic language like Ruby and Python.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:40 PM
Reply to this message Reply
> > Thanks, Alex -- nicely put. Could you give the URL(s)
> > where you talk about Ruby and Python. I would certainly
> be
> > interested in your analysis.
>
> There are many, such as:
>
> <http://groups.google.com/group/comp.lang.python/msg/f9c570
> e9376c7cf3?hl=en&>
>
> <http://groups.google.com/group/comp.lang.python/msg/7256ad
> bbc7f79afe?hl=en&>
>

Ah, yes, much more important to look smart to those who don't know better.

Cool is much different than 'cool'. And if the depth of your investigation extends to a bit of example code, then those who listen to your 'knowlegable' evaluation of Rudy deserve the consequences.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:02 PM
Reply to this message Reply
> > > Thanks, Alex -- nicely put. Could you give the URL(s)
> > > where you talk about Ruby and Python. I would
> certainly
> > be
> > > interested in your analysis.
> >
> > There are many, such as:
...
> Ah, yes, much more important to look smart to those who
> don't know better.

Uh? More important than, what other goals? And why would Bruce Eckel (who here was thanking me and asking for the URLs) be one of "those who don't know better" (better than whom? about what?). I must admit I have no idea what you're talking about.


> Cool is much different than 'cool'. And if the depth of
> your investigation extends to a bit of example code, then
> those who listen to your 'knowlegable' evaluation of Rudy
> deserve the consequences.

One of the relevant URLs is <http://groups.google.com/group/comp.lang.python/msg/73c9aff4f29cbbdf?hl=en&> which does give some small snippets such as:
"""
you 'send a block of code to a method' -- but the difference here is really not much more than syntax sugar, Ruby's
array.each{|item| print item, "\n"}
vs Python's
for item in array: print item
or Ruby's
array.sort{|a,b| a <=> b}
vs Python's
array.sort(lambda a, b: cmp(a,b))
"""
I hope this isn't misread as meaning you need to actually SEND that (silly and) dummy lambda do the array.sort example in Python, any more than you need to send that dummy block to the array.sort in Ruby -- I hope it's obvious to the readers that, even if that cmp is a special function and not the builtin of that name, 'array.sort(cmp)' is a vastly superior approach in the Python case, etc, etc. My point was just that "sending the block of code into the method" should not frighten nor excite anyone compared to the Python way, where you loop extracting items (and apply code to them in the loop's body) or "send in" one or more callables (functions, lambdas, whatever); i.e., as I put it, the difference is mostly one of syntax sugar.

Of course, that was a post from over 5 years ago, and as I already mentioned I don't necessarily still agree 100% with what I wrote then, particularly considering the changes happened in both languages since. In particular, 3 years later I gave it a rather in-depth try, some modest fraction of which is recorded at <http://groups.google.com/group/comp.lang.ruby/msg/6ca81cbd796a5ad5?hl=en&>and the very, very numerous followups -- would the fact that it's comp.lang.ruby exempt it from your fierce strails about "those who don't know better"? Unfortunately much of the discussion turned around performance issues (which I hope are resolved in today's Ruby, or are going to be in 2.0) so it may not be as illuminating as one might hope regarding stylistic issues. However, it did strongly confirm my impression that there's little to choose, stylistically, one way or another, so pragmatic reasons (which may well include performance, depending on what implementations and extensions you have around or can consider making) may be the best grounds for choice.

Why all of this should have provoked your response, so apparently full of hate and spite, is quite beyond me, though. My best guess is that some people are so rabidly fanatical that any attempts at injecting moderation or commonsense in the discussion drive them wild, and that I've just witnessed a manifestation of this mindless, "nuclear-option" hostility.


Alex

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:16 PM
Reply to this message Reply
> Thanks, Alex -- nicely put. Could you give the URL(s)
> where you talk about Ruby and Python. I would certainly be
> interested in your analysis.

Bruce,

I'm really curious, why do you only engage those who are outspoken supporters of Python or Java? There have been numerous interesting posts by folks who profess, at least, to be knowlegable about Ruby.

Which reminds me everyone, I forgot to mention, you're right, nothing special going on here: Ruby is just a cheap knockoff of Python or Perl and Rails is nothing special. Please do not do any of your own investigating. People much more intelligent than you have already told you, nothing to see here.

Please do yourself a favor, go back to your temples, mosques, shrines. Worship those who tell you there is one right way. You might not know what to do if presented with a choice. Don't learn Ruby and find out for yourself whether you think differently when using it. Python is simple and clear (tell that to anyone who has tried to do simple metaclass programming, C embedding, or cringes at the pasted-on feeling of the objected-oriented features). Java is for enterprise apps because it has types and libraries. Continue to believe these things without question. To tell you differently would be the proverbial casting rubies before snakes, or into cups of coffee.

Whatever you do, please don't think for yourself. Stick with the pat answers, be distracted by the folks that tell you method synonyms are bloat, believe those who tell you Python is all about the one right way, and watch while PEP after PEP adds features that weren't really that special in Ruby.

It's safer this way; really; for everyone. The last thing I'd want is for you to come over and start programming Ruby libraries thinking the way you do in Python and Java. Ruby and Rails are nothing, just a blip on the screen, only visible to the hyper-enthusiasts. Please, for everyone's sake, do not learn Ruby.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:42 PM
Reply to this message Reply
> Why all of this should have provoked your response, so
> apparently full of hate and spite, is quite beyond me,
> though.

Alex,

Really, you have misunderstood me. I have neither hate nor spite for you. I've read your some of your posts. I know both Ruby and Python pretty well. I know that for many things, for me, there is a big difference between Python and Ruby.

When I read you talking about a Ruby feature being 'cool', and Bruce calling people who like Ruby hyper-enthusiasts, I feel a need to set straight some misconceptions. Quotes usually indicate that a word is being used euphemistically, and here that there's not much significance to a Ruby feature other than looking 'cool', i.e. no substance, just superficial ego stuff. You don't say that Python is 'simple' because it professes to be and yet has numerous features that make it much less than simple. See, your treatment isn't really unbiased, but for someone who doesn't know Ruby, like Bruce, you probably sound pretty smart.

Rest assured, I'm not telling anyone not to listen to you. I'm sure you're a good programmer. I generally find my work with Python to be rewarding and I'm impressed by the quality of many of the libraries. But don't expect me to be tolerant with Python and Java folks who 'investigate' Ruby and come back to say, ahh, it's a wash, not much interesting, syntactic sugar, blah, blah. If it was all simply equivalence and syntactic sugar, then Python wouldn't be chasing down features that are very useful in Ruby.

And if you insist on treating people who find compelling reasons to use a different language as if they lack substance or are just misguided or just wanting to be 'cool', then don't whine when you receive a figurative slap in the face; you asked for it.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:46 PM
Reply to this message Reply
<quote from="http://paulgraham.com/hamming.html">
I have now come down to a topic which is very distasteful; it is not sufficient to do a job, you have to sell it. `Selling' to a scientist is an awkward thing to do. It's very ugly; you shouldn't have to do it. The world is supposed to be waiting, and when you do something great, they should rush out and welcome it. But the fact is everyone is busy with their own work. You must present it so well that they will set aside what they are doing, look at what you've done, read it, and come back and say, ``Yes, that was good.''
</quote>

Well. Thanks for the space and for the patience, all. Sorry about my excesses.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:55 PM
Reply to this message Reply
> I don't think it's a waste of time to want to use
> alternatives to Java, because Java isn't even available in
> most operating systems out of the box. Why is that? Why is
> that that Java's Swing had problems accented characters on
> Linux and I couldn't even use Java Swing editors because
> they had problem with my Portuguese? Yes, Java did support
> unicode, though its Swing interface didn't work very well
> on Linux. Maybe to help Java we only needed to use Windows
> and Solaris...
>
> Well... I'm thankful that there are alternatives to Java.
> I'm thankful to all the people who have helped to create
> the open source alternatives to Java. Without them I would
> be using Windows right now...

Is it a waste of time to spend 10 times longer to recreate something just because you don't want to spend the time to make it work/port it?

This is strangely close to the not-invented-here syndrome.

Jim Shi

Posts: 7
Nickname: jim2000
Registered: May, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 9:08 PM
Reply to this message Reply
The methods in Perl, JavaScript, Python, etc are really
stand-along 'global' functions, whereas in Java,
(instance) methods are attached to their objects and can't be called without instance objects.

You can pass *anything* to first argument in methods of Perl, JavaScript, Python etc if you like, while this is impossible in Java.

This is not to Say Perl etc are better languages
than Java. Java is just more retricted and force you to
do things in decipline. The payoff are greater when you have a larger project.

> >
> http://zephyrfalcon.org/weblog/arch_d7_2003_07_12.html#e284
>
> >
> > Shows how Python was designed as an OO language from
> the
> > beginning. Version 1.0 supported classes, virtually the
> > same as they appear today.
>
> Fair enough, Bruce, I stand corrected.
>
> I still don't understand why self was made mandatory,
> though. I used to think that backward compatibility was
> the reason, but now I'm completely at a loss. The only
> reason I can think of is that this is how we emulated
> classes in C (passing a pointer to this to the function)
> but C++ was already fairly established by then, so it's
> not as if it was a brand new technique.
>
> Also, I'm still bothered by the fact that you declare a
> method with n arguments (self being the first one) but
> invoke it with n-1 arguments.
>
> I also dislike how crowded the code becomes when you read
> "self" everywhere, which is very non-pythonic. I like
> significant space indenting for that reason (it saves you
> from all these "end" keywords that I dislike in Ruby) but
> the omnipresence of self ruins a lot for me.
>
> --
> Cedric

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 9:16 PM
Reply to this message Reply
"Is it a waste of time to spend 10 times longer to recreate something just because you don't want to spend the time to make it work/port it?
This is strangely close to the not-invented-here syndrome."

Indeed. You are right. It feels good to recreat things. Maybe JDBC 1, 2, 3, EJB 1, 2, 3, Java 1, 5, 6, JSF, JSP, etc, are not being recreated all the time. Java is a moving specification, just like me and my tools -- you blink and another open source tool appears.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 10:18 PM
Reply to this message Reply
> both Ruby and Python pretty well. I know that for many
> things, for me, there is a big difference between Python
> and Ruby.

So, why not show them to us, these many things where the difference doesn't boil down to syntax sugar, instead of attacking those who, having investigated to the best of their abilities, haven't found them? Do they have to do with modifying built-ins, using blocks as coroutines, or what else?

You can't expect anybody to read your mind. I haven't found these many important examples throughout two editions of the excellent Pragmatic Programmers' book, nor in my frequentation of comp.lang.ruby, so they can hardly be *obvious*. You have already shown us that you're good at making enemies (I do assure you that you've made at least one, me: and if you are at all representative of the Ruby community, then my position towards Ruby must shift from one of sympathy and interest to intense enmity, too); show us that you're as good at actually SHOWING your points, will you?

> I feel a need to set straight some misconceptions. Quotes

You've certainly set straight MY previous misconception that the Ruby community was composed mostly of sensible people, assuming you're at all representative of it.

> be tolerant with Python and Java folks who 'investigate'
> Ruby and come back to say, ahh, it's a wash, not much
> interesting, syntactic sugar, blah, blah. If it was all

Don't be an idiot, or, if you can't help that, try not to SHOW it so badly. Anybody claiming that the difference between a statically typed language and a dynamically typed one is essentially "syntactic sugar" would of course be laughed out of court: you can't quote any "Java folk" claiming THAT on this thread, so this sentence implicating that this has happened is OVERTLY cretinous.

> simply equivalence and syntactic sugar, then Python
> wouldn't be chasing down features that are very useful in
> Ruby.

If you had bothered to read the various posts I made on Python and Ruby, instead of just coming out swinging for the sole purpose of makign sworn enemies, you would have noticed that I _have_ made the point that obviously the consensus on python-dev must be that using blocks as coroutines can be useful; otherwise, we wouldn't have an approved PEP to enrich generators with features useful for that very purpose (to some extent it IS still syntax sugar, since generators are quite analogous to iterator classes, but the amount of boilerplate differs by enough to make it "substantial"). I am not aware of other language features being similarly "chased down", but since you've chosen to use a plural I'm sure you'll be glad to share your superior knowledge with us.


> And if you insist on treating people who find compelling
> reasons to use a different language as if they lack
> substance or are just misguided or just wanting to be
> 'cool', then don't whine when you receive a figurative
> slap in the face; you asked for it.

I insist on forming my own opinion, and on freely sharing it when publically asked to by a friend; and if that opinion is that two languages are extremely close, with almost nothing but syntax (except of course all sort of possible pragmatical issues, tied to implementation, community, libraries, etc, not to the languages proper) to guide one's choice, I further insist on being able to express that opinion as my answer to my friend without any would-be tyrant feeling enabled to decide that this means "I asked for" any beating, figurative or otherwise.

I would like to hear from other people who consider themselves to be in the Ruby community as to whether you're an isolated, shunned freak, or a well accepted, representative member of that community. That will help me (and other readers of this exchange) decide whether it's you, in particular, who are just a terrible, possibly dangerous individual, 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...:

Perhaps in the near-mid term future somebody will request my opinion (people often do, even though I'm now an employee, not a consultant any more), and what I say will determine whether a given project will be given the go-ahead to proceed with Ruby, or not. Before I suffered this unbelievable attack, my opinion would most likely have been mildly favorable, as is easily ascertained by studying all my posts on the issue (with more weight on recent than on ancient ones, as I have explained). Right now, given the doubt that this attacker IS representative of Rubyists in general, I would of course be otherwise inclined. But I always keep listening (which may be why I am so frequently asked to express my opinion, and why many appear to hold that opinion in high regard), so both technical points, and ones about the connection between this attacker and the community, will matter to any opinions that I may be asked to express in the future -- so, thanks in advance to any who want to offer such input.


Alex

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 11:00 PM
Reply to this message Reply
Alex,

Eeks, would it be that I really slapped you in the face. It was a figure of speech, not a real deed. Poor fella, he must really be smarting.

I don't make any claim to being a representative of the entire Ruby community; that's preposterous.

To say that you may now recommend unfavorably to Ruby because you don't like how I talk to you, is well, just plain cretinous. Really, you give me far too much sway over your wibbly opinions; and that statement sounds really stupid.

I do apologize for putting a wrinkle in your day.


These are things that I find compelling reasons to use Ruby:

1. Classes: open; single inheritance; mix-ins; class methods; singletons; singleton methods; class methods, class_eval; instance_eval. (I'm sure I'm forgetting some aspects, but these are all fantastic. and yes, I know, Python has something like class methods, and for me, decorator syntax is ugly)
2. Blocks and closures
3. Conditional modifiers: print 'yes!' if you_like_ruby unless you_are_grumpy
4. Optional parentheses
5. 'end' closes a "block" (not a Block in 2 above but a block of statements/expressions). Far from being cumbersome or litering code, like self in Python, this 'end' provides a psychological closure, which gestalt psychology has shown to be very important for the way the human brain creates meaning. If you want to understand closure, think about the saying, 'waiting for the other shoe to drop'.
6. No syntatically significant white space. Usually this is not a problem for me in Python, but I don't like it and no one will ever convince me it's a good thing. I have had it bite me, like when programming Python scripts in Zope, and it's just an annoyance I don't like to deal with
7. Libraries have been implemented from the beginning using blocks. Iterators and generators are basic concepts, not add-ons. I generally find the core libraries to be more elegant in Ruby. In Python the C origin usually shines through pretty clearly.
8. There is not necessarily 'one right way' to do something. I really don't like a dumb computer language to act as if it knows better than I do. Of course, there is often a 'better way', but hang out a bit on the python list and you will see it is hardly so clear. A recent example: Guido wants to remove map, lambda et al, and impose list comprehensions as the 'one right way' even though a number of people wrote and said they are very useful to them and would hate to see them go.

There are many reasons why I find Ruby to be more elegant and simpler to understand and use than Python. You won't find me calling Python folks hyper-enthusiasts or making other disparaging remarks. I may say you should know what you're talking about, but so what? You should!

I'm pleased to know that Bruce is a friend of yours. Perhaps he'll listen to you. If you're such a nice guy, why don't you admonish your friend for rudely treating people who think Ruby and Rails are great by arrogantly dismissing them as hyper-enthusiasts.

And, since your last emotional post sounded pretty dense, I must again include a disclaimer: I don't speak for the Ruby community. Hopefully the community as a whole tries to emulate Matz a bit as he is very humble and kind. I have a lot of trouble being humble, especially when people like Bruce like to slap on labels like hyper-enthusiast. I'd rather tell them chinga su madre.

So, grow up Alex. If you have so many people seeking out your opinion, then be cautious when you give it and accept that you won't always be popular. Even if my treatment of you is unfair, as an adult you just learn to deal with it. You don't say ridiculous things like, 'that mean guy with a red hat pissed in my cheerios, now I don't think I can trust anybody with a red hat'. *roll eyes*

Dan Shafer

Posts: 3
Nickname: dshafer
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 11:48 PM
Reply to this message Reply
As a programming language junkie, who like early poster Mike Pence has more background as a writer than a programmer but considers himself both, this has been a fascinating and largely informative discussion. I appreciate Bruce's insight in starting it and the contributions of many who have stayed more or less on topic and enlightened me in many ways.

For me, the choice of a programming language for a particular task comes down to three decisions. More or less in rank order, these are:

1. Familiarity
2. Suitability
3. Personal Taste

Note that I said "for a particular task." There is no one perfect programming language. The task at hand must be considered. Religious wars over languages almost always omit that fact, as this thread basically has. That's OK but it does narrow the usefulness of conclusions for me.

As I examine the problem, then, I try to mentally list the languages with which I have some degree of comfort or familiarity (perhaps expertise is a better word) that would be candidates for solving the problem set. It may even require the use of more than one language.

Next, I look at each candidate language and ask myself how well suited it is to solving the particular problem set. I may seek out the opinions of others more knowledgeable either in the domain or in the language as part of that process.

Finally, unless the first two steps yield an obvious choice (which they seldom do in my experience), I make a choice based on taste. My personal taste has a preference for languages that are dynamic rather than static, object oriented rather than procedural, syntactically clean (the more like writing English they are than programming, the happier I am), and with strong graphical IDEs so that I don't have to hand-code UI elements.

For some time, I devoted a lot of energy to Python and Zope. I was never really able to feel like I'd mastered them. In part, I think, that's the fault of Zope more than Python. But I don't look for things to blame, I just recognize that reality. I'm a Ruby Nuby but I'm already quite impressed by and taken with Rails as a real-world solution to two problems on which I'm now working. I'm learning Ruby and I like what I'm seeing. (And I am a Smalltalk refugee so that won't surprise at least some of you.) So I am quite likely at this point to become a Ruby/Rails kinda developer for a while. This despite the availability of an even close-to-decent graphical IDE. (I'm probably going to create my own private code-generator using a tool that would probably only draw great disdain here, <a href="http://www.runrev.com">Revolution</a>.)

Does that mean I think Ruby is "better" than Python? Nope. It just means that, at least for now, it seems to me more comfortable to my particular taste.

To each his/her/its own.

Angsuman Chakraborty

Posts: 19816
Nickname: angsuman
Registered: Dec, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 12:18 AM
Reply to this message Reply
I very much enjoyed your article.

I have gone through Ruby and RoR. I couldn't find significant business or development advantage to jump ship. In fact the hype is rather surprising and potentially indicates immaturity of the crowd.

I would rather use PHP or Python instead of Ruby any day.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 5:45 AM
Reply to this message Reply
> > > Just so we're clear, a type to me is a set of values
> > and
> > > operations on those values.
> >
> > Yes, and that implies a contract which should be
> checked
> > and validated as early in the runtime of the
> application
> > as possible. Compile time static type checking is just an
> > earlier validation of the contract that makes it easier to
> > feel comfortable about what will happen at runtime.
>
> If you don't already know this, you won't likely benefit
> from me explaining it in depth: the type-checking the
> compiler can do is extremely limited. Therefore,
> the onus is on you again to demonstrate why the baggage
> that comes with static typing is outweighed by this
> very limited benefit.

I designed and utilized a dynamic language of my own to build a procedure control system. The number one issue that we dealt with was type based test analysis. Second was code path/coverage analysis. I provided a coverage generation dump at VM exit. The analysis data was tied to each class and would be reloaded on the next run. So, at the end of a 4 hour procedure run, we had coverage data that demonstrated which legs of code we had an had not tested. We could devise new tests or do visual walk throughs to provide 100% coverage.

The predominate contributor to type problems was lack of documentation that was browsable and accessible in an IDE like environment that we have these days.

> > > 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.
> >
> > Any language comparison, when aimed at the right
> features
> > can make one look better than the other, right?
>
> See, you can put an advanced cerebral cortex in a monkey,
> but you can't make him use it. Did you read the slides?
> No, you didn't because Jim put one whole big slide in
> there to assure you he wasn't going to tell you Ruby is
> better than Java. All he did was point out important
> things that a Java programmer should now about
> Ruby.

I read every slide. I was specifically speaking to the issue of the overview/comparison of language features. Nowhere was there mention of object serialization across the network, versioning, distributed leasing nor distributed transactions. As I said those are the things that I need and use in the systems that I design and build.

> > Further, new users/uses of the same code get to usethis
> > free testing. They don't have to implement it either.
> > Thus, my test construction is limited to tests that cover
> > semantic behaviors where I cover the vast majority of
> > issues that a human constructed test should have to deal
> > with.
>
> All the compiler can do is ensure that you are executing a
> well defined operation on a set of values (a type). That's
> it. Guess what, that is just as automatic if you write
> tests for your code.

You missed my point. The compiler is written once. It provides the tests so I don't have to write them! That's it, plain and simple. A set of tests that I don't have to write over and over and over as I do with a dynamic language.

Which single test suite you run for your python or ruby code that you can reuse every time that make sure that you have no type incompatibilities? Is that test also available to every single user of your code so that they don't have to write tests to make sure that they are using the right members/methods.

> There is no extra work required. If
> you were just writing tests to mimic a compiler doing type
> checking, that would be stupid. When you test semantic
> things, boundary conditions, etc. you get that
> compiler-like 'type' testing for free. Oops, there I went
> and explained it in more depth. You do know how to write
> tests, yes?

It might be that you can make your tests do both tests at the same time, I don't write tests in that way because the compiler has already done that for me.

> > I guess I'd have to have a language based platform, such
> > as Jini, which provides distributed leasing and
> > distributed transactions, plus a language built in
> > security model, mobile code and method overides "int
> > max(int,int)" vs "double max(double,double)" and finally
> > binary data serialization between instances of the
> > language runtime, over the network to consider a language
> > enterprise worthy.
>
> Um, the only reason why you need int max(int, int) and
> double max(double, double) is because of types.

I picked a poor example for the point I was trying to make. In some cases, you do want to make sure a value is truncated to a integral value. There are other places where you do math on integer values that must be converted to real math because of division that creates real numbers. Perhaps you like to look at a math program and decide what the range of values are.

Automatic type promotion and demotion are interesting, but can result in unexpected results when you don't control them explicitly. At least that's my experience. But, perhaps I do different math calculations that you do.

> It's a lot
> of baggage for nothing gained (unless you don't test your
> code anyway). And of course, you have to have a cast
> operator so you don't need a separate double/int(?)
> max(double, int), and on and on. Now, what happens when
> you get happy with that cast operator?
>
> And you still haven't, or perhaps didn't intend to, answer
> why static typing makes communicating about the program
> more clear.

If all you do is a bunch of string and math stuff, and you are reading software that you know the general behavior of, you'd probably be quite comfortable not seeing type information.

I, personally, want to understand the semantic behavior of the software given the range of values that I expect to use with it. I want to understand the abilities of the software that uses the values that I want to pass to it.

With a Java interface, I get automatic documentation of the expected inputs as the creator. The users get documentation that correctly documents the type based expectations. Like all API documentation, the author provided information might not enumerate all the characteristic behaviors of the software.

> > I don't do web services and I don't create web sites.
> > Those are the features that I use the most often in Java
> > a and which I don't see available in Ruby, Python or many
> > of the other non-statically typed languages which I've
> > looked at.
> >
> > Point me to these kinds of solutions for Ruby and/or
> > Python.
>
> Hmm, you're kidding, right? Okay, probably not considering
> this post: check out druby and pyro. Service locators are
> trivial (as are the rest of distributed objects) when you
> have a dynamic language like Ruby and Python.

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!

Interfaces are important for stipulating the contract of the remote service. The implementation needs to be dynamically changable to manage versioning and optimize implementation centrally without clients having to be updated and redeployed.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 11:36 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.

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.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 1:39 PM
Reply to this message Reply
Please, don't take my opinions as representative of the Ruby community -- I never meant them this way. Actually, I've been trying to specialize myself at Ruby, because I can choose a language to use almost exclusively. Since three years ago, Ruby has been gradually turning into my default language, and when it didn't have the "right tools", I built them myself, like database access, GUI database wrappers, GUI wrappers, reporting (txt, pdf, html, rtf), database administrator, a custom Ruby editor that I hope to improve it with more visual tools in the future, etc. All things that I built myself (many times based on components from other people), all part of my differentiating strategy.

Besides adopting Ruby as my main platform, I chose to support Linux as my development environments, though I intend to support Windows and Linux when deployment time comes.

So, I'm not really trying to make friends or evangelize Ruby in the best way. The Ruby people are really great and mostly don't care about what other people use -- it's your choice, right? No problem about that. Even though we might not agree with the superficial way that people make decisions sometimes, though they are valid decisions in some ways.

Cheer up. I'm cheering up. :-)

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 9:40 PM
Reply to this message Reply
> 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 to agree with Alex; the comments posted here have
> not encouraged me about the Ruby language community,

Bruce,

This is just pathetic. You are the one who painted people who find Ruby a great language and Rails an interesting framework with a broad, broad belittling brush. Are you honestly going to say that calling people hyper-enthusiasts is not derogatory and provocative?

And if you get some less than flattering responses, that means the Ruby community isn't very nice? Take it for what it is: some people who think you wrote a stupid article with a nasty slant that was totally uncalled for.

If you and Alex, for instance, are treated harshly, that's as it should be. You are more dangerous than the average jerk because you profess, and carry, the air of expertise. There's a responsibility that comes with that. If I stand up and call BS on you, it may or may not be true. However, it does a service for those who may be mislead by you.

Ruby deserves a lot of respect. There are a lot of interesting ideas in it. It is not a simple knock-off of Python or Perl. The languages are not equivalent. If they were, you could just as easily recommend Ruby instead of Python. For whatever reason, you don't like Ruby as much as Python. Fine. That's definitely your choice. But if you write nonsense belittling people that do like Ruby, I think you do deserve to be ridiculed. Since you super-sensitive, dish-it-out-but-can't-take-it, folks are also kinda dense, let me emphasize: I think you deserve it; I'm not the Ruby community.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 26, 2005 11:01 PM
Reply to this message Reply
> 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

Yes, I see your point now, and I have to agree: whatever the purported advantages of Ruby may be, the fact that Brian Ford raves so wildly about it (and about anybody who doesn't enthuse as crazily about it as he does, me and you included) is a HUGE disadvantage for Ruby to surpass.

Just one example...:
I claim the differences are mostly syntax sugar, he blasts me for it, and as one of the points allegedly showing that they're not he lists the fact that... (wait for it...) *parentheses are optional*. Yes, that's just right: to show why it's so evil of me to point out that the differences are moslty syntax sugar, he lists TYPICAL SYNTAX SUGAR ISSUES as "counterexamples"! And not just parentheses, but even *lexical* issues such as whitespace significance.

In retrospect, I apologize to the Ruby community as a whole, for even ever suspecting this Brian Ford scum might somehow be "part of it": he's clearly simply a sample of bottom-feeding low-life. The best favor he could possibly do, to Ruby as well as to the world in general, would no doubt be to keep his foul mouth shut tight, although that's no doubt beyond his understanding.

Still, if there are more rabid sickos like him prowling around the edges of that otherwise respectable community, that must still count as a serious issue. I think Python's been unusually lucky in mostly avoiding attracting that type of weirdo, perhaps because of the "dampening" influence of its highly pragmatical, commonsense, real-world-based Dutch origins.


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

I think that, much as I was inclined to do earlier, you're tainting the whole community by their association with Brian Ford. Joao, for example, has been guilty of a little over-enthusiasm, but he's also apologized for it and I don't think he attacked anybody personally, like Brian did, nor did, to the best of my recollection, post such patent absurdities as Brian's implied claim that making parentheses optional or whitespace nonsignificant is anything OTHER than *syntax sugar*.


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

Agreed on all points. Still, of all the commenters, including enthusiastic ones, only Brian Ford has definitely exceeded the norms of civil human coexistence: that he's allegedly on Ruby's side is a worry, but we're basically talking about ONE dangerous individual, I don't think we've yet seen proofs that the crazed Brian-like assault-bots have overrun a programming community that just a couple of years ago (back when I participated in that long thread on comp.lang.ruby) was still quite a decent one... only worrisome HINTS of that hypothesis, such as the fact that no other Ruby enthusiast, so far, has considered it appropriate to chastise Brian for his excesses.


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

Haven't read the book you mention (I'll look for it) but I do agree on the other points. Still, let me make a technical point: language design is a trade-off; you don't get to simplify some things without making OTHER things less simple. Consider, for example, the point of syntax sugar that Brian considers so important as to justify his despicable personal attacks against me, and later you: "parentheses are optional" to call a method... the mere MENTION of the method calls it.

This implies that "mere mention" means something utterly different for a method versus other attributes. So, to get a REFERENCE to an attribute, mentioning it is sufficient UNLESS it's a method, but if it's a method and you want a reference to it that you can seamlessly call in the future then you have to go through some syntax gyrations -- if, that is, you can get seamless polymorphism among callables at all.

In Python, it's a no-brainer: ANY mere mention ALWAYS just gets a reference; given ANY reference to a callable, you can always, if you wish, call it by juxtaposing parentheses [possibly with arguments inside, if needed]. There is hardly any "rule" to memorize here: by making the juxtaposed parentheses mean "call this thingy", like in C, the need for a chasm between callables and non-callables disappear. For an example of structured containers of callables, see for example the excellent Deferred class in Twisted (a book on Twisted has just been published by O'Reilly, though I haven't seen it yet). You CAN, I'm sure, arrange things similarly in Ruby -- but not without heavier syntax, because you can't just pass "x.y" for future reference if it's a method, you have to gyrate syntactically around it. I remember similar obstacles in Smalltalk (similar to Ruby in many ways -- except syntax sugar;-) being part of why I went back to Scheme, at the time, in my quest for the most usable VHLL (a quest I've been on for over 20 years, since I first met Rexx when it was still an internal IBM research project, which gave me my first inkling that there WERE other possible VHLL's, beyond Scheme and other Lisp variants, and besides the sheer academia of Backus' FP... a quest that, for the nonce, has led me to choose Python).


> 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, it's hard to fault that conclusion.

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

Thanks for the appreciation. If and when I do publish anything more on the subject, I will be certain to mention the Brian Ford-style rabid dogs as a potential disadvantage of Ruby, unless I should hear a strong condemnation of his unjustifiable personal attacks by other Ruby practitioners.

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

I don't think there can be any doubt about that. Should I ever want to try and sabotage some emerging technology in the future, I think I'll take a leaf from Brian Ford's book: I'll make up a credible pseudonym and pose as a rabid take-no-prisoners Rottweiler dog "defending" it by personally attacking anybody trying to be reasonably even-handed about it, "justifying" the rants by self-contradictory diatribes.

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

And that's a completely different issue from the garbage Brian Ford has posted, for sure. One may agree or disagree about specific technical arguments, but the kind of junk and personal attacks that Brian Ford has posted is obviously beyond the pale.


> 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

Good point. FWIW, my frequent experiences with the Ruby people at open source conferences has been ENORMOUSLY more positive than Brian Ford might lead one to suspect; we've shared coffees and beers and stimulating discussons, and nobody's ever been obnoxious, indeed, in my experience at those conferences, NOBODY AT ALL has EVER been anywhere as obnoxious as he is. I think that here we get a chance to check if things have changed recently: if no Ruby enthusiast speaks up strongly and unconditionally condemning Brian Ford, then that may sadly confirm the impression that the Ruby community has recently taken a horrid turn for the worse, and disgusting behavior at the Brian Ford level is now considered to be justifiable if it is "for the Cause".

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

A fair summary -- which, until Brian Ford stomped crazily on the scene attacking me with no holds barred, I might have equally used of my experiences with the Ruby community, or, for that matter, the Perl one (in which I also count a lot of friends, even though we intensely disagree on technical language-design issue we'd never DREAM of behaving as abysmally as Brian Ford appears to think he was fully justified to do).


Alex

Dan Shafer

Posts: 3
Nickname: dshafer
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 27, 2005 12:05 AM
Reply to this message Reply
Wow. This whole Brian Ford and Ruby community "tude" byplay has been so unproductive and unhelpful that both sides seem to me to obscure the real conversation.

I didn't find Mr. Ford nearly as offensive as Alex obviously did. OTOH, I didn't enjoy his participation much, either, because it seemed to me to lack substance a lot of the time. But, at the same time, I found it strange that Bruce, whose work I've long admired, would feel that -- even if the Ruby community contained a BUNCH of offensive jerks (which my experience says it doesn't) -- the presence of nimrods in a language's community somehow affects the quality or usability of the language itself.

Oh, well.

I thought it might be interesting to try to help steer this conversation back on a Java vs. Ruby (sorry, no Python in this one) slant by pointing to a recently posted piece on IBM's development site by Andrew Glover. You'll find it at http://www-128.ibm.com/developerworks/library/j-ruby/?ca=dgr-lnxw06RubyOffRails. I think it's a pretty intriguing piece even if I understood only about half the Java and about 2/3 of the Ruby.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The departure of the hyper-enthusiasts Posted: Dec 27, 2005 3:55 AM
Reply to this message Reply
> > I have to agree with Alex; the comments posted here
> > have
> > not encouraged me about the Ruby language community,
>
> pathetic.
> belittling
> derogatory
> provocative?
> stupid
> nasty
> dangerous
> jerk
> belittling
> you do deserve to be ridiculed.

QED Bruce.
Well done.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 27, 2005 2:11 PM
Reply to this message Reply
Brian, I'll start this reply as a "pythonista" who's spent the last few weeks getting his hands dirty with Ruby in order to try to "get" the language.

I, though, hope that I won't make too many mistakes.

I'll disclaim that, even though there are slight differences, I fond Ruby to be extremely similar to Python in spirit, and in capabilities. It has zones where it really shines, and others where I prefer the Python way. Overall, I really think that none of both languages is "The True Answer", and the one you pick really is a matter of personal taste (that's a short version of what I wanted to write when I first read Bruce's post/troll, back when there were no answers yet, but I decided to check what others would have to reply first)

> 1. Classes: open;
I assume you talk about the ability to re-open previously coded classes.

Truth to be told, this is a useless feature for user-defined classes. Now for the base classes of the languages, I do indeed find it wicked cool and, above the basic coolness, extremely nice.

> single inheritance; mix-ins;
This is a matter of personal taste, a toned down (less powerful) version of multiple inheritance, yet more than enough for 99.99% of the situations.

I don't really like single inheritance + mix-ins, but that's really personal taste

> class methods; singletons; singleton methods; class
> methods, class_eval; instance_eval. (I'm sure I'm
> forgetting some aspects, but these are all fantastic. and
> yes, I know, Python has something like class methods, and
> for me, decorator syntax is ugly)
Apart from the fact that you mentioned class methods twice and that I don't mind (hell, I quite like) decorators syntax, I haven't had the need to use any ruby singletons yet so I won't comment on that part

> 2. Blocks and closures
Aaah, blocks.

It's funny how 75% of the Ruby hype comes from them (nb: That number has just been Pulled Out Of My Ass).

Even more when you realise:
* That most other languages already have that with a less specific syntax (including Python)
* That blocks are not OO items, they come straight from functional programming.

What are blocks? Blocks are units of code execution, they take arguments, they reply with return values.

Damn, blocks are functions. Period.

Blocks are objects (well blocks can be converted to proc objects that can be returned and passed around as arguments, but that's trivial and usually done by Ruby under the hood, so blocks are objects).

So blocks are first-class object functions.

With closure, which most if not all languages that consider functions as first-class objects feature. And that includes not only Python, but languages as "basic" as Javascript.

The last thing, the only thing that Python misses (yes, I say misses because I find that quite annoying) is that blocks can be defined as anonymous functions. Python functions are always bound to a name (except lambdas, but lambdas are castrated functions and Guido wants to nuke them from Python 3000 so they don't count).

Blocks is merely the rubyist linguo for anonymous functions used as first class objects. Even though most rubyists don't seem to realize it (or don't want to admit it).

I find very interresting the reason why Ruby needed such a construct: Ruby has methods, these methods can be used as functions, but they have to be bound to an object, they don't feature closure, and due to the parens-less ability to call them you can't pass around Ruby methods as regular objects, because doing so would merely pass around their return values.

Damn, Ruby's not perfect and the necessity of blocks comes from one of the "features".

In fact, you can emulate ruby blocks in python with just about one more line:

Instead of
object.action do |args|
doSomething args
end

You write
def block(args):
doSomething(args)
object.action(block)

You have closure, you have FP functions that you can pass around and dynamically generate and use as return value and etc.

Wouldn't I like to be able to write
object.action( def (args):
doSomething(args)
)

now that I tried "blocks"? Truth to be told yes, even though I see many issues that we'd run into in Python (the first one being that Guido quite seems to hate anonymous functions)

Are blocks the Gift Of God?
No. Clearly not, they're anonymous functions with closure period, the birth of these things can be traced back to lisp for god's sake.

The only think we can say about them, is that Matz had the idea to use them everywhere in the code language, and that it was appropriate (at least for Ruby).

> 3. Conditional modifiers: print 'yes!' if you_like_ruby
> unless you_are_grumpy
That one is truly, completely, fully and extremely clearly a matter of taste.

While the construct reads as vanilla english and pleases the eye of the Perl refugee, it doesn't bring much, some people will like it others won't, but I don't call that a big difference.

> 4. Optional parentheses
Extremely debatable, and probably one of he reasons why Ruby had to have specific function objects (that don't want to be called functions).

The very nice thing about them, though, is that they make properties a breeze (and properties are, imo, one of the fields where Python could do much better even though the rubyists trying to diss python often use blocks to do so but very rarely use properties)

> 5. 'end' closes a "block" (not a Block in 2 above but a
> block of statements/expressions). Far from being
> cumbersome or litering code, like self in Python, this
> 'end' provides a psychological closure, which gestalt
> psychology has shown to be very important for the way the
> human brain creates meaning. If you want to understand
> closure, think about the saying, 'waiting for the other
> shoe to drop'.
Style again. I hate that end construct, even more than I hate Java's Curly Brace Forests. Others like them.

> 6. No syntatically significant white space. Usually
> this is not a problem for me in Python, but I don't like
> it and no one will ever convince me it's a good
> thing
. I have had it bite me, like when programming
> Python scripts in Zope, and it's just an annoyance I don't
> like to deal with
Style again. My editor does indentation for me, I don't worry about it, I just know that I won't have to reindent, and I have much less typing to do.

Hell, in fact that one should be merged with 5.

> 7. Libraries have been implemented from the beginning
> using blocks.
As I said, that's the only praise I'd have for blocks if I had to praise them, the fact that they're used a lot in the STL, and -- much more importantly -- the fact that they're used damn well. Most if not every usage of block in the STL is intelligent, meaningful and well thought of.

Then again, where Ruby uses blocks Python will very often use comparison functions. Different syntax, same goal.

> A recent
> example: Guido wants to remove map, lambda et al
Duh? Last time I checked Guido wanted to remove lambda and reduce, not map or filter, do you have any link for these?

Oh, and he wants to nuke out print, too *wink* *wink*

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 28, 2005 9:24 AM
Reply to this message Reply
> James,
>
> How thoroughly did you read the post that you quoted? It
> didn't state that Ruby doesn't scale well. It stated that
> Ruby used a very different model for scale out than Java,
> one that has weaknesses and strengths. You linked to an
> excellent article but seemed to misunderstand its
> subtleties.

I understood it to say Ruby doesn't support true threading inside a process. To scale, multiple processes are used. This is not a "different model" than Java, it's the lack of a model. Java can be scaled with multiple processes too. It's not a solution provided by the language, it's a work-around for the lack of a feature. In fact we run some old Java code that uses the multiple process model and it's definitely inferior to using true threading IMO.

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
> 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 3 pages [ « | 1  2  3 | » ]
Topic: The departure of the hyper-enthusiasts Previous Topic   Next Topic Topic: Java Applets + Ajax = ?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use