Shiny Red Rock

Search

It’s about That Language. All the software fashion slaves will tell you:
down on the plantation, Massa’s new missus is a far-Eastern
belle named Ruby.
Herewith Ruby remarks: on the Pickaxe, slickness, language learning, and
duckstatic typing.

How I got here was, two recent pieces of writing that made
me think heavily were Ruby-centric: Mikael Brockman’s
Continuations on
the Web and Sam Ruby’s
Rails
Confidence Builder (there is no truth to the rumor I just
made up that either the language or Sam are named for the other).

The Book ·
So I went and bought
Programming Ruby
(“Pickaxe” in the same sense that Programming Perl is “the Camel
book”) and, out on the farm in Saskatchewan, spent some quality time with its
first few hundred pages and sketching out some code (it helps that OS X comes
with an up-to-date Ruby).

The book is good; really exceptionally good.
And, since there’s no way to avoid comparisons with That Other
Language:
Based on first impressions and light exposure (a basis that matters a lot)
Ruby seems better-documented and easier to get into than Python.
I’ve actually written (a little) production code in Python, but I always had
the feeling that there was lots of stuff going on I didn’t understand; a
couple of days in, I think I have a better grasp on what Ruby’s up to, even
where I’m not looking.

The Pickaxe ain’t perfect; the typesetting automation goes off the rails at
least once.
And irritatingly, the book uncritically presents examples of
hey-ain’t-it-cool Ruby features that look to me like terrible
programming practice. For example, in the Exceptions chapter
they illustrate the use of retry with trickery from someone’s
net/smtp.rb library. The effect is just like that of COBOL’s
ALTER, deprecated 40 years ago and now often cited as
the worst feature ever to appear in a major programming language.

What’s Slick... ·
My early impression is that the whole blocking, looping, and iterating
infrastructure that falls out of the yield/{block} construct is
the best I’ve encountered in any language.
Other super-cool things:

The case statement.

The general notion of “attributes”, and the ?/!/=
method-naming tricks.

=== and ...

As for class engineering, the notion that single-inheritance plus mixins is
the Right Way To Go seems pretty plausible, based on the evidence here.

Finally, as an XML guy, I note that REXML, generally accepted as The Way To
Do XML On Ruby, comes with a
stream-processing mode, and doesn’t make the
common XML-novice everything-is-a-DOM error.

... and Unslick ·
Python still leads the pack in pure syntax elegance; all those
end statements littering Ruby code are simply unnecessary (but I
think you’d still have to keep the {} construct, if only to make
the one-liners easy to read).
If you disagree, go read Ken Arnold’s
Style is
Substance, which to my mind ends this particular debate.

The support for Unicode in regular expressions seems quite a bit behind
what you have now in Perl and Java.

I’ve had access to languages with closures and continuations and suchlike
constructs for years and years, and I’ve never ever written one.
While I’m impressed by how natural this stuff is in Ruby, I’m still
unconvinced that these are a necessary part of the professional programmer’s
arsenal.

Language Learning ·
The Pickaxe frequently calls out to other languages, comparing Ruby’s
idioms to those of Perl, Java, and C++.
This helped me an awful lot, since I can think in those languages; for
example, to a Java programmer
the terms “instance variable” and “class variable” hardly need further
explanation.
[Side trip:
In my early Java programming days I used to prefix variables with
m for class member and s for static. I eventually
decided that if you named them properly that wasn’t necessary, but I suppose
Ruby’s @ and @@ syntax sugar can’t
hurt.]

I’m wondering how Ruby would work as a learner’s first language, and how
effective the Pickaxe would be at teaching it that way; while it calls out to
other languages, it doesn’t rely on those call-outs in any essential way.

Duck and Static Typing, Again ·
Excited calls for programmers to break the shackles of static typing
are no longer revolutionary or surprising, but there’s a good one
here: The upshot is that the “safety” in “type safety” is often illusory
and that coding in a more dynamic language such as Ruby is both safe and
productive.

But you know, there are two sides to that question, and the Pickaxe
tries to be
fair: Static typing can be good for optimizing code, and it can help IDEs
do clever things with tooltip help, but we haven’t seen much evidence that it
promotes more reliable code.

Call me hidebound and conservative, but I think that “optimizing code” and
“helping IDEs” (and it’s a whole lot more than just “tooltip help”) are awfully
damn important. In particular, as James Strachan
has often argued, the combination of a good modern IDE and a statically
typed language mean that you hardly ever have to type out a full method or
variable name, and even though you might have to write more lines of Java than
you would in Ruby, you might get the code written just as fast.

And unless I’m missing something, the static typing ought to give the
compiler and runtime enough extra information to make the code run
faster; implicit in the notion of duck typing is that you’re going to spend
plenty of cycles executing code like “Does this thing have a quack
method and if not, does its superclass?”
So I suspect that both static and dynamic languages are with us for the
long haul.