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
casestatement.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.
Also, maybe I’m missing something, but it looks like Ruby’s current threading mechanism, in the context of parallelism everywhere from silicon to applications, is pretty well a toy.
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.
Conclusion · It sure looks like more than a fad to me.
