the true reason C++ always wins

Here in Seattle, there's a little park hidden away at the edges of Queen Anne.

There's a lookout at the top with one of the best views of the city. To get back down, there's a paved switchback path that winds gently down the hillside.

It's thoughtful, well-designed, people use it.

But I've never taken it all the way before. If you look to your left, you'll

before. If you look to your left, you'll notice something.

You'll see a thin dirt path going directly down the hill where thousands of people decided that this would be an easier way. In a lot of ways, it's

easier way. In a lot of ways, it's worse. It's steeper. It's more

worse. It's steeper. It's more

dangerous. You'll get dirt on you. But

the worst path just keeps on winning. A

programmer named Dick Gabriel noticed that the same thing was happening in the field of computer science back in 1989.

He called it worst is better and then spent the next 30 years arguing with himself about it. And that's why, and I do mean this literally, C++ won because

of New Jersey. This is the world's most famous third-rate computer scientist.

And no, I'm not calling him that myself.

This is how Dr. Gabriel chooses to describe himself. And yes, that is his

describe himself. And yes, that is his real LinkedIn picture. I really I really like it. That's a mood right there.

like it. That's a mood right there.

Respect. Anyway, Gabriel was a Lisp guy, but like really a Lisp guy. Gabriel

worked on the Common Lisp standard, and he based his entire company on creating Lisp IDEs for Sun hardware. So he spent the majority of his career betting on

the fact that Lisp would eventually win in the end, but then watching it not win. And in the middle of all this, he

win. And in the middle of all this, he sat down and wrote a talk. Buried inside

of that paper is a small section that's called worst is better. And he didn't even think that was the main point of the paper, and he didn't even really try to get the paper published. The only

reason that the paper ended up resurfacing is because one of his employees at Lucid ended up finding the paper inside of his files and started sharing it around. And fun fact that

that employee went on to be one of the creators of Netscape. Pretty flowers.

This paper quickly became kind of the golden standard in software engineering for, you know, {quote} why the right thing keeps on losing. And this is a

point that has been argued for 35 years and counting, including by the creator himself on two different sides. What's

crazy is that just a few months later Gabriel actually wrote another paper under a fake pseudonym that it was a complete rebuttal to his original point.

For Bucky, I think I'm saying that right, computer scientist, author of worse is better is worse. Seems a little familiar huh?

But what's crazy is that after that, he ended up writing a third essay comparing which of the two past Gabriels had actually been right. And he named this

is worse really better, and he never decided. I'd like to join the debate

decided. I'd like to join the debate that's been going on longer than I've been alive, but honestly at this point, even I'm not really sure what the right answer is. And it just became such a

answer is. And it just became such a thing with Gabriel that even his own employees started to get, and I quote, seriously concerned that he might have a mental disease. The problem really came

mental disease. The problem really came down to the difference in software philosophies between the two coasts of the United States. So that's right, it's an East Coast versus West Coast type

thing, and weirdly enough a battle between MIT and New Jersey. There are

two philosophies for writing software in the United States. And these two philosophies are just completely incompatible with each other, and they can't even agree on the definition of

what good actually is. So on one hand you have the MIT style, and this is the style that Gabriel called the {quote} right thing. It's really simple, Just

right thing. It's really simple, Just design the perfect program, make the interface easy to use and simple to call no matter how complicated the underlying

implementation actually is. And above

all, every single time, no matter how long it takes, make it correct. Just 200

mi apart in another building over in New Jersey, we have Bell Labs and they had a flurry of activity around Unix. Now, the

Unix philosophy was keep the implementation simple. It doesn't matter

implementation simple. It doesn't matter if the interface is ugly because the users basically just going to have to deal with it. And as for correctness, well, eh, correctness can come later.

The important part is just get it out.

Now, I'm not making this up, but Gabriel used to say, and I quote, "Well, what do you expect from an operating system designed and implemented in New Jersey?"

[laughter] And over the years, this kind of morphed into this East Coast versus West Coast philosophy. Berkeley ended up choosing

philosophy. Berkeley ended up choosing the New Jersey style of software engineering and that combined with the kind of ship it fast culture of Silicon Valley ended up making the West more

culturally New Jersey, while the East Coast ended up veering more towards an academic form of software engineering.

As much as he hated it, Gabriel argued that New Jersey style was better. Not

the software, the software he thought was trash, but trash spreads faster.

According to him, it's better to get half of the right thing available so that it spreads like a virus. That's

exactly what Unix did. And just as importantly, that's exactly what C did.

It was easy to port and could run on garbage hardware. And Gabriel said that

garbage hardware. And Gabriel said that those two were the ultimate computer viruses. And keep in mind, he's saying

viruses. And keep in mind, he's saying all of this while he's betting his entire company on the MIT philosophy.

So, why does the worst thing always win?

Why does everybody end up taking the crummy dirt path instead of the nice smooth paved switchbacks? Well, there's

one specific technical decision, and it's one of the cleanest parts in the entire essay. It takes the entire East

entire essay. It takes the entire East Coast versus West Coast debate and summarize it into one single dilemma.

Programmers call it the PC load sharing problem. I know PC doesn't mean personal

problem. I know PC doesn't mean personal computer in this context, it means program counter. Imagine it's the 1980s,

program counter. Imagine it's the 1980s, and you write [music] a program and you're waiting for some data, maybe from the network or something. But wait,

something happened. Holy guacamole, the user accidentally resized their terminal. Interrupt sigwinch, sigwinch.

terminal. Interrupt sigwinch, sigwinch.

I'm actually not joking, by the way, because if you were using graphical Unix back in the '80s, then window resizing could actually mess you up because the processor has to just completely drop

whatever it's doing to be able to handle the new incoming notification. In the

lovely MIT way, the OS just handles all of this for you. Saves the state of the program counter, does what it needs to do, then resumes your program, and nobody's the wiser. Meanwhile, in the

second approach, if you're working on Unix-based systems, you're absolutely screwed. Over in New Jersey, Bell Labs

screwed. Over in New Jersey, Bell Labs was like, "Backing up the program counter would make the OS like really complicated, so I think we're going to let the programmers deal with that one."

So, then you would get thrown this error code like e enter, and the OS would just be like, "I have no idea what to do. You

need to deal with this one."

This is a book on coffee, by the way.

[laughter] I don't think we're going to find our e enter signals in here. Espresso signals.

And if you think this is just some ancient 1980s history, it's not. The

ghost of New Jersey is still with us everywhere we go today.

For example, if you take a look at the Git source code, then you'll see all of these e-enter handlers all over the place. Let's say, for example, you do a

place. Let's say, for example, you do a Git clone, and then in the middle of that you decide to resize your terminal window.

We still have this exact same problem in 2026. Isn't it kind of crazy to just

2026. Isn't it kind of crazy to just think if I just go like this? On the

back end, your system is completely freaking out right now. It's like,

[laughter] So, you might be thinking like, "Hmm, maybe the MIT philosophy has a few points to it." But, none of that mattered because the entire point of

Gabriel's essay is essentially the best way to guarantee your software's failure is to make it 100% correct, which brings

us to the ultimate contagion, C++. Now,

just to be clear, I love C++. So much so that I'm actually giving a talk coming up soon in the UK talking about some runtime reflection techniques for C++.

But, it's also really clear that a lot of people really hate C++. And both the success of the language and that hatred of the language come from the same

thing. And this is what Dr. Gabriel

thing. And this is what Dr. Gabriel calls New Jersey. Turns out, Bjarne Stroustrup is a pretty smart guy. And

fun fact, I've actually met him in person before. But, the question you

person before. But, the question you have to ask yourself is, do you want to be correct or do you want to win? Now,

object-oriented languages were this hot new concept. For his PhD, Bjarne worked

new concept. For his PhD, Bjarne worked with a language called Simula, and Simula was the first object-oriented language ever created. It was clean,

elegant, beautiful, also unusably slow.

So, nobody really used it like out of side of academia. And remember, Bjarne was literally at Bell Labs in New Jersey. And so, he was given a crazy

Jersey. And so, he was given a crazy open-ended task. Do something

open-ended task. Do something interesting and give us a presentation in a year. What would I do with that task?

[laughter] I don't know what I would do. It's

interesting to think about.

I think I would uh come up with You know those pianos that are like on the ground that you like move your feet on?

I do that, but it's a keyboard, so you can program, but you also can get exercise at the same time. It's just

like It's [laughter] just It's just like really slow. You're like

if [laughter] bracket else done. There's a world-changing decision

done. There's a world-changing decision right here, because he could either take Simula, redesign it from scratch, and create a new beautiful language that

runs on modern hardware, or he could take fast, ugly C, and basically bolt on object orientation on top of it, and try to maintain as much backwards compatibility as possible. In his own

book, Bjarne wrote that the cleaner language he could have built would have been an unimportant cult language, and he decided that the only way to get a really large amount of existing C

programmers to try out a new object-oriented language would be to allow them to compile their existing C code directly in C++ unchanged. In fact,

his first compiler, Cfront, wasn't even a full compiler in the traditional sense. It didn't output machine code

sense. It didn't output machine code directly. What it did is it took C++

directly. What it did is it took C++ code and translated it over to C code so that existing C compilers could then handle the rest of it. But the absolute

genius of this is that means that C++ could run wherever C could already run without any kind of porting, and C ran everywhere. What's funny is that Gabriel

everywhere. What's funny is that Gabriel ends up kind of calling out this point inside of his essay, and he says, "Half the computers that that at any point are worse than the median, smaller or

slower. Unix and C work fine on them,

slower. Unix and C work fine on them, which means Unix and C are easy to port, which means that C++ is the ultimate virus. Meanwhile, 3,000 mi away in

virus. Meanwhile, 3,000 mi away in California, Gabriel's working on the committee for object-orientation in Lisp, and almost nobody ends up using

it. Now, Gabriel understood the hardware

it. Now, Gabriel understood the hardware problem really well because, if you remember with his company Lucid, his job was basically to take Lisp and make it

run on cheap Sun workstations rather than, you know, $70,000 Lisp machines. But, it wasn't enough.

Lisp machines. But, it wasn't enough.

Even cheap Lisp was too much of an ask for everybody so far entrenched inside of the C mindset. And, in the craziest twist of fate ever, his company Lucid

actually ended up writing an IDE for C++ called Energize just to keep the lights on. You've got the man writing the essay

on. You've got the man writing the essay on why the worst thing always wins working at a company now that is shipping out the worst thing just to

stay afloat. And, this is all because of

stay afloat. And, this is all because of some decision that another guy made at a lab in New Jersey. So, yeah. C++ won

because of New Jersey. If you asked Gabriel what his official stance is right now in 2026, I'm actually not really certain what he would say because he never really officially decided on

his previous stances. You've got his second essay written under a fake name, his third essay arguing the previous two essays that he created, and then a fourth essay came out in 2000 where he

decided that maybe the quote-unquote right thing was the correct decision all along. I also highly encourage you to

along. I also highly encourage you to read his papers on dreamsongs.com.

He's also a highly accomplished poet and writer as well. For what it's worth, Bjarne has said before that there are two kinds of programming languages in the world, the ones that people complain

about and the ones that nobody uses, which is kind of like the entirety of Gabriel's essay summed up by the man who ended up winning. And it is kind of a

tricky problem. If I think back about

tricky problem. If I think back about that dirt path that I cut through on my way home, I'm not sure who's winning either. If you like this kind of

either. If you like this kind of content, don't forget to subscribe, [music] and think about it. Whose side are you on? Do you believe that the worst option

on? Do you believe that the worst option is the better option, or do you think that the right option is the best decision? [music]

decision? [music] Thanks so much for watching everyone.

Lori Wired out.