Bjarne Stroustrup Awarded 2015 Dahl-Nygaard Prize 200
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.
You can't argue with that (Score:2, Insightful)
It's Sladhdot. Watch me..
Poor Alan Kay (Score:5, Insightful)
Re:Poor Alan Kay (Score:5, Insightful)
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.
Is FORTRAN still winning? Was Re:Poor Alan Kay (Score:5, Interesting)
But a question for those who have: Does it still win with dynamic memory allocation? How granular is the dynamic memory allocation? Complete like C? or it is a bastardized version where the common block sizes could be defined at run time and then it runs without ever calling free()? I could imagine the language getting malloc() but not free() to retain speed.
Re:Is FORTRAN still winning? Was Re:Poor Alan Kay (Score:4, Insightful)
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: (Score:2)
Re: (Score:3)
Re: (Score:3)
Does it still win with dynamic memory allocation? How granular is the dynamic memory allocation? Complete like C?
Fortran's dynamic memory allocation is much easier to work with than C's. You simply declare a variable allocatable, then allocate as needed with the appropriate size. It automatically gets deallocated when it falls out of scope, so no memory leaks (at least since F95).
e.g.
real, allocatable :: myarray(:)
allocate (myarray(1000), stat=ierr)
(something to check error code ierr here)
I've written a bit of finite difference code in Fortran. Repeatedly allocating and deallocating can give a huge performance hit, so
Re: (Score:2)
It's a hardware thing -- the memory bus and memory read/write speeds are still a limiting factors, particularly as CPU cores get faster and more efficient. In any code, memo
Re: (Score:2)
It's a hardware thing -- the memory bus and memory read/write speeds are still a limiting factors, particularly as CPU cores get faster and more efficient.
Oh yes, I've seen plenty of code that's limited by memory bandwidth. But I don't think that's what's going on here - simply deallocating and reallocating shouldn't actually touch all of the memory in question, should it?
Fortunately for that kind of code, avoiding such reallocations isn't difficult.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The syntax you're already used to is probably not real good for code generation. Even Lisp added some syntax (the backtick notation) to make it easier to write macros.
You're mostly right about Lisp syntax. I remember suddenly realizing that I was writing Lisp code that was pretty much the same memory layout that my parser spat out when I was taking a compilers class.
If you're paying too much attention to the parentheses in Lisp, you're doing it wrong. Use a pretty-printer and look at the indentation
Re: Is FORTRAN still winning? Was Re:Poor Alan Kay (Score:2)
Re: (Score:2)
Repeatedly allocating and deallocating can give a huge performance hit, so I tend to do all my allocations before the main loop.
which is the correct way of doing it. Allocating and deallocating, especially larger chunks of memory, requires you to interact with the operating system.
This should off course be avoided in tight loops.
Re: (Score:2)
Maybe according to the strict F95 standard it's not allowed, but I've done it. I think it was officially introduced in F2003 (or some TR that I forget) but compilers supported it even before then. Similarly for allocatable dummy arguments to subroutines.
Not to say there aren't some weird quirks with Fortran arrays, like how if you pass an allocatable array to a subroutine where the dummy argument is not allocatable then it *must* be allocated, even if the subroutine isn't going to touch it.
Re: (Score:2)
I've been writing a scientific simulation in Fortran for half a year now. I usually like to write in some combination of C and Python.
While Fortran does make the life of a compiler writer easier, I think C benefits from being a small and very popular language.
C compilers are just more advanced, which gives it the speed advantage. But the speed difference for most purposes is negligible.
Choosing the right algorithm and approximations is a much more important concern (factors of 10-100-1000 vs. 1.1-1.2-1.3).
D
Re: (Score:2)
Re: (Score:2)
Re:Poor Alan Kay (Score:4, Insightful)
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 (Score:4, Insightful)
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: (Score:3)
True, because it is basically terrible for everything, it is terrrible also for using it in the same way as C.
We get it, you don't like C++. I don't like strawberry ice cream.
Yes, RAII is nice. But only *some* memory and resource leaks go away, basically the ones which are trivial, because allocation and deallocation simply follow lexical scope. Ofcourse, this is only trivial in languages which do not have exceptions. Exceptions make this simple thing very complicated, and without RAII it is indeed almost impossible to avoid resource leaks in C++. But without exceptions, it is not so much of a deal. In other words, RAII had to be invented after the fact to make exceptions usable in C++ because - again - some feature were introduced without much thought.
Exceptions are absolutely the right way to do error handling. This was controversial last century, maybe? But it's more than simple RAII - if you have non-trivial destructors, you're likely doing it wrong. Shared_ptr combined with scoped objects fixes the non-trivial ones, and basically everyone uses shared_ptr for everything now. Perhaps over-used, but it gets it right.
This is only a tragedy for people who have to use C++ or think they have to. There is nothing more liberaring than to realize that all this complexity of C++ is completely unnecessary.
I haven't paid much attention to D, but C++ is in a space where none
Re: (Score:2)
Probably the most useful side effect of exceptions is printing the stack trace, and that's not something where the overhead (both performance wise, and logical complexity wise) of exceptions is needed. And you should really be doing logging rather than relying on cryptic exception traces.
The one theoretical case where exceptions are som
Re: (Score:2)
You're doing exception safety wrong, then. It seems to be a tricky part to learn.
The idea is that you write code to be exception-safe, which is greatly aided by RAII. Some code simply won't throw (a swap() should not throw, for example). Some will be transactional: either it succeeds, or nothing happens. The rest will be written such that an exception will leave everything in a nominally valid condition. A C++ function that will leave things in an inconsistent state from any exception is badly writ
Re: (Score:2)
Yes, RAII is nice. But only *some* memory and resource leaks go away, basically the ones which are trivial, because allocation and deallocation simply follow lexical scope. Ofcourse, this is only trivial in languages which do not have exceptions. Exceptions make this simple thing very complicated, and without RAII it is indeed almost impossible to avoid resource leaks in C++. But without exceptions, it is not so much of a deal. In other words, RAII had to be invented after the fact to make exceptions usable
Re: (Score:2)
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.
Well put. Real science and engineering often necessitates a compromise of multiple incongruent requirements. For a tool, such as a programming language, the proof is in the pudding, as programmers will usually default to the best tool for the job. I am not a programmer. Is there an alternative language that does a better job meeting the three criteria indicated?
Re:Poor Alan Kay (Score:4, Interesting)
> But that doesn't mean it is a bad language.
It is when programmers blindly use OOP as a Silver Bullet (TM) and then wonder WTF they run into all sorts of performance problems ...
"Pitfalls of Object Oriented Programming"
* http://research.scee.net/files... [scee.net]
I'm sorry but the C++ committee has their head up their @$$es for *practical* matters:
* Standardized Name Mangling?
* Standardized ABI so compiler A can call code compiled with compiler B
* Standardized error messages
* Standardized pragmas to enable/disable warnings for unused variables
* Standardized forced inline, never inilne
* A consistent grammar between forward declarations and function definitions to make it easier to copy/paste
* Multi-column debugging instead of the archaic line debugging
Gee, who would ever want that!
Yeah, lets ignore real world issues for the past 20 years and keep adding CRAP onto the language ...
"A Proposal to Add 2D Graphics Rendering and Display to C++"
* http://www.open-std.org/jtc1/s... [open-std.org]
For high performance games, most of the C++ features are *ignored*
"CppCon 2014: Nicolas Fleury "C++ in Huge AAA Games"
* https://www.youtube.com/watch?... [youtube.com]
Re:Poor Alan Kay (Score:4, Insightful)
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: (Score:2)
Would be nice, but would cause major backwards compatibility breakage because all but one compiler would have to change the magling scheme
All the same, it would be nice if they'd given a recommended method of name mangling, because over time (a decade or more) all compilers would converge on that recommendation. But anyway, to me name-mangling's a minor issue compared to problems like calling conventions, especially with things like smartpointers. Not sure there's a way to fix that problem, but it sure can be annoying when you're trying to interface with C++.
Re: (Score:2)
You're right, name mangling is only one part of the differences between compilers. This means that standardizing that would be essentially useless, since all sorts of things can differ, and standardized mangling would only exchange fairly clear error messages at link time to screwy run-time errors. (Also, it's an implementation detail, not part of the abstract language.) There are people working for a standard ABI, which compilers could optionally implement.
Re: (Score:2)
Do you _actually_ use different compiles on different platforms at all ????
'inline' is only a hint
I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.
This the reason #define macro's haven't died. 100% guarantee inlining.
Do you even understand the point of having "standards" ??
You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...
* http://www.volvoclub.org.uk/hi... [volvoclub.org.uk]
This isn't rocket science -
Re: (Score:2)
If this is a priority, why not just use C?
Or, more cynically, it's simple enough to pick up basics fast yet has enough complexity to take years to master and an endless amount of obscure gotchas for true gurus to demonstrate their superiority. In other words, once it got adopted it helped establish a
Re:Poor Alan Kay (Score:5, Informative)
C++. All of programming in one language - except simplicity.
"When programming in C++, you have to pick the subset of the language that you want to use. Otherwise your code will be unreadable."
C++ is a travesty of design (Score:4, Interesting)
Because its requirements, chosen by its designer, were misguided and impossible to achieve with a clean, elegant design.
Attempting to be compatible with C was a terrible mistake. The resulting language complexity, inconsistency, and limitations resulted in an unsafe language much harder to use than is justifiable.
What would have been wrong with just creating a compiler which was both a C compiler, and also a compiler for a clean OO language.
Programs could have had C functions in some source files/directories, (considered unsafe, of course), and clean OO modules in other files / directories. An easy way of using data in some C types such as basic numbers, arrays, and strings within the OO language could have been crafted, and a no-muss-no-fuss way of calling C functions from OO and vice versa could have been included.
What was lacking was the courage to drag programmers away from C rules and conventions enough to create a simple and powerful OO language.
The ugly compromise approach set back OO programming momentum, cost millions of person-years of unnecessary debugging effort and allowed many, many continued buffer overflow exploits etc. that ruin the reputation of software in general.
Re:C++ is a travesty of design (Score:4, Insightful)
Re: (Score:2)
Like Common Lisp, e.g.
Re: (Score:2)
Like Common Lisp, e.g.
That's not quite what I meant. Lisp can act as a metalanguage, so you can write your own languages in it, but then every single program ends up with its own language.
I'm thinking or a language that consists of multiple "variations on a theme" to allow multiparadigm programming. The problem with most "functional" languages is that they compromise the core concepts of functional programming in order to be useful -- side-effects and monads mean that the "function" is not a mathematical function (provides the s
Re: (Score:2)
Because its requirements, chosen by its designer, were misguided and impossible to achieve with a clean, elegant design.
I don't think a clean, elegant design was ever the goal. It was built as a practical set of design compromises to fill the needs of the industry at the time.
The ugly compromise approach set back OO programming momentum, cost millions of person-years of unnecessary debugging effort and allowed many, many continued buffer overflow exploits etc. that ruin the reputation of software in general.
I think it is worth pointing out that there are plenty of languages that took the non-compromising approach and have fallen into obscurity while C++ took off. In the end it was the compromises of C++ that the software industry as a whole actually wanted. C++ for a long time has provided tools such as std::string and std::vector, to mitigate/eliminate th
Re: (Score:2)
Re: (Score:2)
What was lacking was the courage to drag programmers away from C rules and conventions enough to create a simple and powerful OO language.
lol
Lacking courage.
Don't foolishly insult the creator of the language with such historically ignorant and ill-thought out comments. There are hundreds of morbiund, obscure and unpopular languages for people who wanted to wean people off C. Nobody lacked the courage: hundreds of people have tried.
Re: (Score:2)
The high degree of C compatibility was probably necessary for C++'s acceptance. Stroustrup thought so, anyway.
A compiler that compiled both C and some other language would be essentially two compilers glued together. People might use the C compiler, but would regard it as bloated. Just because a compiler is normally shipped doesn't mean people will use it.
Stroustrup didn't lack the courage to drag programmers from C, he lacked the ability.
Re: (Score:3)
Contribution? (Score:5, Funny)
Contribution to Object Orientation? That's like an award for hammer-based carpentry.
Re:Contribution? (Score:5, Interesting)
I also find it hard to believe an award for pioneering work in object-orientation which started in 2005 just got around to awarding Bjarne Stoustrup ten years later. Since they give out two awards each year, I wonder what the other 18 guys did. Off the top of my head only Alan Kay comes to mind as being more deserving.
Re: (Score:3)
Well, Kiczales, des Rivieres, and Bobrow come to mind [wikipedia.org]. It's not that well known, but the meta-object protocol and multiple dispatch are so much more powerfull than C++ OO that it is actually not funny.
Re: (Score:2)
Stroustrup, in his "Design and Evolution of C++", said that he wished he could have thought of a good way to include Lisp's multiple dispatch. (There's a lot more to the Common Lisp Object System, but its basic features are extremely useful.) I don't remember him specifically envying any other feature of another language.
Of course, Lisp has always been a language that pushed for meaningful abstractions, with performance something considered later, while C++ was a language that considered performance al
Re: (Score:2)
Stroustrup's original idea was to make a language that combined C's efficiency with Simula's classes, so I'd imagine the people behind Simula count.
Re:Contribution? (Score:4, Insightful)
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.
Re: (Score:2)
Really? I think the GOF should be round-up and shot. No other group has caused more harm to the industry.
Nope. I was trying t othink of an analogy but I'm stumped. The GoF wrote a nic book documenting ang giving standard names to a bunch of stuff people were already doing. It gave us a nice standardised vocabulary to talk about existing things. It was very much a descriptive book.
Then untoled nutcases decided it was *proscriptive* and used every bloody pattern they could remember in every piece of code. Bla
Re: (Score:2)
Re: (Score:2)
The entire concept of design patterns, really. While I'll admit their book is widely misunderstood, and they address a lot of my concerns in the first few pages, the negative impact the book has had on software can't be overlooked. From the rampant misuse of patterns to the countless over-engineered systems they've inspired, their influence has caused far more problems than it solved.
The general understanding of design patterns is a problem as well. While broadly misunderstood as a 'language of design',
Re: (Score:2)
1) Knowledge of design patterns don't help programmers become better (and may make them worse)
2) GoF the book was not well-researched, they didn't show that the patterns solved a common problem.
3) GoF was not well-researched, they didn't show that the patterns even solve a problem, only that they can
Re: (Score:2)
Ideally, design patterns are standard ways of doing common things that work well. They vary by language, since some things that would require certain code (and hence a pattern) in language A may be built into language B. It probably didn't help that the GoF book was so hard to read.
Re: (Score:2)
Any technique can be applied blindly to make simple things complex. C++ makes it a lot easier to use OO than many other languages, which is really nice, but OO should only be done where it's useful. Any inheritance relation should have a simple explanation as to why it makes sense.
Who knew? (Score:5, Informative)
Who knew that there was an annual award for such a specialized field? It's surprising that Stroustrup hasn't gotten this award already. Based on the Wikipedia entry about this prize [wikipedia.org], it looks like in 2013 and 2014 they couldn't think of anyone else who created a popular object-oriented language. Maybe somebody should tell 'em about Guido Van Rossum and James Gosling. And what about the STL guy who was just interviewed here? Not to mention the Objective-C guy, whoever he is. (I'm sure I've left many other deserving candidates out - sorry about that.)
Award? (Score:2, Funny)
I thought Dahl-Nygaard was an Indian soup.
Re: (Score:2)
And what about the STL guy who was just interviewed here?
STL has little to do with OO, it's mostly about algorithms and generic programming.
Re: (Score:2)
I guess I was fooled by the fact that all of the STL things I've ever used are classes. In fact, offhand, I can't even figure out how you'd do generic programming without some manifestation of objects to allow you to provide overloaded operators.
To be fair, though, the only two forms of generic programming I know a little about are the template approach in C++ and the duck-typing approach in Python. Both of those rely heavily on classes. Maybe there's something else that doesn't. I guess in C++, for exa
Re: (Score:2)
To be fair, though, the only two forms of generic programming I know a little about are the template approach in C++ and the duck-typing approach in Python. Both of those rely heavily on classes.
Presence of classes does not automatically mean OO. In C you also have structs and can store also function pointers in them to mimic virtual functions, yet nobody says C is an OO language. For "real" OO one needs at least derivation/inheritance and virtual method overriding. In C++, one could implement containers, iterators and algorithms without any derivation or virtual functions whatsoever, so in my mind, no OO is involved in STL.
Re: (Score:2)
I guess we just disagree about what the definition of object-oriented programming is, but I think of it simply as a set of operations that you are associated with a particular user-defined data type. In that sense, I've done plenty of object-oriented programming in C by just passing a pointer to a structure into a function that was intended to operate on that "object". Of course, you can do deriviation, inheritance, and virtual methods using the mechanisms C provides. The system of classes that C++ provi
Re: (Score:2)
I'd say that some form of inheritance and polymorphism would be necessary for OO programming, not just user-defined types. I suppose definitions vary; I've seen some that would exclude the Common Lisp Object System. In general, the STL parts of the library involve UDTs, not inheritance and polymorphism (which are done with generic and not OO programming).
Re: (Score:2)
Ken Thompson on C++ (Score:5, Interesting)
"I would try out the [C++] language [at AT&T] as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point, I said, no, no more. In an interview I said exactly that, that I didn't use it because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language."
"[C++] certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, "I wrote it; here, take it." It’s way too big, way too complex. And it’s obviously built by a committee. Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that."
Ken Thompson; cited in Seibel, Peter (2009). Coders At Work. p. 475.
Re: (Score:2)
Us guys who have worked on C++ compilers have an old joke ...
There are only 2 problems with C++.
1. Its design,
2. Its implementation.
Fortunately most C++ compilers use the EDG front-end to handle all the crap of template parsing.
Re: (Score:2)
Re: (Score:2)
Fortunately most C++ compilers use the EDG front-end to handle all the crap of template parsing.
Except the three most popular: GCC, LLVM and Visual Studio.
Re:Ken Thompson on C++ (Score:4, Insightful)
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.
Re: (Score:3)
Well that just sounds like mean-spirited carping. This for example is demonstrably not true:
And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed.
The committee process is very open and one can see how it works. and it doesn't work like that. And it certainly doesn't have every feature: most proposals get rejected.
Re: (Score:2)
If you want to see how things got into C++, read Stroustrup's "Design and Evolution". You could also go through the committee proposals (on line and freely available, but tedious reading) and notice that not all of the stuff Stroustrup favors makes it into the Standard.
Well deserved (Score:2)
Kudos, and well deserved.
C++ is my favorite language to program with, over the past few years.
C++ is the triumph of syntax over clarity (Score:2)
Comment removed (Score:4, Insightful)
FTFY (Score:2)
considered the most prestigious prize in object-oriented computer programming
I won't put it past /. submitters or editors, but why can't the very intelligent, accuracy-blessed computer coders out there, at least, understand this? If you're not doing any science, then it can't be "computer science."
"Science"? (Score:3)
Re: "object-oriented computer science" -- Where is the "science"? Where are the theories, the metrics, and the independent repeats to verify?
Re: (Score:2)
Wait til you see the Political Science department!
Re: (Score:2)
Where are the theories, the metrics, and the independent repeats to verify?
There's a bunch of that in Bertrand Meyer's book. I know you don't like that book, but it has theories, metrics, and independent studies.
Functional Awards? (Score:3, Funny)
Where are the "Functional Science" awards? You gotta have Paradigm Envy, no?
And how about the Procedural Awards, and the Goto Awards? I hear the Goto team racks up a lot of air-fare.
Object Oriented (Score:2)
Re: (Score:2)
Re: (Score:2)
Fortunately, more people are starting to recognize that. I'm amazed it took this long.
Where's Tablizer? He's owed some vindication.
Re: (Score:2)
Where's Tablizer?
Here? :-) [rubygems.org]
Re: (Score:2)
I'm going to disagree with this: inheritance can be an excellent idea. It can be way overused. Good C++ code doesn't have inheritance for the sake of inheritance, but rather to use different types the same way with appropriately different results.
If there's a massive type hierarchy in C++ software, chances are it's a real mess, and should have been avoided.
Re: (Score:2)
Why is inheritance a bad idea?
It couples polymorphism/dynamic dispatch to implementation sharing. These concepts can be used orthogonally through other means which gives much better flexibility. One example is what Go does with interfaces for one polymorphism/dynamic dispatch and composition for implementation sharing. You can do this style in C++ as well, and it often works out better than massive type hierarchies. Its much easier to re-factor (thus requires less upfront design) and avoids the problems of multiple inheritance. It can
Re: (Score:2)
It couples polymorphism/dynamic dispatch to implementation sharing.
Well, in most languages with some OOP support.
Re: (Score:2)
Re: (Score:2)
Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. [...] a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages.
My favorite example of that is the Circle-ellipse problem [wikipedia.org]. It seems so natural that a circle is-an ellipse, but it doesn't map to OO heirarchies the way we expect it to. The ontologies offered by OOP languages are always presented as if they were perfectly natural and universal without a hint of the lurking problems. It's not until you come up against some of these problems (hopefully early, before you've drank the coolaid) that you start to realize something's wrong.
[...] In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning.
Ok, fine, but I'd settle for less inade
Re:Ppl who don't know C++ slamming C++ (Score:5, Insightful)
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: (Score:2)
There are a few languages I'd call works of genius, like LISP and Forth. C++, however, is not one of those languages.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2, Informative)
As Stroustrup himself has explained several times, C++ is a multi-paradigm language. You can use it to do C-style system programming (indeed, using the exact same library and system calls without the overhead of a translation layer), object-oriented programming, or generic programming, and mix and match within the same app, library or even the same class definition. And there's no bytecode virtual machine overhead.
So to say that it's not a pure OO language, well no, it wasn't designed that way.
Re: (Score:2)
You are missing the point, you can't do true OO programming with C++
Re: (Score:3)
What is true OO and how C++ prevents me from doing it? Show some code.
It's like a resume question from Evil Overlords, Inc. software division.
Re: (Score:3)
What is true OO
No one knows. Those who think they know all disagree with one another.
Re: (Score:2)
What is true OO and how C++ prevents me from doing it?
One of the commonly expected features would be the ability to late-bind the features of the language itself, for example, method lookup. Which C++ to my knowledge lacks, the mechanisms are fixed.
Re: (Score:2)
In what way is late binding a matter of object orientation? I'd think it a feature in its own right.
Re: (Score:2)
I've spent over a decade writing C++ code professionally for financial, insurance and CRM systems. So Stroustrup made a half-baked badly designed partially-OO langauge that has set back the evolution of real OO back at least two decades, and he gets an award? A kick in the ass would be more appropriate.
I have lost count of the number of times I have ran across a mess of C++ code where someone was trying to implement Smalltalk-style semantics in C++. Which doesn't work.
C++ rewards good design but brutally punishes poor designs. And most C++ coders aren't very good at designing clean class hierarchies. This means that most large C++ programs end up being insane vats of code goo after a few years.
Oh, and pet peeves...
The class mechanism in C++ is used to implement several incompatible concepts that would
OO is not a property of the language. (Score:2)
C++ rewards good design but brutally punishes poor designs.
You hit the nail on the head, somewhere in the early 90's, language vendors stopped claiming "Our language supports OO concepts" and started claiming "Our language is OO".
The first C++ compiler I used professionally was Wacom's (circa 1991). Back then the Watcom C++ extensions were not part of the language, they were implemented with a bunch of C macros pulled in with include files, the macros themselves were riddled with goto (another macro) statements. I still have nightmares....
The fact is any gen
Re: (Score:2)
I don't understand this distinction between "object" and "value". It sounds to me like an object is something that can be named and a value is something an object has (in other words, the difference between lvalues and rvalues), and in that case, you're making no sense. Could you clarify?
Re:Pronunciation (Score:4, Funny)
Yes. And it is "see" "ploose" "ploose" for those in the know.