This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. You can watch the full conversation here: https://www.youtube.com/watch?v=uTxRF5ag27A
(more links below)

Podcast full episodes playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4

Podcasts clips playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41

Podcast website:
https://lexfridman.com/ai

Podcast on Apple Podcasts (iTunes):
https://apple.co/2lwqZIr

Podcast on Spotify:
https://spoti.fi/2nEwCF8

Podcast RSS:
https://lexfridman.com/category/ai/feed/

Note: I select clips with insights from these much longer conversation with the hope of helping make these ideas more accessible and discoverable. Ultimately, this podcast is a small side hobby for me with the goal of sharing and discussing ideas. I did a poll and 92% of people either liked or loved the posting of daily clips, 2% were indifferent, and 6% hated it, some suggesting that I post them on a separate YouTube channel. I hear the 6% and partially agree, so am torn about the whole thing. I tried creating a separate clips channel but the YouTube algorithm makes it very difficult for that channel to grow. So for a little while, I'll keep posting clips on this channel. I ask for your patience and to see these clips as supporting the dissemination of knowledge contained in nuanced discussion. If you enjoy it, consider subscribing, sharing, and commenting.

Bjarne Stroustrup is the creator of C++, a programming language that after 34 years is still one of the most popular and powerful languages in the world. Its focus on fast, stable, robust code underlies many of the biggest systems in the world that we have come to rely on as a society. If you're watching this on YouTube, many of the critical back-end component of YouTube are written in C++. Same goes for Google, Facebook, Amazon, Twitter, most Microsoft applications, Adobe applications, most database systems, and most physical systems that operate in the real-world like cars, robots, rockets that launch us into space and one day will land us on Mars.

Subscribe to this YouTube channel or connect on:
- Twitter: https://twitter.com/lexfridman
- LinkedIn: https://www.linkedin.com/in/lexfridman
- Facebook: https://www.facebook.com/lexfridman
- Instagram: https://www.instagram.com/lexfridman
- Medium: https://medium.com/@lexfridman
- Support on Patreon: https://www.patreon.com/lexfridman

So, how do you inspire or ensure that the Einstein level of simplification is reached?

If I gave you the code for the Ford F-150 and said, here, is this a mess or is this okay?

Is it possible to tell, is it possible to regulate?

An experienced developer can look at code and see if it smells.

The point is that it is hard to generate something that is really obviously clean and can be appreciated, but you can usually recognize when you haven't reached that point.

And so if I have never looked at the F-150 code, so I wouldn't know, but I know what I ought to be looking for.

There I'll be looking for some tricks that correlates with bugs and elsewhere.

And I have tried to formulate rules for what good code looks like.

And the current version of that is called the C++ core guidelines.

1 thing people should remember is there's what you can do in a language and what you should do.

In a language, You have lots of things that is necessary in some context, but not in others.

There's things that exist just because there's 30-year-old code out there and you can't get rid of it.

But you can't have rules that says, when you create it, try and follow these rules.

This does not create good programs by themselves, but it limits the damage and for mistakes, it limits the possibilities of mistakes.

And basically we are trying to say what is it that a good programmer does at the fairly simple level of where you use the language and how you use it.

Now, I can put all the rules for chiseling in marble.

It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo.

That is, there's something else to write a good program.

Just as there's something else to create an important work of art.

That is, there's some kind of inspiration, understanding, gift.

But we can approach the sort of technical, the craftsmanship level of it.

The famous painters, the famous sculptures was among other things superb craftsmen.

They could express their ideas using their tools very well.

And so these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well.

For a really good piece of code, you need a spark of inspiration and you can't, I think, regulate that.

You cannot say that I'll take a picture only, I'll buy your picture only if you're at least Van Gogh.

There are things you can regulate, but not the inspiration.

It is true that there is, as an experienced programmer, when you see code that's inspired, that's like Michelangelo, you know it when you see it.

And the opposite of that is code that is messy, code that smells, you know, when you see it.

And I'm not sure you can describe it in words except vaguely through guidelines and so on.

Yes, it's easier to recognize ugly than to recognize beauty in code.

And for the reason is that sometimes beauty comes from something that's innovative and unusual.

And you have to sometimes think reasonably hard to appreciate that.

On the other hand, the messes have things in common.


Speaker 0: So, how do you inspire or ensure that the Einstein level of simplification is reached? So, can you do code review? Can you look at code? If I gave you the code for the Ford F-150 and said, here, is this a mess or is this okay? Is it possible to tell, is it possible to regulate?

Speaker 1: An experienced developer can look at code and see if it smells. I mix metaphors deliberately. The point is that it is hard to generate something that is really obviously clean and can be appreciated, but you can usually recognize when you haven't reached that point. And so if I have never looked at the F-150 code, so I wouldn't know, but I know what I ought to be looking for. There I'll be looking for some tricks that correlates with bugs and elsewhere.

And I have tried to formulate rules for what good code looks like. And the current version of that is called the C++ core guidelines. 1 thing people should remember is there's what you can do in a language and what you should do. In a language, You have lots of things that is necessary in some context, but not in others. There's things that exist just because there's 30-year-old code out there and you can't get rid of it.

But you can't have rules that says, when you create it, try and follow these rules. This does not create good programs by themselves, but it limits the damage and for mistakes, it limits the possibilities of mistakes. And basically we are trying to say what is it that a good programmer does at the fairly simple level of where you use the language and how you use it. Now, I can put all the rules for chiseling in marble. It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo.

That is, there's something else to write a good program. Just as there's something else to create an important work of art. That is, there's some kind of inspiration, understanding, gift. But we can approach the sort of technical, the craftsmanship level of it. The famous painters, the famous sculptures was among other things superb craftsmen.

They could express their ideas using their tools very well. And so these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well. For a really good piece of code, you need a spark of inspiration and you can't, I think, regulate that. You cannot say that I'll take a picture only, I'll buy your picture only if you're at least Van Gogh. There are things you can regulate, but not the inspiration.

Speaker 0: I think that's quite beautifully put. It is true that there is, as an experienced programmer, when you see code that's inspired, that's like Michelangelo, you know it when you see it. And the opposite of that is code that is messy, code that smells, you know, when you see it. And I'm not sure you can describe it in words except vaguely through guidelines and so on.

Speaker 1: Yes, it's easier to recognize ugly than to recognize beauty in code. And for the reason is that sometimes beauty comes from something that's innovative and unusual. And you have to sometimes think reasonably hard to appreciate that. On the other hand, the messes have things in common. You

See all Lex Fridman transcripts on Youtube

Bjarne Stroustrup: Recognizing Beautiful Code