This is satire. A parody based on Stroustrup's many defenses of C++.
It makes me laugh every time I read it. Some day, hopefully many years from now, I suspect someone will write "Bjarne's Deathbed Confession" with the exact same premise, just updated.
We have "Poe's Law"; we've seen numerous people being caught making overly-candid remarks in various contexts; numerous people caught posting to main instead of their sock-puppet... and that's before we get in to the difficulty of recognizing satire when it's not your native language, etc.
We know people say absurd things, so there is absolutely a need to clearly mark satire/humor
This week I had the opportunity of revisiting C++. I had not used it in a project in nearly twenty years and I found modern C++ an absolute joy to use. Of course it is still blazingly fast. But now I could build a complete app with no explicit memory management at all. Lamdas are a joy to use and integrate cleanly with STL and boost. Compiler error message are now much much better. Cross platform compatibility was awesome. The same program compiled cleanly with VC++ clang on MacOS and GCC on Linux cleanly. Finally there is a ton of documentation on every weird nuance of the language just a web search away. Both CPP reference and MSDN are just amazing. Overall I’m really happy with how much progress the language and tools have made.
The language itself has made enormous progress, but build-systems and lower-level concerns like linkers and compiler idiosyncrasies still plague even simple projects.
Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto, but even then things like mixed-version dependencies and system libraries are large barriers to entry in getting started and distributing serious work.
(This applies mostly to new projects adopting modern C++. Projects that are already established in my experience don't usually have to invest much in way of their tooling and build-system provided they're not adding new dependencies or platforms on a super regular basis. We recently upgraded a 100k+ SLOC program from C++17 to C++20 and only one or two very small things failed to compile. Once the system works the system tends to stay working.)
The standards committee has stayed away from delving into these issues. Perhaps with good reason. But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly.
Perhaps modules and other newer features will obviate some of those build-like features and the problem will be more tractable by the time C++25 (?) comes around.
> Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto
Given that I've been working with C++ for nearly 30 years, have used autotools, cmake, meson and waf but have never heard of vcpkg, it seems unlikely to me that such a thing is going to be the de facto anything.
> But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly.
Binaries are platform specific (especially installers). I don't want my language (which should almost necessarily be platform independent) grappling with or trying to tell me how to deal with them.
Understanding that creating binaries is a potentially complex task that is largely (though not totally) independent of writing code is an important step for programmers working in compiled languages.
14.4k+ stars, and it's a product from Microsoft. It uses cmake under the covers (for now?). Doesn't mean it will win, but it's a contender.
> Binaries are platform specific
Yes? Each new platform has to be more or less officially adopted into a build-system. Maybe better one "official" build-system rather than dozens. Reduce the surface-area for adding a new platform and maybe it won't seem so herculean anymore.
> trying to tell me how to deal with them
An official build-system doesn't have to be any less feature-ful than the hodge-podge of current offerings.
> creating binaries is a potentially complex task that is [...] an important step for programmers
It doesn't need to be as complicated as it is today. And I don't think you intended it, but this last bit reads as dismissive and condescending.
Many of us veteran C++ folks are so used to the way things have always been that it's hard to imagine an alternate universe where a sane and powerful build-system was "in the language" from the start.
It may be a hard problem, but `cargo` has some interesting ideas, and I don't hear anyone complaining about not being able to do low-level and platform-specific things in Rust...
The first problem with these concepts for packaging is that they almost always start with a provably false assumption:
* that there is a canonical way to build every dependency
With this assumption in hand, they move to a conception in which you somehow make the dependencies available (canonically built) and then assemble your binaries (if not your actual installer) with this.
But there is no canonical way to build lots of dependencies. Two reasons (at least);
* software libraries with build flags that totally change their behavior. One example that I deal with is libfftw which can be built for single-threaded or multithread use (and the two should not be used in the wrong context). Of course, this can be addressed by referring to each "version" with a different name, but if there are N build flags, that causes an explosion of possible variant names. Another example would include libraries that have hard-coded search paths (this is NOT automatically wrong) that are set at build time; the search paths may differ depending on the target platform. The "appropriate" location for dynamically-loaded modules, for example, differs even among Linux systems, because of the behavior of the system's dynamic linker. Plugins (compiled to dynamically-linked objects, loaded at run time based on user input) are always problematic because they have their own build systems that can be out of sync with those of their associated SDKs.
* projects that need to patch libraries with changes that, for whatever reason, will not be accepted upstream. An example for me are changes I made to GTK2 to support macOS's version of mouse events so that you can differentiate the extent of a scroll wheel "roll" correctly. My project needs this functionality, and it was never going to be part of GTK2 (the API was frozen before anyone realized that macOS handled scroll wheel events differently). So my project builds with a patched version of GTK2, not the one provided by the platform "package manager"
These sorts of real world complications are easy to want to dismiss or wave away or pretend that there's some sort of magic that will make them vanish and never come back. I don't believe that this is true.
I got to revisit C++ to port some code to boost::asio
It crashed because the object was deallocated by time the handler ran. So now I'm taking a shared_ptr parameter thisref parameter to keep "this" alive. Ideally it'd be a unique_ptr, but then my understanding is that ptr->func(std::move(ptr)) is undefined
It's nice if these sorts of details are compiler errors, but at least there were some compiler errors:
I ran into some issues over whether move being ambiguous for std::move. Took awhile figuring out where to get socket types for boost, between template parameters being duck typed & boost source being a tangle to read as documentation. Errors end up being in some header when the issue is my code somewhere passing the wrong thing
Got it all sorted out eventually, but glad to get back to C/Ruby/Go/Rust programming
No so long ago I rewrote sizeable python web application with C++ upon client's request. Never mind huge performance gain the C++ source code was about the same size if not shorter (do not remember exactly). And not a single explicit memory management code.
Your comment is timely and encouraging for me. I last used C++ seriously in the late 90s and have thought about picking it up again to get out of my comfort zone (it's that or something like F#). I plan to play with some Wasm.
Yeah I can't help but wonder if this was written by somebody who was either too dumb to learn C++ or somebody who's hiring programmers and is angry that they're not willing to work for him for minimum wage.
I’m using it for the first time and have been wondering what all the horror stories are about.
But then realize those horror stories were from 15+ years ago.
Did we need Rust?
Or did we need to build out the C and C++ ecosystems to make them easy and safe?
How many hours spent on all these languages for a few folks to build fiefdoms upon? Every human endeavor has a group of swindlers that tell you they’re helping but in hindsight often looks like they just got in the way.
Under every modern, shiny, abstract, high-level feature of the language or the standard library there are layers and layers of legacy cruft. Every aspect the language has experimented with has to be supported by the new features, making simple things like the Variant type for example, very difficult to implement correctly [1].
C++ is nice and good until you hit a bug that leaks an abstraction and you realise you barely understand 10% of the language, and you'll never understand it completely, because people spend their entire careers trying to track down how language features interact and where they explode, and they're never finished.
Also, I'm fairly convinced that when they chose not to take Epochs for C++ 20 they sealed the long term fate of the language.
Epochs was the only halfway practical way to attempt the ever elusive step B of the "Smaller, better C++" idea, the part where you toss away all the stuff nobody needs. For many years now, the protestation has been that it's a great idea but first a few more things must be added. And then a few more. And a few more. Bjarne himself has a laundry list. Adding things to C++ is extremely ugly but it can be done and is still being done. However removing things is hard, and Epochs proposed a practical way to begin that work. It was shot down and I think years from now a C++ post mortem will pronounce that as at least contributing to the outcome if not outright the primary cause.
Epochs would have been really hard to do in C++ 20. But it isn't getting easier and the will to attempt such a thing seems to me to be finite.
Isn't that the poster-child of template metaprogramming? Being able to choose a different sub-byte layout for your container type depending on the type parameter? What problems are you running into when using std::vector<bool>?
Templating has nothing to do with my hate. It’s the fact that for all other vector types you can assume that index-based access only conflict for the same index. The only exception is…
Of course it’s unlikely for you to know this because who knows all the nuances of C++ so you end up with a race in your code. Those can be very hairy to crash, reproduce, and debug.
Surely shining light on and fixing those issues would have resulted in C/C++ essentially becoming what Rust hopes to be.
But western kids needed to found new big business and institutionalize math.
Seems the west has a real issue with oligarchs needing to manage the masses. No one can be rich unless an institution has decided they are correctly rich.
Multithreaded C++ programming without bugs is still very hard. There was an interview on Mozilla and why they started Rust and everytime they had some path in the code with threads, they found some concurrency issue. I can't find the link right now.
> Multithreaded C++ programming without bugs is still very hard.
Multithreaded programming without bugs is hard in any language, unless the language completely cripples your ability to do certain things that tend to be where the bugs can creep in.
If you religiously stick to the rules (e.g. mutexes around all variable use, mutexes and condition vars used correctly), you will not have bugs. The problems come because people do not religiously stick to the rules, because their language doesn't require them too.
The problem is that if you are forced to follow all the rules, then certain things become impossible, such as lock-free programming (even the simple single-reader, single-writer FIFO). The use of memory barriers to create provably safe lock-free code is outside the scope of regularized multithreaded programming, and since it's very very hard to get that write, but people want to try it anyway, that's where things go wrong.
Just use things the way you're supposed to and you won't have bugs with this.
> Just use things the way you're supposed to and you won't have bugs with this.
If we humans just learned to use things we're supposed to, we would never have null pointer exceptions, issues with use-after-free nor buffer overflows. Heck, we should all just use goto while we're at it, all it takes is to religiously stick to the rules!
Reasoning about null ptr, use after free, buffer overflows is tricky, because you cannot determine whether you've done the right thing by "just reading the code".
If you are doing multithreaded programming, and there's a variable shared among threads, and there's a read or write of the variable without a mutex in sight, you've done it wrong.
Yes, the mutex owner could be a caller several layers up the stack. Sometimes that's a legitimate design, and if you know what you're doing your function/method names will reflect the fact that the lock is already held. If you don't know what you're doing, you should avoid that design and lock the mutex in the same scope as the read/write.
And of course, using RAII with C++ (or anything else that supports it) makes this sort of thing easy to do.
Really? We did not need Rust? Here is what some of the best paid C++ Developers in the world come up with after billions of dollars invested in product development:
You do realize Chrome's code has a lineage that is over 24 year old, based on khtml.
If you are starting a project from scratch with C++, you can avoid a lot of the pitfalls chrome's team has. Additionally Google has an arguably poor C++ coding style that is also completely out of date.
A company that uses C++ more effectively is arguably Adobe, who has the great Sean Parent.
Uh, using Adobe as an argument in favour of C++ as a reliable programming language from a memory safety perspective is not a good argument. Just looking at the CVE count tells a story that cuts across their entire product line, and then we have the long and storied history of Flash and Acrobat vulnerabilities.
Any non-trivial code base in any language will have security issues, but the argument that these security vulnerabilities are a result of using C++ poorly doesn't change the fact that C and C++ have tons of footguns and pitfalls based on both modern and legacy code.
That's the problem with these languages (both C and C++) — it's always the user's fault. The language blows up if you accidentally miss one of the twelve thousand rules? User's fault, PEBCAK. If only the poster X was writing the software in question, these bugs never would have happened. I've seen this argument a million times.
One thing that is still horrific (imho) is unicode support. Last time I found that in order to print unicode strings with cross platform support on a simple way I required a boost library [1]. The dichotomy between standard and "wide" string APIs is kind of a mess.
Also, construction, destruction and move semantics makes everything really complicated and even simple baseline code requires a bunch of boilerplate [2].
Rust does much more to force you to be safe. (Or, to put it differently, C++ still has all the unsafe ways available, and not locked away behind the "unsafe" keyword.)
Note that the unsafe keyword of Rust unlock only few things. But that what makes it powerful.
unsafe mainly allows you to dereference pointers. References are guaranteed to be safe at all time, with an associated lifetime, while pointers can hold any possible memory address, valid or not (like in C++).
unsafe also let you promote a pointer to a reference by assigning a lifetime.
And finally, unsafe allows you to call functions themselves marked unsafe. One notable function is called transmute, and is very similar to how the the C style cast works in C++. It's the one that automatically selects between static_cast and reinterpret_cast depending on the context.
> Or did we need to build out the C and C++ ecosystems to make them easy and safe?
If so, the C++ committee wasn't interested in doing so. Preferring instead to say that new features don't have safety if there was any possibility that doing so might provide opportunity for improved performance.
Don't worry, when inevitably you blow your feet off with any of the new footguns provided, they'll be happy to tell you that it's your fault, a true C++ programmer would have known not to do that. "Git gud" as the gamers say.
Backward compatibility is valuable, but so is letting go of old habits. With C++ and Rust, we can have our cake and eat it too. Plus, arguments about which language is better! ;)
It is insanely complex. Yet modern C++ is easy to use. Just don try to be Alexandrescu. I am very far from being C++ expert yet I have zero problem using it to write stateful multithreaded business servers that run for month at a time (maybe able to run for longer but I update with new features more often).
The challenge with C++ is that unless you are writing something entirely from scratch with very few third party dependencies, it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++. I've worked on projects that have started out small as well as projects that have reached (and passed) the 10M LOC mark, and this is a recurring theme.
I've worked as a developer for about 35 years and I have yet to work on a C++ project where there isn't older code that has to be accommodated.
Being able to write code that doesn't crash after a while isn't really a high bar.
>"Being able to write code that doesn't crash after a while isn't really a high bar."
Totally agree.
>"it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++"
I do not work with the projects (I assume monoliths) of such size so I guess I can count myself lucky. I would guess though that this amount of code accumulates over many years and I suspect that the majority of languages along with libs and other accompanying stuff would change as well over the time. Maybe C++ is not so special in this regard.
I was hired once to fix old PHP application which was insanely giant. The type of code I saw there ranged from beautiful to making me nearly puke. It looks like the situation similar to what you've described but in completely different language. Again the cause here I think is total size, many developers coming and going and their qualifications.
Also for as long as I can remember (40 years) I've almost exclusively worked on creating new products from scratch. Again extremely lucky. For new projects I would definitely advocate C++. But if one wants to do it in Rust / (insert your own favorite) for example I have nothing against it. Seems like a matter of taste to me (assuming compile times are reasonable and do not impede workflow).
I would admit that I would never dare to write / mess with some code I see in system libraries or some other template heavy libraries. It can be extremely complex language wise. But I've already mentioned it in original post. Do not try to be Alexandrescu. Those are special people. And this is also special purpose type of code that is not needed for general application programming.
You make one very important point: code that accumulates over many years. Not least in libraries you depend on (which make up a significant part of a lot of non-trivial code).
This is is bad in every language as it often means you get code that was written for a different version of the language. But for C++ it is particularly bad because C++ has spent so many years not even getting the most basic things right.
And when I say basics, I mean things like a string type that people will consistently use.
> There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about ‘90 or '91.
This reminded me of the very first industry conference I attended as a kid, Usenix C++ 1992, from where I seemed to recall a talk about Mentor dealing with static initializer costs. :)
I remembered that paper about a decade later, when a related problem came up in an interview at a company developing a new Web-oriented programming language, when they were talking technical about how they do program loading. It turned out they had indeed anticipated and/or run into that, and had a clever solution for it, and seemed impressed that I'd asked about it (thanks to the Usenix C++ paper by John F. Reiser from Mentor Graphics).
Bit OT, but I think I never had a venue for saying this in public: Stroustrup is absolutely one of the most inspiring programmers I'm aware of, think of C++ what you like.
Stuff like const correctness and references were way ahead of its time IMHO, and I always found his talks and writing insightful.
Despite the pretty insane success of his creation, and all the hate, he always seemed pretty down to earth and friendly to me - I don't know if a lot of people could have pulled that off in his position.
Maybe I'm missing some major flame wars or dramas, but from all I've seen and heard, a very inspiring person.
I thought it would have been obvious to anyone that this is satire, but then again I know that it was explicitly presented as such the first time I read this text so I'm probably biased.
"I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers?"
Why would anyone say that about a language they designed?
Yeah, we would definitely be ahead by using tcc instead of gcc (who cares about running optimized code anyway? Smh), PDF is harmful so use PS? They are not even competing projects.
SQL database as harmful? Wtf. Vim is harmful? Like, they should just fking quit CS if they are afraid of complexity - because due to many interesting problems having an essential complexity way higher than the very low bar they can understand, they can’t really produce anything worthwhile.
I try to stay away from C++ (successfully for the most part), but I do recommend Stroustrup's "Design and Evolution of C++".
It is a bit dated by now, but it is the best book on the design and evolution of any programming language in general I have come across. (wink If anyone knows of a serious contender, please let me know!) I wish he'd update it to reflect the changes C++ has seen since the book was first published.
I'm torn on this. Had to learn (well just the basics) c++ in school and even though I didn't really know anything I wondered if things really need to be that complicated. So I went over to the "dislike c++" group as soon as I figured out one exists. On the other hand, I really enjoyed his c++ book (there are probably many, don't know which one anymore) and from it and the few talks of his I saw I think he's really good at explaining and a good teacher.
I'd disagree about C. It is just too simple to look like something deliberately created to write unmaintainable code. Although we know it is not only possible, but actually common.
If only people took Bjarne Stroustrup's paper "Generalizing Overloading for C++2000" more seriously and implemented it as part of the official standard, all of C++ usability and complexity problems would have been solved long ago, and C++ programs would all look beautiful and elegant.
It's funny but honestly Stroustrup is the best language designer out there. While others abandoned their creations to make new languages, Stroustrup soldiered on and modern C++ is actually amazing. He's a working programmers language designer, not an academic.
He basically added every feature he could think of on top of C, glued it with spit and released it as a pre-processor. There was barely any design involved. Just look at how many types of inheritance there are.
I remember Stanley B. Lippman (one of the first developers on cfront) recollecting how the proposal to implement multiple inheritance was met with resistance from the community. And the implementing team realized they couldn't write a sane implementation, and people complained against it, but they made one anyway, partially because they wanted to prove they could. New features to cfront were added with very little concern for design.
Things where standardization would have mattered (like the mangling algorithm) were never touched, so now every compiler has the liberty to generate whatever symbols it wants, and call functions with whatever calling convention it chooses, so you either have to compile all your dependencies, or make sure you fetch the binaries that use the exact same compiler version and flags, otherwise they won't link.
Also, Stroustrup didn't "soldier on", the CPP standard is maintained by a committee of people from all over the world, and the standard library slowly adopts data types and algorithms from the boost library, because they need a multi-year staging period, handled by someone else, to see if things work before they muster the courage to standardize it.
The reasoning behind what was added is clearly described in the "Design and Evolution of C++" book.
Besides the main reason why C++ exists is because he swore to himself never to go through the Simula => BCPL downgrade ever again, and C is a tiny step up from Bootstraping CPL compiler, so....
Here are a few excerpts from "The Design and Evolution of C++"
Another factor was purely irrational. Nobody seemed to doubt that I could implement templates efficiently. Multiple inheritance, on the other hand, was widely supposed to be very difficult to implement efficiently. For example, in summary of C++ in his book on Objective C, Brad Cox actually claimed that adding multiple inheritance to C++ was impossible. Thus, multiple inheritance seemed more of a challenge.
He then goes on a 13 page explanation of how he thought there was a simple implementation.
He then acknowledges the controversy, but brushes it aside with:
I think - as I did then - that the fundamental flaw in these arguments is that they take multiple inheritance far too seriously. Multiple inheritance doesn't solve all your problems, but it doesn't need to because it's quite cheap. Sometimes multiple inheritance is very convenient to have.
I have kept out of the multiple inheritance debates: multiple inheritance is in C++ and cannot be taken out or radically changed; I personally find multiple inheritance useful at times; some people insist that multiple inheritance is essential to their approach to design and implementation; it is still to early to have solid data and experience about the value of C++ multiple inheritance in large scale use; and, finally, I don't like to spend my time on sterile discussions.
This goes hand in hand with the original "principles" of C++ design, namely "C++ must be useful now". It didn't really matter how the complexity will evolve in the future, as long as it solved someone's problem today. And once it was implemented, there was no going back, so it didn't matter what people thought, it was done.
This process isn't really what I would call "design".
Rob Pike's reluctance to implement anything in Go that would add unnecessary complexity. Or Andrew Kelley's Zig language principles of no hidden control flow.
These are examples of doing more with less and avoiding unnecessary complexity by thinking ahead. Ironically, they probably wouldn't be designed the way they are if it wasn't for the hindsight provided by C++
People still write Go applications fine without generics, and Zig is a smidge higher level than C and currently in beta. How does this disprove anything I argued before?
Ah, so now the argument moved from how delightful the authors of those languages are capable to perfectly design them, to people write code in them, got it.
It's really ironic that you're the one to play the goal post moving card, when you haven't refuted my original statement.
They don't have to be "perfectly" designed, the design needs to exist. If Go didn't have a design, it would've had a half assed generics implementation, like C++ has multiple inheritance. It's precisely because generics are hard to implement right and the design constrains how much you can stretch the language that Go still doesn't have them. And it's arguably a good thing.
Sorry I wasn't explicit: it's safer and easier to write the same application in Go or Zig than it is in C++, even without generics or read-after-write compile-time checks.
No my dear friend, you attack Bjarne Stroustrup, asserting he doesn't have a clue how to design a language, and then present two examples of design perfection, which have proven to actually be just as clunky.
Go generics are half assed, compromised to fit into existing codebases, as it was expected they would turn out.
Are you also going to argue for the beautiful design of nullable interfaces that aren't actually null?
Maybe it was the clever design idea that one has to produce a compiler error to validate if a given type does support or not a specific interface.
I know, modules, what a beautiful design, where the community feedback was greatly appreciated, what a lovely design it turned out to be.
I didn't assert Bjarne doesn't have a clue how to design a language (and I can list features of C++ that are brilliant). I didn't provide examples of "design perfection", I provided examples of design principles I think better manage complexity.
I asserted CFront was a mess of ad-hoc features implemented in a rush prioritized by personal hubris. I asserted Bjarne didn't consider how much complexity was piling up and didn't listen to critics. I've provided you with quotes from his own book supporting this.
Your every reply was condescending whataboutism, my friend. Can you provide counter arguments why CFront was a beautifully thoughtfully designed language where features and complexity was considered and debated before being implemented? Because all your other arguments are just strawmen.
And I would really appreciate it if you could use a language that at least tries to use a constructive tone that adds value to the debate, instead of the snarky sarcasm one-liners. I don't care much for this white horse, Bjarne defending attitude.
I've actually watched Andrew Kelley stream implementing and designing the Zig compiler and I've been following the discussions on language features. But this is just another whataboutist strawman.
Stroustrup is brilliant. Even his books on C++ are well written. The problem is that C++ treats humans as smart, whereas a language like Rust treats humans as fallible. This is probably the most important and impactful paradigm shift in language design in the last few decades. Make a language for when people are weak.
I recently went through a bout of existential angst and nostalgia that led me back to the programming languages of my youth. I spent some time in C++ as it is today and honestly found it such a throughly modern language that it didn’t really scratch the itch I was reaching for. Ended up doing a couple of hobby projects in C, which maintains its brutalist charm.
He came to our startup once (IncludeOS) and simply asked us what we had problems in, in C++ and what we think about it. Very refreshing. I also won a game of Secret Hitler by denying his veto.
As a grad student, I was willing to take boutique courses from any of the PLT folk in the larger group (including Bjarne & Gaby). Most of the students were terrified of Bjarne, but I'd sit front-and-center and pepper him with questions. Eventually it got to the point that when I'd show up to lecture he'd shine his (green) laser pointer at me until I moved back & off center.
Bjarne's a genuinely good guy, and very smart; I think the "interview" is fun, but it doesn't really sound anything like him.
>"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg
>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg
>Andrew Hejlsberg:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
And these Larry Wall and James Gosling and Guido van Rossum quotes:
>James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall
>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
>"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling
>"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)
The interview is fake, but this story isn't. Years ago, when I still had to earn living by coding in C++, I complained about C++ to a friend of mine who was a well respected university professor. He said: "I know Bjarne. He is a good guy. He didn't do it deliberately."
Incidentally, back then I had to write device drivers in C++ - templates, inheritance and all. To preserve my sanity, I wrote a Perl script which converted a simple text file describing device registers into the horrible C++ code sausages.
I didn't know it was that old. There's a 1997 article that is in a similar vein, basically saying that Ada was created to slow down software development for the Soviets by bogging them down in creating an Ada compiler and using Ada:
I've been looking for a few minutes for a public copy or transcription, because I doubt I read it in ACM's digital library (though I may have when I was in college). I wonder how much it may have influenced this Stroustrup "interview".
Modern C++ is nice to use, but there's no way I would use it for a greenfield project. Rust simply gets so many things right and saves you the CPU years you have to spend on ASan/MSan/TSan/UBSan/valgrind and fuzzing just to shake out all the bugs.
the point that companies are looking for ways to create a supply of cheap code monkeys so they can pay everyone in the industry less. they do this by creating their own training programs and selling the idea you don’t need a college degree. they then also make sure that you cannot get hired if you have one, by requiring you take leetcode style interviews. this way they can give priority to those who took their programs, without getting sued for discrimination. this limits the number of highly paid people coming in. and everyone is falling for it and doing these stupid code interviews instead of saying no.
Mostly agreed, except that a college degree really isn't needed. There are a lot of successful programmers around who taught the craft to themselves as kids on their home computers, or in computer clubs.
