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.
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.
10 Comments
so, why do you hate ruby? is this another blog dedicated to destroy ruby?
for me it’s obvious that you don’t understand ruby and DO NOT WANT TO, you just want to destroy it, I don’t know why.
probably cos it’s cool to blame ruby.
btw, those blogpost about ruby types are YOUR fault not ruby, probably you know but it doesn’t matter.
i didn’t think it was a joke, I just skimmed the post and said, “Who cares?”
To each their own. If someone wants to spend all day hacking Forth then go for it. Or Objective-C, for that matter. A lot of innovation comes out of Ruby and I think people’s willingness to experiment with weird/strange APIs and openness of the source code (so others can see how it was done) have a lot to do with it.
In my defense, while I totally missed the satire until the last sentence, I didn’t actually agree with what you wrote. I do prefer Ruby to most other languages (except maybe OCaml and a few others), but the bit about libraries producing incomprehensible error messages bugged me. The solution is to file a bug report and insist on better error messages. And frankly, that’s the solution for every single language out there, IMHO. In fact, if you have an exception from deep within the bowels of your program bubble up far enough that it no longer makes sense, but it’s still an exceptional situation, you should be catching and rethrowing it with a new error message that makes more sense within that context. And even then, you should still be catching that exception wherever you’re best prepared to handle and recover from the exception. 500 errors are never a valid response to user input. :-P
Also, method redefinition in Ruby is way, way too messy.
@Bobby
Did you actually read this post? I don’t hate Ruby. And this blog is certainly not dedicated to destroying it.
At first, I was going to come out against OCaml or Groovy, but seeing as how this blog has already done that in all seriousness (cite, cite, cite), it wouldn’t be much of a joke.
Then I was going to come out and write a love letter to Ruby, but I was afraid it’d be taken seriously and passed around without context, so I ended up hedging everything I was saying with warnings about how it can be abused: “Mixins are great and awesome and wonderful, but…”, “The Ruby’s successful sale of method_missing to the mainstream is a revolutionary change for programming, but…” Both times I tried to write that post, the result read less “love letter” and more “contract offering”. So I abandoned that approach.
In frustration, I pinged Brian, and he sent me the “Real Programmers” page, and it was all over. :)
As for “Why Ruby” as opposed to other languages — I targeted Ruby for an April Fool’s joke because there is such a large and easily-riled-up community (as you well demonstrate), and because I’ve read some pretty naive stuff that was only slightly more absurd than my own satire, so I figured the satire would come off was vaguely plausible and would get more shares throughout the web. That plan actually worked better than I expected — almost frighteningly better.
@Bob Aman
One of the downsides of monkey-patching is that it breaks down the feedback loop between libraries and their users: why put the effort in to submit a patch when I can just attach a fix to my own code and move on? Of course, from the user’s standpoint, it’s extremely nice — it gives the ability to fix the library without having to check out the source code, patch it, and re-build the library.
Ouch. You caught me, even though, in my comment, I argued against one part of your post, I didn’t detect the satire, possibly because it’s too close to true? :)
By true, I mean that there are quite a number of dynamic language zealots out there who write in a similar vein but sincerely. When your post came up in my reader, I thought I had to chip in on the other side, but alas, I was mistaken… :)
Wow. 4500 unique visitors to “Ruby is the Future” on April 1st. It usually takes me a whole month to rack up that much traffic.
@RobertFischer You just need to write more controversial posts.
Mark
Hi, Robert.
In my role as the care and feeding for a relatively large and involved Rails application, I can assure all readers that bullets # 1, 5, and 6 are real issues. My question is this: doesn’t more freedom/flexibility imply more points of failure? If so, might that not be a good tradeoff?
I am not certain what the future holds, of course, but I believe that as time passes, the Rails community will have more opportunity at mature libraries with the “just-right” balance of flexibility and stability in construction and performance. Perhaps this just reinforces bullet 6 however! Some users will need to examine the code to make such a determination.
@bigfleet
It might be a good trade-off. Of course, if you could have more flexibility/freedom *and* reduce the points of failure (a la Duby), wouldn’t that be even better?
2 Trackbacks
[...] [ Edit: More on this at the post "Ruby is the Future 2".] [...]
[...] which is why I satired that functionality in Ruby is the Future (be sure to read the follow-up at April Fails or April Fools Epic Win? On “Ruby is the Future”). Whatever the reason, though, Ruby developers seem motivated to really explore and grok and push [...]