April Fails or April Fools Epic Win? On “Ruby is the Future”

Wow.

So, some people realized it, some people didn’t, and some people weren’t sure what to make of it, but the Ruby is the Future post was an April Fool’s Day joke. It was intended to be satire, starting with plausibly-beneficial-yet-dubious aspects of Ruby and ending with downright bad practices, and defending any failing with “MORE UNIT TESTS!” The goal was to see how far into the post I could get people before they realized it was a satire: I never imagined I’d get them all the way to the end.

Here are a few highlights that were apparently missed by those who thought it was profound wisdom, or who think all the points I made were good ones. In rough order of pronouncement:

• Library design should be disregarded flagrantly. Upgrade paths and APIs be damned — just reach in and grab what you need from libraries.
• It’s best to generate your class by gluing things together willy-nilly at runtime. It’s even better if you’re doing this to undercut safety checks. Triply awesome if you’re doing this to circumvent your boss and putting things together in completely novel ways in production.
• Ruby needs lots of unit tests, but it also makes it hard/impossible to vet every possible usage case, so you should just unit test the happy path, and that’s a Good Thing. Unit testing failure paths just slows you down.
• More generally, meaningful error handling is for morons and wussies.
• A library exploding and forcing you to burn time spelunking into the bowels of its implementation is 1) a standard occurrence, and 2) a good thing.
• Of course, you really should just grok the entirety of the implementation of a library before you use it in the first place. You do read all your gem source files thoroughly, don’t you?
• It’s not worth fixing code: a complete rewrite of the code is the only proper response to a bug.

If that’s the kind of stuff you believe (apparently like this redditer), I don’t want you anywhere near my code. Or my business.

The last line linked to the exceedingly dated Real Programmers Don’t Use Pascal page, which was a major point of inspiration (and provided to me courtesy of Brian Hurt). I figured that if people hadn’t figured it out by that point, they would when they realized I was saying Ruby was for “Real Programmers”. The page linked to talks about “Real Programmers”, and describes them thusly:

• Real Programmers aren’t afraid to use GOTOs.
• Real Programmers can write five page long DO loops without getting confused.
• Real Programmers like Arithmetic IF statements– they make the code more interesting.
• Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop.
• Real Programmers don’t need comments– the code is obvious.
• Since Fortran doesn’t have a structured IF, REPEAT … UNTIL, or CASE statement, Real Programmers don’t have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.

[...]
As all Real Programmers know, the only useful data structure is the Array. Strings, Lists, Structures, Sets– these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications. The worst thing about fancy data types is that you have to declare them, and Real Programming Languages, as we all know, have implicit typing based on the first letter of the (six character) variable name.

[ My running theory is that the content is tangential to some of the judgments made, as there is some partisan brain action is in play: something self-identifying as positive about Ruby == Right; something self-identifying as negative about Ruby == Wrong. Therefore, the argument must be good (even if it's intended as satire!), and the person who thinks its satire must be silly (even if they're the author!). ]

At the base of “Ruby is the Future” is a kernel of truth, though: a genuine realization I had while working on Scala and Cornerstone. The fact of the matter is that in one form or another, business languages are going to be expected to mimic certain aspects of Ruby. Note that Scala — the functional/über-static Java.next de saison — is being expected to defend its mixins and open class alternatives, as well as its ability to create “internal DSLs” (which really means the flexibility/abuseability of its syntax).

And that expectation is rather fair: although the DSL vogue is rapidly calming down to sanity (cite, cite?), the reality is that the business world is waking up to how much very real damage has been done by Java’s inflexibility, and so any language that smells of the same straitjacket is going to be dismissed out of hand.

This means that more flexible approaches to programming are simply mandatory these days. And while many of the stunts of Ruby are very powerful, and I like them quite a bit, there’s got to be a more sane way to apply them — some way to apply them and still have the confidence of knowing the language’s standard library distribution wasn’t hosed by someone forgetting to check in. I suspect that kind of thinking is behind Duby, and it’s certainly what’s behind Cornerstone.

Related posts:

1. Ruby is the Future
2. Best April Fools Sites
3. Ruby + XML: A Serious Question That Only Sounds Facetious
4. My Fundamental Issue with Ruby
5. Postgres for the win!