kinda reminds me of a page on stallman.org that tells potential hosts what stallman likes and dont likes...if only i could find that link....hmmm..
Bjarne Stroustrup Quotes
151–160 of 173 posts
Re: Bjarne Stroustrup Quotes
#152I'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
A selective quotation which misses the point.
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind. The important thing here is that I have many of the same feelings about Smalltalk."
Re: Bjarne Stroustrup Quotes
#153Earlier quoted context omitted.
FWIW, I think Bjarne and other C++ magnates have a plan for eating Rust's lunch by allowing for "safe"/"unsafe" within C++.
I mean, sure, Bjarne calls his proposed way forward "safety profiles". Most fundamentally, this completely misunderstands the nature of the problem. This is a technical change, but the most important problem C++ has is cultural. So, they're not even addressing the right problem. In his original talk about this Bjarne even repeatedly describes his approach as a "strategy" which practically begged someone to say "Cultu…
> but the most important problem C++ has is cultural
That part, Bjarne and others have been working on for at least two decades I think. There's a lot of indoctrination/education about "staying safe" so to speak, through better coding practices, extended standard library facilities, static analysis and so forth. And from the little I can see, this is seeping into the C++ culture.
> The many different kinds of "safety" delivered via Bjarne's "safety profiles" don't compose
I'm not familiar enough with the details. But, about Rust - I was under the (possibly wrong) impression that you have the binary of either safe or unsafe: https://doc.rust-lang.org/std/keyword.unsafe.html
> Are you confident that starting this far behind the pack will be OK?
You're counting the wrong thing IMHO. If you count software systems of note, or add up their sizes; or count developers; or count organization; or add up turnover; etc. - its Python, Java, C, C++ in some sort of order that are at the head of the pack. Rust has certain benefits which make it attractive to jump onto its bandwagon - but it needs a lot of bandwagon-jumping to take the lead. If you can achieve more or less the same thing by just fiddling with your C++ development environment, then people might just not switch.
Re: Bjarne Stroustrup Quotes
#154Earlier quoted context omitted.
FWIW, I think Bjarne and other C++ magnates have a plan for eating Rust's lunch by allowing for "safe"/"unsafe" within C++.
Profiles will help on the domains where C++ is going to stay for a long time, like HPC, GPUs, game development, GCC/LLVM. However it is kind of late in domains where Rust, or other safer languages are already being used. They won't rewrite back into C++.
> domains where Rust ... [is] already being used
The point is that Rust usage is still quite limited. This is a bit like C++ and D, two decades back; or perhaps even Scala and Java. The analogy isn't perfect, but the point is you had a language with a lot of potential usability-domain overlap which addressed some or many pain points and failures of the older, more popular language - but the older language embraced some of the alternative ideas, adopted them in a more-or-less compatible way, and made it not-attractive-enough to switch. So the newer languages lost momentum, and at least in the case of D - stopped gaining users and eventually sank into oblivion.
> other safer languages ... won't rewrite back into C++.
I mostly agree. Except... that some safe languages, like Java, pay for safety with a lot of overhead. And Dennard scaling is over. So, over time, there is some pressure to replace Java, or maybe C# code with something closer-to-the-metal. But we'll see.
Re: Bjarne Stroustrup Quotes
#155Earlier quoted context omitted.
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 h…
"i must have indexable strings for performance reasons. oh, btw its an electron app"
Re: Bjarne Stroustrup Quotes
#156Language 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?
Raku introduced the concept of NFG - Normal Form Grapheme - as a way to represent any Unicode string in its logical ‘visual character’ grapheme form. Sequences of combining characters that don’t have a canonical single codepoint form are given a synthetic codepoint so that string methods including regexes can operate on grapheme characters without ever causing splitting side effects.
Of course there are methods for manipulating at the codepoint level as well.
Re: Bjarne Stroustrup Quotes
#157Earlier quoted context omitted.
> 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. People who like "list of Unicode code points" string types in languages like Rust and Python 3 always say this, but I'm never sure what operations they think are enabled by them. In the "bag of bytes that's probably UTF-8" world, you c…
> People who like "list of Unicode code points" string types in languages like Rust and Python 3 Rust and Python 3 have very different string representations. Rust's String is a bunch of UTF-8 encoded bytes. Python 3's String is a sequence of codepoints, and the size changes based on the encoding.
Yeah, implementation-wise, Rust's version of this idea is a little better, since at least you can convert their strings to a bag-of-bytes/OsStr-style representation almost for free. (And to their credit, Rust's docs for the chars() string method discuss why it's not very useful.)
I do think the basic motivation of Unicode codepoints somehow being a better / more correct way to interact with strings is the same in both languages, though. Certainly a lot of people, including the grandparent comment, defend Rust strings using exactly the same arguments as Python 3 strings.
Re: Bjarne Stroustrup Quotes
#158Earlier quoted context omitted.
> 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. People who like "list of Unicode code points" string types in languages like Rust and Python 3 always say this, but I'm never sure what operations they think are enabled by them. In the "bag of bytes that's probably UTF-8" world, you c…
> In the "bag of bytes that's probably UTF-8" world, you can safely concatenate strings, compare them for equality, search for substrings, evaluate regular expressions, No you can't (except byte -level-equality). If your regex is "abc" and the last byte of an emoji is the same as 'a' and the emoji is followed by "bc" it does the wrong thing.
You still have this problem in the "list of Unicode code points" world, since many multi-code-point emoji sequences appear to users as a single character, but start and end with code points that are valid emojis on their own.
Python 3 believes that the string "[Saint Lucia flag emoji][Andorra flag emoji]" contains a Canada flag emoji.
Re: Bjarne Stroustrup Quotes
#159Earlier quoted context omitted.
> In the "bag of bytes that's probably UTF-8" world, you can safely concatenate strings, compare them for equality, search for substrings, evaluate regular expressions, No you can't (except byte -level-equality). If your regex is "abc" and the last byte of an emoji is the same as 'a' and the emoji is followed by "bc" it does the wrong thing.
You can. The last byte of an emoji is never the same as 'a'. UTF-8 is self-synchronizing, a trailing byte can never be misinterpreted as the start of a new codepoint. This makes `memmem()` a valid substring search on UTF-8! With most legacy multi-byte encodings this would fail, but with UTF-8 it works!
Assuming that your strings are normalized, otherwise precomposed characters will not match decomposed characters.
Re: Bjarne Stroustrup Quotes
#160Earlier quoted context omitted.
> not real? real genuine Eric S Raymond humor, yes.
I've been a C++ user since 'cfront' and he simply has a point. If Stroustrup had been a little bit more disciplined about what features to add and which to leave out C++ would have been much more manageable. I'm not really afraid of many things but legacy C++ codebases I try very hard to stay away from. With some luck the original author(s) went overboard with all of the stuff that's available and never got around to…
C compatibility is both the best and worst thing about C++