> Just on the database side, it implies that there’s a “people” table backing the “Person” record.
Plural table names are already pretty stupid, but using "people" vs "persons" even more so.
Implicitly having the table name match the entity after some case transformation is fine, but it should be more direct and not require an English dictionary to handle edge cases.
It's stupid, but it's approximately as stupid as having single object variable names, type names, collections, table names etc. all with the same, indistinguishable singular noun. It's also what programmers have dreamed about since we realised you didn't have to use punchcards, and it's what I tell people programming is like so they can understand what I do.
Rails lets you write code that can be read out loud and still make sense. You can have a meeting about an ActiveRecord class and not get caught up clarifying what you're talking about every step of the way. You could put some code in a presentation to your manager if you really wanted. In three years' time when you look at your code, you can read it aloud again and find yourself saying exactly what it does. Rails lets you describe ideas at a similar level of abstraction as common English speech. That has value, even if it lacks precision. If having a dictionary embedded into the macros is what helps people write code well, then they clearly value matching up with their brain over matching up with a compiler, and good for them.
Code isn't prose and you don't read it out loud or have it read to you. You read it with your eyes so the case of the word is clearly visible. You also have the additional context of the language of the code and syntax highlighting from your editor.
If I'm read app code, a "person" is a variable and a "Person" is a class.
If I'm reading SQL a "person" is a relation (e.g. a table).
I consider losing structure and adding complexity just to be able to read something out loud a net loss.
> I consider losing structure and adding complexity just to be able to read something out loud a net loss.
So would I. But Matz wrote early on that 'Ruby is designed to make programmers happy,' and that is behind lots of language decisions in Ruby and Rails. Reading aloud isn't an isolated end goal but more a way of describing that design principle. Writing Ruby should be a pleasant interaction, and Ruby programmers should feel like they are talking to a friendly machine. There are many ways to write the same code, and you can develop a distinctive writing style if you want. Many Rubyists talk about and write code like it's poetry, and feel like they have a voice through the code they write. Can you say that about a single Java programmer?
This isn't an accident, and effects like this are not frivolous entertainment the Real Programmers can ignore. It isn't a perfect vision, and you're absolutely right that sometimes it introduces complexity, but it's a real philosophy with tangible benefits, and pluralisation is a tiny part of that vision.
Plural table names are already pretty stupid, but using "people" vs "persons" even more so.
Implicitly having the table name match the entity after some case transformation is fine, but it should be more direct and not require an English dictionary to handle edge cases.