back to article 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 …

Page:

  1. werdsmith Silver badge

    Top-heavy, turning hard, firing a broad-side and a gust of wind all coinciding will cause the ship to heel over and flood through the open gun ports. The Danes had not learned from the Mary Rose 80 years before.

    1. Solviva

      What's with the reference to Denmark (here and in the main article)? Vasa is/was a Swedish shp.

      1. T. F. M. Reader Silver badge

        What's with the reference to Denmark (here and in the main article)? Vasa is/was a Swedish shp.

        Stroustroup is Danish.

        (This is not intended as support for stings against Danes, in either articles or comments.)

      2. rsole

        And "shp" is probably the sound it made as it went down.

    2. Steve Crook

      Actually, there's more...

      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.

      1. ibmalone Silver badge

        Re: Actually, there's more...

        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.

        1. Dodgy Geezer Silver badge

          Re: Actually, there's more...

          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....

      2. SVV Silver badge

        Re: Actually, there's more...

        "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.

        1. GrumpenKraut Silver badge

          Re: Actually, there's more...

          > ...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.

      3. Dagg
        Trollface

        Re: Actually, there's more...

        The Vasa didn't start out top heavy. Marketing decided they needed new features to keep up with the cutting edge of flagship design.

        Sounds like they used an agile approach to warship construction.

        1. onefang Silver badge

          Re: Actually, there's more...

          "Sounds like they used an agile approach to warship construction."

          Coz when you try to build a warship under the waterfall model, it sinks very quickly.

          1. tychosoft

            Re: Actually, there's more...

            they simply iterated their way to an ever taller and more unbalanced ship...

      4. qwertyuiop

        Re: Actually, there's more...

        I doubt if it was the weight of the canons that did it. Obviously they'd be written down and paper can be heavy but there would have to be a huge number of them to have any effect.

        The weight of the cannons however is a different matter...

    3. Anonymous Coward
      Anonymous Coward

      C and C-style C++

      I will stick to C and C-style C++.

      All these incompatible extensions from M$ to C++, and all the feature creep that started with C++2011 - no thanks. Btw. M$ is too dumb to even support C99 in 2018. There is no hope for them.

      1. HmmmYes Silver badge

        Re: C and C-style C++

        I think the problem is trying to do everything in one language.

        You can't. Itll drive you mad.

        Layer your software - assembler/C at the metal/kernel. C++ at the system level. Dynamic scripting language a the application level.

        1. The Indomitable Gall

          Re: C and C-style C++

          @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?

          1. Wayland Bronze badge

            Re: C and C-style C++

            Software became unreliable when the malloc() function was implemented. If you can write in C and use static memory allocation then it's possible to properly test a program.

          2. HmmmYes Silver badge

            Re: C and C-style C++

            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.

        2. JohnFen Silver badge

          Re: C and C-style C++

          "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.

          1. HPCJohn

            Re: C and C-style C++

            JohnFen

            Plesae have a look at Julia. 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. Runs comparably fast as C.

            https://julialang.org/

            1. Michael Wojcik Silver badge

              Re: C and C-style C++

              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.

        3. JBowler

          Re: C and C-style C++

          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.

      2. Rob Gr

        Re: C and C-style C++

        With all the incurrring dangers relating to buffer overflows, unfreed memory, etc.

        To write new code without some form of protection from these kind of errors is verging on irresponsible now.

        1. HieronymusBloggs Silver badge

          Re: C and C-style C++

          "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.

          1. GrumpenKraut Silver badge
            Windows

            Re: C and C-style C++

            > It always was irresponsible to write code without that kind of protection, regardless of language.

            Try teaching THAT the kids these days!

            Mumble, mumble, ... *waving crutch* ------>

          2. bobajob12

            Re: C and C-style C++

            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.

            1. JohnFen Silver badge

              Re: C and C-style C++

              "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.

              1. aks Bronze badge

                Re: C and C-style C++

                "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.

              2. Ian Joyner

                Re: C and C-style C++

                “"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.

          3. Ian Joyner

            Re: C and C-style C++

            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.

      3. david 12 Bronze badge

        Re: C and C-style C++

        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

      4. Wayland Bronze badge

        Re: C and C-style C++

        C is excellent. C++ is insanity. It sounds like the insanity is metastasising.

      5. oneguycoding

        Re: C and C-style C++

        This approach is probably the reason I stopped using C/C++.

        Stroustrup has always been a blowhard, for me his ship sank almost 20 years ago.

        1. Michael Wojcik Silver badge

          Re: C and C-style C++

          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.

    4. Stork Bronze badge

      The Danes at the time knew that - they build ships that sailed. BTW, generally Danes beat Swedes at sea and Swedes Danes on land - which may be why it is now a sea border between them

    5. Anonymous Coward
      Anonymous Coward

      TRANSPUTER WAS AN UNDISPUTED RULER

      No body will be able ever again to make such a success story into an regrettable sadly true comedy.

  2. Mike 125

    Disagree....

    "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.

    1. Wilco

      Re: Disagree....

      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

      1. LucreLout Silver badge

        Re: Disagree....

        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.

      2. JDX Gold badge

        Re: Disagree....

        >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).

      3. Blank Reg

        Re: Disagree....

        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.

        1. JohnFen Silver badge

          Re: Disagree....

          "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.

          1. Someone Else Silver badge

            @ JohnFen -- Re: Disagree....

            "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.

      4. JLV Silver badge

        Re: Disagree....

        >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.

        1. Jack of Shadows Silver badge

          Re: Disagree....

          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.]

      5. Adrian 4 Silver badge

        Re: Disagree....

        C++ still isn't good enough for embedded systems (unless you mean phones, which are more like a pc on a stick than their embedded roots)

    2. ForthIsNotDead Silver badge

      Re: Disagree....

      I thought the same. I thought he just described Java when he described a "completely type-safe and resource-safe style of programming". That's what Java *is* and it became a thing precisely as an antidote to C++.

      1. WallMeerkat Bronze badge

        Re: Disagree....

        Java was killed off when the JRE installer started becoming a trojan platform for browser bars.

        1. LDS Silver badge

          "when the JRE installer started..."

          .... 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....

      2. Dan 55 Silver badge

        Re: Disagree....

        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.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019