Ruby is not a serious programming language

My little theory It is that the concept of “imprinting” in psychology can be easily applied to programming: just as a baby goose decides that the first animated life form it encounters is its parent, so embryonic programmers form irremovable attachments to the patterns and essence of their first formative language.

For many people, that language is Ruby. He is often credited with making programming “click”; Publicists speak of it with a certain amount of indebtedness and affection. I get it. I wrote my first book, Hello World, in a terrible language called Java, but programming only started to seem intuitive once I learned it. Javascript (I know, I know) and OCaml, both of which basically shaped my taste.

I arrived a little late to Ruby. It wasn’t until my fourth job that I found myself on a team that primarily used it. By then, I had heard enough paeans to its elegance that I was filled with anticipation, ready to be charmed, to experience the kind of professional satori described by its followers. My dislike for it was immediate.

Coming to a language late means seeing it without the self-indulgent fog of sentimentality that comes with imprinting—the endearing willingness to overlook a flaw as odd. What I saw was not a jeweled gadget, but rather a nasty little thing that had not received the news that the world of programming had evolved.

Ruby was created It was created in 1995 by Japanese programmer Yukihiro Matsumoto, affectionately called “Matz”. Aside from creating the only major programming language to originate outside the West, this Osaka-born practicing Mormon is also known for being exceptionally kind, so much so that the Ruby community has adopted the slogan MINASWAN, which means “Matz Is Nice And So We Are Nice.”

As befits this, as well as its pretty name, Ruby is easy on the eyes. The syntax is simple, without semicolons or parentheses. Even more so Python– A language known for being easy to read – Ruby reads almost like plain English.

Programming languages ​​are generally divided into two camps: statically typed and dynamically typed. A fixed-type system is like a set of Lego pieces where the pieces only interlock with other pieces of the correct shape and size, making some errors physically impossible. With dynamic typing, you can put the pieces together as you want. While this is theoretically more flexible on a small scale, this freedom backfires when you’re building large structures – certain types of errors are only detected when the program is running. In other words, the minute you put weight on your Lego footbridge, it slides into a useless pile.

You may have guessed that Ruby is dynamically typed. Python and JavaScript are, but over the years, these communities have developed sophisticated tools to make them behave more responsibly. None of the current Ruby solutions are on par with these solutions. They’re very useful for what programmers call “shotguns,” features that make it very easy to shoot yourself in the foot.