DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474

No one anywhere who's serious believes that Cookie banners

does anything good for anyone.

Yet, we've been unable to get rid of it.

This is the thing that really gets me about cookie banners, too.

It's not just the EU.

It's the entire world.

You can't hide from cookie banners anywhere on this planet.

If you go to goddamn

Mars on one of Elon's rockets

and you try to access a

web page, you'll still see a cookie banner.

No one in the universe is safe from this nonsense.

It sometimes feels like we're barely better off.

Like web pages aren't that different

from what they were in the late 90s, early 2000s.

They're still just forms.

They still just write to databases.

A lot of people, I think, are very uncomfortable

with the fact that they are essentially CRUD monkeys.

They just make systems that create,

read, update, or delete

rows in a database.

And they have to compensate

for that existential dread

by over complicating things.

That's a huge part of the satisfaction

of driving a race car is driving it at the edge of adhesion,

as we call it,

where you're essentially just a tiny movement away from spinning out. Doesn't take much.

Then the car starts rotating.

Once it starts rotating,

you lose grip and you're going for the wall.

That balance of danger

and skill is what's so intoxicating.

The following is a conversation

with David Heinmire Hansen,

also known as DHH.

He is a legend

in the programming and tech world.

Brilliant and insightful, sometimes

controversial and always fun to talk to.

He's the creator of Ruby on Rails,

which is an influential

web development framework behind many websites used by millions of people,

including Shopify, GitHub, and

He is the co-owner

and CTO of 37

signals that created base camp

and once he is a New York Times best-selling

author together with his co-author

Jason Frerieded of four books

rework remote getting real

and it doesn't have to be crazy at work.

And on top of that,

he's also a race car driver,

including being a class winner at the legendary 24-hour lemon race.

This is the Lex Rubin podcast.

To support it, please check out our sponsors in the description and

consider subscribing to this channel.

And now, dear friends, here's DH.

For someone who became a legendary

programmer, you officially got into programming late in life.

And I guess that's because

uh you tried to learn how to program a few times and you failed.

So can you tell me the uh the full story, the saga

of your failures to learn programming?

Was Commodore 64 involved?

Commodore 64 was the inspiration?

I really wanted a Commodore 64.

That was the first computer I ever sat down in front.

And the way I sat down in front of it was I was 5

years old and there was this one kid on my street who had a Commodore 64.

No one else had a computer,

so we were all the kids just getting over there and we were all

playing Y Kung Fu.

I don't know if you've ever seen that game.

It was one of the original fighting games.

It's really a great game.

And I was playing that for the first time at 5 years old.

And we were like seven kids sitting up in this

one kid's bedroom all taking our turn to play the game.

And I just found that unbelievably interesting.

And I begged and I begged and I begged

my dad, could I get a computer?

And he finally comes home.

He's like, "I got your computer."

I was like, "Yes,

my own Commodore 64."

And he pulls out this

black, green, and blue keyboard.

That's an Armstrong 464.

I was like, "Dad, what's this? >> The disappointment.

>> This is not a Commodore 64."

But it was a computer.

So, I got my first computer at essentially 6 years old, that Armstrad 464.

And of course, the first thing I wanted to do, I wanted to play video games.

And I think the computer, which he, by the way, had traded

for a TV and a stereo

recorder or something like that, came with like two games.

One was this Frogger game where you had to escape from underground.

It was actually kind of dark, like this frog.

You're trying to get it out from underground.

And I was just I was pretty bad at it.

And I only had those two games.

And then I wanted more games.

And one way to get more games when you're a kid who don't have

a lot of money and can't just buy a bunch of games is to

type them in yourself.

Back in ' 84 85

magazines would literally print source code

at the back of their magazines

and you could just sit and type it in.

So I tried to do that and it would take like two hours

to print this game into

the Armistrad and of course I'd make some spelling mistake along the way and

something wouldn't work and the whole thing

I wasn't that good of English.

I was born in Denmark.

So I was really trying to get into it because I wanted all these

games and didn't have the money to buy them

and I tried quite hard for quite a while to get into it but

it just never clicked.

And then I discovered the magic of piracy.

And after that I kind

basically just took some time off from learning to program

because well now suddenly I had access to all sorts of games.

So that was the first attempt

like around six seven years old.

And what's funny is I remember these fragments.

I remember not understanding

the purpose of a variable.

If if there's a thing and you assign something, why would you assign another thing to it?

So, for some reason, I understood constants.

Like, constants made sense to me, but variables didn't.

Then, maybe I'm 11 or 12.

I've gotten into the AmIGGA at this point.

The Amigga, by the way,

still perhaps my favorite computer of all time.

I mean, this is one of those things where you like people get older

and they're like, "Oh, the music from the 80s was amazing."

To me, even as someone

who loves computers, who loved new computers,

the AmIGGA was this magical

machine that was made by the same

company that produced the Commodore 64.

And I got the AmIGGA

500, I think in

>> Look at this sexy thing.

That is a sexy machine right there.

>> This is from an age, by the way, where computing

wasn't global in the same sense.

The different territories had different computers that were popular.

The Amigga was really popular in Europe,

but it wasn't very popular at all in the US, as far as I understand.

It wasn't popular in Japan.

The there were just different machines.

The Apple 2 was a big thing in the US.

I'd never even heard of Apple in the8s in Copenhagen.

But the Omega 500 was the machine that

brought me to want to try it again.

And you know what's funny?

The reason I wanted to try it again was I remembered the first time to learn.

And then there was this programming language that was literally called easy Amos.

>> Like the easy version of Amos.

I'm like, if it's if it's easy Amos, how hard can it be?

I got to be able to figure this out.

And this time I tried harder.

I got into conditionals.

I got into loops.

I got into all these things and I still I couldn't do it.

And on the second attempt, I really got to the point like maybe this

is just maybe I'm not smart enough.

Maybe programming is just not maybe it's too much math.

Like I like math in this sort of superficial way.

I don't like it in the deep way that some of my

perhaps slightly nerdier friends did who I had tremendous respect for.

Like I'm not that person.

I'm not the ma math geek who's going to figure it all out.

So after that attempt

with easy Amos and failing to even get I don't even think I completed

one even very basic game.

I thought the program is just not for me.

I'm going to have to do something else.

I still love computers.

I still love video games.

I actually at that time had already begun making friends with people who knew

how to program who weren't even programming easy Amos.

They were programming freaking Assembler.

And I would sit down and just go

I'm how do you the moves and the memories and the copies?

How do you even do this?

I don't even understand

how you go from this

to AmIGGA demos, for example.

That was the big thing with the Amigga.

had this wonderful demo scene in Europe.

It's this really interesting

period of time in the Amigga's

history where you had all these programmers spread out mostly all over Europe who

would compete on graphic competitions

>> where you could probably bring one of these on YouTube

on on this thing.

They would make these little

um almost like music videos

combining some MIDI music, combining some cool graphics

and they would do all of it in like 4K.

4 kilobytes that is

not 4K is a revolution,

4 kilobytes of of memory.

And I just thought that was such a cool scene.

This was obviously pre- internet.

It was even prebs

bulletin board systems to some extent.

me was you swap

your demo software with someone else by sending them a disc in the mail

>> like the 3.5s and I just I was enamored

with that whole scene.

I was enamored with what they were able to create and I just wanted

to be a part of it even though I kind of didn't have any

skills to contribute and that's how I got into running BBS's.

I didn't learn programming

then and I wouldn't learn programming until much later until I was almost 20 years old.

The bulletin board systems existed in this funny space where they were partly

a service to the demo scenes allowing

all these demo groups to distribute their amazing demos.

And then it was also a place to trade piracy software, pirated software.

And I ended up starting one of those when I was 14

years old in my tiny little bedroom in Copenhagen.

I had my at that point Amigga 4000.

I had three telephone

lines coming into my tiny

>> Which was funny because again, I'm 14 years old.

By the time I was installing

my third line, you had to get someone from the telephone company to come do it.

I get this guy and he's just looking around like, "What is this?

Why the hell is a 14-year-old

having three phone lines into their tiny little bedroom?

What are what's going on here?

Why are all these modems

blinking red and um black and making funny sounds?"

Did your parents know?

>> They did and they didn't.

They knew I had the phone lines.

They knew I had the computer.

I don't think they really understood

that I was trading

pirated software that was both illegal

and whatever else was going on.

>> Oh, we should probably say that in Europe, maybe you can comment on this

in especially in Eastern Europe, but Europe in general, piracy, I think, was more

acceptable than it was in the United States.

I don't know there maybe maybe it's just my upbringing.

That conversation wasn't present.

I never spoke to anyone growing up in Denmark who had any moral qualms whatsoever about piracy.

It was just completely accepted that >> you're a kid.

You want a lot of games.

You don't have a lot of money.

What do you do? You trade.

>> Some people would occasionally buy a game.

I mean, I once bought a uh Sega Master System

and the I bought one game cuz that was what I could afford.

I got Afterburner 2.

I don't know if you've ever played that game.

It's pretty bad implementation

on the uh Sega Master System,

but it was like

600 crowners and I was making money at that time

uh doing newspaper delivery.

I had to do that for a month to afford one game.

I like video games way too much to wait a month just to get one game.

So piracy was just the way you did it.

And that was how I got into running this bulletin board system,

being part of the demo scene,

being part of the piracy scene to some extent.

And then also at some point realizing,

oh, you can actually also make money on this and this can fund buying

more phone lines and buying more modems and buying more amiggas.

Oh yeah, that was one of the demo parties.

These were amazing >> What am I looking at?

>> Look at all those CRT monitors.

>> All these CRT monitors.

Again, when I was 14,

I I don't understand

fully why my parents allowed this,

but I traveled from Copenhagen,

the capital of Denmark, to O,

this tiny little town in Judan

on the train with a bunch of dudes who were like

late teens in their 20s.

I'm 14 years old.

I'm lugging my 14in

CRT monitor with my computer in the back to go to the party.

That was what it was called.

That was the biggest demo scene party at that time.

And it was exactly as you see in that picture.

Thousands of people just lining up with their computers,

programming demos all day long,

and trading these things back and

>> That's kind of awesome.

Not going to lie, it's a little ridiculous. >> It's totally awesome.

And I I I

miss it in ways where

the internet has connected people in some ways,

but the connection you get from sitting right next to someone else

>> who has their own CRT

monitor who's lugged it halfway around the country to get there

is truly special because

it was also just this burst of creativity.

You're constantly running around.

You're constantly surrounded by people who are really good at what they could do.

They're really good at programming computers. It's infectious.

It was part of that

pang I felt then going like oh man

why can't I figure this out?

I mean why can't I even figure out easy Amos?

I it's kind of frustrating.

>> But on your third attempt you were more

>> So third attempt is when I start getting it.

This is when I start

helping out let's say

building things for the internet.

So around 95 I think it is or

I discovered the internet.

Actually ninth grade that was my first experience.

I went to some university

in in Denmark and in ninth grade we had this excursion

and they sat us down in front of a computer and the computer had

Netscape Navigator the first version or maybe it was even the the precursor to

that and they had a text editor and us kids just got like hey

built something on the internet and it was just HTML

and the first thing you do is like oh I can make the text

text blink by just putting in this tag and saving it.

That was that moment.

That was actually when I reawakened

the urge to want to learn to program because I got a positive experience.

All the other experiences I had with programming was

I'd spend hours typing something in,

I'd click run and it wouldn't work.

And I'd get an error message that made no sense to me as a

kid, either at six or seven or at 12.

And here I am sitting in front of a computer connected to the internet

and I'm making text blink.

I'm making it larger.

I'm turning it into an H1 or an

And these guys out here, we just did it for like an hour and a half.

And suddenly I go, "Oh, I can make things for the internet

that someone in Germany

can be able to access and see and I don't have to ask anyone for permission.

This is super cool.

I got to do more of this."

So I got into the internet.

I got into working with HTML

and I still had all these friends from these demo

>> and I started working with them

on creating gaming websites.

I'd write about the video games. I'd review him.

This was another good way of getting new video games was

to walk down to some store and say like, hey, I'm a I'm a journalist.

I'm like this 15year-old

kid and they're they're looking at me, you're you're a journalist. Yeah.

Can I borrow some some games?

Cuz this was when games moved on to the PlayStation

and these other things.

You couldn't just as easily pirate,

at least not at first.

So, I went down there, did all that.

And that started the journey of the internet for me.

It started working on these gaming websites,

working with figuring out that I could do something.

I could work on the HTML part.

It's not really programming, but it kind of smells like it.

You're talking to a computer, you're making it put

text on the screen, and you're communicating

with someone halfway around the world.

So, that became my

pathway back into programming.

And then slowly I picked up more and more of it.

First website I did with someone,

one of these programmers from the demo scene that was dynamic was ASP.NET.

net and it wasn't even actually called.net

that was what we started on and then we moved on to PHP

and PHP was when I finally got it

when it finally clicked

when conditionals and loops and variables

and all of that stuff started to make sense enough to me

that I thought I can do this.

>> So would it be fair to say that we wouldn't have DHH

without PHP and therefore you owe

all your success to PHP?

100% that's true and it's even better than that

because it's PHP to me

didn't just give me a start in terms of making my own web applications

it actually gave me a bar

in many ways I think the pinnacle

of developer web developer

ergonomics is late '90s PHP

you write this script

you FTP it to a server

and instantly it's deployed

instantly it's available you change anything in that file and you reload boom it's right there.

There's no web servers,

there's no setup, there's just an Apache

>> that runs mod PHP.

And it was essentially the easiest

way to get a dynamic web page up and going.

And this is one of the things I've been chasing that high

for basically the rest of my career

that it was so easy

to make things for the internet

in the mid to late 90s.

How did we lose

the sensibilities that allowed

us to not just work this way, but get new people into the industry

to give them their success

experiences that I had,

adding a freaking Blink tag to an HTML page,

ftping a PHP page to an Apache web server

without knowing really anything about anything,

without knowing anything about frameworks,

without knowing anything about setup,

all of that stuff have really taken us to a place where

It sometimes feels like we're barely better off.

Like web pages aren't that different

from what they were in the late 90s, early 2000s.

They're still just forms.

They still just write to databases.

A lot of people, I think, are very uncomfortable

with the fact that they are essentially CRUD monkeys.

They just make systems that create,

read, update, or delete

rows in a database.

And they have to compensate

for that existential dread

by over complicating things.

Now, that's a bit of a character.

There's more to it, and there's things you can learn for more sophisticated

ways of thinking about this, but there's still an ideal here, which was why

I was so happy you had Peter Levels on because he still basically works like this.

And I look at that and go like, man, that's amazing.

>> Yeah, you're chasing that high.

He's been high all along

using PHP, jQuery, and uh SQLite.

>> I think it's amazing because he's proving

that this isn't just a nostalgic dream.

He's actually doing it.

He's running all these businesses.

Now, some of that is, as he would admit

up first up front,

is that he's just one guy.

And you can do different things when you're just one guy.

When you're working in a team,

when I started working on the team, when I started working with Jason Freed

on Base Camp, we at first

didn't use version control together.

I used version control for myself and then I thought, you know what,

designers ah, they're probably not smart enough to figure out CVS. Yeah.

>> And therefore I just like, "No, no, no.

You just FTP it up.

You just FTP it."

I knew they knew how to do FTP.

And then after the third time, I had overridden their changes.

I was like, "God damn it.

I guess I got to teach Jason

CBS to not do that again."

But I think there's

still way more truth to the fact that we can work the way we

did in the '90s,

work the way Peter works today,

even in the team context

and that we've been far too willing to hand over far too much of

our developer ergonomics to the merchants of complexity.

>> And you've been chasing that with Rails 8.

So h how do you bring

all the cool features

of a modern framework

and make it no build

make it as as easy

to create something and to ship it as it was in the '9s with just PHP.

It's very difficult for me to beat the Peter Level's approach

uh of just just it's so easy to just ship some PHP

and it should be

why should it be harder than that?

Our computers today are

almost infinitely faster than what they were in the 90s.

So, shouldn't we be able to work in even easier ways?

We should be looking back on the '90s and go like, "Oh, that was way too complicated.

Now we have more sophisticated

technology that's way faster and it allows us to work

in these easier to use ways."

But that's not true.

But now you can see the line I draw in my work with Ruby

and Rails and especially with Rails 8.

No build to me is

reaching back to that '90s feeling and going

now we can do some of those things without giving up on all the

progress because I do think you can get too nostalgic.

I do think you can start

just fantasizing that everything was better in the '90s. It wasn't.

I mean I was there.

There was a lot of things that sucked.

And if we can somehow find a way to combine

the advantages and advances

we've had over the past 20 years with that ease of developer ergonomics, we can win.

No build is a rejection

of the part of web development I've hated the most in the past 10-15

years which is the JavaScript

>> And I don't say that as someone who hates JavaScript.

I mean I often joke that JavaScript

is my second favorite programming language.

It's a very distant second.

Ruby is by far in a way number one.

But I actually like JavaScript.

I don't think it's a bad language.

It gets a lot of >> flak.

People add a string of two plus a one and it gives something nonsense

and I just go like, "Yeah, but why are you why would you do that?

Just don't do that."

The language is actually quite lovely,

especially the modern version

ES6 that really introduced

a proper class syntax to it.

So I could work with JavaScript

in many of the same ways that I love working with Ruby

made things so much better.

But in the early

20110s until quite recently,

all of that advancement

happened in pre-processing happened in built pipelines.

The browsers couldn't speak a dialect of JavaScript that was pleasant to work with.

So everyone started to pre-ompiling

their JavaScript to be able to use more modern

ways of programming with a browser that was seen as stuck

with an ancient version of JavaScript that no one actually wanted to work with.

And that made sense to me, but it was also deeply unpleasant.

And I remember thinking during that time, the dark ages

as I refer to them with JavaScript,

that this cannot be the final destination.

There's no way that we have managed to turn the internet into such

an unpleasant place to work

where I would start working on a project in JavaScript

using Webpack and all of these dependencies

and I would put it down for literally 5 minutes and the thing wouldn't compile anymore.

The amount of churn

that the JavaScript community,

especially with its frameworks and its tooling,

went through in the decade from 2010 to 2020 was absurd.

And you had to be

trapped inside of that asylum

to not realize what an

utterly perverse situation we had landed ourselves in.

Why does everything break all the time?

I mean, the joke wouldn't be just that the software would break.

That would annoy me personally.

But then I'd go on hacker news

and I'd see some thread on the latest JavaScript

release of some framework

and the thread would be like

um someone would ask well aren't we using the thing we just used three

months ago and people would be like that thing is so outdated

that's so three months ago

you got to get with the new program we're completely rewriting

everything for the teen time

and anything you've learned in the framework you've been spending the

last amount of time on it's all useless.

You got to throw everything out and you got to start over.

Why aren't you doing it, stupid idiot?

>> Is that a kind of mass hysteria

that took over the developer community? You think?

Like where you have to keep creating new frameworks and new frameworks

and we are we past that

dark >> I think we're getting out of it.

And we're getting out of it because

browsers have gotten so much better.

There was a stagnation in browser technology.

Some of it was an overhang

all the way back from IE5.

So I5 essentially put the whole internet development experience into a deep freeze

because Microsoft won the browser wars in the mid 2000s

and then they basically disbanded their browser development team because they're like all right

job done we don't need any more innovation on the internet.

Can we just go back to writing Windows forms or something now that we

control And it really wasn't until

obviously Firefox kind of kindled

a little bit of something, then Chrome got into the scene

and Google got serious about moving the web forward

that you had an kindling

of maybe the browser could be better, maybe the browser wasn't frozen in time

in 2005, maybe the browser

could actually evolve like at the development platform that it is.

But then what happened was

you had a lot of smart people

who poured in to the web because the web

turned out to be the greatest

application development platform of all time.

This was where all the money was being made.

This were this was where all the billionaires were being minted.

This was where the Facebooks

and whatever of the world came to be.

So you had all of this

brain power applied to the problem of how to work with the web.

And there were some very smart people

with some I'm sure very good ideas

who did not have

uh programmer happiness as their motivation.

Number one, they had

other priorities and those priorities

allowed them to discount

and even rationalize the complexity

they were injecting everywhere.

Some of that complexity came from organizational structure.

When you have a company like Facebook

for example that does depend on the web and want to push it forward

but have sliced the development

role job into these tiny little niches.

I'm a front-end glob pipeline configurator.

Oh yeah well I'm a front-end whatever engineer.

And suddenly the web developer was no longer one person.

It was 15 different roles.

That in itself injected a ton of complexity.

But I also want to give it

the bold case here, which was that

some of that complexity was necessary

to get to where we are today.

That the complexity was a bridge.

It wasn't the destination,

but we had to cross that bridge to get to where we are today.

Where browsers are frankly incredible.

The JavaScript you can write in a text file

and then serve on a web server for a browser to ingest is amazing.

It's actually a really good experience.

You don't need any pre-processing.

You can just write text files,

send them to a browser,

and you have an incredible

>> And we should also say that it can kind of be broken.

At least the HTML, but even the JavaScript

could be a little bit broken,

and it kind of still works.

Like maybe it halfass

works, but like the just the amount

of mess of smelly

code that a browser has to deal with is insane.

This is one of the hardest problems

in computing today is to parse the entire internet

because thankfully for us as web developers

but perhaps not so much for the browser developers

every web page that has ever been created

minus the brief period with flash still runs today.

>> The web page I did in ninth grade would render on a modern browser

today 30 years later.

That is completely crazy when you think about the amount of evolution

we've had with the web, how much better we've made it, how many more

standards browsers have adopted.

It's essentially an Apollo

project today to create a new browser, which is why it doesn't happen very

often, which is why

even companies like Microsoft

had to throw in the towel and say we can't do it.

Now, I actually don't think that's

good for the web.

There is the danger of the monoculture

if we just get a single browser engine that runs everything.

And we are in danger of that.

I love the fact that the Ladybird

project, for example, is trying to make a new

browser engine from scratch.

I've supported that project.

I would encourage people to look into that.

It's really a wonderful >> thing.

It's staffed by a bunch of people who worked on other browser

projects in the past.

>> Truly independent web browser.

>> We really need that.

But I can hold

that thought in my head.

At the same time, I hold the thought in my head that

Google's Chrome was pivotal

to the web surviving

as the premier web development platform.

If it had not been for Google

and their entire business depending on

a thriving open web,

Apple, Microsoft, I think would have been just as fine to see the web

go away to disappear

into being something that just served

native web applica or native mobile applications

and native desktop applications that they could completely control.

So I have all sorts of problems with Google,

but it's not Chrome.

Chrome is a complete

gift to web developers everywhere to the web as a development platform

and they deserve an enormous amount of credit I think for that even if

it's entangled with their business model and half of

Chrome is code that spies on you or informs

targeted ads and a bunch of things I'm not a big fan of.

I can divorce that from the fact

we need champions in the corner of the web who have trillions

of dollars of market cap value riding on the open web.

>> We're going to take tangents

upon a tangent upon a tangent.

So, let's go to Chrome.

I think Chrome positive impact on humanities

is immeasurable for reasons that you just described.

On the technology front, the features they present, the competition they created,

it's spurred on this

wonderful flourishing of web technologies.

But anyway, I have to ask you about the

the recent stuff with the DOJ

trying to split up Chrome and Google.

Do you think this is a good idea?

Do you think this does harm? Is a disaster?

And I say that as someone who's been very sympathetic

to the antitrust fight

because I do think we have antitrust problems in technology.

But the one place

where we don't have them

by and large is with browsers,

is with the tools we use to access the open web.

First of all, we have Firefox.

Now, Firefox is not doing all that great and Firefox

has been propped up by Google for many years

to deter from exactly what's going on with the DOJ

that they were the only game in town. Apple has Safari.

I have a bunch of problems with Apple, too, but I love Safari.

I love the fact that we have a premier

browser running on a premier

operating system that people can't turn the web into just a Chrome

experience, but I also think

that the open web needs this trillion dollar champion

or at least benefits from it.

Maybe doesn't need it, but it certainly benefits from it.

And of all the things that are wrong with monopoly

formation in technology, Chrome is the last thing.

And this is why I get so frustrated

sometimes about the anti-

or the monopoly fight that there are real problems and we should be focusing

on the premier problems first like the toll booths

on our mobile phones.

There are far bigger problem.

It's not the open web.

It's not the tools that we use to access the open web.

If I don't want to use

Chrome, if my customers of my businesses that run on the internet

don't want to use Chrome, they don't have to.

We're never forced to go through it.

the open internet is still open.

So, I think it's a real

shame that the DOJ

has chosen to pursue

Google in this way.

I do think there are other things you can nail Google for and their

ad monopoly maybe or the

uh shenanigans they've done in controlling both sides of the ad ledger that they

both control the supply and the demand. There are problems. Chrome isn't it.

And you end up making

the web much worse.

And this is the thing we always got to remember when we think about

legislation, when we think about

um monopoly fights is

you may not like how things look today

and you may want to do something about it,

but you may also make it worse.

The good intentions behind the GDPR

in Europe currently has amounted to what?

cookie banners that everyone

on the internet hates

that helps no one do anything better,

anything more efficient, that saves no privacy in any way, shape, or form, has

been a complete boondoggle,

that has only enriched

lawyers and accountants and >> Yeah.

You said that the cookie banner is a monument

for why Europe is losing

is is doing the worst

uh of all the regions in tech.

It's it's a monument

to good intentions leading straight to hell.

>> And the Europe is actually world class

>> in good intentions leading straight to

>> So hell is the cookie accept button.

They have to accept all cookies.

That's what hell looks like over and over.

You don't actually ever get to the web page.

>> Just on a human scale.

Try to imagine how many hours

every day are wasted

clicking that away and how much harm

we've done to the web as a platform

that people enjoy because of them.

The internet is ugly

in part because of cookie banners.

Cookie banners were supposed to save us from advertisement

and advertisement can make the web ugly.

There's plenty of examples of that.

But cookie banners made the entire internet ugly in one fell swoop.

And that's a complete tragedy.

But what's even worse,

and this is why I call it out as a monument to everything the

EU gets wrong, is that we have known this for a decade.

No one anywhere who's serious believes that cookie banners

does anything good for anyone.

Yet, we've been unable to get rid of it.

There's this one piece of legislation that's now, I think, 10 or 12 years old.

It's complete failure on every conceivable metric.

Everyone hates it universally,

yet we can't seem to do anything about

That's a bankruptcy declaration

for any body of bureaucrats

who pretend or pretend

to make things better for

not just citizens but people around the world.

This is the thing that really gets me about cookie banners, too.

It's not just the EU.

It's the entire world.

You can't hide from cookie banners anywhere on this planet.

If you go to goddamn

Mars on one of Elon's rockets

and you try to access a

web page, you'll still see a cookie banner.

No one in the universe is safe from this nonsense.

>> Probably the interface on

on the rocket >> slower.

You have basically 150 second ping time.

So it'll take you 45 seconds just to get through the cookie banners from Mars. >> Um, all right.

Let's walk back up the stack of this recursive

tangents we've been taking.

So Chrome, we should say, at least in my opinion,

is not winning unfairly.

It's winning in the fair way by just being better. >> It is.

If I was going to steal man the other side just for a half

second, >> people would say, well,

maybe yes, most people do

sort of begrudgingly agree that Chrome is a pretty good browser.

But then they'll say the reason it got dominance was distribution.

And the reason they got distribution

was because Google also controls Android

and therefore can make Chrome the default browser on all these phones.

Now, I don't buy that.

And the reason I don't buy that is because on Android,

you're actually allowed to ship a different browser that has a browser engine that's

not the same as Chrome.

Unlike on iOS where

if you want to ship a browser,

Chrome, for example, ships for iOS, but it's not Chrome.

It's Safari wrapped in

And every single alternative

browser on iOS have to use the Safari web engine. That's not competition.

That's not what happened on Android.

Again, I think there are some nuances to it.

But if you zoom out

and you look at all the problems we have with big tech, Chrome is not it.

Chrome won on merits.

I begrudgingly have switched to Chrome

on that realization alone.

As a web developer, I just prefer it.

I like Firefox in many ways.

I like the ethos of it, but Chrome is a better browser than Firefox. Full stop.

And by the way, we've never mentioned Edge.

Edge is also a good browser

>> because it's also Chrome in address,

>> but it never gets the love.

I I don't think I've ever used Bing

and I'm sure Bing is really nice.

>> Maybe you have because you know what is Bing in address?

>> Duck.Go, which is actually the search engine that I use.

Duck.Go gets its search results from Bing.

Or at least it used to.

If they changed that, that would be news to me.

>> Well, maybe everything is just

a wrap or a dress.

Everything is wearing a dress.

Underneath there's some other turtles.

It turtles all the dresses all the way down. Okay.

What were we talking about?

We got there from JavaScript

and from you learning how to program.

So the big success

story is when you built a bunch of stuff with PHP

and you were like actually

shipping >> And that's when the the Ruby story came.

So when your big

love affair with programming began there.

So can you take me there?

What what is Ruby?

Tell the story of Ruby.

Explain Ruby to me.

PHP was what converted me from just being able to

fondle HTML and turn out some web pages to

actually being able to produce web applications myself.

So I owe a tremendous gratitude to PHP in that regard.

But I never thought of PHP as a calling.

I never thought I'm a professional

programmer who writes PHP.

That's who I am and that's what I do.

I thought of PHP

as a tool I needed to

smack the computer with until it produced web applications I wanted.

It was very much a means to an end.

I didn't fall in love with PHP.

I'm very grateful that it taught me the basics of programming and I'm very

grateful that it set the bar for the economics.

But it really wasn't until Ruby

that I started thinking of myself as a programmer.

And the way that came about was

that the first time I ever got hired

as a professional programmer

to write code was actually

by Jason Frerieded, my business partner still.

All the way back in 2001,

I had been working on these gaming websites in PHP for essentially 18 months at that point.

No one had been paying me to do code in that regard.

And I connect with Jason Freed

over an email sent from Copenhagen,

Denmark to Chicago, Illinois

to a person who didn't know who I was.

I was just offering solicited advice.

Jason had asked a question on the internet and I had sent him the

answer and he was asking in PHP

and I'd sent him the answer to that question and we started talking and

then we started working which by the way is a miracle of what the internet can allow.

How can a kid

in Copenhagen who's never met this guy in Chicago

connect just over email

and start working together and by the way we're still working together now

24 years later that's incredible

but we started working together and we started working together on some client projects

Jason would do the design

37 signals would do the design I would bring the programming PHP

and after we worked on I think two or three client projects together in

PHP we kept hitting the same problem

that whenever you work with a client,

you start that project off an email.

Oh yeah, let's work together.

Here's what we're building

and you start trading more and more emails

and before a few weeks have passed, you got to add someone to the project.

They don't have the emails.

They don't have the context.

You send where's the latest file?

Oh, I've uploaded on the FTP.

It's like final final V6 2.0, right?

That's the one to get.

It's just a mess, a beautiful mess.

in some ways a mess that still

runs the vast majority of projects to this day.

Email is the lowest common denominator. That's wonderful.

But we had dropped the ball a couple times in serious ways with customers

and we thought we can do better.

We know how to make web applications.

Can't we just make a system

that's better than email for managing projects?

It can't be that hard.

We've been doing blogs.

We've been doing to-do list.

Let's put some of these things together

and just make a system

where everything that anyone

involved in the project needs is on one page.

And it has to be simple enough that

I'm not going to run a seminar teaching you how to use the system.

I'm just going to give you the login code.

You're going to jump into it.

So that's base camp.

>> And when we started working on base

I for the first time in the

experience I had with Jason had the freedom of technology choice.

There was no client telling me,

"Yeah, PHP, that sounds good. We know PHP.

Can you build it in PHP?"

I had free reigns.

>> And at that time, I'd been reading uh IE

>> and a couple of other magazines back from the early 2000s

where Dave Thomas and Martin Fowler

had been writing about

programming patterns and how to write better code.

And these two guys in particular

were both using Ruby

to explain their concepts because Ruby

looked like pseudo code.

>> Whether you were programming in C or Java or PHP,

all three constituencies could understand Ruby because it basically just reads lang English.

So these guys were using Ruby to describe the concepts.

And first of all, I would read these articles

for just the concepts they were explaining.

And I'd be like, what is this programming language?

I mean, I I like the concept you're explaining, but I also want to

see the programming language.

Why haven't I heard of this?

So, I started looking into Ruby.

And I realized at that time,

Ruby might not be known by anyone, but it's actually been around for a long time.

Matts, the Japanese creator of Ruby,

had started working on Ruby back in 93,

before the internet was even a thing.

And here I am in 2003,

10 years later, picking up what seems like this

hidden gem that's just

laying in obscurity in plain sight.

But Dave Thomas and Martin Fowler,

I think, successfully put me and a handful of other people

on the trail of

a programming language that hadn't been used much in the West, but could be.

So I picked up Ruby and I thought

this is this is very different.

First of all, where are all the semicolons?

>> I'd been programming in PHP in ASP.

I'd even done some Pascal.

I'd looked at some C.

There are semicolons everywhere.

And that was the first thing that struck me is where are the damn semicolons?

And I started thinking

actually why do we have semicolons in programming?

there to tell the

interpreter that there's a new line of instructions,

but I don't need him as a human. How?

Oh, someone is looking out for the human here,

not for the machine.

So, that really got me interested.

And then I thought to myself, do you know what?

I know PHP quite well.

I'm not an amazing programmer.

I haven't been working in programming for all that long,

but maybe I can figure it out.

I'm going to give myself two weeks.

I'm going to write a proof of concept

where I talk to a database.

I pull some records.

I format them a bit and I display them on an HTML page.

Can I figure that out in a couple weeks?

It took about one weekend and I was completely mesmerized.

I was completely mind blown

because Ruby was made for my brain

like a perfect tailored glove.

by someone I'd never met.

Like, how is this even possible?

>> We should say maybe

like paint a picture of the certain qualities that Ruby has.

Maybe even compared to PHP.

We should also say that there's a ridiculous

thing that I'm used to that I forget about that there's dollar signs everywhere. >> there's line noise.

That's what I like to call >> line noise. Line noise.

That's such a beautiful phrase. Yeah.

So, there's all these things that look like programs.

And with Ruby, I mean, there's some similarities in Python there.

Uh, it just looks kind of like natural language.

You can read it normally.

>> Here's a while loop that does a five iterations.

You can literally type the number five dot.

Now, I'm calling a method on the number five.

By the way, that's one of the beautiful

aspects of Ruby that primitives

like integers are also objects.

And you can call

five dot start brackets.

Now you're iterating over

the code in that bracket five times. That's it. >> Okay, that's nice.

>> That's not just nice, that's exceptional.

There is literally no other programming language that I know of that has managed

to boil away the line noise that almost

every other programming language would inject

into a five time iteration

over a block of code to that

>> That's a really nice Well, thank you for giving that example.

That's a beautiful example.

Wow, I don't think I know a programming language that does that. That's really nice.

>> Ruby is full of that.

And there's So, let me dive into a couple examples because I really think

it helps paint the picture.

And let me preface this by saying I actually I like the ethos of Python.

I think the Ruby and the Python community share a lot of similarities.

They're both dynamic interpreted languages.

They're both focused on

immediiacy and productivity and ease of use in a bunch of ways, but then

they're also very different in many other ways.

And one of the one ways they're very different is aesthetically.

Python to me, I hope I don't offend people too much.

I've said this before,

it's just it's ugly.

And it's ugly at it in its base because it's full of

superfluous instructions that are necessary

for legacy reasons of when Guido made Python back in ' 87

that are still here

in 2025 and my brain can't cope with that.

Let me give you a basic example.

When you make a class in Python,

the initializer method, the starting method is defaf. Okay, fair enough.

That's actually the same as Ruby def

definition of a method.

Then it is not one

underscore two in it

underscore >> Parentheses start self,

and then the first argument.

>> Yeah, the whole self thing. Yeah.

>> I look at that and go, I'm sorry. I'm out.

I can't do it.

It's just it's everything about it offends my sensibilities to the core.

Here you have the most important

method that all new objects

or classes have to implement

and it is one of the most

aesthetically offensive ways of typing initialize

that I've ever seen anywhere.

And you guys are okay with this?

>> Yeah, you're making me you know where

you're like talking about my marriage or something like this and and I'm now

realizing I've been in a toxic relationship all along.

Yeah, I just get used to it.

That to me, by the way, was the magic of Ruby.

It opened my eyes to how beautiful programs could be.

I didn't know I'd been working in ASP.

I'd been working in PHP.

I didn't even have the concept that

aesthetics, beautiful code, was something we could optimize

for, that something we could pursue.

And even more than that, that we could pursue it above other objectives.

That Ruby is, as beautiful as it is, is not an accident and it's not easy.

Ruby itself is implemented in C.

It's very difficult to parse

Ruby code because Ruby

is written for humans

and humans are messy creatures.

They like things in just the right way.

I can't fully explain

why the underscore_initers make me

repulse, but it does.

And when I look at the Ruby alternative, it's really instructive. So, it's defaf.

same part df space

parenthesis not even parenthesis if you don't need to call it within the arguments

there's not even a parenthesis that in itself is actually also a major part

if the human doesn't need the additional characters we're not just going to put

them in because it'd be nicer to parse for the computer

we're going to get rid of the semicolons

we're going to get rid of the parenthesis

we're going to get rid of

the underscores we're going to get rid of all that ugliness

all the line noise and boil it down to its pure essentials

and at the same time we're not going to abbreviate.

This is a key difference in the aesthetics between Ruby and Python as well.

In it is shorter type.

It's only five characters.

Initialize is a lot longer, but it looks a lot better.

And you don't type it very often.

So, you should look at something pretty.

If you don't have to do it all the time, it's okay that it's long.

Those kinds of aesthetic evaluations

are rife all over the Ruby language.

But let me give you an even better example.

The if conditional, that's the

bedrock of all programming languages.

They have the if conditional.

If you take most programming languages,

they all have if.

That's basically the same in almost every language. Space start parenthesis.

We all do that.

And then you have

um perhaps let's say you're calling

a object called uh user

dot is admin close parenthesis

close parenthesis start brackets

and here's what we're going to do if the user is an admin. Right?

That would be a normal programming language.

Ruby doesn't do it like that.

Ruby boils almost all of it away.

We start with the if.

Okay, that's the same.

No parenthesis necessary because there's no

ambiguity for the human

to distinguish that the next part is

just a single statement.

So you do if space

user dot admin question mark.

>> No open brackets, no parentheses, no nothing.

Next open line here's unconditional.

That question mark means nothing to the

but it means something to the human.

Ruby put in the

predicate method style purely

as a communication tool between humans.

It's actually more work

for the interpreter to be able to see that this question mark is there.

Why is this question mark in here?

Because it just reads so nicely.

if user admin question mark.

That's a very human phrase.

But it gets better.

You can turn this around.

You can have your

statement you want to execute before the conditional.

You can do userupgrade.

Say you're calling an upgrade method on a user

space if space user.admin question mark.

We do the thing

if the thing is true.

Instead of saying if the thing is true, do the thing.

But it gets even better.

This is why I love this example with the conditional because you can keep diving into it.

So let's flip it around.

if exclamation point not user.admin. Right?

That'd be a typical way of writing it.

Ruby goes, that exclamation

point is light noise.

Why do we have if and then an exclamation point? That's ugly.

We could do question mark.

That to me is an encapsulation

of the incredible beauty

that Ruby affords the programmer through ambiguity

that is only to serve

the human reader and writer.

All of these statements we've just discussed, they're the same for the computer.

It'll compile down to the same C code.

They'll compile down to the same assembly code, it makes no difference whatsoever.

In fact, it just makes it harder to write an interpreter.

But for the human who gets to choose

whether the statement comes before the conditional

or the predicate method has, it's just incredible.

It reads like poetry at some point.

It's it's also incredible that you know, one language designer is creating that.

you know, Guido and Ross

also it's like one person gets to make these

extremely difficult decision because

it's you have to think about how does that all get parsed

and you have to

think about the thousands if it's a popular language the millions of people that

end up using this

and what they feel

with that question mark on the for the if statement what what does that

feel like for >> that's what Matt's thought about because he started his entire

mission off a different premise

and almost every programming

language designer that I'd heard at least articulate their vision.

That his number one goal was programmer happiness.

That his number one goal

was the affordances that would allow programmers to articulate

code in ways that not just

executed correctly, but were a joy to write and were a joy to read.

And that vision is based on a fundamentally

different view of humanity.

There's no greater contrast between Matts

and James Gosling, the designer of Java.

I once listened to

James talk about the design of Java.

Why was it the way it was?

Why was it so rigid?

And he was very blunt about it, which I, by the way, I really appreciate.

And I think Gotham has done a tremendous job with Java.

But his view of humanity is rather dark.

His view of humanity was

programmers at the average are stupid creatures.

They cannot be trusted

with sophisticated programming languages

because they're going to shoot their

foot off or their hand off.

And that would be kind of inconvenient

to the regional development

office of a mid-tier

insurance company writing code

that has to last for 20 years.

Now, it's actually a very Thomas Saul

view of constrained capacity

in humans that I've come to appreciate much later in life.

But it's also a very depressing

view of programmers that there are just certain programmers who are too dumb to code poetry.

They're too ignorant to learn how to write it.

Well, we need to give them

a sandbox where they just won't hurt themselves too much.

>> Matt's went the complete opposite direction.

He believes in humanity.

He believes in the unlimited

capacity of programmers to learn and become better.

So much so that he's willing to put the

stranger at his own level.

This is the second part I truly appreciate about Ruby.

Ruby allows you to extend base classes.

You know how we just talked about five dot times is a way to

iterate over um a statement five times.

That five is obviously a base class. It's a number.

Do you know what

you can add your own methods to that?

I did extensively in Rails.

We have something called active support

which is essentially my dialect

of Ruby for programming web applications.

And I'll give you one example.

I've added a method

called days to the number.

So if you do 5

days, you get five days in seconds

because seconds is the way we set cash expiration

times and other things like that.

So you can say

cash expires in 5 days.

>> And you're going to get

whatever 5* 24 * 60

* 60 is or whatever the math is, right? very humanly readable.

In a novel programming language, you would type out

the seconds and then you would have a little comment above it saying this represent five days.

In Ruby, you get to write five days.

But even better than that,

Matts didn't come up with it.

Matts didn't need the five days.

I needed that because

I needed to expire caches.

I was allowed by Matts

to extend his story

with my own chapters

on equal footing such that a reader of Ruby

could not tell the difference between the code Mattz wrote and the code that I wrote.

He trusted me as a complete

stranger from Denmark who had never met

to mess with his beautiful story.

That level of trust is essentially unheard of.

I know there are other programming languages that allow things with macros and so

forth, but none do it in a way like Ruby does it.

None does it with an articulated

vision of humanity, a trust in humanity like Matts does.

That is the opposite end of the spectrum of Java. >> Yeah.

I mean, for my aesthetic

sensibilities, just the way you describe five days,

that's really pleasant to me.

like I could see myself sitting alone

sleepdeprived and just writing that

it's just is an easy thing you can write it in a long way

with a comment you can you can write a multiple lines you could do

and now with AI

I'm sure it's going to generate it correctly but there's something really pleasant about

the simplicity of that I'm not sure what that is

but you're right there is a good feeling

there and I'm sure we'll talk about happiness from all kinds of philosophical

angles but you know

that is what happiness is made of.

That little >> good feeling there.

>> It's the good feeling that come

out of a concept

compressed to its pure essence.

There's nothing you can take away

from that statement that's superfluous.

>> But see, I I also want to push back a little bit because it's

not cuz I also

program in Pearl a bunch

just just to be cool.

Um so like it's not all about compression.

No, you can compress it too far.

Pearl Gulf is a thing

where you can turn

programs into something that's unreadable for humans.

Now, the great thing about Pearl

was that it came out before Ruby.

Mattz was a great student

of Wall, was a great student of

Pearl, was a great student of Python and Small Talk and Lisp.

He took inspiration from all of these

prior attempts at creating good programming languages

and really edited down the very best bits into this.

So he was able to learn from his lessons.

But what I found incredible

about Ruby is that here we are 2025.

Ruby has been worked on for over 30 years

and essentially the first draft

is 90% of what we're still using.

There was almost a sense of divine inspiration

possible in wherever Matts

was writing that initial version of Ruby

that transcended time to such a degree that no one has still even

begun to reach it.

This is the other thing I always find fascinating.

I generally believe in the efficient market theory that if someone comes up with

a better mousetrap or better idea, others will eventually copy them to such an

extent that perhaps the original mousetrap

is no longer even remembered.

No one has been able to copy that essence of Ruby.

They borrowed elements and that's totally fine, but Ruby still stands

taller than everyone else on these metrics

on this trust in humanity and programmers.

>> And we should also say like

you know uh maybe the perfect programming language

that that metric and then there's the successful language and those are often different.

There there's something wonderful about the Brendan Ike story of creating JavaScript. >> Yes.

of of there's something

truly beautiful uh about

the way JavaScript took over the world.

I've uh recently got to visit the Amazon jungle and just one of my

favorite things to do is just to watch the ants take over anything

everything and it's just like

it's a nice distributed system.

It's a messy thing that doesn't seem to be order

but it just works

and the machinery of it >> worse is better.

I mean that's actually the name of a pattern

for in in software

development and other ways of how do is the pattern of Linux.

Linux was quantifiably worse than I think it was minix at the time.

Other ways of it that were more

cathedral >> less bizarre and

is still one that there's something to it that the imperfections

can help something go forward.

It's actually a trick

I've studied to the degree that I now incorporate it in almost all open

source that I do.

I make sure that when I release the first version of any new thing

I work on, it's a little broken.

>> It's a little busted in ways that invite people

to come in and help me cuz there's no easier way

to get the collaboration

of other programmers than to put something out that they know how to fix and improve. >> Yeah, that's awesome.

But Ruby is somehow

or was at least a little bit different in that regard.

Not in all regards.

Matt's got the ethos

of the language, the design of the language just right.

But the first versions of Ruby were terribly slow.

It's taken, I mean, hundreds of

man years to get Ruby to be

both this beautiful yet also

highly efficient and really fast.

And we should say that the thing that made you fall in love with

this particular programming language is meta >> Yes.

So that takes all of these elements we've just talked about

and turned them up to 11.

I'll explain metaroming real

>> Metar programming is essentially

a version of the five days.

You get to add keywords to the language.

>> Active record is the part of Rails that communicates with the database.

This is a system where every

table in the database is represented by a class.

So if we take the user example again

you do class user

um descends from active record base

and then the first line you can write is this

I want my users to

have many posts or have many comments. Let's do that.

We're making some system where users can make comments.

The very next line is has

underscore many space colon comments.

Now you've set up a dependency

between users and comments

that will give you a whole host of

access and factory methods for users to be able to own comments, to create

comments, to update comments.

In that line alone

has many looks like a keyword.

It looks like it's part of the Ruby language. That's metaroming.

when Rails is able to add these elements

to how you define a class and then that runs code that adds a

bunch of methods to the user class. That's metaroming.

And when metaroming is used in this way, we call it domain specific languages.

You take a generic language like Ruby and you tailor it to a certain

domain like describing relationships

in a database at a object level.

And this is one of those early examples where you can do

um user has many comments

belongs_2 space colon account.

Now you've set up a uh onetoone relationship.

Before we had a one to many relationship.

Rails is rife with all these kinds of domain specific languages

where at sometimes it doesn't even look like Ruby.

You can't identify Ruby keywords.

You can just identify

what looks like keywords

in its own programming language.

Now again, I know that

lisp and others also do this stuff.

They just do it with the maximum amount of line noise that can ever

be crammed in to a programming language.

And Ruby does it at a level where you cannot tell my metarogramming

from Matt's keywords and with zero line

>> Yeah, I should say that my first love was lisp.

So there's a slow tear

that you can't see.

>> I've actually never written any real lisp myself.

>> Well, how can you judge it so harshly

>> Because I have two eyes

and I can look at code and my aesthetic

sensibilities forbid me to even go much further, which is a limitation.

I know I should actually dive into Lisp because

I found that I've learned a lot just diving into

maybe I'm insulting Lisp again here but the past of

programming languages with small talk for example

I think small talk is a

incredible experiment that also worked but isn't suitable

for today's programming >> I love that we're talking about Ruby so much and what

beautiful code is 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 uh 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

static typing because to me

is the bedrock of what this is.

Why would you want to 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 metaroming harder.

I write a bunch of meta programming.

I've seen what it takes to do meta programming in Typescript.

That was actually one of the things that just

really sent me on a tear of getting meta or getting Typescript

out of some of the projects that I'm involved with.

We pulled TypeScript out of

um Turbo, one of the front-end frameworks that we have because

I tried to write some meta programming in Typescript and I was just infuriated.

I don't want that

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 the of a example.

For example, um, capital U user.

I'm declaring the type of the variable lowerase 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.

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.

One of the primary arguments is that it makes tooling easier.

It makes it easier to do autocomplete

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 autocomplete.

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