Slashdot Mirror
Bjarne Stroustrup Reveals All On C++
An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."
C++ is a woman?! I didn't see this coming.
Print Version of the same article http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1
http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1
It's always cool to see this kind of interview. It's even cooler when you can read it all on one page rather than 8.
I suggest that anyone who uses C++ or is interested in the history of programming read this. Some of it is a bit banal, like how they chose the name, but some of it is really intersting. RTFA for once, you lazy clods!
(C'mon KDE guys, it's funny. Laugh.)
My blog
what all good code-writers should think about when using the language he created."
Mostly, I try to meditate on being calm when writing C++ code, because the language is so full of infuriating and avoidable design problems.
I can't believe how small they made the content on these pages ... it's 1/4th of the page! The rest is 3/4 crap with a dash of navigation.
C++ is a language of a million gotchas. The moment I start having to think about implementation detail and I'm not writing an operating system or compiler, I know I'm using the wrong language.
in an 8 page interview? I feel like a sucker for buying the 900 page book
More music, fewer hits
... for an equally partisan view from another perspective, the C++ FAQ.
programs in C++ could be simultaneously elegant ... and efficient for systems programming... Obviously, not every program can be both and many are neither
Many are neither. Ain't that the truth.
Best Slashdot Co
Avoid it like the plague!
Some of you might remember the article at:
Facial Hair:Coding Success
Has Bjarne grown a beard or something? That's the only way I can explain that he's on the front page of slashdot today.
FTA they tried calling it C with Classes, but that didn't stick, so they asked for suggestions and got C++
I think they should have called it Class-C. Much more fun to pronounce.
On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's Computer magazine.
Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created.
By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, for the good of the industry, but, as with many of these things, there was a leak.
Here is a complete transcript of what was was said,unedited, and unrehearsed, so it isn't as neat as planned interviews.
You will find it interesting...
Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.
Interviewer: problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.
[NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - re
Computerworld is undertaking a series of investigations into the most widely-used programming languages. Previously we have spoken to Alfred v. Aho of AWK fame, S. Tucker Taft on the Ada 1995 and 2005 revisions, Microsoft about its server-side script engine ASP, and Chet Ramey about his experience maintaining Bash.
It's like having a series on car designers, where they're the teams responsible for the Renault 4, DeLorean, Trabant and NSU Ro 80 respectively.
Good find. I don't usually look on websites that bill themselves as "The Voice of IT Management"---the reason why I wear headphones---but apparently even ComputerWorld can rise above the morass of vapid "IT" bullshit once in a while.
Inaccurate. You forgot COBOL. But that's understandable, I want to forget it, too.
Extreme Programming - Redundant Array of Inexpensive Developers
I've used PHP/MYSQL to make some financial reporting web application which behaved very much like excel. I think it was still better than it would be in c++ (but in php it was about 1000 times slower, which I managed to get only 100 times slower after massive optimizations).
Extreme Programming - Redundant Array of Inexpensive Developers
The interview just seems like a very brief sampling of "The Design and Evolution of C++".
Even if you do not care much about C++, it's an excellent look into the philosophy and thought that goes into language design.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"Hello, C++, I'm your father"
Err, you mean like Managed C++?
What are you smoking?
Which means some PHB swallowed Microsoft's .NET sales lines, not that native code is in decline.
Think what you want, if that extends to the belief that kernels, device drivers or any serious (non-research) systems work is going to be deployed as memory managed JIT'd bytecode -- you're a fool. Performance optimizations are still inline ASM, put that in your "managed code" pipe and smoke it!
First, read the printable version of the article on one page. The original version is one paragraph per page, surrounded by ads and related dreck.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had two more decades of buffer overflow problems. This isn't a performance issue, by the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
The FQA. One of my favourite extended rants. I cant speak as to how accurate it is (never really have done much in C++), but there are many eye openers in there. (C++ grammar is undecideable-what?)
* No standardized pragmas
* Macros after-thought and not type safe
* No 24, and 32 bit (unicode) chars
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
* No distinction between typedefs and aliases
* Inconsistent left-to-right declarations
* Compilers still limited to ASCII source
* No binary constant prefix (even octal has one?!)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time
There is always, introduced with much fanfare, a new interview with Stroustrup where he says the same thing he said in the previous 15 interviews. As a professional developer I enjoy reading these types of things but I get frustrated at the same questions being asked over and over again. The was a very good read but fell into the normal Stroustrup interview cadence.
I did like the "sugar daddy" comment!!!And in fact, Cfront was a compiler, not just a preprocessor; it was just a compiler that compiled C++ into C.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
How well has your shop been able to port managed code to handheld devices? Sure, there's J2ME on cell phones, but more often, the buzzword "managed code" appears to refer specifically to Microsoft's .NET Framework (and compatible environments such as Mono).
Bjarne Stroustrup Reveals All On C++
You mean... He's been holding back?
If you do what you always did, you get what you always got.
I'm afraid that web site is one of those things that gets way too much attention in some on-line communities because of its controversial nature.
The reason the two sides are far from equally partisan is that Stroustrup freely admits there is another side to the debate and that C++ has its flaws, and he is making efforts to improve the situation. The FQA, on the other hand, just makes blanket statements like "For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective", which simply isn't true (and neither are many of the statements made in the FQA under those particular headings).
If you read the comments the guy who wrote the FQA makes on forums like reddit, as well as throughout the FQA itself, it's pretty obvious that unlike Stroustrup, he has little interest in any balanced discussion on the subject. He's just out to prove the other side wrong — where "wrong" often means "not agreeing with him" — and perhaps, the cynic in me suspects, to make a reputation for himself in the process.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
the (in)famous s l a s h d o t ?
No LANGUAGE WARS ?? So far an astoundingly decent discussion.
At least for me, Stroustrup's most interesting statement of the interview was
"My view of GC differs from that of many in that I see it as a last resort of resource management, not the first, and that I see it as one tool among many for system design rather than a fundamental tool for simplifying programming."
Exactly, and dead on. Ignoring the potential (and pointless) language wars, I just do not understand the Java focus on their GC weirdness, and am fascinated by Ruby's ability to turn GC on and off. Probably too late for Python to do this...
While I do not have fond memories of C++ from my school daze, I have more 'respect' for C++ than Java. To paraphrase Archimedes, give me ANSI C and Python and I can simulate the world.
There ARE managed versions of C++ available. However, they do have a few disadvantages relative to languages designed to be managed by default, instead of having this bolted on. As managed code becomes the prevailing paradigm, it is expected that this will create a disadvantage for C++ relative to other languages. However, there is a lot of inertia in language use - there are still people making a living doing Cobol programming, and similarly C++ will still be in use in 20 years, although it will continue to fade in importance over that time.
Producing managed code is *already* a much larger industry than unmanaged. Java & C# together dwarf C and C++ together. Imagining this trend will not continue is just wishful thinking. Unmanaged code is becoming a niche.
"The Design and Evolution of C++" by Stroustrup is a must-read if you are interested in why C++ is the way it is.
After reading it, I really hated C++. It's the classic example of a project that gets ruined by too many people working on it, all with their own goals, and the book tells you exactly why this happened. C++ now is a hideously complex monstrosity that is popular because it is all things to all people, not because it is a good language.
Anyway, if you disagree with me, have a look at the book. It is a testament to Stroustrup's objectivity that I came to the conclusion I did, and that you may come to the exact opposite conclusion as me after reading it.
You forgot COBOL.
You forgot Forth, a write-only language if there ever was one.
And I suppose your shop used to say "COM only", and now says "ugh, COM, who'd want to code those things up". You seem to have swallowed the Microsoft marketing man's sales spiel wholesale.
When you find out how slow some parts of .NET is (eg DB access), or how much memory it uses when you don't want it to, or how to find the object you expected to be GCd but hasn't been.. then you'll think about writing a chunk of your code in old C++.
MS did do a lot of work (pretty poor IMHO though) with C++/CLI to get some interop going between C++ and C#/VB. Poor because of the somewhat contrived bodges to the language they put in that they could have hidden behind the compiler, and also because there isn't any real interop with old unmanaged C++ except by wrapping it with a managed dll (or recompiling with the /clr flag set). Its also a poor implementation - eg STL/CLR is a lot slower than the .NET containers surprisingly.
25 years later there's still not a !@#^%^&$ single compiler that implements the entire language correctly. We're all waiting for Godot...
"Not an actor, but he plays one on TV."
So... Is it a prank after all?
http://www.dieblinkenlights.com
Disclaimer: I am not god.
We may not be created equal
But we can be treated equal.
Yes we are a windows only shop (oh noes, we've limited ourselves to 93% of the market!), but managed code can be created on non windows systems. We don't do that here, but it works fine.
You might argue any *particular* managed language won't be here in the future, but managed code will be the norm in a decade in *some* form. In fact, it's probably the norm right now.
Sure but this so called "managed code" is for user space apps where performance is not critical. Even Microsoft recommend that performance critical code is unmanaged (ie: native). What you're saying is disingenuous; by the same metric I could say that PHP and javascript are set to replace all other programming languages. And IMHO, scripting languages will wipe the floor with Java and C# well before native code becomes a niche. The underlying C ABI isn't going anywhere in the next decade, no matter what second-tier "managed coders" think.
(Do yourself a favor and read the note at the bottom of the page)
Exactly.
The performance issues are for the most part untrue - for 98% of all purposes, even games and other performance sensitive things, managed code can be as fast as unmanaged. By FAR the bigger factor is programmer skill, not whether the target is managed or unmanaged code. That's why unmanaged code is becoming a niche. There may always be a tiny sliver where it continues to be useful, but that is going to become a very small area over time. Again comparisons to Cobol come up: there are still Cobol jobs out there, but it's a very small area.
MS did do a lot of work (pretty poor IMHO though) with C++/CLI to get some interop going between C++ and C#/VB.
I think Herb Sutter did a pretty good job of explaining why they designed C++/CLI the way they did in this article on his website http://www.gotw.ca/publications/C++CLIRationale.pdf.
Except for some problems with boxing/unboxing(as in being a pain in the ass), I've not really ran into any problems using C++/CLI as a langauge on any of my projects. And unless your using the /clr:safe flag, linking with "OLD" C++ should not be problem, every thing else being equal.
And yes, while .NET can be slow, inconsistent and otherwise a piece of s**t, for somethings it's all there is, atleast without rewriting/creating alot of code.
BWP
The performance critical parts (DirectX) are native code with managed bindings. Not that you can't use JIT techniques to great effect in a rendering pipeline but the heavy lifting has to be done without memory management. Many games use scripting languages for the game logic, it's simply not a performance bottleneck.
But you already know all this ;)
If you're thinking along the lines of a bunch of #defines making C into proto-C++ then you're completely wrong.
The early compilers produced C as a sort of "assembly language" so that it could be used on many different targets (C was widely available).
But it you looked at the C it produced you'd have a hard time relating it to the original C++ source code.
No sig today...
Without examples your statement is completely vacuous.
No sig today...
Try writing some numerical code and see if operator overloading is useful.
No sig today...
Might have been a valid rant in about 1992 or so, but that's a long time ago.
C++ programmers will laugh at you for posting it, non-C++ people will be confused, so why bother?
No sig today...
>"there are a lot of C++ features I don't really
> understand."
That doesn't stop you spouting off on message boards though, does it?
Leave C++ opinions to people who understand it and use it every day.
>"It's all the damned constructors and destructors that get me. I want one way to make a new FOOMINATOR, one way to kill a FOOMINATOR, and maybe one way to copy a FOOMINATOR.""
Um, there*is* only one way for each (well, ok, you can overload the constructor but I fail to see how that's confusing).
Plus, if you learn what a smart pointer is then you can mostly forget about writing copiers and destructors - let the compiler do it for you.
No sig today...
The C++ FAQ says "arrays are evil" and I completely agree with that.
Use std::vector instead and all your memory management and buffer overflows will melt away.
"C++ is also the only language that has hiding ("abstraction") without memory safety"
C++ can have as much memory safety as you want, even more than Java if that's what floats your boat. The point is that C++ doesn't force you to have that overhead unless you want it.
eg. You can write a version of std::vector which always range-checks operator[], iterators, etc.
You should never use a raw C-style pointer to control a resource (Bjarne even says this in the article).
No stray pointers, no buffer overflows.... tell me again why C++ is "bad"....
No sig today...
What about using Maple to write the math, and then generating C code from that? better than hacking the language.
Oh, good lord, have you ever seen Maple (or Matlab) C output? it's horrendous. We used to integrate that stuff at work for a project I was on. Never again.
Anyone trying to defend C++ as a language should read this. And I speak as a programmer who has used C++ since cfront 1.0 was released to the world.
Useful, yes. Pragmatic, maybe. Design heavily rationalized ex post facto by its creator and its proponents, most certainly. But a well-designed programming language, it is not.
That is all.
1. no *optional* (I repeat: optional) garbage collection.
2. many syntax problems: not context-free grammar (great problem for tools), various semicolons that are reduntant etc.
3. no functional programming(no lambdas, etc).
4. shared_ptr sucks (just try to pass 'this' to a function that requires a shared ptr and deletes the current object).
5. no consistency: primitives are not classes, although I could program classes that behave as primitives.
6. no import statements; still using old boring header files.
7. many others, too numerous or small to mention.
C++ is built on some excellent ideas, it's just the execution of those ideas that sucks. There can be another C++ like language with none of the problems of C++ and all its benefits.
Is anyone else getting increasingly frustrated with these retarded web page layouts? The only reason this "in-depth" article is 8 pages is because the column width of ACTUAL CONTENT on the page is 280 pixels wide, out of 960 pixels (locked).
29% of the page is content, or less, if you count the stupid header ads and such. Eight pages, my ass.
DrPascal: Not the language, the mathematician.
Hex is close enough and less error-prone
When you're actually bitmasking, it's nice to see the bits rather than having to accumulate them in your head.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Is that example program on the first page some kind of weird joke?
Sorry, but I am uninterested in exploring a web site or language that includes this kind of shit:
"Note: all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars."
what the fuck does that even mean?
Course that point in the article is contentious. Adding garbage collection after the fact can yield a host of problems. And inevitably most applications in C++ that use dynamic memory allocation will need some sort of GC. Purists would argue you hide this in your constructor/destructor, or object manager classes... but it all adds up to complexity, and complexity is bad, because it means defects.
Languages that support GC, or have optional support, still allow programmers to write bad programs. I review so much bad Java code that bleeds objects - show me that the developer was never educated (in school or by fire) about the how and why GC works or doesn't.
To add this to C++0x (or any language) late in the game is silly, even if optional. Languages like Java, more specifically the VM behind them, have over 10 years of solid development and evolution. Most Java developers do not know that they can complete tune and/or replace GC strategies in the VM. I wouldn't call this wierdness, if that is what you refer to. It, in my opinion, has everything to do with knowing about how things work under the hood. Optimization in general seems to be a forgetten art.
And of course I'd never come to appreciate it in Java if I weren't a C++ programmer for 8 years prior where a lot of my time was wasted hunting down memory issues and/or reinventing GC as the application's problem (yay object reference counters, object managers, and other strategies that aren't directly related to problem domain.)
/\/\icro/\/\uncher
His answer was along the lines of: "Oh, I never use a debugger. If something's not working right I just think about it...maybe I'll add a printf once in a while if I need to check something."
Now you know why utterly un-debuggable features like templates went into the language...
Here is a real eye opener: Bjarne Stroustrup cited the JSF coding standard as an example of C++ usage: "Also, embedded systems programming is a major area of use and growth of C++; for example, the software for the next generation US fighter planes are in C++ (see the JSF++ coding rules on my home pages)." http://www.computerworld.com.au/index.php/id;408408016;pp;5;fp;16;fpid;1
I particular like the following statement in the JSF++ coding rules that the creator of C++ holds up as an example of how to use C++:
AV Rule 208 C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time.
About C: you think it is easier to manage memory with C char* and arrays than with C++ string,vector,and exceptions + resource-acquisition-is-initialization paradigms? I can only call that an outlandish claim! Hell even auto_ptr helps (I use it to express ownership transfers in function parameters and return values), and in C++0x they will finally have a real smart pointer standardized too. If you use raw arrays in C++ and get buffer overflows, don't blame stroustroup.
About garbage collected languages: true, memory management is not your problem anymore, which makes coding a bit easier (although there are other resources than memory which must still be managed manually). The problem is performance and, specifically, memory usage. My memory-leaking C++ implementation may well use half as much memory at any given time as your non-leaking GC code. Despite what people think, computers do not have over-abundant performance for all relevant tasks. I myself wrote 2 pieces of code in C++ just in the first months of this year where I knew from the start performance would be a problem. In one case because of the sheer size of the data I was handling, in the other because I knew the problem was NP-Complete. The first one would have simply page thrashed me to death in a GC environment.
The problem is that GC is viral, in the sense that if I link my non-GC code to a single library written to run in a GC environment, GC needs to be enabled for the entire program. This is the difficulty of adding GC as an optional feature to C++. Making it mandatory is not an option for performance reasons. In a GC environment you have little in the way of guarantees that memory will be freed right away, and this will occasionally come back to bite you hard when your application slows to a crawl as it runs out of memory. GC may be fine 98% of the time, the problem is if the language uses GC, you just can't turn it off locally where the memory usage is really hurting you.
Me too.
Simple solution - look for the print this link and read there.
If there is no print this link, then the article is not worth reading.
No stress.
Anyone who has tried to use .NET/C# for a TCP server with a few thousand clients over a GPRS cloud (frequent disconnect/reconnects) has my sympathies. .NET is not worth the hassle for scalability in some areas. Of course, since M$ is showing it down the throat of the next generation of CS students, the sheeple will go down the same path as that of C++
I on the other hand used about 10% of the features and had a wonderful time using a subset that probably was actually just "c with classes". I used c++ as a better c compiler with warnings turned up all the way. I found classes an elegant way of encapsulating code that dealt with hardware. Concrete classes were my favorite. My c++ programs were straightforward and easy to read. I am thankful that BS wrote the language. It was a lot of fun. I never really needed more than I learned in the first month. Strong type checking kept me out of trouble. I actually spent very little time subclassing and enjoyed the luxury of keeping my prime classes functional. Modeling hardware as c++ objects was the most fun I had in programming ever. When done right, the code was as compact and maintainable as any I have written in any other language. Unfortunately I got very little follow-on work because the functionality of my code was obvious. Vendors like Microsoft and Borland just couldn't wait to use polymorphism to create frameworks. I hated frameworks because they were these huge collections of c++ complexity that had to be studied endlessly, and about the time you knew enough, the vendor brought out a new version. MFC is a prime example of a piece of code I just couldn't get my head around. It seemed to me that the point of all the frameworks was to make hello.cpp in 100 lines or less, but anything non-trivial got huge quickly.
I suspect that there are other people out there that felt like I did about c++. At least I hope there are. Every time I encountered a project where the legacy code used every feature of c++, my spirits took a dump. C++ was a tool that consultants often used to make themselves indispensable. Some of the code I encountered, like the bio-rad application was a good thesis, but a lousy piece of intellectual property. Twenty levels of nested classes, heavily subclassed made for a long research project every time you needed to track down a bug.
The secret of c++ for me was knowing just how much to use to leverage off the power of it's object orientation. Encapsulation was good, Inheritance was ok sometimes. Multiple inheritance was almost never a good thing, and polymorphism usually lead to spaghetti code. IMHO
... should be hearsay. I noticed after submitting. My apologies to the grammar-nazis out there.
And what if there's nothing behind the door until it is being opened?
Sooo right.
I worked on a large-scale system a few years back and the performance was atrocious. Truly the directors were concerned the company would go bust if they couldn't sell the product, and the product was unsellable. A long story shortens to: it was MTS. We had out comms working through DCOM objects, only those objects were placed in MS Transaction Server, you know the nice green spinning globes. This made it easy to implement and MS told us it was the bee's knees.
Unfortunately, removing those objects and running the comms through plain DCOM made an astounding difference. (the other things we found were XML is slow as treacle, and context switches are bad).
Now, we find the same thing: MS wraps lower level technology with more and more "feature-added", "easy to use" stuff and forgets to tell us that its slower, sometimes dramatically so. What they do tell you deserves a marketing-person health warning.
So, I'm looking at WCF now. Its 'cool' apparently, but I find it to be more wrappers on top of the already slow ones. And you can't even connect a WCF tcp/ip socket to a non-WCF socket. (you want interop, you should use SOAP apparently, tcp/ip connections are 'optimised' for WCF-only apps).
I can see why you'd want to use it all, its easy (though maybe its me, its not much better that anything else), but on large-scale systems you should avoid .NET and for small-scale systems (where resources are a premium) again avoid .NET. For systems that you need to be resource-efficient (because you're going to run it in a VM alongside several others - popular in today's green world), you should avoid .NET too.
Hmm.. not much left really, when will the world realise this?
Have you ever sat down and worked on a C++ project? Here's what happens:
"First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module.
Try pulling that lot together, when you have a hundred or so modules. And as for data hiding. God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other. I think the word 'synergistic' was specially invented to twist the knife in a project manager's ribs."
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
I helped doing the database bulk importing routines of a PHP application. The catch is that every record needed some processing, so it was not really bulk.
I eventually wrote that part in C++, PHP would have taken days to do what C++ did in minutes. I used wxWidgets as a framework, and things like Unicode support (the source files where in UTF-8) were much easier in C++ than in PHP. Nevermind that a true hashtable was also much faster than a PHP associative array.
That said, I would never try to write that in plain C++. Too painful that way. Frameworks are the key to C++.
We are Turing O-Machines. The Oracle is out there.