<i>Language design is a curious mixture of grand ideas and fiddly details</i><p>I hadn't heard this last one before, but it's SO right ...<p>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)<p>Turns out there's an avalanche of details, and they interact in many ways!<p>Python did better, but I strongly argue both Python 3 and Python 2 got strings wrong. (Array of code points isn't generally useful, and it's hard to implement efficiently. See fish shell discussion about wchar_t on the front page now; also see Guile Scheme)<p>OCaml seems to have gotten mutable strings wrong (for some time), and also I think the split between regular sum types and GADTs is awkward. And also most people argue that objects vs. records vs. modules is suboptimal. And a bunch of mistakes with syntactic consistency, apparently.<p>Looks like almost every language had problems with for loops and closures, including C# and Go - <a href="https://news.ycombinator.com/item?id=37575204">https://news.ycombinator.com/item?id=37575204</a><p>So basically I agree that plowing through all the details -- and really observing their consequences in real programs -- is more important and time-consuming than grand ideas.<p>But if you lack any grand ideas, then the language will probably turn out poorly too. And you probably won't have any reason to finish it.
“C++ is a language, not a religion.”<p>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.<p>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.<p>I think the quote holds up well.
“The problem with many professors is that their previous occupation was student”<p>This one is one of the more impactful on our industry in my opinion. I have a “side gig” as an external examiner, which means that every half year I get to sit through examinations on topics that I know most of the students will never ever have to use. And that’s the best case for much of it, the worst case is all the stuff they’re going to need to unlearn to actually become good programmers in a world where much of the academic programming that is taught today is the same I learned more than 20 years ago. Like a heavy use on technology based architecture, like separating your controllers and your models into two directories… Fine when you have two or three, not so fine when you have 9 million. I’m still impressed with how hard it’s been for domain driven architecture and a focus on actual business logic to make its way into academia when it’s literally always going to be how the students are expected to work in my area of the world. The same goes for much of the OOP principles, like code-share which has been considered an anti-pattern around here for the better part of a decade. Not because the theory is wrong, but because it just never works out well over a period of several years and multiple developers extending and changing the shared code.<p>I’m honestly not sure how we can change it though. Because most of the people who govern the processes are exactly students who’ve become professors, and if I had gone that route myself, I’d probably also be teaching the flawed lessons I was taught those 20+ years ago. Hell, I would’ve still taught them a few years into my career as it wasn’t until I “stuck around” or got to work on long running projects it became apparent just how wrong those theories were in practice. Again, not because the theories are wrong but because they are never applied as intended because the world is so much less perfect than what is required for the theories to actually work. You’re not going to be at your best on a Thursday afternoon after a sleepless week of baby watching and being slightly sick, but you’re still going to write code and someone is going to approve it.
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.
"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."<p>I have been unable to determine the provenance of this quote. Source and image: <a href="https://ifunny.co/picture/history-the-official-mascot-for-c-is-an-obese-diseased-Yy6zDtEU9" rel="nofollow noreferrer">https://ifunny.co/picture/history-the-official-mascot-for-c-...</a>
"We didn't have time for that." (Bjarne Stroustrup, before an invited talk, Cambridge Computer Lab)<p>(in response to my complaint to him that hastables again hadn't been included in the most recent standard at the time.)
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".<p>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.<p>This quote could be a very harsh reply to Rust vs C++.
A few of my favourites;<p>> <i>An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only</i>.<p>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.<p>> <i>Far too often, 'software engineering' is neither engineering nor about software</i><p>This is a follow-on from the above.<p>> <i>Any problem in computer science can be solved with another layer of indirection.</i><p>I have also heard this attributed to Andy Koenig.<p>> <i>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.</i><p>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.<p>> <i>Legacy code' often differs from its suggested alternative by actually working and scaling.</i><p>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.
Section 10.7 of "The Design and Evolution of C++" has some good ones from the early 90s:<p>"When (not if) garbage collection becomes available, we will have two ways of writing C++ programs."<p>"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."<p>"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."
> "When (not if) automatic garbage collection becomes part of C++, it will be optional"<p>Technically, his prediction (the implied inevitability of GC) came true, in practice, it did not.<p>Optional GC was added, never implemented, never used, and removed again.
Programming -- Principles and Practice Using C++ is one of the few must-read programming books in my opinion.<p>Even if you're a C++ expert, have 20 years in industry, etc. it's still an amazing example of beautiful technical writing.
I'll see you Bjarne Stroustrup, and raise you Alan Kay,<p>"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."<p><a href="https://en.wikiquote.org/wiki/Alan_Kay" rel="nofollow noreferrer">https://en.wikiquote.org/wiki/Alan_Kay</a>
Let's also not forget this: <a href="https://harmful.cat-v.org/software/c++/I_did_it_for_you_all" rel="nofollow noreferrer">https://harmful.cat-v.org/software/c++/I_did_it_for_you_all</a>
Shooting yourself in the foot in various programming languages.<p><a href="http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html" rel="nofollow noreferrer">http://www.toodarkpark.org/computers/humor/shoot-self-in-foo...</a>
"Nobody should call themselves a professional if they only know one language".<p>Presumably he means programming language, but this may apply more generally.
> "There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.<p>True for many things. There are only two kinds of companies: the ones people complain about and the ones with no market power.
> "<i>People who think they know everything really annoy those of us who know we don't</i>"<p>I have read some of these quotes before, but not this one. Very true, especially for designing programming languages (where many people think they're experts), but not only...
> "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.<p>To be fair, it's not exactly a rude statement.