Hasty Generalizations Make Wastey Generalizations

chromatic on 2008-02-26T02:19:45

... what I'm seeing in Ruby is that the many ways have been transformed into idioms and guidelines. There are no hard rules, but the community have evolutionary evolved idioms that work and found out many of the ways that doesn't work.

Ruby has almost all of the flexibility of Perl to do things in different ways. But at the end of the day, none of the Perl problems tend to show up. Why is this?

Ola Bini, Language design philosophy: more than one way?

Why? Probably because you're not a very good Perl programmer.

A better question is "Why do programmers experienced with a language so often fail to have the maintainability problems that plague novices?" That might have led nicely into a discussion of idioms and the evolution of good style in a language which encourages such things.

See also the discussion why Java fans luuurve their IDEs and can't understand why those of us who can go through the TDD cycle once or twice before Eclipse finishes loading the whole project think that Java's syntax might be a touch verbose. Another fun discussion is "Why don't you Lunix types make one-click installers you can just download and click to install?"

I suppose only the familiar is awesome, and the unfamiliar is stupid and scary.


Oh I don't know

btilly on 2008-02-26T04:05:43

I'm a pretty experienced Perl programmer, but I find it easier to, say, sort an array of arrays in Ruby than it is in Perl. I also still find myself having to think about and then getting annoyed at the concept of context in Perl. So there are certainly some big Perl annoyances that don't exist in Ruby.

OTOH Perl catches most of my typos for me far more conveniently than Ruby does. That fact alone is worth a lot to me.

Re:Oh I don't know

chromatic on 2008-02-26T06:24:13

Ruby definitely has some advantages over Perl, especially with handling references (Python wins here too) and blocks (Python fails).

I don't think Ola was talking about syntactic features though. I took that to mean advice like "Don't auto-generate subs you know you need at compile time through AUTOLOAD." and "Always use the strict and warnings pragmas for code you care about."

That's the idiomatic level of programming, and it's a level you can't pick that up in a week by skimming the documentation.

Oh, come on

pdcawley on 2008-02-26T10:52:17

There's definitely aspects of TIMTOWTDI that can create maintenance headaches when you're trying to write something that can cope with those different ways. I lost count of the hoops we had to jump through when we were writing Pixie in order to cope with the myriad ways in which objects could be represented.

Then again, there's no way that Ruby would let me perform the trick of having a proxy object magically become the object it was a proxy for.

Re:Oh, come on

chromatic on 2008-02-26T18:53:50

I lost count of the hoops we had to jump through when we were writing Pixie in order to cope with the myriad ways in which objects could be represented.

I agree, and I wouldn't dream of arguing otherwise. However, the conventional wisdom in the Perl world for ages was "Just bless a hash", and now that conventional wisdom is starting to be "Use an inside-out object; encapsulation is good."

These are changes in community wisdom, not in the language, and that's the point I think Ola was trying to make.

You're right that Ruby's default OO system is better than Perl's default OO system for default cases.

Re:Oh, come on

hex on 2008-02-29T08:41:08

conventional wisdom is starting to be "Use an inside-out object; encapsulation is good."

It is? Since when? Christ. Should I start re-writing all my code?

It would probably help if I finally learn what inside-out objects actually are. Every time I've tried before, my eyes have glazed over after a few lines and I've gone back to writing plain old objects that just work the way I expect them to.

(None of this is sarcasm. Seriously.)

The Right Way To Do It

jdavidb on 2008-02-26T15:02:15

See also: The Right Way To Do It.

And I'm real curious what "the Perl problems" are.

Ruby does have some advantages.

gdey on 2008-02-26T18:38:19

The fact that Ruby has a true object model, with true data encapsulation is one major advantage over Perl. I think would and does cause problems, especially if you are not aware of it. I had a hell of a time have to re-implement (and probably doing it wrong) proper class level data encapsulation. Of course there is moose and other object frameworks that do this, but that the major stumbling block, that the native(naive) object system that everyone starts our learning and using does not do this by default.

Originally, just wanted to point out that Lindows did have a one-click installer; but, is more like a service.

Re:Ruby does have some advantages.

chromatic on 2008-02-27T07:09:50

I agree. There's just one reason Perl 6 is so much nicer to use (even now in its unfinished state) than Perl 5.

Re:Ruby does have some advantages.

pdcawley on 2008-02-28T14:27:04

Having bitched about Perl's object model, I confess that I still have a sneaking regard for it. Its very simplicity enables the cunning implementor to experiment with almost any meta object protocol they like.

In a sense, Perl 5 the language doesn't provide much more than Smalltalk the language does (smalltalk message dispatch boils down to 'tell the target object to handle this message with these arguments; it's down to the target object to decide what to do with it'), but Smalltalk the environment/library has a very rich set of objects that support a single inheritance, class based object system with powerful reflection capabilities and all that other good stuff. Sure, you _could_ roll your own system (eToys, say), but there's usually not much point.

Perl 5 just gives you "Dispatch is handled by the package into which the target reference has been blessed" and you're on your own from there. So there's no real surprise when the lazy perl programmer decides to 'just bless a hash' and carry on from there. But it also enables things like Moose. Huzzah. That flexibility lets us muck about with the semantics of objects and classes in Perl 5, before we bake 'em into Perl 6 and (one hopes) optimize the fsck out them.

Meanwhile, in ruby, you get a default object model that's pretty damned capable, but it will only flex so far before you start running out of turtles. What seems to be exciting the likes of Ola is that it's so much more capable than, say, Java's object system and, out of the box at least, gives you nicer objects than you get from unadorned Perl 5.

Re:Ruby does have some advantages.

chromatic on 2008-02-28T19:06:03

What seems to be exciting the likes of Ola is that it's so much more capable than, say, Java's object system and, out of the box at least, gives you nicer objects than you get from unadorned Perl 5.

That's completely true, and I have no objection.

I do expect, however, people who make language comparisons to have used all of the languages they compare. It doesn't suffice to port Java's "Hello, world!" to a new language and then write about how it's impossible to do things in the new language that you do every day in the one language you actually know.

Still, we've all known for a long time that I'm an unreasonable man.

Re:Ruby does have some advantages.

pdcawley on 2008-02-29T12:58:00

Do want to send me a cannon I can fire Ola out of next time we're at the same conference?

Re:Ruby does have some advantages.

chromatic on 2008-02-29T18:43:41

We've met actually. Ward Cunningham introduced us. My mind boggles sometimes.

Re:Ruby does have some advantages.

pudge on 2008-03-20T16:36:59

Still, we've all known for a long time that I'm an unreasonable man.
Just like Ralph Nader! (BTW, I quite enjoyed that movie. I've always admired Nader even when I thought he was full of it, because he desires what he thinks is good for everyone, and he has principles, and actually acts on them. Imagine that. If this is at the core of being unreasonable, then we need more unreasonable people.)

Perl on-click installer...

Alias on 2008-02-27T03:09:43

I should probably avoid mentioning my idea for adding a URI handler to pip so that you can make a one-click installer web link like pip:://server/path.tar.gz :)

At least until that later conversation.