Bjarne Stroustrup Quotes
stroustrup.com
Bjarne Stroustrup Quotes
1–10 of 173 posts
Re: Bjarne Stroustrup Quotes
#2Re: Bjarne Stroustrup Quotes
#3(in response to my complaint to him that hastables again hadn't been included in the most recent standard at the time.)
Re: Bjarne Stroustrup Quotes
#4Re: Bjarne Stroustrup Quotes
#5Re: Bjarne Stroustrup Quotes
#6C++ is my favourite programming language precisely because one of its main designers is so sensible.
I wonder what his blank slate language would have looked like.
Re: Bjarne Stroustrup Quotes
#7C++ is my favourite programming language precisely because one of its main designers is so sensible.
Yeah mine too until Rust. But part of that sensibleness was making it backwards compatible with C, which entails a mountain of inherited design mistakes. I wonder what his blank slate language would have looked like.
Re: Bjarne Stroustrup Quotes
#8Let's also not forget this: https://harmful.cat-v.org/software/c++/I_did_it_for_you_all
Re: Bjarne Stroustrup Quotes
#9I hadn't heard this last one before, but it's SO right ...
I always wondered why JS and PHP and Perl got so many details "wrong" (e.g. with Perl, one definition of "wrong" is that Perl 6 / Raku didn't make the same design choice)
Turns out there's an avalanche of details, and they interact in many ways!
Python did better, but I strongly argue both Python 3 and Python 2 got strings wrong. (Array of code points isn't generally useful, and it's hard to implement efficiently. See fish shell discussion about wchar_t on the front page now; also see Guile Scheme)
OCaml seems to have gotten mutable strings wrong (for some time), and also I think the split between regular sum types and GADTs is awkward. And also most people argue that objects vs. records vs. modules is suboptimal. And a bunch of mistakes with syntactic consistency, apparently.
Looks like almost every language had problems with for loops and closures, including C# and Go - https://news.ycombinator.com/item?id=37575204
So basically I agree that plowing through all the details -- and really observing their consequences in real programs -- is more important and time-consuming than grand ideas.
But if you lack any grand ideas, then the language will probably turn out poorly too. And you probably won't have any reason to finish it.