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

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

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

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

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

  2. BebopWeBop
    Trollface

    the infamous Stroustrup 'interview'

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

    Nuff said

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

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

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

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

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

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

  9. CheesyTheClown

    Mark Twain on Language Reform

    Read that and it all makes sense

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

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

Other stories you might like