Live data from Hacker News

Bjarne Stroustrup Quotes

stroustrup.com

41–50 of 173 posts

Re: Bjarne Stroustrup Quotes

#41

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". He is right on this one. Pretty much in every discussion about Programming Languages people write how good Rust is and complain about how bad C++ is but the reality is, C++ it's one of the most used languages in the world. This quote could be a very harsh reply to Rust vs C++.

I came to the conclusion that the inverse is true, people tend to love languages they don't use.

I used to love Lisp and Racket. But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Came to hate Haskell for the very same reason. Every Haskell programmer think he's more clever than others so he decides on 30/40 language extensions and you have something that simply isn't Haskell.

People should not program programming languages. There's use cases for this style of programming, but they aren't how general-purpose programming should look like.

Re: Bjarne Stroustrup Quotes

#42
"The official mascot for C++ is an obese, diseased rat named Keith, whose hind leg is missing because it was blown off. The above image is a contemporary version drawn by Richard Stallman."

I have been unable to determine the provenance of this quote. Source and image: https://ifunny.co/picture/history-the-official-mascot-for-c-...

Re: Bjarne Stroustrup Quotes

#43

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". He is right on this one. Pretty much in every discussion about Programming Languages people write how good Rust is and complain about how bad C++ is but the reality is, C++ it's one of the most used languages in the world. This quote could be a very harsh reply to Rust vs C++.

You can already program. When you program a hobby/research project in the language you want to learn (better) you program /with/ the grain of the language. It's a nice experience.

Move over to implementing someone else's hard requirements where you have to make that happen, with time pressure - you find yourself going against the grain of the language by necessity and start describing the difficulties, sometimes colorfully.

People waxing lyrical about (this year haskell, rust for example) and who don't have a list of complaints are in the first category.

Re: Bjarne Stroustrup Quotes

#44

Earlier quoted context omitted.

I think the main alternative design is to treat strings like in Rust or Go. The problem with the “array of code points” idea is that you end up with the most general implementation, which is a UTF-32 string, and then you end up with the fastest implementation, which is a UTF-8 string, and maybe throw in UCS-2 for good measure. These all have the same asymptotic performance characteristics, but allow ASCII strings (wh…

Thanks for your response. Personally I fall into the "strings are arrays of bytes" camp (which is also shared by Go). A difference between my view and that of the Go designers is that I don't feel that it is important to support Unicode by default and am perfectly happy to assume that every character corresponds to a single byte. Obviously that makes internationalization harder, but the advantage is that strings are…

"strings are arrays of bytes" combined with the assumption that "characters are a single byte" sounds basically the same as the "array of code points" that the parent comment is disagreeing with

Re: Bjarne Stroustrup Quotes

#45
post #21
post #9

Language design is a curious mixture of grand ideas and fiddly details I 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…

Languages have trends too. Weak typing/Implicit conversion was cool in the 90s. JS and PHP would have magnitudes better if they were typed like Python, but that's history.

I can appreciate why it was cool. "What if everything could automatically do the right thing when it interacts with other things, and you wouldn't need any of this ritual boilerplate stuff? Why do we keep needing to convert from string to number to string over and over and over it's crazy. The language should just do the right thing!"

I think it's very easy to be sympathetic to the design trend.

Re: Bjarne Stroustrup Quotes

#46
Programming -- Principles and Practice Using C++ is one of the few must-read programming books in my opinion.

Even if you're a C++ expert, have 20 years in industry, etc. it's still an amazing example of beautiful technical writing.

Re: Bjarne Stroustrup Quotes

#47
post #15

Earlier quoted context omitted.

honestly, no one cares about splitting that hair. Most valid C programs will compile in C++ and believe it or not, binary logic is not the only logic humans are capable of.

actually, i reckon that most, if any, c programs will not compile with c++, without at least some (possibly not difficult) modifications

My only qualms is the number of genuine C only compilers in use, vs number of embedded system companies/projects/codebases in the world.

The subset of C features that are incompatible with C++ is quite small, and most of the features are a little out of the way IMO.

Of the regular suspects (GCC, MSVC, Clang), your C codebase is probably entirely compatible with C++ as each of these has varying levels of compliance with the C and C++ standard.

Re: Bjarne Stroustrup Quotes

#48
post #20

I'll see you Bjarne Stroustrup, and raise you Alan Kay, "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind." https://en.wikiquote.org/wiki/Alan_Kay

Fun fact: The Wright brothers didn't have modern airliners in mind when they invented airplanes.

Re: Bjarne Stroustrup Quotes

#49

Earlier quoted context omitted.

I think the main alternative design is to treat strings like in Rust or Go. The problem with the “array of code points” idea is that you end up with the most general implementation, which is a UTF-32 string, and then you end up with the fastest implementation, which is a UTF-8 string, and maybe throw in UCS-2 for good measure. These all have the same asymptotic performance characteristics, but allow ASCII strings (wh…

Thanks for your response. Personally I fall into the "strings are arrays of bytes" camp (which is also shared by Go). A difference between my view and that of the Go designers is that I don't feel that it is important to support Unicode by default and am perfectly happy to assume that every character corresponds to a single byte. Obviously that makes internationalization harder, but the advantage is that strings are…

> this design makes the common case much simpler at the expense of making the rare case harder

In the age of emoji (and uhhhh, everyone who doesn't use English as their main language), I don't think your "rare case" is really that rare.

Re: Bjarne Stroustrup Quotes

#50

Earlier quoted context omitted.

Can you explain how you think strings should work?

I think the main alternative design is to treat strings like in Rust or Go. The problem with the “array of code points” idea is that you end up with the most general implementation, which is a UTF-32 string, and then you end up with the fastest implementation, which is a UTF-8 string, and maybe throw in UCS-2 for good measure. These all have the same asymptotic performance characteristics, but allow ASCII strings (wh…

Working with strings is one of the most common complaints about rust though. Unless your only talking about the implemtation of it?
Post reply on HN