Things I Don't Like About Ruby Pt. 1

Part one of what I am sure is a long series of things I don't like about Ruby/Rails.


  1. Application of natural language features

One of things people generally hate about programming is that computers do exactly what you tell them to do.  They don't make decisions, they don't try to guess your mind, they don't just give it a go if they're not sure what your code means.  They just do whatever they're told to do - or, more often, they just error out after you forget to put in a closing bracket.

While it's frustrating knowing that one small mistake can ruin your whole program's day, I find a lot of comfort in knowing that my program is doing exactly what I tell it to do, because if it's not working all I have to do is figure out what the right thing to say is.  It's difficult sometimes but it's straightforward.

That is, until you start using Rails or ActiveRecord.  Whoever wrote these frameworks decided that as not just as a matter of convention but as a functional aspect of how the program calls upon various objects, users should name their classes, models, migration files, etc. either with plural names or singular names, depending on what type of object/file is being made.  For instance, classes are singular while the migrations that add those classes to a database make pluralized data tables.  I am guessing because, in a somewhat metaphorical way, when you call a class thing's method, it's generally like a single one of the class things is doing something, whereas the table is a collection of the class things.

This is horrible.

While theoretically this makes understanding what each thing represents a little easier to a natural language user, what it means in practice is that the actual programmers who are actually using the language have to guess whether the names they use for things should be (or need to be) plural or singular, and if they get it wrong they get to spend a fun afternoon running through hundreds of lines of code trying to add esses to things or taking them away, and making sure that all the names of one type of object are consistent with each other while all the names of another related type of object are consistent with each other but totally distinct from the objects that have very similar and related uses in the program.

Not only is doing that a joy, but there's a bunch of weird edge cases where you're not sure how whatever it is that various generation methods use to pluralize/singularize words are going to work and you're left scratching your head as to whether or not the Ruby gods know that "pokemon" is both plural and singular and whether or not that will matter when you start coding things out.  It's no longer you vs. your coding knowledge, it's you vs. your coding skills + the natural language abilities of a mystical ruby database somewhere coded at an unknown linguo-cultural moment.

Don't even get me started on the stupidity of using both snake case *and* camel case (but only in specific spots and not in others) to make multi-word phrases understandable.

Anyway, I have heard that Ruby's creator Yukihiro Matsumoto is/was big into the idea of Ruby being a beautiful, semi-readable language with multiple ways to do the same thing.  I'm a big stan for Python's stance on there being only and preferably only one correct way to do things, but let's let that little bit of Ruby hate stand aside for a second and suppose that Matz's got, if not a defensible stance, at least a laudable goal.  WELL THEN FOR GOD'S SAKE let us do multiple things multiple ways and don't have your application frameworks get all spun when you decided that you wanted, for beauty and simplicity's sake, to have everything everywhere be singular.

That is all.

Comments

Popular posts from this blog

The Sorting Hat

Kadane's Algorithm

Loose Equality, the Null Operator, and Other Oddities