Rails manifesto: Principles of a great programming language

`2:07:53`

I can actually understand all of HEY. Both of those systems are just over a hundred thousand lines of code. I've seen people do this that maybe twice, maybe three times that scale and then it starts breaking down. Once you get north of certainly half a million lines of code, no individual human can do it and that's when you get into maybe some degree of microservices can make sense. — Basecamp and HEY are both a hundred thousand? — A hundred thousand lines of code thereabouts. — Wow, it's small. — It is. Considering the fact that Basecamp I think has something like 420 screens, different ways and configurations. — Ah, do you include the front end in that? — No, that's the Ruby code. Well, it's front end in the sense that some of that Ruby codes. It's beneficial to the front, but it's not JavaScript for example. Now the other thing we might talk about later is we write very little JavaScript actually for all of our applications. HEY, which is a Gmail competitor. Gmail ships I think 28 megabytes of uncompressed JavaScript. If you compress it, I think it's about six megabytes, 28 megabytes. Think about how many lines of code that is. When HEY launched, we shipped 40 kilobytes. It's trying to solve the same problem.

`2:08:55`

You can solve the email client problem with either 28 megabytes of uncompressed JavaScript or with 40 kilobytes if you do things differently. But that comes through the same problem essentially. This is why I have fiercely fought splitting front end and back end apart. That, in my opinion, this was one of the great crimes against web development. That we are still atoning for. That we separated and divided what was and should be a unified problem solving mechanism. When you are working both on front end and back end, you understand the whole system. And you're not going to get into these camps that decompose and eventually you end up with like GraphQL. — Okay, let's fly through the rest of the doctrine. No one paradigm. — No one paradigm goes to the fact that Ruby is a fiercely object- oriented programming language at its core, but it's also a functional program language. This five times I told you about, you can essentially do these anonymous function calls

`2:09:58`

and you can chain 'em together very much in the spirit of how true functional programming languages worked. Ruby has even moved closer towards the functional programming and of the scale by making strings immutable. There are ideas from all different disciplines and all different paradigms of software development that can fit together. Smalltalk, for example. With only object oriented, and that was just it. Ruby tries to be mainly object oriented, but borrow a little bit of functional programming, a little bit of imperative programming, be able to do all of that. Rails tries to do the same thing. We're not just gonna pick one paradigm and run it through everything. Object orientation is at the center of it, but it's okay to invite all these other disciplines and it's okay to be inspired. It's okay to remix it. I actually think one of the main benefits of Rails is that it's a remix. I didn't invent all these ideas. I didn't come up with active record. I didn't come up with the NBC way of dividing an application. I took all the great ideas that I had learned and picked up from every different camp

`2:11:01`

and I put it together. Not because there was gonna be just one single overarching theory of everything, but I was gonna have a cohesive unit that incorporated the best from everywhere. — Is that idea a bit at tension with the beauty of the monolith system? — I think the monolith can be thought of as quite roomy, quite as a big tent that the monolith needs actually to borrow a little bit of functional programming for the kinds of problems that that excels, that discipline excels at solving, and that paradigm excels at solving. If you also want object orientation at its core. I actually think when I've looked at functional programming languages, there's a lot to love. And then I see some of the crazy contortions they have to go through when part of the problem they're solving calls for mutating something. And you go like, holy shit, this is a great paradigm from 90% of the problem. And then you're twisting yourself completely out of shape when you try to solve the last 10. — Ooh, exalt beautiful code is in the next one.

`2:12:03`

— We've talked about that at length and here's a great example that really summarizes the domain specific language quality of Ruby on Rails that you can make code actually pleasant to write and read. Which is really funny to me because as we talked about when I started learning programming, it wasn't even a consideration. I didn't even know that that could be part of the premise, that could be part of the solution. That writing code could feel as good as writing a poem. — class Project, ApplicationRecord belongs_to:account has many participants. Class_name, Person, validates_presence_of:name. — See, you could read it out. You didn't even change. — Anything like a haiku or something. — Right? Isn't that beautiful? — Yeah, it's nice. It's really nice. There's an intuitive nature to it. Okay, so I have specific questions there. I mean ActiveRecord, just to take that tangent. That has to be your favorite feature. — It's the crown jewel of Rails. It really is.