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 …

  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

        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

        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

        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

          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 Silver badge
        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

          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

        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

            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

            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

          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

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

            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

              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

                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 Bronze badge

                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 Bronze badge

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

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

        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

          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

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

          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

        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

      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

        Re: Disagree....

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

        1. Anonymous Coward
          Anonymous Coward

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

      3. Fibbles

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

        The difference is that C++ aims to do these things with zero runtime overhead. Think RAII vs garbage collection.

    3. I Am Spartacus
      Coat

      Re: Disagree....Because it's been done

      Have a look at RUST.

      Total type safety, with race conditions eliminated, safe sharing of data structures between threads, and blisteringly fast. Compiles and links to a standalone executable.

      The future looks Rusty.

      Mines the one with "Borrowing for beginners" in the pocket.

      1. Anonymous Coward
        Anonymous Coward

        Re: Disagree....Because it's been done

        In a few years, Rust will honor its name... and you can't really rely on a language that changes too much among versions, striving for "perfection".

        Not everybody has the pleasure to re-write applications to cope with changes.

        That's the mistake Wirth made with Pascal, instead of evolving it made different incompatible languages.

        And while many people like to ignore it and bash it, Pascal had many of the features languages now try to reintroduce to make them safer.

        1. JohnFen

          Re: Disagree....Because it's been done

          "And while many people like to ignore it and bash it, Pascal had many of the features languages now try to reintroduce to make them safer."

          True, and those features are exactly what prevented Pascal from being used for serious programming. The later revisions to Pascal (which I agree were terrible) were mostly trying to fix that problem.

          A language which protects you from having to think about what you're doing is also a language that prevents you from doing quite a lot of useful stuff.

      2. HieronymusBloggs

        Re: Disagree....Because it's been done

        "Have a look at RUST.......blisteringly fast"

        Is that actually true in general use, as opposed to a few carefully chosen benchmarks?

      3. Michael Wojcik Silver badge

        Re: Disagree....Because it's been done

        Have a look at RUST.

        Rust (it's not an acronym) suffers from programmer resistance to the borrow model, a community widely noted for hostility to being questioned, and (as someone else noted below) a tendency to change without preserving backward compatibility.

        It may yet outgrow those challenges, but history suggests that new programming languages have an uphill battle, and Rust hasn't done a great job so far of building momentum.

        I have no dog in this fight myself - I haven't done anything significant with Rust, and I'm perfectly happy with the borrow model. (I designed a toy language with something conceptually similar years ago.) But I'd be quite surprised if Rust is one of the major languages in, say, ten years.

    4. Anonymous Coward
      Mushroom

      Re: Disagree....

      > C++ has been a Vasa for years. It floats because it's in dry dock.

      C++ Rule #1: When you suck at writing C++, you start bashing it on newsgroups and message boards. I've yet to see an exception to that rule.

      There's always PHP.

      Just sayin'.

      1. Rob Gr

        Re: Disagree....

        C++ Rule #2:

        Insulting those who raise valid criticisms of the language really helps engage the community.

        1. Anonymous Coward
          Mushroom

          Re: Disagree....

          > Insulting those who raise valid criticisms of the language really helps engage the community.

          It doesn't. And that was the point in the first place.

          In this case, the community that you refer to is this constant background noise of commentards who are so far off the mark in their so-called valid criticisms they don't even realize they would've been better off keeping quiet.

          Kind of like art critics. They can't paint or sing to save their lives, but they know exactly how someone else should paint or sing.

          It's Better to Remain Silent and Be Thought a Fool than to Speak and Remove All Doubt.

      2. Anonymous Coward
        Anonymous Coward

        Re: Disagree....

        > There's always PHP.

        Actually, PHP is the dynamically typed cousin of C++. Like C++ and ObjectiveC, PHP originates from the C syntax and C standard library (and Perl stuff). PHP is very similar to C++ in so many ways, some devs hate it for some reasons or another, just like C++. Overall, PHP and C++ are multi-paradigm languages that offer more and compile to faster machine code than competitive languages. The language syntax is not always nice and its standard library has grown over decades. It speaks for itself that 95% of all consumer GUI applications on desktop/notebook are written in C++ and 85% of all websites are coded in PHP. And the reason why ObjectiveC and Java are so common on iOS and Android is, because they are forced upon those devs. C++ is a alien there, with no proper platform first party support. But is often used behind the scene to power cross platform native libraries.

      3. James Jones

        Re: Disagree....

        Conversely, any criticism of C++ is met with accusations of incompetence (with implied superiority of the accuser).. Should I end up using C++, I will make a point of using a bare minimum of its ever-growing list of features. For now, I'm just watching the language's accretion disk--not sure whether in amazement or sadness.

      4. No-One@No-Where

        Re: Disagree....

        Or more accurately if you suck at other languages you fail to understand what is so fucking retarded about c and c++

    5. Daniel von Asmuth
      Holmes

      Re: Disagree....

      C++ has so many features it has become unlearnable. It cannot be completely specified in less than 1000 pages. It is almost impossbile to write a C++ compiler from scratch.

      Just learn the core features and try to invent a new language based on those.

  3. Ian Johnston Silver badge

    Obligatory:

    https://www-users.cs.york.ac.uk/susan/joke/cpp.htm

    1. BebopWeBop

      got there just before me

      1. Chris Miller

        A real Stroustrop joke*

        I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.

        * but was he joking?

        1. GIRZiM

          Re: A real Stroustrop joke*

          real joke (*Stroustrop)

          FTFY.

          But, fun and jokes aside, the problem with C++, as we al know, is exemplified in The Sex Life of the Computer Programmer, wherein it is explained that:

          "You make love to your girlfriend and her cousin at the same time - unfortunately they both learned their technique from their uncle and you walk home sporting an anus like the Japanese flag."

        2. Grikath

          Re: A real Stroustrop joke*

          chris miller: "* but was he joking?"

          Probably not.. In this interview he happily combines C++ and "casual users". As if that will ever happen... Yet he seriously seems to think so.

    2. DropBear

      For some reason, people seem to think that piece is a joke. I cannot possibly imagine why. Adding "I'm just kidding" after "I eat babies" does not make it so when you really do. Now let the downvotes commence...

  4. BebopWeBop
    Trollface

    the infamous Stroustrup 'interview'

    http://www-users.cs.york.ac.uk/susan/joke/cpp.htm

    Nuff said

  5. Anonymous Coward
    Anonymous Coward

    Design by committee

    I have always admired Stroustroup's pragmatism, and he's quite the diplomat as well.

    With languages (programming and human) everyone has got at least one opinion of "what should be the norm", so the committee is a risky one.

    If the committee decides to observe what is being done in practice and create a norm out of it, then things may more or less work and there should be tendency towards simplification; if on the other hand the committee is seen as a vehicle to push each member's pet projects and goals... we have an idiom for that: "design by committee".

    With ISO being such a political organisation I wonder if it is the best choice for the matter at hand.

    1. Nick Kew

      Re: Design by committee

      Whoops, missed your post. Apologies for re-using your title to express similar sentiments without acknowledgement! Upvote for saying it not just first but also better than me.

    2. Bronek Kozicki

      Re: Design by committee

      if on the other hand the committee is seen as a vehicle to push each member's pet projects and goals...

      It is not - because it is possible for any member of the committee to stop dead a pet project of another member if they deem it an "unworkable time hog". Sometimes that saddens me, sometimes I glad because of that. There are many proposals and also some interesting research which deserve closer attention than they receive.

      However, "design by committee" does show up, in the very very long "bikeshedding" discussions where most participants agree in principle on a feature or change, but cannot agree on how it should be designed.

  6. Anonymous Coward
    Anonymous Coward

    I am scared of the pressure to add [...] features to address immediate needs and fashions

    This.

    Most languages are today designed only for immediate needs and fashion, and are also proliferating - "heck, this fashionable construct is missing, let's make a new language!" - if most of their applications don't die soon enough, it will become a maintenance nightmare.

    1. Voland's right hand Silver badge
      Gimp

      Re: I am scared of the pressure to add [...] features to address immediate needs and fashions

      Correct. Additionally, the prejudices reign supreme.

      Example - when you mention Perl you get retches all around. At the moment I am doing a piece of code which needs to deal with some low level packet mangling, database access and a northbound RPC interface in both Python and Perl.

      1. Every single library in Perl worked out of the box and all of them were on the system, so no CPAN abuse. PCAP, Epoll, JSON, DBI and most importantly packet manipulation. Straight sailing all the way until it worked.

      2. Python. My, oh, my. It takes some guru level hoop jumps to integrate pcap into anything useful with an event loop, half of the packet mangling does not work, DBI is non-existent and there is only a very loosely policed database interface. Most importantly the off-the shelf packet manipulation does not work so you are either facing the choice of reusing scapy which is a dinosaur or you have to write your own.

      So the fact that the emperor has no clothes does not prevent the emperor's followers to continue shouting loudly. Fashion and fanboiing all around.

      By the way, the system this will be integrating with is written in C++, but there is no way I am writing in this. Not that I cannot, life is too short for it considering that it has an API interface and python bindings.

      1. Anonymous Coward
        Anonymous Coward

        Re: I am scared of the pressure to add [...] features to address immediate needs and fashions

        On the other hand, I could tell an opposite story if I wanted to do some large array-bashing numerical-model stuff in Python or Perl. In Python there's NumPy and an entire culture built on top of it, in Perl there's ... what?

        Note I hate Python (though I have to write it) and am secretly rather fond of Perl (which at least has variable scoping rules which don't make me want to sandpaper my fingers off): I'm not trying to support either language.

        1. onefang

          Re: I am scared of the pressure to add [...] features to address immediate needs and fashions

          "Note I hate Python (though I have to write it) and am secretly rather fond of Perl (which at least has variable scoping rules which don't make me want to sandpaper my fingers off): I'm not trying to support either language."

          I personally have an unreasonable hatred of any language beginning with the letter P, and I include Ruby as a dishonourable member of that club.

  7. chuckufarley Silver badge
    Childcatcher

    This is...

    ...the kind of thing I would like to see on El Reg. I even read it twice. Once like I normally do, and then once more with the ad blocker turned off. It's a good idea to interview the people behind the projects that drive the modern world. Their work and ideas are used by a billion people every day. Getting to hear what they think is a rare thing unless you can afford to fly all over the world to conventions and meetings.

    Please Sir, I want some more.

    Thanks, El Reg

  8. Eclectic Man Silver badge
    Coat

    Whatever happened to ...

    ... Ada?

    (I'll get my coat.)

    1. Nick Kew

      Re: Whatever happened to ...

      Sorry, missed your post when I referenced ADA.

      I always thought that pascal-on-steroids was a missed opportunity for nice things like builtin checking of types and dimensions. All that extra complexity, yet it never occurred to anyone that the language might enforce that dividing a distance by a time gives you something that isn't your blood pressure.

      1. Nick Ryan Silver badge

        Re: Whatever happened to ...

        In my experience one of the key problems with the early iterations of Wirth's Pascal and ADA (and Modula/2) was his obsession in having to have a single pass compiler and how just this one thing tended to ruin a real-world developer's life. That and almost no supporting libraries or direct access to anything useful system-wise.

  9. Detective Emil

    Visit the Vasa!

    If you're in Stockholm, visit the Vasa. I did, thinking I'd be in and out in a couple of hours. I was there all day.

    1. HmmmYes

      Re: Visit the Vasa!

      Did it sink, again, during your visit?

    2. Vanir
      Childcatcher

      Re: Visit the Vasa!

      "...I did, thinking I'd be in and out in a couple of hours. I was there all day."

      That's software planning and devlopment in a nutshell.

  10. Nick Kew

    Design by committee

    I thought the rot in C++ started with navel-gazing over templates, about when it went from C-with-classes to designed-by-committee. But at least STL is kind-of a separate module in the language.

    I think my attitude over the years has been shaped by the alternatives. When I first encountered it, the world I worked in was drooling over ADA, and I grasped C++ as a beacon of relative sanity. A decade on, JAVA was the new kid on the block with promises that looked a lot like ADA had done, but C++ had turned committee-ugly and was no longer such an attractive refuge.

    1. hammarbtyp

      Re: Design by committee

      "navel-gazing" <-> Vasa LOL

    2. Anonymous Coward
      Anonymous Coward

      Re: Design by committee

      I think the rot in C++ started when someone thought it was reasonable to overload the bitshift operator to do I/O. I mean, seriously? (Yes, I know why that happened, but it doesn't help).

    3. Anonymous Coward
      FAIL

      Re: Design by committee

      > I thought the rot in C++ started with navel-gazing over templates, about when it went from C-with-classes to designed-by-committee. But at least STL is kind-of a separate module in the language.

      It would be to your advantage if you stopped opining on matters you obviously haven't the first clue about.

      To begin with, STL is not a module. It's a blueberry muffin with custard filling.

    4. ThomH

      Re: Design by committee

      I disagree; templates are the best bit — the syntax could be cleaner but being able to write std::find(container.begin(), container.end(), value) and that result in the compiler being able to generate the proper code to search any iterable container is a neat alternative to more traditional approaches towards the same objective like dynamic dispatch. Specialisation (i.e. providing special cases explicitly) is the icing on the cake.

      It's just a shame that (i) it's helpful for the template system to be Turing complete; but (ii) the look-at-me-I'm-clever crowd think that barely-comprehensible template hoops are a fantastic way to advocate the language.

    5. JohnFen

      Re: Design by committee

      "I thought the rot in C++ started with navel-gazing over template"

      Me too. I still consider templates, and the STL, to be a bit of an abomination and ignore that whole mess to the greatest degree that I can.

      1. onefang

        Re: Design by committee

        "Me too. I still consider templates, and the STL, to be a bit of an abomination and ignore that whole mess to the greatest degree that I can."

        That I think is one of the major problems with C++, it's such a huge language that everyone uses only a sub set of it, coz that's the bit they can understand. Except everyone uses a different subset, making it hard to understand other peoples code.

      2. parperback parper

        Re: Design by committee

        Yup. It took a wrong turn with templates, and most of the changes since have been trying to patch up the resulting mess.

        And the STL is a nice idea but frequently a pain in the arse to use.

        You can't debug it, due to second-class compiler and debugger support.

        Minor syntax errors take dozens of lines of garbage to basically say 'template problem'.

        Debuggers give you cryptic structures to navigate (because STL is a library, not a language feature, so it gives you implementation detail you really don't care about).

        Oh, and the syntax of the STL produces barely readable code. eg. the standard idiom for checking if a container contains something reads as 'if, between the start and end items of the container you don't find the not found item'.

        cf:

        if ( std::find(vector.begin(), vector.end(), item) != vector.end() ) // Actual STL

        vs

        if (vector.contains(item)) // What readable code would look like

        1. Fibbles

          Re: Design by committee

          The contains method is certainly shorter but the whole point of Standard Library algorithms is that they are generic. The free function 'std::find' will work with any container that provides iterators, even user created ones. You can even use the function on a raw array by just passing it pointers rather than iterators. The fact that it lets you specify the begin and end iterators also lets you find an item within a sub-range.

          On the other hand the 'contains' method needs to be re-implemented for every new type of container. It also only lets you search the full container, there's no facility for specifying a sub range.

          Then there's the return type. The 'std::find' function will return a pointer/iterator to your found element so you can immediately start using it, otherwise it'll return whatever you specified as the end of the range. By the looks of things 'contains' just returns a bool which is considerably less useful.

        2. ThomH

          Re: Design by committee @parperback parper

          I'd read that more as "if the element was found before reaching the end" rather than inflecting it with negatives, but I agree with your point in the main part. C++ is a lot of really useful stuff and good ideas, hiding behind syntax kludges.

          SFINAE is possibly an even better example. If anybody here isn't already familiar, look up std::enable_if, then calculate the ratio between the amount of time it took you to understand the purpose and utility and the amount of time it took you to be able to produce the syntax.

        3. Anonymous Coward
          Anonymous Coward

          Re: Design by committee

          "cf:

          if ( std::find(vector.begin(), vector.end(), item) != vector.end() ) // Actual STL

          vs

          if (vector.contains(item)) // What readable code would look like"

          But then you cant do

          if ( std::find(vector.begin()+2, vector.end(), item) != vector.end() ) // Actual STL

          and you can always right your own template contains

          if(contains(vector, item))....

    6. Tom 7

      Re: Design by committee

      Strangely (for most) is I can see why most of C++ is like it is as for some reason or other my personal programming development has matched what went on with C++. I think the problem you have is its not designed by your committee. All languages will, if allowed to develop, will eventually encapsulate the same concepts. All languages will try and square the circle slightly differently - the square will simply be presented with a different rotation and the greek use of epicycles to calculate the orbit accurately will crop up in different places.

      Learn the square, learn the circle and dont fight the epicycles - its a fucking pointless self defeating exercise that just makes you miserable.

  11. CheesyTheClown

    Mark Twain on Language Reform

    Read that and it all makes sense

  12. hammarbtyp

    Parallel algorithms – there is no easier way to use the power of the concurrency features of modern hardware

    Not sure what he meant by that - Have they managed to shoehorn some sort of side effect free way of writing C++ or implemented a message passing scheme?

    C++ is a nightmare to write Parallel Algorithms in, but then again so are most imperative languages. As soon as it scales, you will hit issues unless you are very careful.

    1. James 47

      > Have they managed to shoehorn some sort of side effect free way of writing C++ or implemented a message passing scheme?

      They're developing Executors and future releases of some STL algorithms will support an ExecutionPolicy, for example: http://en.cppreference.com/w/cpp/algorithm/find

      1. Richard 12 Silver badge

        There are several C++ map-reduce libraries

        Boost, Qt etc

        Essentially:

        Future<type> result = map_reduce (data, mapfunctor, reducefunctor);

        The Future class gives you a flag/signal/event when "done", and an accessor to get the actual result. If useful, it can also indicate progress and get cancelled.

        Manylots of threads go off and do the map and reduce functors to the data, then the Future lets interested parties know.

        The calling thread can start it and do something else while it's running, or block until done.

        The Qt implementation is really rather nice.

        1. Tom 7

          Re: There are several C++ map-reduce libraries

          I do like them myself.

          I do not like the fact Qt seems to take up several gig and when I have to upgrade so I can compile a 500 line graphics app I seem to have to download all possible libraries. I'm sure I've see a QT library for the Manchester Baby in there!

  13. CommanderGalaxian
    Unhappy

    Heaven help the newbies.

    From about 1989 through the 2004 - I spent most of my time programming in either C or C++ and loving them both. Then for the last decade and a bit I've been programming SCADA sytems (which tend to have their own Pascal or C like languages).

    On coming back to C++ in 2018 - all I can say is: WTF happened!?

    1. Fibbles

      Re: Heaven help the newbies.

      It got better?

      You don't have to use every new feature of the language and I can't think of any that actively make it worse.

  14. Anonymous Coward
    Anonymous Coward

    Code style

    For goodness sake!

    for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v

    Should be:

    for (int i = 0; i < MAX; i++) ++v[i]; // increment each element of the array v

    People who don't use white space properly should be taken behind the bike sheds and shot!

    1. CommanderGalaxian

      Re: Code style

      Either style is equally legible. The problems come when people start mixing styles (usually because some arsehole thinks their style is better than everybody else's) - that's what gives the readability headaches.

      1. GrumpenKraut
        Trollface

        Re: Code style

        The real nasty here is using the postfix-form of the increment operator.

        Only half trolling --->

      2. JohnFen

        Re: Code style

        This. It doesn't matter what a company's (or individual's) official code style is, it's only important that they have one and that it is used consistently. This is true for all languages.

        1. Anonymous Coward
          Anonymous Coward

          Re: Code style

          Concur. That's part of the future support capability in whatever I do. It's highly likely, for one reason or another, some one else is going to try something with what I've crafted. Why should I make their life Hell? I also keep the complexity level low, not stupid but useful. APL (J now) is a favorite of mine but I'm used to using maths most everyone else doesn't know exists.

    2. Tom 7

      Re: Code style

      You dont understand, The purpose of Code Style is so that no-one can ever learn the full set of quirks in your company so you will always make a mistake here or there and then the really shit managers can go off on one for several weeks explaining to everyone in the department how its your fault you couldn't solve Fermat's last theorem in 20 lines of python as he'd demanded in the project plan.

  15. Hans 1
    Happy

    there is hardly any feature I wouldn’t do somewhat differently if I had to do it again.

    Anybody who has ever written code would say this, too!

  16. karlkarl Silver badge

    I was on the C++ spec discussion group the other day asking why std::shared_ptr<T> or std::vector<T>::iterator did not provide some additional checking whether memory gets destroyed whilst within the member function itself (i.e 'this' gets destroyed, via a smart pointer resetting or a vector clearing).

    Whilst I certainly I agreed that these features will add some overhead and should not be part of the spec, I would really like to see it enabled in some sort of debug mode rather than leave that task to compiler specific vendors (to mess up).

    Basically I fear that C++ is evolving the wrong way. It is becoming full of really cool advanced and fast features that I will likely never use, whereas it is still just as unsafe as it was since the invention of smart pointers in TR1 / C++0x.

    I think the problem is that these guys are so smart that they don't need this additional error checking. Unfortunately the rest of us really need them (as evidence with a lot of security related bugs that keep cropping up).

    1. Bronek Kozicki

      why std::shared_ptr<T> or std::vector<T>::iterator did not provide some additional checking whether memory gets destroyed whilst within the member function itself

      My response to this category of problems is: fix your design.

      1. Tom 7

        RE: why std::shared_ptr<T> or std::vector<T>::ite....

        So you've identified somewhere in the language where there could be a problem if you dont write your code properly and rather than adding some check in your coding procedure you are going to wait until someone updates the language?

  17. Missing Semicolon Silver badge

    C++ has been squeezed out

    If you want stuff to run quickly, or with few resources in a tiny micro, there's C.

    If you have a bigger box, heap, scheduling, whatnot, you use a proper manage language like Java/Rust/Scala.

    For code where the expression on a complex algorithm is the main problem, not the cyle-level efficiency, you go higher level Python/R/Go

    C++ can't really be used unless you have a heap. If you do have a heap, with plenty of free space, yoiu need memory management, ruling C++ out.

    1. karlkarl Silver badge

      Re: C++ has been squeezed out

      C++ uses the same memory management system as Rust. RAII.

      In many cases, big heavy things like Java and .NET are simply not a solution to C++ and aren't they all written in C++ anyway? ;). I don't think C++ will ever be squeezed out and I predict its lifespan will actually extend well beyond most of those mentioned languages.

      Ultimately, C is king and in theory the only language we really need (it attaches our logic to the machinery) and C++ is meant to be C with additional safety and facilities. I have tried to create a safe ANSI C library (https://github.com/osen/plank) largely using MACROs. It still isn't quite up to the safety of C++.

  18. Anonymous Coward
    Coffee/keyboard

    I've alwats been concerned that C++ just isn't complicated enough...

    ...so I'm glad to see this fundamental flaw is being properly addressed.

  19. Lee D Silver badge

    I have to say, just that simple for-loop is a prime example of why I don't like C++.

    I can memorise the entire standard library of C, and every command in it, and every operator, and every syntax. Nobody can then run up a piece of code which can't be deciphered (sure, I may have to play pre-processor games, but everything will come down to obvious code).

    When there are a dozen ways to iterate over a simple group of objects, and half-a-dozen different groups of objects, and obscure syntactic sugar the people use because it saves them a fraction of a second, it quickly becomes a pain to understand. Which means it's a pain to verify. Which means it's a pain to secure. Which is not what you want in something like C/C++.

    The "hidden effects" of such code, where things are iterated upon, objects are instantiated, etc. behind your back is a real pain to me. It's like every simple line becoming a dozen "subroutines", overrode and silently inserted, and no obvious way to tell that's what's happening from a quick glance.

    I'm sure with a good IDE, these things become mere colourations, and you can expand object creation etc. but it means too much is going on under the hood without my say-so.

    That's the problem I have with C++... someone can give you the worst spaghetti code and it could easily be malicious, obtuse, or just terrible. With C, you have a chance to spot it, you can pre-process and then see each step, and you have the entire library in your head. If you want to use fancy objects, you have well-defined headers and you can easily isolate the problem.

    When I read my first book on C++, I was so excited to try using it. We all know that "reading about it" and "doing it" are two very different things, but I'd never seen such a gap when learning a programming language. Everything about C++ suggests it should be wonderful, but the pitfalls and readability plummet the second you try to use it, and the other code you inherit is usually nothing more than show-off gibberish trying to use every template, library function and short-cut syntax possible.

    I dearly want C-with-objects back again. C++ never was that, despite claiming so at one point.

    1. GrumpenKraut
      Angel

      > I have to say, just that simple for-loop is a prime example of why I don't like C++.

      Funny, I really like that idiom.

      But let me offer you some help with hating C++: Let A be a std:valarray (of, say, type int). Then you can replace all elements strictly greater than 5 by 77 as follows:

      A[ A > 5 ] = 77;

      No, I am not kidding.

    2. Fibbles

      "Language I know is easier to understand than language I do not know."

      The range based for loop is far from opaque to anybody who actually knows the language. It simply iterates the each element 'foo' in container 'bar'. It does it by using a feature of the language that has been in the standard for 20 years, namely 'iterators'. Every algorithm in the Standard Library uses iterators, they're not a difficult concept and are fundamental to understanding the Standard Library.

      Your complaint seems to be that you don't understand the inner workings of the Standard Library and therefore can't 'secure' your code which is ridiculous because you shouldn't care about the implementation any more than you should care about the implementation of your compiler. At a certain point you have to trust that something does what it says on the tin.

    3. karlkarl Silver badge

      I agree that C has some advantage over C++ in that it is simpler. This is quite evident by the K&R book being about 1/4 the size of Stroustrup's C++ Language book ;)

      However the complexity in some cases is worth it. For example with "safe" iterators it can be set up so that if the data you are iterating through changes (i.e some berk has cleared the container hidden down the call stack), you can know about it (with an assertion).

      That said. Some developers I feel over-consume C++ features (especially templates). For example, I present to everyone the GLM challenge. Who can find where the glm::mat4 glm::rotate() function is actually implemented in 1 minute?:

      https://github.com/g-truc/glm/tree/master/glm

      I'll give you a clue... If you are using an IDE with intellisense. Turn it off. It will probably crash ;)

      Contrast this with linmath (ANSI C): https://github.com/datenwolf/linmath.h

      GLM is safer but gosh is it more complex. I would hate to extend that thing.

      1. Fibbles

        /glm/gtc/matrix_transform.inl

        glm - because it's in the OpenGL Math Library

        gtc - because it's Template Core rather than Template eXperimental (gtx)

        matrix_transform - because it's a free function for transforming a matrix object

        .inl - design choice of the library, could just as easily go in the hpp file

        This seems more a criticism of the GLM library and their header layouts rather than a valid criticism of templates. It's also unfair comparing its size to linmath since GLM is specifically designed to inter-operate with OpenGL and mimics GLSL as closely as possible within the limits of the language.

      2. Anonymous Coward
        Facepalm

        Who can find the glm::rotate() function?

        > For example, I present to everyone the GLM challenge. Who can find where the glm::mat4 glm::rotate() function is actually implemented in 1 minute?:

        Interesting .. I've also wondered why, for such a high level language, you need to help C++ keep track of its variables using the Namespace feature. For another example, it's perfectly obvious that :: is the scope resolution operator and does different things depending on the context. It would be like creating a human language that the key words could be overloaded with ever changing meaning <sarcasm>

        Human brains don't work like this, C++ a high level computer language written for computers :]

        1. Richard 12 Silver badge

          Re: Who can find the glm::rotate() function?

          Namespaces are because it's not possible to give every class, function and constant a unique, memorable name.

          It is common - nay certain - that a mid to large sized project will have multiple things that with the same name.

          But if you have Eigen::matrix4x4 and GLM::matrix4x4, you can actually say which one you mean.

          Nothing more.

          And of course, you can just tell the compiler "in this source file I use GLM", to avoid typing the letters.

  20. tony2heads

    closer to the Mary Rose

    The Tudor warship performed well for decade until the upgrade.

  21. regreader2011

    I guess we now live in an age where computer languages are treated akin to consumer electronics items -- one must ship a new version every couple of years, else people switch to a different brand? Or is it just a self-serving effort to keep the C++ education business humming?

    1. ThomH

      I think it's more like the explosion in new languages, resulting from the post-internet easier grouping of interested people, has led to a much faster turnover in new ideas and the established languages like to crib what they can.

  22. HmmmYes

    Problem is, each language version really should be considered a different lanaguage.

    Maintaining any long (>10 year) lifed C++ is a massive PITA.

    Ibe seen programmers start off MFC C++ style - C++90 + the stupid MS addons.

    Then some has read the Design Pattern book, so you get 'patterns' in the code base from 95is-00ish.

    Then they discover the STD. All the new stuff then becomes templated.

    All a massive fuckup.

    You need to have strongly applied coding rules, not just syntax but on the language and libraries used.

    The module needs needs to be frozen to that C++ version.

    End of the day, I spend more time testing.checking stuff than I do writing new stuff. Any language that makes testing easier gets my vote.

  23. arctic_haze

    What's wrong with good old ANSI C?

    ANSI C is good enough for the scale of project I do. If I really needed to start a big multithreaded project I would think of something created for that purpose, but most probably that would not be C++.

  24. vincent himpe

    why not simply have a 'foreach' ?

    foreach (x in v) x++;

    why all those cryptic modifiers ? language syntax should be easy to read. Not look something written by a drunk hamfisted keyboard pounder typing expletives in symbolic form... $#@&%^!!!

    1. Fibbles

      It's not far off that really. C++ is a statically typed language so you need to provide a type in your code or explicitly tell the compiler to deduce it from the value passed.

      for ( auto& x : v )

      If you look at the above range based for you can see that the colon is equivalent to 'in'. The only non obvious bit to somebody who uses another language is the 'auto&'. The 'auto' just tells the compiler to deduce the type since it knows what 'v' contains and therefore knows the type of 'x'. The '&' tells the compiler that it should not make a copy of the element from the container but just use a reference back to the original object.

      1. Lee D Silver badge

        I'm with the foreach guy.

        The second you start using a different syntax for the same command (for), and distinguish using obscure symbols, and even HAVE things like "auto" type modifiers (which just makes me think of VB "Variants"... shudder...), then you've strayed far enough from the original command to warrant a new keyword.

        That line is impenetrable to my programming mind. Can you honestly imagine seeing something like that inside, say, the Linux kernel? Or the LibreSSL library?

        C++ just wants to overload absolutely everything, including its own commands, and that quickly turns into a royal mess.

        And I can't imagine that the generated code is any better than just using the "obvious" foreach and a type/object that allows iteration, and an obvious array/collection of objects.

        For instance, if that loop modifies x, and it's just a reference back to the object inside the collection, that could quickly turn into disaster and it might well be hard to spot.

        Honestly, a programming language is like a joke, if you have to explain it, it's not working. Sure, C is hardly as readable as BASIC, but C++ is an order of magnitude more obscure than either, especially when people play with these pretty "tricks".

        1. Fibbles

          The second you start using a different syntax for the same command (for), and distinguish using obscure symbols, and even HAVE things like "auto" type modifiers (which just makes me think of VB "Variants"... shudder...), then you've strayed far enough from the original command to warrant a new keyword.

          That line is impenetrable to my programming mind.

          What makes it impenetrable? I really can't see how 'foreach x in y' is significantly more readable than 'for x in y'.

          The auto keyword is not specific to for loops, you can use it pretty much anywhere you'd like the type deduced. It's useful because you shouldn't be redeclaring the same information over and over. If I change variable foo from int to unsigned int I don't want to have to then go through each line of code to change the type there as well.

          Can you honestly imagine seeing something like that inside, say, the Linux kernel? Or the LibreSSL library?

          No because they're both written in C, not C++.

          For instance, if that loop modifies x, and it's just a reference back to the object inside the collection, that could quickly turn into disaster and it might well be hard to spot.

          References have been a core part of the language since the year dot. Do you have the same complaint about pointers? A reference serves the same purpose as a dereferenced pointer.

          Honestly, a programming language is like a joke, if you have to explain it,

          You can't honestly expect to be able to use a language without learning the syntax. Even something like Python (which is marketed as close to natural language,) requires you to learn the syntax.

          1. onefang

            "You can't honestly expect to be able to use a language without learning the syntax."

            Half the time I can.

          2. Waseem Alkurdi

            (which just makes me think of VB "Variants"... shudder...)

            Talking of the devil! For those who haven't endured the mental pain of understanding it:

            Want a data type that stores strings and integers, yet can't use string functions nor integer functions, nor can be useful for anything? Yes sir: Variant.

            Worse still is that not defining a data type for a variable "implicit declaration" gives you a fucking Variant.

      2. parperback parper

        Although you're better off avoiding the auto if you're using a non-templated function.

        That way your IDE will know what type it is, and you'll get a nice compiler error message if someone changes the type of v without telling you.

    2. Lee D Silver badge

      Expletives in symbol form are called "grawlixes".

      Just a bit of trivia for you.

    3. Anonymous Coward
      IT Angle

      why not simply have a 'foreach' ?

      > why not simply have a 'foreach' ?

      Because computer programming is an esoteric art form not to the shared with the hoi polloi :]

      1. Someone Else Silver badge

        Re: why not simply have a 'foreach' ?

        Prolly because that symbol was taken by the likes of boost and Qt and ...

    4. Anonymous Coward
      Anonymous Coward

      why not simply have a 'foreach'....

      "why not simply have a 'foreach' ?

      foreach (x in v) x++;"

      Because that would require reserving another keyword, unnecessarily breaking lots of existing code , when 'for' is already reserved and easy to understand, the only new bit of syntax is the reuse of the ':' the rest is all normal C++

      You could just as easily write

      std::vector<int> v

      for(int i : v) ....

      Backwards compatibility.... for when your language is not just a fashionable toy

  25. handleoclast
    Coat

    Bring back the good old days

    Those wonderful days when Niklaus Wirth had a strong say in the design of a new language, and of new features to an existing language.

    That way it is absolutely guaranteed to be unusable crap. So almost nobody but bondage and discipline fetishists will use it, and the rest of us can safely ignore it.

  26. Ian Joyner Bronze badge

    I Agree with Bjarne Stroustrup!!

    I remember reading something a long time ago by Bjarne on the Vasa. I really recommend a trip to see it if you are in Stockholm – quite a sight.

    I have been agreeing with Bjarne on this point for over 20 years, and C++ has been a top-heavy artefact for at least that time.

    http://ianjoyner.name/C++.html

    I'll admit to missing the most critical point (for 2018) that security is the elephant in the room for both C and C++ (and CPU/system architectures). Like most, I concentrated on correctness and verification, as well as other factors such as maintainability. Security is intricately tied to correctness, but rather than guarding a programmer against their own mistakes, it is guarding a system against the malicious intents of others. C and C++ can be too early undermined, and buffer overflows have proven to be the curse of modern computing, but blessing to the hackers.

    But security is indeed the issue that should see C and C++ relegated to the past of the wild-west days of computing.

    It is time for a rethink – or at least to learn the lessons from the past for good software development, even back to the 1960s, that C and C++ have wilfully ignored and spurned as 'restricting programmer freedom'. That attitude was naive, then stupid, now it should be criminal.

  27. Grant Fromage
    Coat

    Too many years ago from byte magazine

    The man himself " to err is human, to really fsk up you need C++"

    I have the mag somewhere 85?.

  28. Maelstorm Bronze badge

    Uhggg Another C++ standard?

    You know, we don't really need any new features to the language. In fact, there's a few features that probably should be removed. So yes, I agree with Bjarne Stroustrup. Right tool for the job really. I view C++ as the object oriented version of C, and I use C...a lot in my coding since I code close to the bare metal. C and assembler for my work.

    C: Low level system stuff such as kernels, device drivers, libraries, etc...

    C++: Higher level application stuff (especially on GUI platforms) or when using objects make sense...like the Abstract Syntax Tree that's generated from a parser and is fed into the code generator for a compiler. OOP makes sense here since the nodes are all the same, the data they contain is what differentiates what type of node it is.

    Here's a little thing that Linus said about C++. Enjoy.

    http://harmful.cat-v.org/software/c++/linus

  29. Waseem Alkurdi

    Regarding the "C Plus" in the headline

    <rant>

    It REALLY GETS ON MY TITS when engineering students at our university (who have to take C++ as mandatory) call it "C plus" as shorthand/acronym/whateverthefuck.

    REALLY ANNOYING.

    </rant>

    I do understand that this is to rhyme with "fuss", but it awakes my PTSD whenever I hear it.

  30. shaunhw

    stroustrup sounds like a C ansii string function!

    The man is right. Leave C++ alone, it doesn't need anything else adding for the sake of it.

    If they want an extended version with new features give it new name.

    1. onefang

      "If they want an extended version with new features give it new name."

      Hmm, C+=2, ++C, D (Oops, taken already), CPLusPLus (from BCPL, the grand daddy of C++), CRAP++, I could go on...

      Though given my above declaration for hating all languages beginning with P, continuing the BCPL -> B -> C tradition and calling it P will just get right up my nose.

  31. amanfromMars 1 Silver badge

    No need to reinvent the wheel ... but there are always leading improvements to be made for markets*

    There are no major decisions I regret, though there is hardly any feature I wouldn’t do somewhat differently if I had to do it again. .... Bjarne Stroustrup

    Exercise that easy option and invent a much more formidable scripting tool leading machines towards goals delivering invincibility with increased markets share of derived product.

    Anything else surely has one polishing a turd rather than displaying a diamond in the raw?

    * For example ..... Not quite reinventing the wheel, but ...

  32. Anonymous Coward
    Anonymous Coward

    B is right

    Although, one can wonder why is he late?

  33. CodeBlaster

    C++ vs C

    Coming from an assembly language background (6502 and 68000) back in the day, I decided that it was time to learn how to code in C/C++. This was back in the early 90s - I was a games programmer and the move from the Amiga to the PC meant that I had to learn how to code in this "new" high level language. Having bought a number of C++ books, it was an uphill struggle and I decided to just learn C, giving myself the option to learn C++ if I needed it in the future. I taught myself C in 2 weeks using an excellent disk/book set called "Master C". To prove to myself that I had learnt it, I wrote a crappy PC version of Galaga with assembly language for the graphics and everything else in C. No problem, it took me 3 days. I've never needed C++! I was involved in one other (PC) game back in the 90s and then got out the industry but I've written numerous complex apps in C and never felt the need for C++. In my opinion it is too much for a beginner or maybe I just wasn't intelligent enough to pick it up easily. I long for the heady days of assembly language coding - software seemed to work better back then...

    1. Missing Semicolon Silver badge
      Unhappy

      Re: C++ vs C

      There are two things wrong with C++

      1) Spooky hidden code. Due to the horrors that are overloaded operators

      c=a+b;

      Is completely incomprehensible. If a and b are instances, the actual code is presumably in the overloaded operator+ for the class of a. Then, it must create a temporary a on the stack, before using the copy constructor to make c. So, if there are side effects in the constructors, all sorts of shizzle goes on. Plus it can eat up loads of stack.

      And, the whole mess was just to make sure that strings are not special objects, but you can still write

      foo=bar+"more";

      The world already has Perl as a write-only language. It doesn't need another one.

      2) The utterly crap reference book. Everyone worships Stroustrup, but the book is utterly useless for learning to write real-life code. It always shows stuff as definitions, ans rarely describes how to separate declaration and definition - the way you always work. The descriptions of the various features are a hymn to how clever they are, not a careful description of the use, abuse, and side effects.

      1. onefang

        Re: C++ vs C

        "The world already has Perl as a write-only language. It doesn't need another one."

        The world already has several write only languages, you left out APL and Whitespace. I think there is a few more to.

  34. martinusher Silver badge

    Been there.....done that.....

    Back in time there was a family of languages called Algol. They're the grandparents of the block structured language, its where you'd first find curly braces and semicolons. A very popular version was the 1960 model, Algol 60, which worked but had a few imperfections. These were fixed for the version Algol 68. It was a superb language with just one slight snag -- it was effectively unimplementable on the machines available at that time. Various implementations were made but most were panned as impure, not worthy or whatever.

    C++ is in danger of going down the same rabbit hole -- if it isn't lost already. Its worse for us because at least all Algol sprung on us was a "Revised Report...", a well thought out theoretical document. C++ started off as an incremental improvement to a systems programming language (one that should never have been used to write user applications in), it gained wide currency because it just happened to be a useful shorthand for writing GUI applications in, it got widely taught and so it just morphed and morphed like the terror from some naff 50s sci-fi movie. Common sense, please -- some of us have do deal with the fallout from people who know all about how to write object oriented programs (but wouldn't necessarily know an object if they tripped over one...). This language has caused me so much grief over the years that if I'm in a position to make the decision I'll ban it (embedded programming and poor quality C++ are a particularly noxious combination!).

  35. Stjalodbaer

    No more tinkertoy pseudo-languages

    We don’t know what the language of 2020 will look like, but it will be called Fortran.

    But we’d like it to be ML.

  36. Anonymous Coward
    Happy

    Eh I refer Pascal and Delphi

    I can not understand why people have to override so many internal elements in C.....

    they still have to include code in their program so just write another module.

  37. Libertarian Voice

    It's not the features, it is how you use them that counts!

    I write a lot of code in C++ that has to interface with C libraries and do not have the time nor inclination to create wrappers for every library as I would never get any work done. This is what happens in the real world; most companies are not prepared to pay you to write wrappers and would much rather employ programmers that have a reasonable understanding of C and can use it withing C++ programs and find workarounds where necessary.

    The problem with c++ is not the code itself (you either use STL features or you don't, it is up to you); it is the evangelists who insist that you should write everything using strict OOP and every single available feature to write a hello world program.

    The good thing about the STL is that it can save an awful lot of documentation if used properly, and OOP too has its place. Where I start to get a little annoyed with cpp is its determination to hide or mess around with what are basically pointers just for the hell of doing so, it makes no sense and over complicates things unnecessarily.

    I like the language, I like the features and I like the fact that I can still use C code quite comfortably within, should the need arise or should it make the code more readable (which in many cases it does).

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

Other stories you might like