What's all the C Plus Fuss? Bjarne Stroustrup warns of dangerous future plans for his C++ Earlier this year, Bjarne Stroustrup, creator of C++, managing director in the technology division of Morgan Stanley, and a visiting professor of computer science at Columbia University in the US, wrote a letter inviting those overseeing the evolution of the programming language to “Remember the Vasa!” Easy for a Dane to …
The Vasa didn't start out top heavy. Marketing decided they needed new features to keep up with the cutting edge of flagship design.
They were added by reluctant developers while trying to stick within original project schedules and work with a design that wouldn't easily accommodate RFEs. Then marketing added some more. Bigger canons? Yes! More canons? Yes! Another gun deck? Damn right we will!
Familiar, no?
Which is what Stroustrup is warning against.
Another interesting aspect of the Vasa disaster is that they did test the ship first, and the sinking could have been avoided. Standard practice was to get a team of sailors to stand on the top deck and run from one side to the other. When they did this to the Vasa it started to rock dangerously. So obviously, the Vasa being too big to fail, the person in charge called off the test. Various people knew there was a problem, but nobody spoke up.
It's of interest to know why the Wasa was top heavy, and what happened at the investigation afterwards.
Gustavus Adolphus wanted a big tall ship for fighting, so the shipwrights designed one according to his specs. During the build the designer died, so it was finished off by another, and at that stage was found to be obviously unstable.
But because the king wanted it, no one dared say anything. The ship was completed, launched, fitted out, and capsized on the maiden voyage when she encountered her first gust of wind. The king raved, and set up an inquiry to blame the sailors, the captain - anyone but himself. Eventually they settled on blaming the dead designer, and God....
"Which is what Stroustrup is warning against."
Well, Stroustrup has been at the helm of this officer-run ship for rather a long time now, and whilst he may hae been worried that the vessel is endangered by its' own weight and ungainliness, the urgency of pronouncing that the thing is about to sink without trace has been largely msiing until now - previous releases have seen him mainly extolling the virtues of the often mind bogglingly complicated new features. Having to write a "Core C++" manual so that the junior shipmates can fight their way through the confusing architecture just to find the damn wheel is an indication of just how ridicukous the situation haa become.The real danger is not sinking, but that the ship sails on forever getting so full of stuff that all the crew have left without the officers noticing.
The fact that lots more features get added every 2 years means that the current complete spec is incomprehensible to everyone who's not a rabid C++ obsessive. I've been using it as a primary, then secondary language for over 20 years and it makes me feel dizzy looking at many of the new features from the last decade. The reason I've given up on it is not because the old stuff isn't still sufficient for what I need (it is) ,it's because I know what happens when people get their mitts on all the luvverly new features : they start using them. Unnecessarily. And really inapproriately and badly. And they don't document their code because "duuuh, don't you understand implicit virtual module template pointer type conversion autoboxing precedence yet you thicko?". That's when you give up and decide to quietly abandon C++ and make a living using something a bit more sane.
It's a brilliant technology for expert low level programming, but just too dangerous to let average programmers anywhere near it for any general purpose use.
> ...when people get their mitts on all the luvverly new features : they start using them.
That's pretty much true for any language that offers a non-trivial amount of tools/techniques.
Look at some of the more horrible VBA code to see what happens with people's brains when a language from the other side of the spectrum is inflicted on them.
@HmmmYes
" Layer your software - assembler/C at the metal/kernel. C++ at the system level. Dynamic scripting language a the application level. "
Where do libraries sit though?
What do you see as the role for functional programming?
And why would you want dynamic scripting for applications when self-modifying applications are a security risk?
Libraries sit at the system level.
C++ is fine for software running on top of heap/MMU. Less so in the kernel/restricted memory.
I use Erlang/OTP. For its niche - distributed state - its great. But is a niche not a general purpose language.
Im looking at using Haskell for test/verification.
AS far as dynamic scripting being a security risk ..... nuts. You secure the application/system levels.
"Dynamic scripting language a the application level."
Please, just no. Applications implemented in dynamic scripting languages have the advantage of reduce development costs, but they come with the disadvantage of being inferior in terms of user experience and performance.
The "two languages" problem you describe is exactly what Julia is designed to overcome. Code in a modern language, with a REPL and Juyputer notebooks.
I like Julia, but I don't see Julia growing outside the HPC and data science domains. As with most programming languages, its advantages aren't compelling enough to retrain large groups of developers, much less convert existing codebases.
Jupyter (which is what I assume you're referring to) definitely has its applications - if I were doing quantitative research I'd definitely be considering using Jupyter notebooks, whether we were using Julia or Python or some other supported language. But I don't immediately see much use for it in typical system or business programming, even if that happens to be done in a language Jupyter supports.
Indeed, match the language to the application.
Perhaps he would have achieved more communication and less grandstanding if he had said "Algol 68".
For that matter, still less obscure than the Vasa or, indeed, the Mary Rose, "CPL", for which famously (in the right circles) BCPL was intended as the compiler-compiler and BCPL was, of course, the antecedent of B, then C, then C++.
Aseembler is only necessary for the bootstrap - surely that is the legacy of UNIX? C more appropriately encodes the only very slightly later requirements of assembler.
IMO the missing link is not a language but the ability of system level programmers to encode compute intensive tasks into C APIs which can be called from Python.
Alas, system level programmers always were the dumb ones.
"To write new code without some form of protection from these kind of errors is verging on irresponsible now."
You mean like understanding what you're doing and taking care to do it right? It always was irresponsible to write code without that kind of protection, regardless of language.
Certainly software standards are low compared to "real" engineering disciplines like civil engineering. So yes, people do need to know what they are doing and pay attention.
But the days of being able to keep the entire state of the machine in your head as you program, which was something that you could do back in the day, have long since gone. It's not you, a 68k, 16 registers and a bit o' RAM. It's two, or four sockets each with a variable number of cores, maybe with hyperthreading, maybe with memory access crossing a QPI, god knows how many registers, maybe the whole thing is virtualized, the clock can go slow, fast, stop for days and then wake up, I mean the complexity is astounding. I don't believe that any systems programmer can place their hand on their heart and predict zero % chance of a stray memory access or timing bug in that environment.
"Certainly software standards are low compared to "real" engineering disciplines like civil engineering."
Hell, software standards are low compared to what software standards were just a couple of decades ago.
"But the days of being able to keep the entire state of the machine in your head as you program"
A correct point, but I don't see the relevance here. You don't (and never have) had to keep the entire state of the machine in your head in order to produce high-quality code. And it's not true that computers have only become so complex in the last couple of decades -- it's true for microcomputers, but many mainframes qualified as "too complex for a human to completely grok" from even before the microprocessor existed. And high-quality code was produced by the truckload then.
"And high-quality code was produced by the truckload then."
As was low-quality code. I know. I wrote some of it. Just as often, it was the specification rather than the coding that was at fault. Anybody remember Y2K. Plenty of COBOL written in the 1970's was not expected to last that long. Most didn't but some did.
“"But the days of being able to keep the entire state of the machine in your head as you program"
A correct point, but I don't see the relevance here”
It is not just the state machine, it is the general complexity of everything. You need to keep in your head the whole complexity of libraries with many APIs. Some you might be familiar with, others not. It is a great help that compilers actually check that what you have done is correct, especially when you are having to use something obscure.
Really, where are these super programmers who can deal with this complexity in their head?
If you can get it right in your head, fine. It is correct, so the checks won’t bother you. But don’t have the checks and the bugs certainly will bother you.
If you really understand what you are doing, you want these protections. Automated checks to see the programmer is doing the right thing are beneficial. They are a help, not a hindrance. People who argue against protections - verification and security - don’t know what they are talking about.
But more than that is the issue of security. C’s model is that you can trust programmers to do the right thing. That is out of a naive age. It is now really, really, really stupid.
M$ doesn't even have a C compiler. It's a commercial decision: they also don't have a FORTRAN or a PASCAL compiler.
You can use their C++ compiler to run sort-of FORTRAN, PASCAL & C (using the macro language as required, the way C++ was originally implemented), but it's not F77 any more than it's C99
Stroustrup has always been a blowhard, for me his ship sank almost 20 years ago.
I disagree with Stroustrup on a number of points. I've argued with him in public, on Usenet. I'm certainly not an unalloyed fan of C++.1
But your comment is small-minded and foolish. Stroustrup has made many excellent contributions to computing, a good portion of which have nothing to do with C++, such as his essay (written while Chair of CS at Texas A&M) deploring the resistance to programming among academic computer scientists.
The article links to his papers on the history of C++ and programming languages in general, which are a good example of Stroustrup as an academic. I'd like you to point out where in them he's being a "blowhard".
1A decent, fairly clean language, hidden under a huge mound of ugly and unintuitive syntax, grievous legacy features, unfortunate complications, and obvious failings (some of which S. mentions in the article) which have yet to be remedied; most frequently seen in fevered visions after looking at far too much extant C++ code, which is nearly always execrable.
"I’d like to see C++ supporting a guaranteed completely type-safe and resource-safe style of programming. This should not be done by restricting applicability or adding cost[...] I think it can be done and that the approach of giving programmers better (and easier to use) language facilities can get us there."
I disagree. If it could've, it would've, by now. Performance and safety will always be in conflict.
C++ has been a Vasa for years. It floats because it's in dry dock.
If you want type safe resource safe programming I'd suggest Java, or preferably Scala.
There are now only narrow use cases for C++: embedded systems, low level systems programming, hard resource or performance constraints that you have demonstrated that you can't meet with a more tractable language.
I spent a decade writing C++, and nearly 20 years more working in Java, Scala, C# and F#. Only very occasionally have I had to fall back to C++ to meet some non-functional requirement.
The idea of writing a large scale system with a modern distributed architecture in C++ is ludicrous. Even if you could, what would be the point? And where would you get the developers.
Not quite a dead language, but one with increasingly little point
Not quite a dead language, but one with increasingly little point
An interesting view, and not one I'm qualified to disagree with particularly. I'm a C# dev - have been since it was released. I've not looked at C++ since the 90s, but upon reading the article formed the view I should possibly look again at C++ as another potential tool, so I've ordered the 2018 book as a prerelease.
>The idea of writing a large scale system with a modern distributed architecture in C++ is ludicrous. Even if you could, what would be the point? And where would you get the developers.
What do you mean, where would you get the developers? As the dominant applications language in the recent past, there are a vast number of experienced C++ developers out there. Many of them still relatively young (30s).
Despite having used it extensively, C++ has long ago become my language of last resort. It has just become too complex. This is especially problematic for legacy projects where you can find every instance of the latest and greatest addition to the language being used.
While you can write clean, easily maintained code, it's also trivially easy to write code that will make your eyes bleed just looking at it. And once that second developer joins the project the risk of eye bleed ramps up and increases as the team and project grow.
"While you can write clean, easily maintained code, it's also trivially easy to write code that will make your eyes bleed just looking at it."I literally can't think of a language that this isn't equally true for.
Stated another way, you can write FORTRAN in any language.
>I'd suggest Java
Yeah, because GC-originated slowdowns are not a thing. Precisely the type of focus that will motivate team to use C++.
System-level, which Java is not. Java drivers, anyone? If you're using C++ for a good technical req reason, Java is _not_ the alternative.
Contrast also interop capabilities: almost anything can talk to C++. Anything can talk to Java as well... provided it's Java, or at least JVM.
Lots of crap to learn:both.
If you separate active developement from legacy corporate base maintenance, a la COBOL, I suspect that C++, for all its flaws, will age better.
Been casually looking at Rust lately. Nothing immediate to do with it, but it does seem like a potentail for a true generic system language. Their focus on memory is what really sets them apart.
Rust has caught my eye as well, and for the same reason. If you or I dare to open the parts of my drives containing all compilers, scripting languages, RAD tooling, basically most everything usable over the last 45 years of software development, it's an impressive stack. When doing a job, I get the general requirements, budget, time, and a list of anything already used in-house. [It's extremely likely some other person is going to support this down the road.]
I collect languages and/or libraries like lint (pun fully intended). Look in the toolbag. Does X fit this job spec? Put in the useful widget stack. Otherwise, goto next. I've got better things to do than argue around evangelism of any sort.
[The last time I was evangelical, it was the Amiga.]
.... to multiply because most app work with just one specific release, developers don't know how to bundle it in their damned application locally, and you need to keep installed outdated and vulnerable ones.
And still, as soon you just look at a Java application, a couple of Gigabytes of RAM are gone....
Java is the antidote to C++ in the same way as a saw is an antidote to gangrene (remember you shot yourself in the foot with C++?). It's fiddly to develop for because it probably won't let you do what you want to do, the bits it will let you do are horribly bureaucratic, and if C++ is getting a bit fat, Java is in danger of collapsing under its own weight in libraries.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
