All the Perl that's Practical to Extract and Report

Ruby -- first impressions

jplindstrom on 2007-11-27T22:31:13

I did some Ruby work at work today. Initial impressions:

  • It's very Perlish. Mostly in a good way. No value sigils, but overall tighter syntax. No ugly dereferencing brace fest, and methods on basic datatypes makes for clean code if you are willing to make an effort.

    I remember someone saying Ruby is Perl's younger, hotter sister. Well, they are clearly related. And she is hot.

  • The block syntax is really nice.

  • Very sparse documentation of method definitions in this app. Not sure whether that's a project thing or a general Ruby/library thing. I mean, It's not like I have been spoiled rotten with well documented Perl enterprise source code historically.

    But wearing the maintenance hat, exploring a code base with zero prior knowledge clearly reveals the need to document what kind of objects are being passed around in a dynamic language. I wonder if the type inferring statically typed languages (Haskell) have the same kind of issues compared to explicitly typed languages (Java).

  • In Ruby, local variables are created on first use. No declaration of these seems... well, insane. This already bit me, and I've been using Ruby for, what, a day?

    I'm a bit curious about the phenomenon. In Perl there's "use strict" and then lexicals are declared with "my". That's such an obvious life saver and such a strongly encouraged practice that it's mind boggling to see people not using it. Not being able to use it. But at the same time... is this the way people using statically typed languages all day look at dynamic languages, not believing it's possible to live without type declarations all over the place?

    There are obvious benefits for understanding the code (see above) to have e.g. type information available in method signatures (not the least the ability to do static analysis of the code for refactorings and command completion, etc), just as there are obvious benefits to not having to care about it until the latest possible moment (late binding). So there's a trade-off there. And you can keep it somewhat sane by documenting as needed (folks, more true laziness, please).

    I can't see the potential advantage of not declaring lexicals. Maybe I'm missing something. Maybe I'll come around. But I'm guessing not, this seems like a genuine misfeature.

  • There seems to be two kinds of exceptions, those you "raise" and those you "throw". There is a distinction, I haven't quite figured out what it is yet though :) Right now I just find it interesting. Off to the manuals.

  • Lanuage documentation is decent. Usually a quick Google for anything yields useful results. Same seems to hold for ActiveRecord and friends, but I haven't been doing anything interesting with it yet.
All in all, a pleasant experience.

I have the same complaint

btilly on 2007-11-28T04:06:02

Not having an option to force declaration of variables is a mistake and is one of my main complaints about the language.

Another is the semi-optional semi-colons. That fights with how I'd like to format code.

Declaring types and names: not the same thing

Aristotle on 2007-11-28T04:42:11

But at the same time… is this the way people using statically typed languages all day look at dynamic languages, not believing it’s possible to live without type declarations all over the place?

I think you are forgetting something: you can write Perl without the vars stricture! If living without name declarations was like living without type declarations, wouldn’t we be doing that in Perl too? Yet community experience is that this is clearly unwise. Obviously, all kinds of declarations are not created equal.

I find, in fact, that the declare-as-you-go nature of my in Perl makes it a trivial burden. Most of the time, I don’t declare variables prior to first use – I declare them in the first use. Yet by having to explicitly declare my intent to introduce a new variable name, I am protected against typos-come-logic-bugs, which may be an incredibly trivial mistake yet may take hours to debug.

And I make such mistakes reasonably often. So unlike the questionable gains from weak type systems like Java’s, this typo protection saves my bacon every day. Weighing the effort of declaring names against the benefits of doing so yields an overwhelming net positive. The effort in declaring types is much greater, and it has great costs along other axes (it puts an artificial burden on abstraction and even limits its extent, thereby necessitating more code), so that on balance, it is at best of debatable benefit. (Personally, I think yields a net negative, but reasonable people disagree about that.)

Re:Declaring types and names: not the same thing

jplindstrom on 2007-11-28T13:27:20

Well, I agree. I was just reflecting on the mindset and attitude of the static typer.

BTW, I think this image as a comment on non-inferring static type systems is a) hilarious, and b) insightful (from a Steve Yegge essay).

Ruby

djberg96 on 2007-11-29T10:16:51

Very sparse documentation of method definitions in this app. Not sure whether that's a project thing or a general Ruby/library thing.
Sounds like a person-who-developed-the-app thing.

But wearing the maintenance hat, exploring a code base with zero prior knowledge clearly reveals the need to document what kind of objects are being passed around in a dynamic language.
Sounds like a documentation problem again. BTW, you may be interested in Python's function annotations.

I'm a bit curious about the phenomenon. In Perl there's "use strict" and then lexicals are declared with "my". That's such an obvious life saver and such a strongly encouraged practice that it's mind boggling to see people not using it.
Strange, it only seems to be the Perl veterans who are stunned by this, and I'm surprised they're surprised. It's one of the things I can't stand about Perl and one of the reasons I switched.

It's a non-issue in practice because most Ruby users organize their code into classes and modules. Methods tend to be short, so the odds of you making a mistake are low. I've never actually seen a bug caused by this with local variables. With instance variables, I've caught a (very) few people making a mistakes with typos. But, those are easily smoked out by running with -w, which is how most people run their tests anyway.

There seems to be two kinds of exceptions, those you "raise" and those you "throw". There is a distinction, I haven't quite figured out what it is yet though :) Right now I just find it interesting. Off to the manuals.
No, catch/throw is for control flow only, typically used for nested control handling.

All in all, a pleasant experience.
Glad to hear it!

Re:Ruby

Aristotle on 2007-11-29T13:06:55

It’s one of the things I can’t stand about Perl and one of the reasons I switched.

You mean use strict 'vars' wrote itself into your Perl programs no matter how hard you tried to erase it? Weird.