David Heinemeier Hansson (DHH)

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 shit like GraphQL.

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 programming language.

This five times I told you about, you can essentially do these anonymous function calls and you can chain them together very much in the spirit of how true functional programming languages work.

Ruby has even moved closer towards the functional programming end of the scale by making strings immutable.

So there are ideas from all different disciplines and all different paradigms of software development that can fit together.

Smalltalk, for example, was 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 going to 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 in.

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 MVC way of dividing an application.