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

Re:You can't argue with that

[Anonymous Coward]

Sorry, but I disagree.

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

[Cassini2]

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

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

[Snufu]

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

[UnknownSoldier]

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

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

void foo(); // semi-colon required
void foo(); // semi-colon is error
{
}

* Multi-column debugging instead of the archaic line debugging

foo(); bar(); qaz(); // try setting a breakpoint on bar .. most debuggers only support 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...

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

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

[K. S. Kyosuke]

Actually, he also talked about how all he wanted was possible in Lisp, and it is my understanding that CLOS had been dragged into the "pay-as-you-go" performance territory quite some time ago.

Re:Poor Alan Kay

[lgw]

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 of the othe mainstream languages are. C is quite overused for lack of expertise in C++ - and Java likely is as well.

Re:Poor Alan Kay

[ultranova]

for backwards compatibility with C (IMO Vala does better -- YMMV)

If this is a priority, why not just use C?

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.

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 pecking order of programmers, who then have every incentive to keep it popular to protect their investment and the resulting status.

There is no field of human activity where psychology didn't rule supreme.

Re:Poor Alan Kay

[serviscope_minor]

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.

That is complete and utter rubbish: you completely misunderstand RAII. shared_ptr escapes lexical scope and is reference counted. Provide you never have cyclic mutable graphs, you are *guaranteed* not to leak resources with RAII.

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:Poor Alan Kay

[Bent Spoke]

The learning curve is too high simply because the language is too big.

Re:Poor Alan Kay

[phantomfive]

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:Poor Alan Kay

[UnknownSoldier]

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

This isn't rocket science -- let alone basic computer science. A dead-line is set, we inform people, and we make the switch. It's not fucking hard.

>> Standardized error messages
> doing something that no one else has ever done.

Gee, why does Microsoft provide a _specific_ number for _each_ warning ???

* https://msdn.microsoft.com/en-...

Do you even code in C++??

>> *"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 according to the correct procedure??

This is a solution in search of a problem.

Do you even _understand_ the term: Kitchen Sink or Over-engineering??

We already have graphics libraries, OpenGL / OpenGL ES, DirectX, etc. We don't need more shit in an already bloated language.

People like you are precisely part of the problem with C++.

1. Completely failing to understand _practical_ matters.
2. Continue to make excuses for why their tools are crap.
3. And then post blatantly false information that gets modded up to Insightful without a clue.

Re: Poor Alan Kay

[martin-boundary]

Essentially, they should never be used at all. If you're going to have an unrecoverable error, it's trivial to design the system to exit without using exceptions anyway.

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 sometimes argued to be superior is if you don't know what to do locally about an error, and you're hoping that a higher level part of the program might know how to recover. Classic example is a read error, and then asking the user to put a usb stick in.

But guess what? That's not how nontrivial programs work. The higher level simply can't know fully the effect of handling an exception that bubbled up, because the low level details that matter can and often do have unpredictable consequences in terms of program correctness, especially when you're reasoning at a higher level. When an exception is thrown, your program state is wonky. Only trivial programs are like the usb stick example. Real programs become subtly wrong if you try to recover a partially completed, partially incomplete, multi statge operation, especially if you're not the guy who wrote the code, but feel you're doing the right thing at a higher level.

Your greatest chance of correctly handling errors is a few lines above or below where the error actually occurs. Anything else sounds good but is worse.

Re: Poor Alan Kay

[david_thornley]

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 written, and it's usually fairly easy to transform it into one of the first three.

This does require some knowledge (including the knowledge that you should be doing this) and a bit of care. In practice, once you learn to write stuff this way (and are comfortable with RAII) it's easy to do.

Re:Poor Alan Kay

[david_thornley]

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:Poor Alan Kay

[phantomfive]

There are people working for a standard ABI, which compilers could optionally implement.

How do they handle the fact that different platforms require (sometimes vastly) different calling conventions at the assembly level (i.e., which registers are saved registers, etc).

Re:Poor Alan Kay

[david_thornley]

The paper I read said that there would be standard ABIs and such on platforms, to be created by the experts on each platform. There's no reason to try linking MS Windows x86 binaries with Linux on PowerPC, after all, but there'd be uses for linking various binaries together on MS Windows. This wouldn't put ABIs into the Standard, but would put in frameworks for creating them.

Re:Poor Alan Kay

[phantomfive]

The paper I read said that there would be standard ABIs and such on platforms, to be created by the experts on each platform.

Seems reasonable to me.

Re:Poor Alan Kay

[serviscope_minor]

Do you _actually_ use different compiles on different platforms at all ????

Yep.

'inline' is only a hint

Inline specifically means "export this as a weak symbol".

I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.

Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.

Nonetheless you're ignoring the other part of the reply that the C++ committe has in fact standardised a way of specifying attributes. Why don't you submit a paper specifying some always inline attribute?

You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...

You wishing something to be the case dosen't make it happen. Unlike your silly car analogy, there is no government body who will arrest and detain anyone using C++98 after some flag day. As a result it will cause fragmentation just like Python 3.

Gee, why does Microsoft provide a _specific_ number for _each_ warning ???

Uh? Again, there is no language where error messages are standardised. The fact that MS provides numbers for each one is a total red herring. Like I said, complaining that the C++ committee have their heads up their arses because they're not standardising something that no other language spec ever standardised is basically idiotic.

But now you've wandered into bizarro world with warnings. So what would the procedure be? The warnings which a compiler is capable of emitting depend quite strongly on the code analaysis part which is in part dependent on the optimizer. There is no way to get GCC, LLVM, VS and ICC to have exactly the same set of warnings. And then what would the procedure be for new warning?

Seriously, the standards committee cannot make something happen by magic. If they try to do something that no one is going to implement then it's a pointless and destructive waste of time. They learned their lesson very well with exported templates. All sorts of people begged and whined for it, so they did it. They didn't listen to the howls of anguish from the compiler writers. All that happened was a dead stub of a standard which almost no compilers ever supported.

This is a solution in search of a problem.

So you're saying that the C++ commitee shouldn't be reading and considering every proposal that is submitted according to the correct procedures? So how should they filter them? Ask you and see if you give the thumbs up?

1. Completely failing to understand _practical_ matters.

Says the person who believes that by magic the C++ committee can make everyone switch to a new, incompatible language and avoid fragmentation! That's about the biggest practical matter and you claim outright that it doesn't exist. Then you rather hilariously accuse me of not understanding the practicalities.

OK, smart-ass, how would you force everyone to switch to a future non-backwards compatible version?

2. Continue to make excuses for why their tools are crap.

Tools are crap for reasons you haven't mentioned: namely it's sodding hard to parse C++. Because of (1) the committee can't fix that. But again, the OP complained that the "committee have their heads up their asses", which is a foolish and ignorant statement. There hasn't ever been a language standard which specifies the kind of tooling he was asking for.

And tools have nothing to do with the language standard.

3. And then post blatantly false information that gets modded up to Insightful without a clue.

Except nothing I said was false.

Re:Poor Alan Kay

[lgw]

If you don't check for an error due to sloppy coding, you get a failure sometime later which can be quite hard to debug. If you don't handle an exception, your program exits, and if you can repro the problem under a debugger, any good debugger will break where the exception is thrown - immediately debuggable. Which approach better protects customer data from bugs?

If you check for errors after every call, your program become 80% error checking, 20% business logic. Needless cluster that obfuscates code.

For a large enough C program you re-invent exceptions anyway. The return code from every function becomes the error code. The first thing you do after every function call is check for errors, and either handle the error locally if you can, or return it up the stack if you can't. If you make some handy macros for doing that, you might as well call them "try" and "catch" and "throw", since you're just doing what the compiler does with exceptions, except in a manual, tedious, and eror-prone way.

Really, this was an intelligent argument 20 years ago. The experiment was tried, the data is in, almost everyone moved to languages with exceptions because they make it easier to get it right, not out of some group masochism.

Re:Poor Alan Kay

[UnknownSoldier]

> Inline specifically means "export this as a weak symbol".

Oh gee, and here I thought it meant merge basic blocks. Do you know _anything_ how C++ compilers even work??

>> I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.
> Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.

You love to constantly make incorrect and incomplete assumptions.

1. I want to write ONE directive not clutter my code up with hacks PER compiler. _Why_ do standards exist ? To make everyone's live _easier_.

2. Gee, why do things like _Profiling_ exist. The *compiler* doesn't have access to *run-time* performance. The optimizer is dealing with a _subset_ of data. It doesn't know the "function temperature".

But go on keeping making excuses. You really don't have a clue.

Re:Poor Alan Kay

[serviscope_minor]

Oh gee, and here I thought it meant merge basic blocks.

Nope. As you pointed out yourself it's only a hint to the compiler whether to actually inline or not. When it is not inlined, the symbol has to be weak, because the function may be exported in may object files: which ever object files have a corresponding source file which includes the function.

Therefore all inline really means is "export as a weak symbol".

Do you know _anything_ how C++ compilers even work??

Yes, which is why I know that thing about weak symbols. You apparently do not.

You love to constantly make incorrect and incomplete assumptions.

Well no.

2. Gee, why do things like _Profiling_ exist. The *compiler* doesn't have access to *run-time* performance. The optimizer is dealing with a _subset_ of data. It doesn't know the "function temperature"

Compiling (under gcc) with -fprofile-arcs, running the program generates that information. Recompiling with -fpbranch-probabilities then tells the optimizer to use the run-time information. That said, I don't think function temperature has much to to with whether to inline or not.

1. I want to write ONE directive not clutter my code up with hacks PER compiler. _Why_ do standards exist ? To make everyone's live _easier_.

And anyway, you still ignored my point. The committee have standardised function attributes, which is 95% of the way towards having what you want. Write a proposal to add force_inline as a standard attribute.

Re:Poor Alan Kay

[Uecker]

I understand RAII just fine.

In fact, what you say seems to be in agreement with my statement: "Provided you never have cyclic mutable graphs" "only some memory and resource leaks go away".

Re:Poor Alan Kay

[Uecker]

If you don't check for an error due to sloppy coding, you get a failure sometime later which can be quite hard to debug. If you don't handle an exception, your program exits, and if you can repro the problem under a debugger, any good debugger will break where the exception is thrown - immediately debuggable. Which approach better protects customer data from bugs?

Without exceptions, you would put in an assertion which would give you the same debuggability (and the compiler would warn if you completely forget to handle the return code). The only advantage of exceptions is that you can ignore the error on the intermedate level and try to handle it higher level instead. This might be useful, but opens up an entire class of new - and very hard to debug - failures from code which is not exception-safe. RAII helps with this, but has its limits.

Re:Poor Alan Kay

[lgw]

Without exceptions, you would put in an assertion

Oh? You check for errors in code that gets #ifdef-ed out in a production build? What could possibly go wrong with that plan? (Or do you mean first the check, then the assert, following every function call, further hiding the few lines of business logic in a huge function).

It's quite easy to write "all exception safe all the time" code in C++, in ways that even the junior guys can't screw up. It's not obvious what that coding standard looks like. That's the big problem with C++. Many have never even seen it done right - it's very understandable why business largely moved to managed code.

People see RAII and think "oh, instead of allocate at the top and free at the bottom, I'll allocate in the constructor and free in the destructor". No, you're still doing it wrong if you have any non-trivial destructors outside of a bit of well-reviewed library code.

If you're doing it right, the only avenues for screwing up resource management are adding stuff to a global object and forgetting it there, as with every language.

Re:Poor Alan Kay

[Uecker]

Why would you #ifdef out assertions in production code?

It's quite easy to write "all exception safe all the time" code in C++, in ways that even the junior guys can't screw up.

Ofcourse... Dream on.

Re:Poor Alan Kay

[lgw]

It's a problem when the default ASSERT macro expands to code with such #ifdefs (no joke - that was the norm everywhere I worked with C/C++). At one place it got so bad that we made using the ASSERT macro a firing offense (not sure why we couldn't just fix the macro, some corporate thing no doubt).

And I've been there and done that with the "no resource leaks" in C++. When you provide library code that's easier to use than doing it the wrong way, it's easy to enforce the standard in code reviews (since then it's only the new guy who hasn't seen how easy the tools are yet).

For example, if you have a good FileHandle class, it's simple to educate people to write FileHandle foo = fopen(...); instead of FILE, and then that's it, the file closes when you exit scope. Works perfectly as a member variable as well - no need to remind people that the destructor isn't called if the constructor throws, as members are always cleaned up.

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

[NoOneInParticular]

I think that OO is possibly the worst thing that ever happened to computer science. Nice try, but it turns out that in practice, inheritance is a bad idea. Luckily C++ doesn't force one into OO like the more pure languages do. That's why I like C++.

Contribution?

[Anonymous Coward]

Contribution to Object Orientation? That's like an award for hammer-based carpentry.

Re:Contribution?

[ranton]

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:Contribution?

[rmstar]

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.

Well, Kiczales, des Rivieres, and Bobrow come to mind. 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:Contribution?

[Anonymous Coward]

I haven't looked at the list of recipients, but here are a few others that may be more deserving than Stroustrup (and I don't say that out of disdain for C++ or Stroustrup): the developer(s) of the Self programming language, the developer(s) of the Common Lisp Object System (CLOS), and the OO design patterns people.

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.

Re:Contribution?

[serviscope_minor]

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. Blaming the GoF for that is like blaming wikipedia for someone losing a finger because they have an article on band saws.

Re:Contribution?

[Bent Spoke]

OO is, in general, an attempt to abstract-out some of the complexity inherent with developing code.

The often overlooked question is: how frequent is it that OO (and in particular C++) end up increasing complexity.

Re:Contribution?

[phantomfive]

ok, I'm interested on this one, because it seems like you have something interesting to say. What don't you like about GOF? (Or rather, why do you think they caused harm? I don't like their writing style, it's boring, but boring writing doesn't really cause harm to the industry).

Re:Contribution?

[narcc]

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', the so-called patterns are not language agnostic. The explosion of 'new patterns' that followed further diluted any possible value that concept offered. Just replace the word 'pattern' with 'solution' next time your read about a pattern and you'll see what I mean. (That all stems from the *title* of the book! I've never seen a book's title alone cause so much confusion and harm.)

A note on that misunderstanding: The 'why' is often far more important than the 'what' when communicating with other programs. To say 'I used the visitor pattern here' gives you the 'what', but not the 'why'. There's also a strong indication there that the code is too complex to understand without hanging a common name around its neck.

Moving on... Sploski offered two points, to which I agree: 1) Patterns introduce unnecessary complexity. 2) Recurring use of patterns indicates a deficiency in the language. (There's also a discussion on c2 somewhere about that.) On (1) there's the use of patterns where far simpler solutions are more appropriate. They're often used here because too many developers think that using patterns mean their code is 'adheres to good principles of design'. This leads to a consequence in (2), related to my point that patterns are not language agnostic, which is the amazing amount of effort placed in to implementing patterns in languages that have no need for them.

So what about the premise? Are there, in fact, recurring design patterns? We'll never know. The GoF based their book on good feelings and personal experience, not actual research. You'd think if there were recurring solutions to common problems, they'd have been discovered -- though they're often simply invented, just like those in the book, by every neophyte developer out there. It's no wonder, then, that the term 'anti-pattern' found its way in to our vocabulary to combat the pattern explosion. I've even seen many of the GoF patterns described as anti-patterns. Being groundless, they're vulnerable to such subjective criticism.

Obvious questions like 'is this a recurring problem', 'is this solution effective', and 'is this solution efficient' never seem to enter the discussion. Without a lot of effort, you can't even begin the answer the first question, let alone start proposing solutions! Lacking actual research means that developers have no choice but to actively look for opportunities to use patterns (leading to pattern abuse) rather than simply determine if a particular pattern is appropriate based on the information they have available. That is, they can only ask 'can it be used' not 'should it be used'.

Patterns are folk wisdom, not engineering, and suffer the same problems. Next time you reach for the GoF book, ask yourself if you're putting butter on a burn.

Re:Contribution?

[phantomfive]

That's great, I was hoping you'd have something interesting to say on this point, and you did not disappoint. If I may summarize, I see three main points in your post (maybe this isn't a very good summary):

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

I would add that in my own experience, code rarely fits neatly into the GoF design patterns. Sometimes the problem matches something similar, but rarely the exact pattern. And even when it does match, I usually use a modified version (example, singleton [which I call a global variable] I rarely make an actual singleton. For example, if I have a clipboard class, I make it generic enough to have multiple clipboards, but then designate one of those as the system-wide clipboard or whatever).

btw the organization of your post is solid, that was some nice rhetoric; logical flow from the weakest point to more convincing points until the end where your final paragraph is strongly stated, but feels as though it naturally flows from the rest of your points.

Re:Contribution?

[david_thornley]

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?

[david_thornley]

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 along with abstractions. It's been a long time since I read about the MOP, but it at least wasn't easy to get it working with high performance.

Re:Contribution?

[david_thornley]

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:Contribution?

[david_thornley]

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.

Re:Contribution?

[phantomfive]

It probably didn't help that the GoF book was so hard to read.

Hard to read, plus poorly researched, plus didn't demonstrate that they are commonly needed, plus the fact that trying to jam everything into design patterns results in bad software, plus the fact that they don't really help programmers become much better......

Re:Contribution?

[Tablizer]

The 'why' is often far more important than the 'what'...

That's pretty much the meat of the GOF meltdown: they didn't scientifically justify when to use what pattern (or use none) such that newbies and fad pumpers shoved square patterns into round holes and then smiled like Nobel winners as they ran off to their next gig, leaving you to hold their spaghetti pattern bag.

Re:Contribution?

[phantomfive]

So........do you have anything to say about OOP?

Re:Contribution?

[narcc]

I have way too much to say about that Scotsman. The trouble, of course, is that it's impossible to produce an operational definition to which a suitable number of people will agree. I can type until my fingers bleed, but I can't escape the simple, yet perfectly reasonable, response: "Well, that's not really OOP."

Even I don't agree that most of my criticisms are necessarily against OOP, as my understanding of the concept is different than some of the more common variations. (For example, I don't think classes are an essential concept. Without classes, a lot of other "OOP" topics vanish from the discussion.)

It's just too nebulous to talk about in the general sense.

Re:Contribution?

[phantomfive]

The trouble, of course, is that it's impossible to produce an operational definition to which a suitable number of people will agree. I can type until my fingers bleed, but I can't escape the simple, yet perfectly reasonable, response: "Well, that's not really OOP."

I don't know, the definition I've heard that I think covers every OOP ideology is, "the functions get passed around with the data."

Re:Contribution?

[narcc]

Not a bad start, gets right to the meat. Though I don't know how we go from 'Object' to 'OOP'.

We could ask 'are objects useful', but that's not the same discussion. It does remind me of this talk [pdf] which took longer to find than I expected.

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

[Anonymous Coward]

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.

Who knew?

[Marginal Coward]

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

Re:Who knew?

[paavo512]

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:Who knew?

[disambiguated]

Doesn't Anders Hejlsberg, of Turbo Pascal (aka Object Pascal), Delphi, C# and TypeScript fame, deserve at least an honorable mention?

Re:Who knew?

[Marginal Coward]

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 example, you could leave objects out of generic programming by limiting yourself to implementing whatever algorithms you could implement using just the built-in types. Seems like more of an exercise than something you'd really do.

Going back to the STL, it seems like most of the things in the STL rely on objects - either to implement the construct (e.g. strings) or for the user to use them (e.g. vectors). So, I guess I still think the STL guy still deserves some sort of object-oriented prize.

Hopefully, though, the object-oriented prize folks will discover Guido first. I don't know how important he really was in the development of object-oriented programming (since Python draws ideas heavily from many other languages), but Guido just generally deserves a prize.

Re:Who knew?

[paavo512]

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:Who knew?

[Marginal Coward]

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++ provides makes that easier, but it's perfectly possible to do object-oriented programming in C - as evidenced by the fact that the earliest C++ compiler just translated C++ into C.

In contrast, object-oriented programming wouldn't be possible in C if it lacked not only "classes" but also structures and function pointers.

It's hard for me to understand why you would think that "no OO is involved in STL", but I guess we'll just have to disagree on that point.

Re:Who knew?

[david_thornley]

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:Ppl who don't know C++ slamming C++

[rubycodez]

You are missing the point, you can't do true OO programming with C++

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

[narcc]

Fortunately, more people are starting to recognize that. I'm amazed it took this long.

Where's Tablizer? He's owed some vindication.

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

[craigm4980]

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 get you lower coupling too.

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

[Kickasso]

What is true OO and how C++ prevents me from doing it? Show some code.

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:Ppl who don't know C++ slamming C++

[halivar]

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.

Award?

[Anonymous Coward]

I thought Dahl-Nygaard was an Indian soup.

Is FORTRAN still winning? Was Re:Poor Alan Kay

[140Mandak262Jamuna]

Till about FORTRAN 77 it was clearly beating C in scientific computations. But that was mainly because Fortran used static memory allocations and C was littered will malloc and associated overheads. With Fortran99, dynamic memory allocations came to Fortran too. At this point I figured it must be just badly hampered C, all the pain and not much gain. Have not tried it personally.

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

[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:Is FORTRAN still winning? Was Re:Poor Alan Kay

[Rising Ape]

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 I tend to do all my allocations before the main loop. Not entirely sure why the penalty is so big, but it seems to be - these are allocations of hundreds of MB or even a few GB, so the cost of operations done on the arrays should dwarf the cost of the allocation. Unless there's some underlying reason why touching newly allocated memory is so slow, but I don't know enough about how virtual memory behaves to say.

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

[macklin01]

Repeatedly allocating and deallocating can give a huge performance hit, so I tend to do all my allocations before the main loop. Not entirely sure why the penalty is so big, but it seems to be - these are allocations of hundreds of MB or even a few GB, so the cost of operations done on the arrays should dwarf the cost of the allocation.

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, memory operations (allocations, copies, and deallocations) are performance killers and best avoided wherever possible (e.g., pre-allocating memory as you are, using temp variables that don't get deallocated, overloading operator+= operations to avoid hidden allocation and copy operations, etc.) The general rule:

[Disk access] is much slower than [memory access] is much slower than [CPU operations] (esp. those in the cache)

FWIW, I'm writing big finite volume codes in C++ (preparing for an open source release), and we deal with these very same issues. Our biggest performance gains (outside of choosing stable algorithms without time step restrictions and using OpenMP) are from avoiding memory allocations and copies, working on vectors of variables rather than individual variables, overloading things like operator+= on std::vector, and using BLAS (particularly axpy). Also identifying any operations that can be pre-computed (like certain steps in Thomas solvers) is helpful. :-)

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

[disambiguated]

This is why the restrict keyword as added to C, 15 years ago. It's not yet part of the C++ standard, but all the major compilers support it already. FORTRAN is where it's at for high performance only if that's the way you've always done it or if your C compiler is 15 years old.

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

[Rising Ape]

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:Is FORTRAN still winning? Was Re:Poor Alan Kay

[Rising Ape]

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:Is FORTRAN still winning? Was Re:Poor Alan Kay

[140Mandak262Jamuna]

Yeah, yeah YOU can. But the C compilers don't know it. They still optimize code not knowing what could change and what could not. So you pay a penalty.

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

[140Mandak262Jamuna]

Have you done any comparison with this keyword in C and Fortran? I play in the Finite Element Field. For me the flexibility afforded by C++ out weighs the performance I could get in Fortran. At least the solver people work on a mesh that is not altered, you could estimate the memory needs in one pass and then do the allocations, even for unstructured meshes. I make unstructured meshes, so I would not know a priori the number of tets incident on a node or number of triangles incident on an edge. I build these structures as I go along, and it is impossible to avoid new() and delete() in C. They are basically malloc() and free(). So have not touched FORTRAN for ages.

Among the solvers some of the matrix solvers use FORTRAN and some blas. Again they too prefer C++ for most of the solution and reserve FORTRAN only for really serious loops.

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

[K. S. Kyosuke]

Ugh. If you want DEFINE-COMPILER-MACRO, you know where to find it.

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

[macklin01]

Thanks! Will brush up in that more. Looks similar to what we avoid with operator+=, passing by reference, etc.

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

[K. S. Kyosuke]

You might like OMeta, then. Bring Your Own Syntax (and Semantics).

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

[whoisisis]

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).
Dynamic memory management is not much different from C.

In my experience, Fortran is extremely useful for expressing linear algebra, which is heavily used in quantum mechanics.
At least it is much much better than C. So in terms of programmer efficiency in scientific calculations, I think Fortran beats C by quite a margin.

Fortran sucks at pretty much anything else though. For example, I think it's a lot easier to have a config module (e.g. class) to manage simulation parameters and recompile the whole application every time you change settings than it is to use an actual configuration file.

The next time I write a scientific application, I think I will have Python handle the logistics (parallelization, files, user input, etc.) and let Fortran do the (heavy) computations.

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

[whoisisis]

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:Is FORTRAN still winning? Was Re:Poor Alan Kay

[140Mandak262Jamuna]

That is true. My original guess was the memory allocations alone could explain the speed difference. Someone pointed out the handicap to compiler optimizations due to aliasing. (I do not have formal education in comp sci, so I have only a fuzzy understanding of aliasing).

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

[david_thornley]

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. At that point, there's a visual structure to Lisp that you can see across the room.

C++ is a travesty of design

[presidenteloco]

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

[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:C++ is a travesty of design

[Anonymous Coward]

Attempting to be compatible with C was a terrible mistake.

Its compatibility with C is its greatest asset.

Re:C++ is a travesty of design

[Anonymous Coward]

I am java programmer...

Chris Lukehart

Re:C++ is a travesty of design

[Anonymous Coward]

It's been more than 20 years (yikes!), but I learned OO (on NeXT) using Objective-C & recall that at the time I thought Objective-C was a thing of beauty/power. Fast forward a few years & I recall being repulsed by C++. (I know, YMMV)

Anyways, I don't think being compatible with C needs to be a mistake.

Re:C++ is a travesty of design

[Jeeeb]

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 the risk of buffer overflow vulnerabilities. The C string functions are terribly designed, but programmers wanted to and chose to continue to use them, that's not the fault of C++.

Personally I'll take the productivity and maintainability of Java/C# over C++ if I can. When I can't though, C++ isn't a bad option. It certainly has its pitfalls/complexity. Some were bad design choices (e.g. exceptions can throw any type). Some were unavoidable (e.g. the interplay of virtual functions/inheritance with in place allocation). Some are technical debt.

Re:C++ is a travesty of design

[chthon]

Like Common Lisp, e.g.

Re:C++ is a travesty of design

[The Evil Atheist]

Ha. I'll take the productivity and maintainability of C++ over Java/C# whenever I can. I develop in Java for a living and I use Qt in my hobby programming. I would take Qt any day of the week over anything in the Java world. Especially now with auto/decltype and lambdas, I can write C++ in a more Pythonesque style than I ever could with Java. And the template system got easy enough that even someone like me could do some metaprogramming that reads like normal programming.

Re:C++ is a travesty of design

[serviscope_minor]

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:C++ is a travesty of design

[Bent Spoke]

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

Because C++ incrementally evolved from C and was originally bootstrapped as an translator to C (cfront).

http://en.wikipedia.org/wiki/C...

Re:C++ is a travesty of design

[david_thornley]

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:C++ is a travesty of design

[Half-pint HAL]

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 same answer for the same input every time) so caching to avoid repeat evaluation is impossible, and there's lots of human optimisation required to avoid wasted cycles.

But if we took all that useful stuff out of FP, what can FP usefully do? Sit as inner code servicing requests by the main code outside. You could therefore have a language with two distinct types of code units: proc and fun. A proc can call a fun, but a fun can't call a proc, because procs allow mutability and side-effects, but funs don't. The body of a proc is a series of statements, but a fun contains only a single expression.

A higher-order function given a proc would return a proc, but if given a fun it would return a fun. Notice that passing a procedure to higher-order function does not break the mathematical integrity of the higher-order function, because it will always return the same procedure for a given input procedure.

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

[Anonymous Coward]

Like they say:

C++ combines the speed and power of assembly language with the readability and high level language features of assembly language.

Ken Thompson on C++

[Anonymous Coward]

"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:Ken Thompson on C++

[UnknownSoldier]

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:Ken Thompson on C++

[jcr]

C++ wasn't designed, it was accreted.

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

Re:Ken Thompson on C++

[serviscope_minor]

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

[serviscope_minor]

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:Ken Thompson on C++

[david_thornley]

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.

Re:Pronunciation

[presidenteloco]

Yes. And it is "see" "ploose" "ploose" for those in the know.

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

[david_bonn]

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 be best separated. One of these is "objects". Objects ideally are almost always used in pointer or reference context, use inheritance, and all public member functions and their destructor should be virtual (a class with a virtual function and a non-virtual destructor is a memory leak waiting to happen). Objects should almost never use operator overloading. Another concept is "values". Values use the copy-constructor and assignment operators, should almost never use inheritance (because getting a virtual assignment operator to work sanely is hard, and a virtual copy constructor isn't really possible) and might use operator overloading. Any case where these two concepts mix is very rarely good.

On the other hand, I can bill $1000/day telling people in painful detail that they have a screwed up mess of code. So C++ is at least rather lucrative for me.

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

[narcc]

There are a few languages I'd call works of genius, like LISP and Forth. C++, however, is not one of those languages.

Well deserved

[mrflash818]

Kudos, and well deserved.

C++ is my favorite language to program with, over the past few years.

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

[narcc]

What is true OO

No one knows. Those who think they know all disagree with one another.

OO is not a property of the language.

[TapeCutter]

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 general purpose language can be used to implement an OO design because OO is not about language features, it's a design methodology, or at least that's what I was taught when studying for my CS degree in the late 80's. As my smalltalk lecturer pointed out at the time, most of the examples in K&R's "The C language" are also great examples of OO design that were written long before the term OO was invented.

Disclaimer: These days I spend much more time tying spaghetti balls with different flavoured source together than I do trying to untangle the individual gordian knots.

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

[TapeCutter]

Well said, you can pull up a lawn chair next to mine anytime.

C++ is the triumph of syntax over clarity

[xx_chris]

In my career, C++ has been my least favorite language. There's really nothing I like about it, save its introduction of // commenting. I hate looking at a page of C++ and not having any idea and knowing I can have any idea ever given that one page. I wouldn't recommend it for anything, for anyone, ever.

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

[flowsnake]

When the only hammer you have is C++, every problem looks like a thumb.

Well, there's another bullshit award, then.

[jcr]

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

-jcr

FTFY

[catmistake]

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

[Tablizer]

Re: "object-oriented computer science" -- Where is the "science"? Where are the theories, the metrics, and the independent repeats to verify?

Re:"Science"?

[50000BTU_barbecue]

Wait til you see the Political Science department!

Re:"Science"?

[Tablizer]

Do we want to stoop that low with language spin?

Re:"Science"?

[phantomfive]

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.

Re:"Science"?

[Tablizer]

I've found his arguments were often weak, had omitted counter-arguments, and often depended on what seemed like word-play to make a point such that if you don't subscribe to his personal labeling, you get a different answer.

Software design is a matter of weighing complex trade-offs. He cherry-picked which trade-offs he focused on such that it was too narrow an analysis in my opinion. (A more thorough trade-off analysis would be far more wordy and probably less conclusive and sell fewer books.)

Re:"Science"?

[Tablizer]

That's more of a model, not evidence of practical software improvement. And not everybody agrees with such models as "faithfully" representing OOP.

Re:"Science"?

[phantomfive]

A more thorough trade-off analysis would be far more wordy

More wordy?? Hey, you have to cut it off at around 1,200 pages. Printing presses can't handle much more!

Re:"Science"?

[Tablizer]

I mean the justification portions. Only a portion of the book is devoted to (alleged) justifications. If you want to pick a specific claim of his, we can go over it in detail. (Some of the criticisms are language-specific.)

Re:"Science"?

[phantomfive]

I was pointing out that actually there are theories metrics, and independent studies, which addressed your original comment. I wasn't claiming that you should like the book.

Re:"Science"?

[Tablizer]

What's a good example of a "useful" independent study cited in the book?

And some statements were outright false, such as claiming OOP sub-classing reduces code over switch/case statements (as I interpreted Meyer's claims). Although it's arguably language-dependent, my experiments suggest that switch/case statements are about the same amount of code. (C-style code has one of the most awkward switch/case statements out there.)

We've had some long and heated debates over switch/case statements versus sub-classing at the c2.com wiki. My own observation is that the net benefits depend on future change patterns of the code, which can vary widely per domain and project.

Re:"Science"?

[phantomfive]

The main advantage of subclassing over switch statements isn't the number of lines, it's that if you want to make a change in the future, you only have to change the decision point in one place, instead of once for every overridden function.

You can tell that subclassing is useful sometimes because people do it in C also, with structs filled with function pointers. It's just not useful to always force your code into a class hierarchy (and indeed, is counter-productive to attempt).

As for the 'useful' independent studies, I'll have to look again when I go home. But you didn't specify 'useful' in your original post. :)

Re:"Science"?

[phantomfive]

What's a good example of a "useful" independent study cited in the book?

Searching, the first example I cam across is on page 17 in my book.

Re:"Science"?

[Tablizer]

No, it depends on the type and frequency of the changes. Some change patterns favor case lists and some favor sub-classing (in terms of fewest lines/blocks/modules that need to be changed). I don't believe one is inherently more common than another. Selecting the "best" solution requires knowledge and experience about the domain, and/or a good "horse sense" of domain analysis.

Predicting the future is never easy.

There are some other complexities to consider, such as if a set-oriented variation-on-a-theme becomes more appropriate than a hierarchy for modeling variation, but that's a long topic.

Re:"Science"?

[phantomfive]

I think people really misunderstand Bertrand Meyer. His view of OOP is not the normal 'code reuse + do things automatically' pablum. The central point of his book, to him, the central point of OOP, is code contracts. How's that for a mind-warp?

Re:"Science"?

[Tablizer]

Do you mean % of software devoted to maintenance? % devoted to "changing data formats"? I know later in the book he claims OOP wraps data formats and therefore allegedly reduces the impact of those on code. But those later arguments are spurious in my opinion when compared to the alternatives. Adapters can be made in any paradigm. And reducing that 18% slice may increase other slices. Either way, those 2 slices are not measures of OOP improvements.

Re:"Science"?

[Tablizer]

Maybe what he really wants is logic programming, along Prolog's line.

Re:"Science"?

[Tablizer]

Let me clarify. It may be "software engineering science" to study reasons existing code bases need changes (written in varied languages and paradigms), but as given, it is not OOP-specific science. The /. intro says "object-oriented computer science". That study is not "object-oriented computer science" because it doesn't split it up by paradigm (OOP versus procedural versus functional, etc). To me "object-oriented computer science" is measuring OOP's impact.

I do not believe there are ANY field studies in Meyer's book that show OOP "being better". You are welcome to prove me wrong.

Re:"Science"?

[phantomfive]

I do not believe there are ANY field studies in Meyer's book that show OOP "being better". You are welcome to prove me wrong.

I don't think so either. Furthermore, they probably wouldn't be accepted generally as OOP, because his definition of OOP is different than most people's (Java and C# still don't have support for contracts).

However, such studies do exist. I particularly like that paper, because the authors made an effort to understand the data, instead of merely giving a P value and hoping it would get published. For example, when the data allowed several alternative explanations, they interviewed the developers and managers of the projects to understand which interpretation was most realistic.

THAT is object oriented computer science.

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

[K. S. Kyosuke]

There's probably a number of reasons, but the one explanation I like the most is Sussman's explanation in SICP regarding how object type systems relate to ontologies in knowledge systems: since we still have problems with the latter, it is logical we hit inadequacies and corner cases in the former, too.

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

[K. S. Kyosuke]

It couples polymorphism/dynamic dispatch to implementation sharing.

Well, in most languages with some OOP support.

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

[K. S. Kyosuke]

Where's Tablizer?

Here? :-)

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

[K. S. Kyosuke]

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.

Functional Awards?

[Tablizer]

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.

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

[disambiguated]

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

Object Oriented

[Murdoch5]

Because you don't understand how to use memory properly so lets make it the compilers problem :-)

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

[Bent Spoke]

Is this in the same vein as "Ppl who don't know General Relativity slamming the Speed Of Light"?

The big problem with C++ is that it's complexity makes it unknowable for the vast majority of the population.

On the plus side, it does make producing entries for Code Obfuscation contests rather easy! <smiley />

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

[david_thornley]

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:Ppl who don't know C++ slamming C++

[david_thornley]

In what way is late binding a matter of object orientation? I'd think it a feature in its own right.

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

[david_thornley]

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:Ppl who don't know C++ slamming C++

[K. S. Kyosuke]

...are you serious?

Re:What sort of prize?

[Tablizer]

To get it to pass, rename it JobCreator++

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

[rubycodez]

nonsense, you just think you were doing oo development. C structures with pointers to functions aren't really objects, sorry.

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

[rubycodez]

myArray = 4.dogs("lewis","bowser","spot","snoopy")
myArray.names.uppercase.sort!

Let's see your code, big guy, especially calling methods on your integer 4.
then your in-place modification of the array to uppercase and sorted by name