Bjarne Stroustrup Awarded 2015 Dahl-Nygaard Prize

mikejuk writes Bjarne Stroustrup, the creator of C++, is the 2015 recipient of the Senior Dahl-Nygaard Prize, considered the most prestigious prize in object-oriented computer science. Established in 2005 it honors the pioneering work on object-orientation of Ole-Johan Dahl and Kristen Nygaard, who designed Simula, the original object-oriented language and are remembered as "colorful characters." To be eligible for the senior prize an individual must have made a "significant long-term contribution to the field of Object-Orientation," and this year it goes to Bjarne Stoustrup for the design, implementation and evolution of the C++ programming language. You can't argue with that.

Comments

You can't argue with that

[Anonymous Coward]

It's Sladhdot. Watch me..

Poor Alan Kay

[TheRaven64]

'When I invented the term Object Oriented, C++ was not what I had in mind.' - Alan Kay.

Re:Poor Alan Kay

[Calavar]

C++ is a three-way compromise between good object oriented design, backwards compatibility with C, and high performance. Stroustrup has never billed it as anything else.

Of course, the fact that C++ is a compromise between three goals that are often at odds means that it isn't anywhere near the best language for object-oriented design (loses to Smalltalk and many others), for backwards compatibility with C (IMO Vala does better -- YMMV), or for high performance (loses to FORTRAN). But it does a reasonable job of "good enough" on all three fronts, and that is what has made it so enduringly popular over the last few decades.

So, no, C++ isn't the best language for object-oriented programing. It's not even close. But that doesn't mean it is a bad language.

Re:Poor Alan Kay

[Anonymous Coward]

'When I invented the term Object Oriented, selling Smalltalk was all I had in mind.' - Alan Kay.

The term object oriented as defined by Alan Kay can only be met by Smalltalk since it is the one language he made money from. The full range of features required to meet Smalltalk like object orientation also had the bad consequence of making program execution extremely inefficient/slow.

Re:Poor Alan Kay

[Uecker]

I disagree that the complexity from C++ is only the result of being the compromise of these three properties. Ofcourse, such a language would be somewhat more difficult than a new language without backwards compatibility to C, but I still think that most complexity in C++ comes from adding whatever feature was cool at the time *without too much thought*. I had to debug my fair share of subtle problems in C++ code (mostly from other people - I stopped using C++ for my own projects years ago) and usually the problems are the new language features that C++ added to C which cause problems. I know excellent programmers who can use them correctly, but most don't. The reason is that they have surprising and hard to understand properties. See, for example, the keynote of Scott Meyer (Effective C++) at the d language conference this year. He lists a lot of arbitrary design flaws in C++.

Re:Poor Alan Kay

[lgw]

You can wrote very fast an elegant code in C++ just as easily as in C - it's just a different tool set. C++ is not for writing code using the same approach one uses with C; It's terrible for that. But once you understand scoped objects, all memory and resource leaks go away (well, you can attach something to a global structure and forget about it, but you can mess that up in any language). That alone is a huge win.

C++ has one terrible, fundamental flaw: the learning curve is too high. There's just about nothing where the "right way" is obvious, or even common. And so few people get to real expertise that there's not a common library that collects all those right ways and makes them easy to learn! It's a tragedy, really.

Re:Poor Alan Kay

[serviscope_minor]

I'm sorry but the C++ committee has their head up their @$$es for *practical* matters:

Says the guy who doesn't understand the C++ committee. The C++ committee care very strongly about backwards compatibility, because so does everyon who uses C++. They also care very strongly about compiler adoption because, well, if the compilers don't adopt changes then no matter how much better it is in theory, it's worse than useless in practice.

* Standardized Name Mangling?

Would be nice, but would cause major backwards compatibility breakage because all but one compiler would have to change the magling scheme.

* Standardized ABI so compiler A can call code compiled with compiler B

Well, GCC won't adopt Microsoft's SEH, because they're slower. Microsoft won't adopt the Itanium ABI, because it would slaughter backwards compatibility and the faster exceptions aren't flexible enough to do what Microsft uses their exceptions for.

Secondly, if they'd mandated this, we'd have never got a huge boost in exception speed somehwere when gcc 3 came online.

But basically, it would be worthless because the compiler writers wouldn't adopt it. So why bother?

* Standardized error messages

Easy to ask for, almost impossible to specify. Do the error messages have to be in colour or is that optional? Besides it's foolish to claim they have their heads up their asses for not doing something that noone else has ever done.

* Standardized pragmas to enable/disable warnings for unused variables

What? Why?

* Standardized forced inline, never inilne

Again why?

* A consistent grammar between forward declarations and function definitions to make it easier to copy/paste

Nope. Never going to break backwards compatibility. Because no one would adopt the new standard.

* Multi-column debugging instead of the archaic line debugging

Outside the scope of the standard. Whine at your debugger vendor.

*"A Proposal to Add 2D Graphics Rendering and Display to C++"

The C++ committee have their heads up their asses because they discuss a proposal submitted acording to the correct procedure??

*For high performance games, most of the C++ features are *ignored* "CppCon 2014: Nicolas Fleury "C++ in Huge AAA Games"

So your argument against C++ is that it's used in one of the most competitive industries? You know, you don't have to use every langage feature in every project.

Re:Ppl who don't know C++ slamming C++

[hey!]

Well it's been many, many years since I've used it, which was back in the late 80s and early 90s. My impression from this time is that C++ is unquestionably a work of genius, but that I didn't particularly like it. Part of that is that we didn't really know how to use it effectively. In that era most object oriented programmers used concrete inheritance way too much. Part of that is due to aspects of what we thought an OO language should have that turned out to add complexity while being only marginally useful in practice (e.g. multiple concrete inheritance and operator overloading).

But in terms of meeting its design goals C++ is a tour de force of ingenuity -- even if some of those goals are questionable by today's standards. The very fact that we know some of those features aren't necessarily ideal is because they were taken out of the realm of academic noodling and put into a practical and highly successful language that could tackle the problems of the day on the hardware of the day. It's hard to overstate the practical impact of C++ on the advancement of both theory and practice of software development.

Any prize for contributions to OO programming pretty that didn't include Stroustrup in its first recipients would be dubious.

Re:Is FORTRAN still winning? Was Re:Poor Alan Kay

[Anonymous Coward]

One of the reasons compilers can often still better optimize FORTRAN code is that FORTRAN makes stronger guarantees about aliasing than C++ does. The lack of such guarantees constrain C++ compilers by introducing more antidependencies that restrict code motion, although in practice most of them are not actually antidependencies.

Compilers are getting better over time at sorting that out, but sometimes it can't be sorted out because there isn't enough information available statically to do so.

I'm not a FORTRAN programmer and don't particularly like the language, but FORTRAN is still where it's at for high performance computation. And FORTRAN is a better language today than FORTRAN77 was back in the day!

Re:C++ is a travesty of design

[Half-pint HAL]

Indeed -- a multiparadigm "language" doesn't have to actually be a single language at all. It can be multiple languages with a single datatype system and call mechanism. (I'm personally more interested in this as a way to combine functional programming with procedural programming, but it would work just as well for OO with non-OO.)

Re:Contribution?

[narcc]

the OO design patterns people.

Really? I think the GOF should be round-up and shot. No other group has caused more harm to the industry.

Well, there's another bullshit award, then.

[jcr]

C++ is to C as Lung Cancer is to Lung.

-jcr

Re:Ken Thompson on C++

[Anonymous Coward]

Stroustrup might agree that he's not necessarily brilliant in the same way Thompson was, but he is disciplined and dogged and willing to talk to people and compromise. He took his job as maintainer of C++ seriously, and was willing to keep at it for three decades, which is something that Nicklaus Wirth didn't do as creator of Pascal for instance. He's been able to attract very intelligent, very dedicated folks to the C++ standardization effort, people who don't resort to juvenile flame wars as we often see breaking out in open source projects.

I don't think it was fair to say that Stroustrup caved and took whatever proposals anybody had. For example, people have been asking for, and proposing implementations for garbage collection in C++ for more than 20 years, but it's still not in the standard. There is no standard GUI or windowing API, or standards for enterprise application server frameworks, or anything matching wall of books that came out of SunSoft/Oracle for the Java API's. When Stroustrup through his lot behind STL, he was implicitly rejecting many competing proposals, including those submitted by his friends and long time colleagues at Bell Labs. Given the change in paradigm that STL represented relative to the mainstream of O-O collection class libraries, that took guts.