Rails manifesto: Principles of a great programming language

`1:59:40`

We forget why Chesterton's Fence is there. We just go like, why is that fence there? Let's yank it out. Oh, it was to keep the wolves out. Now we're all dead, oops. So I wanted to write these things down. And if we just take them quick one by one, you talked about optimizing for programmer happiness. I put that at number one in homage of Matz, and that's a lot about accepting that there is occasionally a trade off between writing beautiful code and other things we want out of systems. There could be a runtime trade off, there can be a performance trade off, but we're gonna do it nonetheless. We're also going to allow ambiguity in a way that many programmers, by default, are uncomfortable with. I give the example actually here of in the interactive Ruby shell where you can play with the language or even interact with your domain model. You can quit it in two ways, at least that I found. You can write exit. Boom, you're out of the program. You can write quit. Boom, you're out of the program. They do the same thing. We just wrote both exit

`2:00:40`

or the people who built that wrote both exit and quit because they knew humans were likely to pick one or the other. Python is the perfect contrast to this. In the Python interactive protocol, if you write exit, it won't exit. It'll give you a lesson. It'll basically tell you to read the fucking manual. It says use exit parentheses or Ctrl-D i.e. end of file to exit. I'm like, one is very human and another is very engineer. And I mean that both of them in the best possible way. Python is pedantic. Python is the value from the start stated is that there should be preferably one and only one way to do a certain thing. Ruby is the complete opposite. No, we want the full expression that fits different human brains, such that it seems like the language is guessing just what they want. — And part of that is also described the principle of least surprise,

`2:01:41`

which is a difficult thing to engineer into a language because you have to kind of, it's a subjective thing. — Which is why you can't do it in one way, which is why I used the example of both exit and quit. The principle of least surprise for some people would be like, "Oh, exit. That's how I get out of the prompt." For other people it'd be quit. Why don't we just do both? — Okay, so what's the convention over configuration? That's a big one. — That's a big one. That's a huge one. And it was born out of a frustration I had in the early days with especially Java frameworks where when you were setting up a web application framework for Java back in the day, it was not uncommon to literally write hundreds if not thousands of lines of XML configuration files. Oh, I need this. I want the database to use the foreign keys as post_id. No, no, no, I wanted as post capital ID. Oh, no, no, no, you have to do it capital PID. There are all these ways where you can configure how foreign relation keys should work in a database and none of them matter.