David Heinemeier Hansson (DHH)

I took all the great ideas that I had learned and picked up from every different camp and I put it together.

Not because there was going to be just one single overarching theory of everything, but I was going to have a cohesive unit that incorporated the best from everywhere.

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 as 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 for 90% of the problem.

And then you're twisting yourself completely out of shape when you try to solve the last 10.

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 that could be part of the solution, that writing code could feel as good as writing a poem.

See, you could read it out.

You didn't even change anything.

Right.

Isn't that beautiful?

It's the crown jewel of Rails.

It really is.

It is the defining characteristic of how to work with Ruby on Rails.

And it's born in an interesting level of controversy because it actually uses a pattern that had been described by Martin Fowler in the Patterns of Enterprise Application Architecture, one of the

books for anyone working on business systems.

And if you have not read it, you must pick it up immediately.