Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday January 04 2018, @03:44PM   Printer-friendly
from the C++ dept.

The US National Academy of Engineering has announced that Bjarne Stroustrup will receive the 2018 Charles Stark Draper Prize for Engineering for his creation of C++ while at Bell Labs. The language C++, to put it mildly, is widely used. The prize will be formally awarded on February 20th in Washington, DC.

Here is Bjarne's home page and his Wikipedia page.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by leftover on Thursday January 04 2018, @04:36PM (9 children)

    by leftover (2448) on Thursday January 04 2018, @04:36PM (#617767)

    My favorite Bjarne statement, by far, is when he said C++ was done as a joke. OOP in general and C++ becoming nearly universal are, IMHO, behind most of the code bloat, bugginess, and perpetual beta status of current software. The [oversimplified] reason is that no individual developer can grok any snippet of code, no matter how small. Externally defined classes, objects, overloaded operators, etc. could have sliced and diced that snippet into cole slaw.

    I really wish he had stuck to his early misgivings but understand his reluctance to step in front of the train it became. OOP evangelists came boiling out of the woodwork like cockroaches, most of whom had never developed and maintained a software product.

    --
    Bent, folded, spindled, and mutilated.
    Starting Score:    1  point
    Moderation   +3  
       Insightful=3, Disagree=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by unauthorized on Thursday January 04 2018, @05:44PM (6 children)

    by unauthorized (3776) on Thursday January 04 2018, @05:44PM (#617825)

    The only reason C++ is "bad" is because bad coders have a lot more string to hang themselves with.

    Operator overloading is a very useful feature when used properly. The expression "(matrixA + matrixB) * C" is far more elegant and readable than some unholy Java-ism like "matrixA.add(matrixB).multiply(C)", or worse it's C equivalent.

    • (Score: 2) by darkfeline on Thursday January 04 2018, @08:06PM (3 children)

      by darkfeline (1030) on Thursday January 04 2018, @08:06PM (#617910) Homepage

      That's like saying that a gun that shoots backwards is "bad" because it's easier to kill yourself with it than a normal gun. Oh wait, no, it's just bad.

      A tool that encourages damaging use by design is bad period (unless the purpose of the tool is to cause damage, which may well be true about C++).

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 3, Insightful) by unauthorized on Thursday January 04 2018, @09:04PM (2 children)

        by unauthorized (3776) on Thursday January 04 2018, @09:04PM (#617954)

        No, that's like saying a double edged knife is okay unless you hold it wrong. Just because you can hold a knife by the blade that doesn't make double edged knives bad tools.

        A language cannot force you to use overloaded operators. It's a ridiculous proposition to say that a tool is made worse by having more optional features unless those features severely degrade the overall quality of the tool. Tools don't encourage things, they can only discourage and prevent you from doing things by inherently limiting the capabilities of the tool. You are no more encouraged to use operators in unintuitive ways than you are encouraged to hit yourself with a hammer.

        • (Score: -1, Flamebait) by Anonymous Coward on Thursday January 04 2018, @09:48PM (1 child)

          by Anonymous Coward on Thursday January 04 2018, @09:48PM (#617985)

          A good programmer always uses refined taste and extensive experience when writing code.
          SADLY, he must interface with code written by LESSER PEOPLE who will use every possible feature in the language to its ridiculous utmost.

          • (Score: 0) by Anonymous Coward on Friday January 05 2018, @05:57PM

            by Anonymous Coward on Friday January 05 2018, @05:57PM (#618417)

            This is not flamebait.

            It's an ironic reply for why one can't realistically restrict oneself to a sane subset of a language with so many so many easily abused features. Those features are an inescapable part of the programming experience because if a feature exists, IT WILL BE USED BY SOMEONE. Perhaps A LOT. Maybe even by you before experience taught you it was a "problematic" language feature.

    • (Score: 2) by TheRaven on Friday January 05 2018, @01:34PM (1 child)

      by TheRaven (270) on Friday January 05 2018, @01:34PM (#618309) Journal

      The problem with operator overloading is that it makes it very difficult to reason about complexity. In C or Java, if I see a + b, then I know that eventually something roughly equivalent to a CPU add instruction will be performed. In C++, I don't, unless I look at the entire type hierarchy of a and b. This is not unique to overloading: the spec describing what happens when you write a+b in JavaScript is huge and terrifying, but at least it's the same huge and terrifying mess every time you see any addition.

      This is a microcosm of the real problem with C++: the amount of code that you have to read to understand the behaviour of a single line is often huge. This is made worse by overloaded syntax. For example, consider the expression a.foo(). In C++, foo could be a field that is a function pointer. It could be a method, with the implementation that is called being determined by the static type of a. Or it could be a virtual method, with the implementation that is called being determined by the dynamic type of a.

      The other problem with overloading is that C / C++ made the decision to try to embed mathematical operator precedence in the language. In Smalltalk, operator overloading is less of an issue, because all evaluation proceeds left to right. This is fine when it's just the four operators that everyone learns at school, but C++ has dozens of operators and it's fairly common for programmers to forget the exact precedence rules (how many of you knew that a || b && c is equivalent to a || (b && c) without looking it up?). These rules apply even when operators are being used in a context that is distinct from arithmetic, where the precedence rules don't make sense.

      --
      sudo mod me up
      • (Score: 2) by maxwell demon on Saturday January 06 2018, @06:59PM

        by maxwell demon (1608) on Saturday January 06 2018, @06:59PM (#618845) Journal

        These rules apply even when operators are being used in a context that is distinct from arithmetic,

        You're right, we definitely should make operator precedence context dependent! ;-)

        --
        The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @06:09PM

    by Anonymous Coward on Thursday January 04 2018, @06:09PM (#617847)

    Compared with C? Where to do anything you have to go through MacroHell? Where there are no namespaces (so function declarations are completely unscoped)? etc etc

  • (Score: 4, Informative) by infodragon on Thursday January 04 2018, @06:22PM

    by infodragon (3509) on Thursday January 04 2018, @06:22PM (#617854)

    OOP in general and C++ becoming nearly universal are, IMHO, behind most of the code bloat, bugginess, and perpetual beta status of current software.

    Hmm... It's been my experience, 27 years, that bad programmers are behind most of the code bloat, bugginess, and perpetual beta status of current software.

    I've been writing C++ for 24.5 years, yea nearly a quarter of a century, and I've seen so much garbage produced by bad programmers it's sickening. I've worked on large teams (18 developers, 20+ testers and 6 managers; that was just the local group) and small teams including lone wolf. I've worked on heavy business oriented applications and systems where I'm counting CPU cycles. The greatest chances for success are the teams with strong leaders with strong design/architecture skills who take the time to mentor, enforce reasonable coding standards, expel toxic team members and understand that there is nothing more permanent than a temporary solution. "We'll fix it later..." is the path to the dark side and forever will it dominate your destiny!

    --
    Don't settle for shampoo, demand real poo!