6 ms·

It's funny but honestly Stroustrup is the best language designer out there. While others abandoned their creations to make new languages, Stroustrup soldiered o

by mempko 5y ago

It's funny but honestly Stroustrup is the best language designer out there. While others abandoned their creations to make new languages, Stroustrup soldiered on and modern C++ is actually amazing. He's a working programmers language designer, not an academic.

fwsgonzo 5y ago
He came to our startup once (IncludeOS) and simply asked us what we had problems in, in C++ and what we think about it. Very refreshing. I also won a game of Secret Hitler by denying his veto.
- thechao 5y ago
  As a grad student, I was willing to take boutique courses from any of the PLT folk in the larger group (including Bjarne & Gaby). Most of the students were terrified of Bjarne, but I'd sit front-and-center and pepper him with questions. Eventually it got to the point that when I'd show up to lecture he'd shine his (green) laser pointer at me until I moved back & off center. Bjarne's a genuinely good guy, and very smart; I think the "interview" is fun, but it doesn't really sound anything like him.
marcodiego 5y ago
I'd put him in the same level as Anders Hejlsberg. And I'm not a microsoft fan.
rootlocus 5y ago
He basically added every feature he could think of on top of C, glued it with spit and released it as a pre-processor. There was barely any design involved. Just look at how many types of inheritance there are. I remember Stanley B. Lippman (one of the first developers on cfront) recollecting how the proposal to implement multiple inheritance was met with resistance from the community. And the implementing team realized they couldn't write a sane implementation, and people complained against it, but they made one anyway, partially because they wanted to prove they could. New features to cfront were added with very little concern for design. Things where standardization would have mattered (like the mangling algorithm) were never touched, so now every compiler has the liberty to generate whatever symbols it wants, and call functions with whatever calling convention it chooses, so you either have to compile all your dependencies, or make sure you fetch the binaries that use the exact same compiler version and flags, otherwise they won't link. Also, Stroustrup didn't "soldier on", the CPP standard is maintained by a committee of people from all over the world, and the standard library slowly adopts data types and algorithms from the boost library, because they need a multi-year staging period, handled by someone else, to see if things work before they muster the courage to standardize it.
- pjmlp 5y ago
  The reasoning behind what was added is clearly described in the "Design and Evolution of C++" book. Besides the main reason why C++ exists is because he swore to himself never to go through the Simula => BCPL downgrade ever again, and C is a tiny step up from Bootstraping CPL compiler, so....
  - rootlocus 5y ago
    Here are a few excerpts from "The Design and Evolution of C++" Another factor was purely irrational. Nobody seemed to doubt that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. For example, in summary of C++ in his book on Objective C, Brad Cox actually claimed that adding multiple inheritance to C++ was impossible. Thus, multiple inheritance seemed more of a challenge. He then goes on a 13 page explanation of how he thought there was a simple implementation. He then acknowledges the controversy, but brushes it aside with: I think - as I did then - that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all your problems, but it doesn't need to because it's quite cheap. Sometimes multiple inheritance is very convenient to have. I have kept out of the multiple inheritance debates: multiple inheritance is in C++ and cannot be taken out or radically changed; I personally find multiple inheritance useful at times; some people insist that multiple inheritance is essential to their approach to design and implementation; it is still to early to have solid data and experience about the value of C++ multiple inheritance in large scale use; and, finally, I don't like to spend my time on sterile discussions. This goes hand in hand with the original "principles" of C++ design, namely "C++ must be useful now". It didn't really matter how the complexity will evolve in the future, as long as it solved someone's problem today. And once it was implemented, there was no going back, so it didn't matter what people thought, it was done. This process isn't really what I would call "design".
    - pjmlp 5y ago
      So what would you call "design", the ups and downs of C married with UNIX porting from PDP-7 into PDP-11, or a waterfall design Algol-68 style?
thom 5y ago
I recently went through a bout of existential angst and nostalgia that led me back to the programming languages of my youth. I spent some time in C++ as it is today and honestly found it such a throughly modern language that it didn’t really scratch the itch I was reaching for. Ended up doing a couple of hobby projects in C, which maintains its brutalist charm.
DonHopkins 5y ago
What about Anders Hejlsberg? James Gosling designed Java to fix C++, and Anders Hejlsberg designed C# to fix Java, and he also designed TypeScript to fix JavaScript. https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 From the HN discussion about the video of "A Conversation with Language Creators: Guido, James, Anders and Larry" https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc: https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 >"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg >"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg >Andrew Hejlsberg: >Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly. >A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with. >But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago. >I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm. >I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming". >It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already. >And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist. >It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster. And these Larry Wall and James Gosling and Guido van Rossum quotes: >James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall >"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling >"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling >"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum Also: https://news.ycombinator.com/item?id=19568860 https://news.ycombinator.com/item?id=19568860 DonHopkins 10 months ago [-] >Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users. >"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs. >But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)
echelon 5y ago
Stroustrup is brilliant. Even his books on C++ are well written. The problem is that C++ treats humans as smart, whereas a language like Rust treats humans as fallible. This is probably the most important and impactful paradigm shift in language design in the last few decades. Make a language for when people are weak.

by mempko 5y ago

fwsgonzo 5y ago

He came to our startup once (IncludeOS) and simply asked us what we had problems in, in C++ and what we think about it. Very refreshing. I also won a game of Secret Hitler by denying his veto.

thechao 5y ago
As a grad student, I was willing to take boutique courses from any of the PLT folk in the larger group (including Bjarne & Gaby). Most of the students were terrified of Bjarne, but I'd sit front-and-center and pepper him with questions. Eventually it got to the point that when I'd show up to lecture he'd shine his (green) laser pointer at me until I moved back & off center. Bjarne's a genuinely good guy, and very smart; I think the "interview" is fun, but it doesn't really sound anything like him.

marcodiego 5y ago

I'd put him in the same level as Anders Hejlsberg. And I'm not a microsoft fan.

rootlocus 5y ago

He basically added every feature he could think of on top of C, glued it with spit and released it as a pre-processor. There was barely any design involved. Just look at how many types of inheritance there are. I remember Stanley B. Lippman (one of the first developers on cfront) recollecting how the proposal to implement multiple inheritance was met with resistance from the community. And the implementing team realized they couldn't write a sane implementation, and people complained against it, but they made one anyway, partially because they wanted to prove they could. New features to cfront were added with very little concern for design. Things where standardization would have mattered (like the mangling algorithm) were never touched, so now every compiler has the liberty to generate whatever symbols it wants, and call functions with whatever calling convention it chooses, so you either have to compile all your dependencies, or make sure you fetch the binaries that use the exact same compiler version and flags, otherwise they won't link. Also, Stroustrup didn't "soldier on", the CPP standard is maintained by a committee of people from all over the world, and the standard library slowly adopts data types and algorithms from the boost library, because they need a multi-year staging period, handled by someone else, to see if things work before they muster the courage to standardize it.

pjmlp 5y ago
The reasoning behind what was added is clearly described in the "Design and Evolution of C++" book. Besides the main reason why C++ exists is because he swore to himself never to go through the Simula => BCPL downgrade ever again, and C is a tiny step up from Bootstraping CPL compiler, so....
- rootlocus 5y ago
  Here are a few excerpts from "The Design and Evolution of C++" Another factor was purely irrational. Nobody seemed to doubt that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. For example, in summary of C++ in his book on Objective C, Brad Cox actually claimed that adding multiple inheritance to C++ was impossible. Thus, multiple inheritance seemed more of a challenge. He then goes on a 13 page explanation of how he thought there was a simple implementation. He then acknowledges the controversy, but brushes it aside with: I think - as I did then - that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all your problems, but it doesn't need to because it's quite cheap. Sometimes multiple inheritance is very convenient to have. I have kept out of the multiple inheritance debates: multiple inheritance is in C++ and cannot be taken out or radically changed; I personally find multiple inheritance useful at times; some people insist that multiple inheritance is essential to their approach to design and implementation; it is still to early to have solid data and experience about the value of C++ multiple inheritance in large scale use; and, finally, I don't like to spend my time on sterile discussions. This goes hand in hand with the original "principles" of C++ design, namely "C++ must be useful now". It didn't really matter how the complexity will evolve in the future, as long as it solved someone's problem today. And once it was implemented, there was no going back, so it didn't matter what people thought, it was done. This process isn't really what I would call "design".
  - pjmlp 5y ago
    So what would you call "design", the ups and downs of C married with UNIX porting from PDP-7 into PDP-11, or a waterfall design Algol-68 style?

thom 5y ago

I recently went through a bout of existential angst and nostalgia that led me back to the programming languages of my youth. I spent some time in C++ as it is today and honestly found it such a throughly modern language that it didn’t really scratch the itch I was reaching for. Ended up doing a couple of hobby projects in C, which maintains its brutalist charm.

DonHopkins 5y ago

What about Anders Hejlsberg? James Gosling designed Java to fix C++, and Anders Hejlsberg designed C# to fix Java, and he also designed TypeScript to fix JavaScript. https://news.ycombinator.com/item?id=22210073 https://news.ycombinator.com/item?id=22210073 From the HN discussion about the video of "A Conversation with Language Creators: Guido, James, Anders and Larry" https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 https://www.youtube.com/watch?v=csL8DLXGNlU https://www.youtube.com/watch?v=csL8DLXGNlU I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc: https://news.ycombinator.com/item?id=19568378 https://news.ycombinator.com/item?id=19568378 >"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg >"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg >Andrew Hejlsberg: >Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly. >A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with. >But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago. >I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm. >I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming". >It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already. >And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist. >It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster. And these Larry Wall and James Gosling and Guido van Rossum quotes: >James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall >"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling >"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling >"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum Also: https://news.ycombinator.com/item?id=19568860 https://news.ycombinator.com/item?id=19568860 DonHopkins 10 months ago [-] >Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users. >"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs. >But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

echelon 5y ago

Stroustrup is brilliant. Even his books on C++ are well written. The problem is that C++ treats humans as smart, whereas a language like Rust treats humans as fallible. This is probably the most important and impactful paradigm shift in language design in the last few decades. Make a language for when people are weak.