31–40 of 173 posts
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
"When (not if) garbage collection becomes available, we will have two ways of writing C++ programs."
"I suspect that a garbage collection scheme can be concocted that will work with (almost) every legal C++ program, but work even better when no unsafe operations are used."
"I am under no illusion that building an acceptable garbage collection mechanism for C++ will be easy - I just don't think it is impossible. Consequently, given the number of people looking at the problem several solutions will soon emerge."
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.
Almost every C program does `int *c = malloc(sizeof(int) *10)` or similar, which has always been invalid C++.
Section 10.7 of "The Design and Evolution of C++" has some good ones from the early 90s: "When (not if) garbage collection becomes available, we will have two ways of writing C++ programs." "I suspect that a garbage collection scheme can be concocted that will work with (almost) every legal C++ program, but work even better when no unsafe operations are used." "I am under no illusion that building an acceptable garba…
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…
Can you explain how you think strings should work?
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 (which are extremely common) to be stored with less memory. The cost is that now you have two or three different string representations floating around. This approach is used by Python and Java, for example.
The Rust / Go approach is to assume that you don’t need O(1) access to the Nth code point in a string, which is probably reasonable, since that’s rarely necessary or even useful. You get a lot of complexity savings from only using one encoding, and the main tradeoff is that certain languages take 50% more space in memory.
Python and Java both date back to an era where fixed-width string encodings were the norm.
Section 10.7 of "The Design and Evolution of C++" has some good ones from the early 90s: "When (not if) garbage collection becomes available, we will have two ways of writing C++ programs." "I suspect that a garbage collection scheme can be concocted that will work with (almost) every legal C++ program, but work even better when no unsafe operations are used." "I am under no illusion that building an acceptable garba…
> I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible.
See this question:
https://stackoverflow.com/q/147130/1593077
and this answer (of mine):
"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++.
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,…
"We didn't have time for that." (Bjarne Stroustrup, before an invited talk, Cambridge Computer Lab) (in response to my complaint to him that hastables again hadn't been included in the most recent standard at the time.)
The really important stuff was printing with "<<", or whatever ...
Earlier 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++.
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…