Live data from Hacker News

Bjarne Stroustrup Quotes

stroustrup.com

91–100 of 173 posts

Re: Bjarne Stroustrup Quotes

#91
“C++ is a language, not a religion.”

I swear Stroustrup said this at the beginning of his EE380 (CS Colloquium) talk at Stanford around 1986. At the time we (grad students) were all C programmers and we were sure that C was the best language evar, at least, better than Pascal, which was the language Stanford used for teaching back then. So we all wanted to see this person who had the temerity to claim that he had improved C and who had the audacity to call it “C++” of all things! Skilling Auditorium was packed. When Stroustrup took the stage, a tense hush fell over the crowd. He said the above line fairly quietly, and everyone burst out laughing, breaking the tension. The rest of the talk was a pretty straightforward explanation of C++ 1.0, and I came away fairly impressed.

Several years later at another talk I asked him to inscribe my copy of the C++ book with that quote. He claimed not to remember it, but he inscribed the book per my request anyway.

I think the quote holds up well.

Re: Bjarne Stroustrup Quotes

#92
post #7

Earlier quoted context omitted.

C++ is not backwards compatible with C. It’s mostly compatible, but it’s not completely compatible like say Objective C which is a strict superset of C.

They have diverged slightly in the years since C++ was introduced. But at the time the incompatibilities were extremely small. Even today they are pretty small and GCC/Clang will happily compile C constructs (e.g. designated initialisers, VLAs) with just a warning. Actually you need `-Wpedantic` to even get a warning for both of those. (And `-std=c++17` since designated initialisers are actually in C++20.)

[deleted]

Re: Bjarne Stroustrup Quotes

#93
post #80
post #56

Earlier quoted context omitted.

>I would be fine having a separate Unicode string type in the standard library for those instances when you really need Unicode; this design makes the common case much simpler at the expense of making the rare case harder. Even as a native English speaker, I'm extremely uncomfortable with the idea that we're going to make software even more difficult to internationalize than it already is by using completely separate…

If you give an input box to an American I promise you an emoji will find it's way into it no matter what it's for.

So much this. Thinking that only America and the UK matter is something that was forgivable 40 years ago but not today. It’s even more bizarre because of what you point out - emojis don’t make sense if you consider them as single byte arrays. And lastly, even if you only consider input boxes that don’t accept emojis like names or addresses, you have to remember that America is a nation of immigrants. A lot of folks have names that aren’t going to fit in ASCII.

And this stuff actually matters! In a legal, this-will-cost-us-money kind of way! In 2019 a bank in the EU was penalised because they wouldn’t update a customer’s name to include diacritics (like á, è, ô, ü, ç). Their systems couldn’t support the diacritics because it was built in the 90s with an encoding invented in the 60s. Not their fault but they were still penalised. (https://shkspr.mobi/blog/2021/10/ebcdic-is-incompatible-with...)

It is far more important that strings be utf-8 encoded than they be indexable like arrays. Rust gets this right and I hope future languages will too.

Re: Bjarne Stroustrup Quotes

#94
post #50

Earlier quoted context omitted.

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

Would love to hear what you think the complaints come from. They seem fine to me, and I have voiced plenty of criticism about the other parts of Rust. They work more or less how I expect—you have an array of bytes, which can either be a reference (&str) or owned / mutable / growable (String). The only unusual thing about Rust is that it validates that the bytes are UTF-8.

Mostly around usability and learning curve. I wasnt sure if the post was meant as a total endorsement of rusts strings or just the encoding aspect of them

Re: Bjarne Stroustrup Quotes

#95
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

Made up the term, but didn't invent object orientation. The real inventors were more generous.

Re: Bjarne Stroustrup Quotes

#96
post #59

Earlier quoted context omitted.

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…

> 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. Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL. Just like we use libraries judiciously in many languages. (Well, w…

Yes but: u/epolanski is referring to the abuse of metaprogramming, such that every org, every project creates its own bespoke mutant creole which remains C++ (or Haskell, Forth, LISP) in name only.

Java's founders wisely omitted metaprogramming. But memories are short. And chaos always finds a way. So now Java has its own medley of obfuscation strategies. Annotations, aspects, inversion of control, dependency injection, logging frameworks, etc.

Re: Bjarne Stroustrup Quotes

#97
post #58

Earlier quoted context omitted.

What people complain about with Rust strings are that there are so many different types, like &str vs String, and OsString / OsStr. The encoding of the strings isn't the issue.

Encoding might not be the whole issue, but "Rust mandates that the 'string' type must only contain valid UTF-8, which is incompatible with every operating system in the world" is the reason why OsString is a separate type.

Quote: which is incompatible with every operating system in the world

Should be some, not every, since there are OS’s where string types are utf-8, eg BeOS and Haiku

Re: Bjarne Stroustrup Quotes

#98
post #71

Earlier quoted context omitted.

Code points are not bytes.

Sure, but if you're insisting that the string be represented as one byte per character, you end up with the exact same properties with "array of code points" and "array of bytes"

No, it's impossible to do random access to retrieve a character, if you are dealing with code points, because code points do not have a fixed byte size. I thought this a good intro https://tonsky.me/blog/unicode/>.

Re: Bjarne Stroustrup Quotes

#99

I don't remember the exact quote, but I saw a talk where he said something like "People want big/verbose/explicit syntax for the languages features they don't understand, and small/terse/implicit syntax for the language features do understand." It made me realize that many of my language design opinions at that time were a matter of personal preference.

Agree. This is also true of UX design in general.
Post reply on HN