Earlier quoted context omitted.
Bjarne didn't have Alan in mind when designing C++ either.
If he had, we would all be better off.
That's why so much more real-world software was written in Smalltalk than in C++.
Wait...
Bjarne Stroustrup Quotes
61–70 of 173 posts
Re: Bjarne Stroustrup Quotes
#62"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-...
The first place I ever saw that was here:
https://en.uncyclopedia.co/wiki/C%2B%2B
Whole article is worth reading, lots of good laughs in there!
Re: Bjarne Stroustrup Quotes
#63Language 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…
Can you explain how you think strings should work?
The short answer is somewhere between Go and Rust strings, which are newer languages that use UTF-8 for interior representation, and also favor it for exterior encoding.
Roughly speaking, Java and JavaScript are in the UTF-16 camp, and Python 2 and 3 are in the code points camp. C and C++ have unique problems, but you could also put them in the code points camp.
So there are at least 3 different camps, and a whole bunch of weird variations, like string width being compile-time selectable in interpreters.
More details here:
https://www.oilshell.org/blog/2023/06/ysh-design.html#text
and here:
https://www.oilshell.org/blog/2023/06/surrogate-pair.html#hi...
A main design issue is that string APIs shouldn't depend on a mutable global variable -- the default encoding, or default file system encoding. That's an idea that's a disaster in C, and also a disaster in Python.
It leads to buggy programs. Go and Rust differ in their philosophies, but neither of them has that design problem.
Re: Bjarne Stroustrup Quotes
#64Earlier 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?
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.
Re: Bjarne Stroustrup Quotes
#65Earlier quoted context omitted.
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.
There must be statistics around how much of the data in the world is or could be Latin-1. I'm going to guess it's a very high percentage.
Re: Bjarne Stroustrup Quotes
#66Earlier quoted context omitted.
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.
On paper you're not wrong, but String used for localized text are a special subclass you can deal with separately. Most Strings that will cause you problems are, you know, technical: logs, name of subsystems, client ids, client-sourced API-provided values which change format across client etc. Those, in my experience, are always ASCII even in China, exactly because nobody wants to deal with too much crap.
Display Strings are simpler to manipulate in most cases: load String from file or form, store back verbatim in DB or memory, you barely do anything other than straight copying, right ?
The way I do in Java is that I always assume and enforce my strings to be ASCII single byte, and if I want to display something localized, somehow, it never really goes through any complex logic where I need to know the encoding: I copy the content with an encoding metadata, and the other side just displays it.
Re: Bjarne Stroustrup Quotes
#67Earlier quoted context omitted.
No, it could be a very stupid reply to Rust vs C++ since people do write in Rust. Bigger programs get written in it all the time and - what a surprise - people who use it have things they are annoyed about, which is why it gets improved. To me this is one of the most stupid things he's ever uttered on one hand and the most useful one on the other. Cause it can be used to remind people that there's always trade-offs,…
FWIW, I think Bjarne and other C++ magnates have a plan for eating Rust's lunch by allowing for "safe"/"unsafe" within C++.
I'm skeptical of the value of adding on "safe / unsafe" to C++ at this point. It's a bit like adding type annotations to Python. Better than nothing I suppose, but there's 30+ years of C/C++ that doesn't and will never be opted-in to these features, and the value declines rapidly when only 10% of the codebase (including dependencies) can be considered "safe" vs. when 99.9% of it can be.
Re: Bjarne Stroustrup Quotes
#68Earlier 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.
The only encoding which is compatible with "every operating system in the world" is no enforced encoding at all, and you can do very little "string-like" operations with such a type.
Even Python, well-known for being a very usable language, distinguishes between strings (which are unicode, but not utf-8 necessarily) and bytes, which you need to use if you're interacting directly with the OS.
The only real difference between the two is really the looseness with which Python lets you work with them, by virtue of being dynamically typed and having a large standard library that papers over some of the details.
Re: Bjarne Stroustrup Quotes
#69> "Java is to JavaScript as ham is to hamster". No. Never. Nothing even close to that. I try hard not to be rude about other languages.
To be fair, it's not exactly a rude statement.
Re: Bjarne Stroustrup Quotes
#70Earlier quoted context omitted.
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…
>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…
such a different level, you could even call it Latincentric :)