YouSaid · the spoken record

Bjarne Stroustrup

lines on the record: 99
first: 2019-11-07
most recent: 2019-11-07
sittings or episodes: 1
sources: podcast

Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections

“This is a very reasonable question. When I designed C. Most languages have multiple implementations because if you run on an IPM, if you run on a Sun, if you want on a Motorola, there was just many, many companies and they each have their own compilation structure, the old compilers. It was just fairly common to those many of them. I wrote CFR assuming that other people would write compilers with C++ if successful. And furthermore, I wanted to utilize all the backend infrastructures that were available. I soon realized that my users who using 25 different linkers, I couldn't write my own linker. Yes, I could, but I couldn't write 25 linkers and also get any work done on the language. And so it came from a world where there was many linkers, many optimizers, many compiler front ends.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Small group of people can do that. Two, three people can work together to do something like that. It's ideal if it's one person that has all the skills necessary, but nobody has all the skills necessary in all the fields where C++ is used. So if you want to approach my ideal in, say, concurrent programming, you need to know about algorithms. You need to know the trigger of log-free programming. You need to know something about the compiler techniques. And then you have to know some of the program, the application areas where this is, like some forms of graphics or some forms of what we call a web server and kind of stuff. And that's very hard to get into a single head, but small groups can do it too.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Take some experience, take some practice, and sometimes you get it wrong, but after a while you sort of get it right. I don't write compilers anymore. Frank Kernigan pointed out that one of the reasons C Succeeded Was some of the craftsmanship I put into the early compilers. Of course, I did the languages sign, of course, I wrote a fair amount of code using this kind of stuff. And I think most of the successes involves progress in all three areas together”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“This happened the first time actually back in the ages with a friend of mine called Doc McElroy who demonstrated exactly this effect. And so the principle is you should give programmers a tool so that their abstractions can follow the zero or eight principle. Furthermore, when you put in a language feature in C++ or a standard library feature, you try to meet this. It doesn't mean it's absolutely optimal, but it means if you hand-code it with the usual facilities in the language in C++, in C. You should not be able to better it. Usually you can do better if you use embedded, a simpler for machine code, for some of the details to utilize part of a computer that the compiler doesn't know about. But you should get to that point before you beat the abstraction.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Loop fusion and other good stuff like that that's quite hard to do by hand and in a lower level language and there's some really nice examples of that and the key here is that that matrix multiplication the matrix abstraction allows you to write code that's simple and easy you can do that in any language but with C++ it has the features so that you can also have this thing run faster than if you hand coded it Now, people have given that lecture many times, I and others, and a very common question after the talk where you have demonstrated that you can outperform Fortran for dense matrix multiplication, people come up and says, yeah, but there are C++. If I rewrote your code and see how much faster would it run, The answer is much slower.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“There are things like don't violate the static type system because I like static type system for the obvious reason that I like. To be reliable on reasonable amounts of hardware. But one of these rules is overhead principle. The zero overhead principle. It basically says that if you have an abstraction, Should not cost anything compared to write the equivalent code at a lower level. So if I have say a matrix multiply. Should be written in such a way that you could not drop to the sea level obstruction and use arrays and pointers and such and run faster. And so people have written such matrix multiplications and they have actually gotten code that ran faster than Fortran because once you had the right abstraction, you can eliminate temporary.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“And other techniques. And that's important because I think that the best solution to most complex, interesting problems require And techniques from things that have been called object oriented Data abstraction, functional, traditional C style code. Of the above And so when I was designing C. I soon realized I couldn't just add features. You just add what looks pretty or what people ask for, or what you think is good. One by one, you're not going to get a coherent whole. You need is a set of guidelines that That guy show decisions should this feature be in or should this feature be out? How should a feature be modified before it can go in and such? And in the book I wrote about that, the Science Evolution of C++, there's a whole bunch of rules like that. Most of them are not language technical.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“That's a good question. I could probably have a year's course just trying to answer it. Yes, there's a tension between efficiency and abstraction, but Also, get the interesting situation that you get the best efficiency out of the best abstraction. And my main tool for efficiency, for performance actually, is abstraction. So let's go back to how C got there. Said it was object oriented programming language. I actually never said that. It's always quoted, but I never did. I said C supports object oriented programming.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Do you know really exactly what went wrong? Usually not. How can you recover when you don't know what the problem was? You can't be a hundred percent sure what the problem was in many, many cases. And this is this is part of it. So yes, we need good languages with good type systems. We need rules for how to use them. We need static analysis and the ultimate for static analysis is of course program proof but that still doesn't scale to the kind of systems we deploy. Then we start needing testing and the rest of the stuff.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Yes, so basically, you need a set of rules for how you use the language. Then you need a static analysis that catches your mistakes when you violate the rules or when your code ends up doing things that it shouldn't despite the rules because this is the language rules. We can go further. And again, it's back to my idea that I would much rather find errors before I start running the code. If nothing else, once the code runs, if it catches an error at runtimes, I have to have an error handler. And one of the hardest things to write. Code is air handling code because you know something went wrong”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Want to make sure that the free is done somewhere else. Now it gets really difficult. And so for static analysis, you can run through a program and you can try and figure out If there's any leaks. And what you will probably find is that you will find some leaks and you will find quite a few places where your analysis can't be complete. It might depend on runtime, it might depend on the cleverness of your analyzer. And it might take a long time. Some of these programs run for a long time. If you combine such analysis with A set of rules that says how people could use it. You can actually see why the rules are violated, and that stops you from getting into the impossible complexities. You don't want to solve the halting problem.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“You represent a piece of code. So that you can write a program that goes over that representation and look for things that are Right and not right. So for instance, you can analyze a program to see if resources are leaked. That's one of my favorite problems. Not actually all that hardened modern C, but you can do it if you are writing in the C level, you have to have a malloc and a free, and they have to match. If you have them in a single function, Can usually do it very easily if there's a malloc here, there should be a free there. On the other hand, in between can be true and complete code, and then it becomes impossible. If you pass that pointer to the memory out of a function and then”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Yes, it's easier to recognize ugly than to recognize beauty. Code. And for the reason 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. And you can have static checkers and dynamic checkers at finds a large number of the most common mistakes. You can catch a lot of slobbiness mechanically. I'm a great fan of static analysis in particular because you can check for not just the language rules but for the usage of language rules. And I think we will see much more static analysis in the coming decade.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“That is, there's something else to write a good program. Just is there something else to create an important work of art? That is some kind of inspiration, understanding, gift. 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, I'll buy your picture only if you're at least then go. There are other things you can regulate, but not the inspiration.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“In a language you have lots of things that is necessary in some context but not in others as things that exist just because this thirty year old code out there and you can't get rid of it but you can have rules that says when you create it try and follow these rules This does not create Programs by themselves, but it limits the damage 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 chisening and marble. It doesn't mean that somebody who follows all of those rules can do a masterpiece by Michelangelo.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“An experi Developer can look at code and see if it smells. Mixed 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 would be looking for some tricks that correlates with bugs and elsewhere. I have tried to formulate rules for what good code looks like. current version of that is called the C++ core guidelines. One thing people should remember is there's what you can do in a language and what you should do.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Are other areas with under constraints where you can be simpler than you can be in C. But in the domain I'm dealing with, That's the simplification I'm after.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“There is a missing piece that's just in your head, and the code you can see what it does, but it cannot see what you thought about it unless you have expressed things directly. When you express things directly, you can maintain it. It's easier to find errors, it's easier to make modifications, it's actually easier to test it. And lo and behold, it runs faster. Therefore, you can use a smaller number of computers, which means there's less hardware that can possibly break. So I think the key here is simplification. But it has to be, to use the Einstein quota, as simple as possible and no simpler.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, let's get back to something we can talk about. And actually make some progress on. We can look at C programs and we can try and make sure they crash this often. The way you do that. Is largely by simplification. It is not the first step is to simplify the code, have less code, have code that are less likely to go wrong. It's not by runtime testing everything, it is not by big test frameworks that you are using. Yes, we do that also. But the first step is actually to make sure that when you want to express something, you can express it directly in code rather than going through endless loops and convolutions in your head before it gets down the code. That if the way you are thinking about a problem is not in the code.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I'm dealing with one part of the system and I want my part to be really good, but I know it's not the whole system. Furthermore, making an individual part perfect. May actually not be the best way of getting the highest degree of reliability and performance and such. This pupil says C++ is type not type safe. You can break it. Sure, I can break anything that runs on a computer. I may not go through your type system. If I wanted to break into your computer, I would probably try SQL injection.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“First of all safety like performance and like Security is the system's property. People tend to look at one part of a system at a time and say something like this is secure. That's all right. I don't need to do that. Yeah, that piece of code is secure. I'll buy your operator. You want to have reliability, if you want to have performance, if you want to have security, you have to look at the whole system.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“But you have to think about efficiency, not just as speed, but as an enabler to important things. And one of the things it enables is reliability, is dependability. When I press the pedal, the brake pedal of a car, it is not actually connected directly to To anything but a computer. That computer better work.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Time interpreting a symbol function call, you are not going to have enough time to do proper signal processing to get the telephone calls to sound right. Either that or you have to have 10 times as many computers and you can't afford your phone anymore. It's a ridiculous idea in the modern world because we have solved all of those problems.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I really want my telephone calls to get through and I want the quality of what I am talking coming out at the other end might be in London or wherever. And you don't want the system to be crashing. If you're doing a bank, you mustn't crash. It might be your bank account that is in trouble. There's different constraints like in games. It doesn't matter too much if there's a crash. Nobody dies and nobody gets ruined. But I'm interested in the combination of performance, partly because of sort of speed of things being done, part of being able to do things that is necessary to have reliability of larger systems. If you spend all your”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Non professional programmers that write lots of that code just couldn't understand them. It did eh. An amazing job for what it was. It's not the prettiest language, and I don't think it ever will be the prettiest language. But that's not bigots here.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Let me say it this way when you build a tool, you do not know how it's going to be used. You try to improve the tool by looking at how it's being used and when people cut their fingers off and try and stop that from happening. But really you have no control over how something is used. So I'm very happy and proud of some of the things C++ is being used at and some of the things I wish people wouldn't do Bitcoin mining being my favorite example uses as much energy as Switzerland and mostly serves criminals Back to the languages, I actually think that having JavaScript run in the browser Was an enabling thing for a lot of things. Yes, you could have done it better, but people were trying to do it better and they were using Sort of more principled language designs, but they just couldn't do it right and the”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“So, my two languages would be machine code and C. And then I think you can learn a lot from the functional languages. So PIG has GLOIML. I don't care which. I think actually you learn the same lessons of expressing, especially mathematical notions really clearly and having a type system that's really strict. And then you should probably have a language for sort of quickly churning out something. You could pick JavaScript. You could pick Python. You could pick Ruby.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“You can see it in real time, and even if you can't read the assembly code, you can just see it his code gets better, the assembler gets smaller, he increases the abstraction level, uses C++ eleven, as it were better. This code gets cleaner, it gets easier maintainable, and the code shrinks, and it keeps shrinking. I could not in any reasonable amount of time write that assembler as good as the compiler generated from really quite nice modern C. And I'll go as far as to say the thing that looked like C was significantly uglier and smaller when it became larger when it became machine code. The abstractions that can be optimized are important.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“So I need the abstraction mechanisms or something like C to write compact high performance code. Those are beautiful keynote by Jason Turner at the CPP Con a couple of years ago where he decided he was going to program Pong on Motorola 6800 I think it was and he says well this is relevant because it looks like a microcontroller. It has specialized hardware it has not very much memory and it's relatively slow and so he shows in real time how he writes Pung starting with fairly straightforward low level stuff improving his subtractions and what he's doing he's writing Cranslate into Which you can do with Klang and you can see it in real time. The compiler explorer which you can use on the web. And then he wrote a little program that translated 86 assembler into And so he types, and you can see this thing.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Even today, even today. The C optimizers write better machine code than I do. But I don't think I could appreciate them if I actually didn't understand machine code and machine architecture, at least in my position, I have to understand a bit of it because You mess up the cash and you're off in performance by a factor of a hundred. It shouldn't be that if you are interested in either performance or the size of the computer you have to deploy. So I would go as a simpler. I used to mention C, but these days going low level is not actually what gives you the performance. It is to express your ideas so cleanly that you can think about it and the optimizer can understand what you're up to. My favorite way of optimizing these days is to throw out the clever bits and see if it still runs fast. And sometimes it runs faster.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“It's like, I don't like, I mean, if you're a monoglot, you are likely to think that your own culture is the only one's periods where everybody else is a good learning of a foreign language and a foreign culture is important. It helps you think and be a better person. With programming languages, you become a better programmer, better designer with a second language. Now, once you've got to, the way to five is not that long. It's the second one that's most important. And then when I had to pick five, I took Sort of thinking what kinds of languages are there? Well, there's a really low level stuff. It's actually good to know machine code.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“This is a very hard question to answer. So, about languages, you should know languages. I recognize I knew about 25 or thereabouts when I did C++. It was easier in those days because the languages were smaller and you didn't have to learn a whole programming environment and such to do it. You could learn the language quite easily. And it's good to learn so many languages.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I understand why Lisp is popular, and I can see the beauty of the idea and similarly with small talk. It's just Relative, it is not as Relevant in my world, and by the way, I distinguish between those in the functional languages where I go to things like ML and Haskell. Different kind of languages. They have a different kind of beauty and they're very interesting. And I actually try to learn from all the languages I encounter to see what is there that would make Working on the kind of problems I'm interested in with the kind of constraints that I'm interested in, what can actually be done better? Because we can surely do better than we do today.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I'm quite aware that maybe 70, 80% of all code are not under the kind of constraints I'm interested in. But somebody has to do the job I'm doing because you have to get from these high level flexible languages to the hardware.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Favorite languages, but listen. But Lisp is not one of my favourite languages. It's obviously important. It's obviously interesting. Lots of people write code in it. And then they rewrite it into CSC+ when they want to go to production. It's in the world I'm at which are constrained by performance, reliability. Issues, deployability, cost of hardware. I don't like things to be too dynamic. It is really hard to write a piece of code that's perfectly flexible, that you can also deploy on a small computer, and that you can also put in, say, a telephone switch in a bog guitar. What's the chance if you get an error and you find yourself in the debugger that the telephone switch in Bogota on late Sunday night has a programmer around? Chance is zero. And so a lot of things I think most about. Can't afford that flexibility.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“So, this was one of the early examples for why you needed inheritance and you needed a runtime polymorphism because you wanted to handle this set of vehicles in a manageable way. You can't just rewrite your code each time a new kind of vehicle comes along.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“That was only part of it. It was an interesting and major part and still a major part in a lot of graphic stuff, but it was not the most fundamental. It was when you wanted to relate one type to another. You don't want them all to be independent. The classical example is that you Actually, want to write city simulation with vehicles where you say, well, if it's a bicycle, write the code for turning a bicycle to the left. If it's a normal car, turn right the normal car way, if it's a fire engine, turn right the fire engine way, you get these big case statements and bunches of if statements and such. Instead, you tell the base class that that's the vehicle saying turn left the way you want to. Is actually a real example. They used it to simulate and optimize the emergency. The emergency services for somewhere in Norway. Back in the 60s.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“It was not obvious, and many people have tried to do something like that, and most people didn't come up with something as wonderful as similar. Lots of people got their PhDs and made their careers out of forgetting about simula or never knowing it. For me, the key idea was basically I could get my own types. And that's the idea that goes further into C, where I can get better types and more flexible types and more efficient types, but it's still the fundamental idea when I want to write a program. I want to write it with my types that is appropriate to my problem and under the constraints that I'm under with hardware, software, environment, et cetera. And that's the key idea. on the class hierarchies and the virtual functions and the inheritance and”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“This was late 60s. I was a visiting professor in Os. And so I learned object-oriented programming by sitting around. Well, in theory, discussing with Keisnugel Once you get started and in full flow, it's very hard to get a word nedgeways with.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“But that was a breakthrough from the technical point of view. And then simula came along to make that idea more flexible. And you could define your own types. And that's where I got very interested.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“That was the first step. And of course there were very particular kind of humans, business people different, so they got cobalt instead, etc. And similar came out. No, let's not go to Simulate yet. Let's go to Algor. Fortran didn't have at the time the notions of Not a precise notion of type, not a precise notion of scope, not a set of translation phases that was what we have today, lexicos, syntax, semantics. It was sort of a bit of a model in the early days, but Hey, they're just on the biggest breakthrough in the history of programming, right? So you can't criticize them for not having gotten all the technical details right. So we got alcohol. That was very pretty. Most people in commerce and science consider it useless because it was not flexible enough and it wasn't efficient enough and etc etc.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Got portability because now they are writing in the terms that the humans used and the way humans thought and then they had a program that translated it into the machine's needs. And that was new and that was great and it's something to remember. We want to raise the language to the human level, but we don't want to lose the efficiency.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I can try. The most sort of interesting and major improvement of programming languages was Fortran, the first Fortran. Because before that, all code was written for a specific machine and each specific machine had a language, a simply language or A simpler or some extension of that idea, but you are writing for a specific machine in the language of that machine. And his team at IBM built a language that would allow you to write what you really wanted, that is, Could write it in a language that was natural for people. Now, these people happen to be engineers and physicists, so the language that came out was somewhat unusual for the rest of the world. But basically they set formula translation because they wanted to have the mathematical formulas translated into the machine. And as a side effect”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Yes, they invented it. Every language that uses the word class for type is a descent of simula. I or indirectly. were mathematicians and they didn't think in terms of types but they understood sets and classes of elements and so they called their types classes basically in C++ as in similar classes a user defined ty”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Basically, Pascal was sort of the simplest language that Niklaus Wiert could define that served the needs of Niklaus Wiet at the time. And it has a sort of a highly moral tone to it. That is, if you can say it in Pascal, it's good. And if you can't, it's not so good. So instead of trying to fit yourself into Niklaus Wierst's world, Nugor's language and Uluan Dao's language allowed you to build your own. So it's sort of close to the original idea of you build a domain specific language. As a matter of fact, what you build is a set of types and relations among types that allows you to express something that's suitable for an application.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“Simula was the extension of Algar sixty done primarily for simulation, but basically they invented object oriented programming at inheritance and runtime polymorphism when they were doing it And that was the language that taught me that you could have Of the problems of a program grow with the size of the program rather than with the square of the size of the program. That is, you can actually modularize very nicely. And that was a surprise to me. It was also a surprise to me that a stricter type system than Pascal's was helpful, whereas Pascal's type system got in my way all the time. So you need a strong type system to organize your code well, which has to be extensible and flexible.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I went through a lot of languages and then I spent significant time in assembler and microcode. That was sort of the first really profitable things I paid for my masters actually. And then I discovered Simula, which was absolutely great.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“I think I'll call sixty and After that I remember I remember snowball I remember Fortran didn't fall in love with that I remember Pascal didn't fall in love with that it all got in the way of me And then I just covered a simpler, and that was much more fun. And from there I went to my microcode.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source
“It was my second year in university, first year of computer science, and it was an alcohol sixty. I calculated the shape of Subollips and then connected points on the perimeter creating star patterns. It was with a wedding on a paper printer.”
2019-11-07 · Lex Fridman Podcast · Bjarne Stroustrup: C++ · IDENTIFIED FROM THE TRANSCRIPT · source