Dynamic typing

`1:06:38`

so much and what beautiful code is and what a beautiful programming language is. So one of the things that is I think implied maybe you made explicit in your descriptions there is that Ruby is dynamic typing versus strict typing. And you have been not just saying that it's a nice thing, but that you will defend dynamic typing to the death. Like that freedom is a powerful freedom to preserve. — It's the essence of what makes Ruby Ruby. This is why I don't fully understand when people call for Ruby to add static typing. 'Cause to me, it's the bedrock of what this is. Why would you wanna turn one of the most beautiful languages into something far uglier? This is one of my primary objections to static typing. It's not just that it limits you in certain ways. It makes metaprogramming harder. I write a bunch of metaprogramming. I've seen what it takes to do metaprogramming TypeScript. That was actually one of the things that just really sent me on a tear of getting meta

`1:07:39`

or getting TypeScript out of some of the projects that I'm involved with. We pulled TypeScript out of turbo. One of the front-end frameworks that we have, because I tried to write to metaprogramming in TypeScript and I was just infuriated. I don't want that experience, but I also don't want it from an aesthetic point of view. I hate repetition. We've just talked about how much I love that Ruby boils all of these expressions down to its essence. You can't remove one dot. You can't remove one character without losing something. This moment you go for static typing that you declare, at least I know there are ways to do implied typing and so forth. But let's just take the stereotypical case of a example, for example. Capital U, user, I'm declaring the type of the variable; lowercase user, I'm now naming my variable; equals uppercase user or new uppercase user. I've repeated user three times. I don't have time for this.

`1:08:40`

I don't have sensibilities for this. I don't want my Ruby polluted with this. Now I understand all the arguments for why people like static typing when the primary arguments is that it makes tooling easier. It makes it easier to do auto complete in editors, for example. It makes it easier to find certain kinds of bugs because maybe you're calling methods that don't exist on an object and the editor can actually catch that bug before you even run it. I don't care. First of all, I don't write code with tools. I write them with text editors. I chisel them out of the screen with my bare hands. I don't auto complete. And this is why I love Ruby so much, and this is why I continue to be in love with the text editor rather than the IDE. I don't want an IDE. I want my fingers to have to individually type out every element of it because it will force me to stay in the world

`1:09:42`

where Ruby is beautiful. Because as soon as it gets easy to type a lot of boilerplate, well guess what? You can have a lot of boilerplate. Every single language basically that has great tooling support has a much higher tolerance for boilerplate because the thinking is, well, you're not typing it anyway, you're just auto completing it. I don't want that at all. I want something where the fabric I'm working in, it's just a text file. There's nothing else to it. So these things play together. There's the aesthetic part, there's the tooling part, there's the metaprogramming part. There's the fact that Ruby's ethos of duck typing, I dunno if you've heard that term before. It's essentially not about, can I call this method, if a object is of a certain class. It is, can I call this method if the method responds? It's very out of Smalltalk in that regard. You don't actually check of whether that class has the method, which allows you to dynamically add methods at runtime

`1:10:45`

and do all sorts of really interesting things that underpin all the beautiful metaprogramming that we do in Ruby. I don't wanna lose any of that. And I don't care for the benefits. One of the benefits I see touted over and over again is that it's much easier to write correct software. You can have fewer bugs. You're gonna have less null pointer exceptions. You're gonna have less all of this stuff. Yeah, I don't have any of that. It's just not something that occurs in my standard mode of operation. I'm not saying I don't have bugs, of course I do, but I catch those bugs with unit testing, with integration testing. Those are the kinds of precautions that will catch logical bugs. Things that compile but are wrong along with the uncompilable stuff. So I've never been drawn into this world, and part of it is because I work on a certain class of systems. I fully accept that. If you're writing systems that have five, 10, 50 million lines of code with hundreds, thousands, or tens of thousands of programmers,

`1:11:47`

I fully accept that you need different methods. What I object to is the idea that what's right for a code base of 10 million lines of code with a hundred thousand programmers working on it is also the same thing I should be using in my bedroom to create Basecamp, because I'm just a single individual. That's complete nonsense. In the real world, we would know that that makes no sense at all. That you don't, I don't know, use your Pagani to go pick up groceries at Costco. It's a bad vehicle for that. It just doesn't have the space. You don't wanna muddy the beautiful seats. You don't wanna do any of those things. We know that certain things that are very good in certain domains don't apply to all. In programming languages, it seems like we forget that. Now, to be fair, I also had a little bit perhaps of a reputation of forgetting that. When I first learned Ruby, I was so head over heels in love with this programming language that I almost found it unconceivable that anyone would choose any other programming language at all to write web applications. And I kind of engaged the evangelism of Ruby on Rails

`1:12:48`

in that spirit as a crusade, as I just need to teach you the gospel. I just need to show you this conditional code that we just talked about and you will convert at the point of a sharp argument. Now, I learned that that's not the way. And part of the reason it's not the way is the programmers think differently. Our brains are configured differently. My brain is configured perfectly for Ruby. Perfectly for a dynamically duck typed language that I can chisel code out of a text editor with. And other people need the security of an IDE. They want the security of classes that won't compile unless you call the methods on it. I have come to accept that, but most programmers don't. They're still stuck in, essentially, I like static typing. Therefore, static typing is the only way to create reliable correct systems, which is just such a mind blowing, to be blunt,

`1:13:49`

idiotic thing to say in the face of evidence, mountains of evidence to the contrary. This is one of the reasons I'm so in love with Shopify as the flagship application for Ruby on Rails. Shopify exists at a scale that most programmers will never touch. On Black Friday, I think Shopify did 1 million requests per second. That's not 1 million requests of images. That's of dynamic requests that are funneling through the pipeline of commerce. I mean, Shopify runs something like 30% of all e-commerce stores on the damn internet. A huge portion of all commerce in total runs through Shopify and that runs on Ruby on Rails. So Ruby on Rails is able to scale up to that level without using static typing in all of what it does. Now I know they've done certain experiments in certain ways because they are hitting some of the limits that you will hit with dynamic typing.