"Nobody should call themselves a professional if they only know one language".
Presumably he means programming language, but this may apply more generally.
Bjarne Stroustrup Quotes
111–120 of 173 posts
Re: Bjarne Stroustrup Quotes
#112Earlier 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…
[deleted]
Re: Bjarne Stroustrup Quotes
#113Earlier quoted context omitted.
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.
Yes.
Then there is the fact that PHP and JavaScript were basically domain specific languages at their inception.
PHP was a hypertext pre-processor. Pearl, but stripped down for templating.
JavaScript was an alternative to Java applets. When you don't need the full power of Java, you could throw in a few small scripts.
To make things a bit less intimidating, the weak typing seemed like a good idea, and for these use-cases it might very well have been. If you don't know how to program and only want to display some fancy styled text, why would you need to understand that a number isn't a string?
But there was the pattern, that "real" programming languages like Java and C/C++ were hard to learn for the average "creator", so they took JS and PHP as entry and built up their skills from there, building bigger and bigger solutions with those tools.
Re: Bjarne Stroustrup Quotes
#114A few of my favourites;
> An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only.
In a broader sense what it implies is that companies should not make a Programmer's job onerous (in any dimension) to the point that the "joy" is gone from the doing of the activity itself. Thus Reports/Meetings/Processes/Testing/etc. should all be modulated/balanced based on needs/project and not because it is the latest fad. Managers should really really heed this.
> Far too often, 'software engineering' is neither engineering nor about software
This is a follow-on from the above.
> Any problem in computer science can be solved with another layer of indirection.
I have also heard this attributed to Andy Koenig.
> My ideal of program design is to represent the concepts of the application domain directly in code. That way, if you understand the application domain, you understand the code and vice versa.
This is how i learnt the techniques of designing in C++ from the early days i.e. from "Barton and Nackman's Scientific and Engineering C++" and "James Coplien's Multi-paradigm design for C++". This is fundamental to problem-solving itself and hence in any job it is of utmost importance to understand the domain i.e. Why and What is being done rather than the How.
> Legacy code' often differs from its suggested alternative by actually working and scaling.
Very very true. This is why i dismiss people who come in and start saying "everything must be rewritten" without spending time studying and learning about the existing system.
Re: Bjarne Stroustrup Quotes
#115Earlier quoted context omitted.
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.
There are definitely trends, but the pattern I see with early JS and PHP is they simply didn't anticipate the consequences of certain decisions. What happens is you make a decision "locally", for some use case or program. And then you don't realize how it affects other programs. The well known "Wat" talk about JS by Gary B. is basically a bunch of these unintended consequences. So the problem is really to see the who…
And why would they? PHP and JS weren't designed with their big use-cases in mind, even if their creators like to boast ("Always bet on JavaScript", etc.)
People saw the alternatives as much better solutions. We had JSP and Java applets; those were the future! PHP and JS were just playthings for people who that couldn't grasp Java.
Python had the luck not to be incepted as a small DSL for a specific problem. So it doesn't have the issues that PHP and JS face.
Re: Bjarne Stroustrup Quotes
#116Earlier 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…
> For example, the number of characters in the string is simply the length of the string.
For I/O you need the amount of bytes it occupies in memory and that's always known.
For text processing, you don't actually need to know the length of the text. What you actually need is the ability to determine the byte boundaries between each code point and most importantly each grapheme cluster.
> when you really need Unicode
You always need Unicode. Sorry but it's almost 2024 and I shouldn't even have to justify this.
For I/O, you don't need "strings" at all, you need byte buffers. For text, you need Unicode and everything else is just fundamentally wrong.
Re: Bjarne Stroustrup Quotes
#117Earlier 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 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!
Re: Bjarne Stroustrup Quotes
#118Shooting yourself in the foot in various programming languages. http://www.toodarkpark.org/computers/humor/shoot-self-in-foo...
My favorite: UNIX: % ls foot.c foot.h foot.o toe.c toe.o % rm * .o rm: .o: No such file or directory % ls %
Ha ha. And that's not even a newb mistake alone. It's possible even for an expert to maje, by just one accidental space keypress, between the * and the .o, in 2nd command above. Such is Unix.
Re: Bjarne Stroustrup Quotes
#119Earlier 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.
Unicode has such a rich collection of symbols. I use them frequently in code comments.
Re: Bjarne Stroustrup Quotes
#120Language 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…
Yeah, it's extremely difficult. Everything interacts with everything else. A recent snag I've run into recently with my language: I want to have mutable strings and lists but that complicates their use as hash table keys.
I'm so used to the C mindset of just modifying everything in place. It wasn't until I actually tried this that I understood why so many languages just copy everything. I researched how other languages dealt with this problem and many only allow immutable objects as hash keys. Most interesting was Ruby which allows mutable objects as keys, warns programmers that modifying keys can invalidate the hash table and provides a rehashing method to fix it.
https://ruby-doc.org/core/Hash.html
> Modifying a Hash key while it is in use damages the hash’s index.
> You can repair the hash index using method rehash
> A String key is always safe
> That’s because an unfrozen String passed as a key will be replaced by a duplicated and frozen String
I like Ruby a lot.