.jpg?w=860&resize=860,0&ssl=1)
My little theory is that the concept of “imprinting” in psychology can just as easily be applied to programming: Much as a baby goose decides that the first moving life-form it encounters is its parent, embryonic programmers form ineradicable attachments to the patterns and quiddities of their first formative language.
For many people, that language is Ruby. It’s often credited with making programming “click”; imprintees speak of it with a certain indebtedness and affection. I get that. I wrote my first “Hello world” in an awful thing called Java, but programming only began to feel intuitive when I learned JavaScript (I know, I know) and OCaml—both of which fundamentally shaped my tastes.
I arrived somewhat late to Ruby. It wasn’t until my fourth job that I found myself on a team that mainly used it. By then, I’d heard enough paeans to its elegance that I was full of anticipation, ready to be charmed, to experience the kind of professional satori its adherents described. My dislike for it was immediate.
To arrive at a language late is to see it without the forgiving haze of sentimentality that comes with imprinting—the fond willingness to overlook a flaw as a quirk. What I saw wasn’t a bejeweled tool but a poor little thing that hadn’t quite gotten the news that the world of programming had moved on.
Ruby was created in 1995 by the Japanese programmer Yukihiro Matsumoto, affectionately called “Matz.” Aside from creating the only major programming language to have originated outside the West, this Osaka-born practicing Mormon is also known for being exceptionally nice, so much so that the Ruby community adopted the motto MINASWAN, for “Matz Is Nice And So We Are Nice.”
Befitting this, as well as its pretty name, Ruby is easy on the eyes. Its syntax is simple, free of semicolons or brackets. More so even than Python—a language known for its readability—Ruby reads almost like plain English.
Programming languages are generally divided into two camps: statically typed and dynamically typed. A static-type system resembles a set of Legos in which pieces interlock only with others of the right shape and size, making certain mistakes physically impossible. With dynamic typing, you can jam pieces together however you want. While this is theoretically more flexible on a small scale, that freedom backfires when you’re building large structures—certain types of errors are caught only when the program is running. The moment you put weight on your Lego footbridge, in other words, it slumps into a useless heap.
Ruby, you might’ve guessed, is dynamically typed. Python and JavaScript are too, but over the years, those communities have developed sophisticated tools to make them behave more responsibly. None of Ruby’s current solutions are on par with those. It’s far too conducive to what programmers call “footguns,” features that make it all too easy to shoot yourself in the foot.
