by asymmetric on 11/26/23, 8:27 PM with 164 comments
by chubot on 11/26/23, 9:28 PM
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 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)
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.
Looks like almost every language had problems with for loops and closures, including C# and Go - https://news.ycombinator.com/item?id=37575204
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.
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.
by smarks on 11/27/23, 5:21 AM
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.
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.
I think the quote holds up well.
by devjab on 11/27/23, 7:05 AM
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.
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.
by default-kramer on 11/27/23, 4:56 AM
by shrubble on 11/26/23, 11:47 PM
I have been unable to determine the provenance of this quote. Source and image: https://ifunny.co/picture/history-the-official-mascot-for-c-...
by jll29 on 11/26/23, 9:02 PM
(in response to my complaint to him that hastables again hadn't been included in the most recent standard at the time.)
by lmedinas on 11/26/23, 10:38 PM
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++.
by rramadass on 11/27/23, 9:21 AM
> 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.
by jlarocco on 11/26/23, 11:09 PM
"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."
by mike_hock on 11/27/23, 12:52 AM
Technically, his prediction (the implied inevitability of GC) came true, in practice, it did not.
Optional GC was added, never implemented, never used, and removed again.
by CSMastermind on 11/27/23, 12:10 AM
Even if you're a C++ expert, have 20 years in industry, etc. it's still an amazing example of beautiful technical writing.
by getpost on 11/26/23, 10:06 PM
"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind."
by zabzonk on 11/26/23, 9:03 PM
by Dudester230602 on 11/26/23, 9:15 PM
by fuzztester on 11/26/23, 10:33 PM
http://www.toodarkpark.org/computers/humor/shoot-self-in-foo...
by closetkantian on 11/27/23, 9:06 AM
Presumably he means programming language, but this may apply more generally.
by amadeuspagel on 11/27/23, 3:44 PM
True for many things. There are only two kinds of companies: the ones people complain about and the ones with no market power.
by rob74 on 11/27/23, 9:05 AM
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...
by actinium226 on 11/27/23, 2:06 AM
To be fair, it's not exactly a rude statement.
by bobmaxup on 11/27/23, 12:48 AM
by uwagar on 11/27/23, 8:04 PM
by zubairq on 11/27/23, 4:42 AM