I ge the screaming heebie-jeebies thinking about a technology that allows "the business" to implement the first thing that comes into their head.
I don't see that things would change *that* much from how they are now. When a CEO makes a decision on something, he will generally stick to it until completion (or take a job somewhere else), if for no other reason than he/she would lose credibility otherwise. All the important events about whether to go forward with a decision occur *before* the decision is made.
Now, that being the case, I think one of the reasons why businesses make bad decisions is that they have limited information, and the impact of their decisions have significant delays. You see people move up the ranks by making a splashy "initiative", and then they get promoted or take a higher paying job somewhere and some other sucker has to clean up the mess they left behind.
The first problem would almost certain be addressed by the same technologies that allow the business to be so flexible in the first place. The same technologies would allow you to quickly and accurately asses the impact and risks of a decision. This would provide "the business" with a far more rational basis to make a decision.
As to the other problem, I suspect the more responsive a business is to those changes, the faster the feedback. This would probably mean that idiots would have "career changes" sooner, and the rest would learn much more quickly how to make good decisions.
But I agree that the whole thing could have downsides. Rarely is technology anything but a double edged sword.
Well, snake oil only makes you think you are getting closer.;-)
Actually, even in what I described I made reference to what you call "snake oil" from various vendors. Nobody has a complete solution that would get you down to rolling out new widgets in hours, but you really can get stuff today that will get things down to 30 days. You can also get systems that will respond in seconds to specific changes (as opposed to the wide ranging changes envisioned in the AE ideal) in the business climate.
I'm not defending the HP sales pitch. I haven't said anything in support of their products (heck, the only product I mentioned was a Sun product). Arguably I'm defending the VP, and the reason I'm doing that is I hate seeing poor journalism mistaken for "hard hitting" journalism. The failure of the audience to distinguish between the two is killing the quality of news media in general.
The problem wasn't that the interviewer didn't know what AE was. The interviewer didn't understand the problem domain.
We're all techies, so were looking at this thing like it's some kind of technology, just like inteviewer did. We do this despite the fact that the VP specifically said it wasn't a technology. The VP actually very clearly defined what is meant by AE. It just turns out it isn't some kind of product you buy. They have a ton of products that can help with that, but there isn't a sound bite that can give an answer like that in the context of a 5 minute interview.
I'd suggest that it's terribly difficult and generally not wise, particularly in a hostile environment, to answer a fluff question with a non-fluff answer.
Okay, I'll be more specific: when I did consulting for various retail banking customers 10 years ago, I was involved in a 10 man years in a project that the bank hoped would allow their IT systems to add new mortgage and loan products within 6 months of product conception (without it being in the system, there was no way to actually provide the product). It actually didn't quite succeed in getting it down to 6 months, but it was close.
It is a bit much to judge me as shill given that you clearly have no background on the subject matter. It makes as much sense as me judging you as a troll based on two sentences.;-)
Nope... that was a good interviewer, since the questions weren't staged so the VP can answer more fluff.
Yeah, you know you are seeing an interviewer who's cutting through the fluff when the interviewer (as opposed to the interviewee) introduces terms like "special sauce" and "paradigm shift".;-)
I drew my comments entirely from the content in that interview. What's different was that I had a clue about the subject matter, unlike the interviewer. The interviewer's agenda appears mostly to be just to make the interviewee look bad, rather than to ask probing questions.
Questions like "Is outsourcing part of AE?" are a waste of time. The question that can't be answered with more fluff would be more along the lines of: "Can you give me an example of a customer you're working with on AE, and what the impact of AE has been on their business." If they question with something like, "well, we're just starting this", than you rephrase to "what the expected impact of AE will be on their business". If they answer the question with just a cost savings number, you follow up with, "yeah, but specifically how and what did (or will) it change in terms of the company's capabilities?"
Instead this "probing" interviewer essentially walked into a quagmire of industry jargon and semantics. The interviewer didn't seem to be listening to the answers to the questions. Heck, half a dozen questions after the exec pointed out that the difference was AE and HP was not linked to a particular technology, the interviewer is still thinking in terms of differentiation based on technology.
If you look at the questions, they are mostly the kind of open ended, broadly phrased questions that cannot be answered concretely. I think my favorite was "Do you feel the message is unclear and needs rethinking?";-)
Well, if I knew the answer to that I'd be out looking for venture capital. However, there are some obvious pieces of the puzzle needed in order to make that happen. Probably the biggest one is on the IT interface side of things. You'd need a way for the IT system to have business changes communicated to it very quickly and efficiently. This could be through an active interface, something that provides a really clear model of the business such that someone can just manipulate the model to describe the changes (before you think this is impossible, keep in mind that B-school folks do this already). Alternatively, it could be a passive interface that observes changes in the business and adapts to them. Maybe we'll just all have cybernetic implants.;-)
Jini and similar technologies show how you can do this in terms of the implementation side. You have a bunch of federated services that find each other in response to certain needs. They're completely distributed, so changes are immediately reflected across the whole network. So, this part of the equation could easily get to the point where changes effectively take place in milliseconds.
Then you have what is probably the slowest part of the equation: marketing and sales. It's just hard to come up with a new marketing pitch in an hour, so probably what you'll see more likely are things like learning machines hooked up to electronic advertising systems. So, when new products roll out, the learning machine would start making adjustments to what banner ads and search ads you place, and maybe when and where your TV commericals and product placements are made (yup, someday we'll have movies where the soda the star is drinking can dynamically change brands). You already see services out there which will constantly change your banner ads and search ads in order to optimize advertising impact.
Lots of problems with all this, I'm sure, but it's actually not too hard to see that these kinds of things will eventually happen. When it gets there, it'll already be second nature to us tech folks, but the business folks will still be getting used to the notion that they can place a search ad today and have sales within minutes.;-)
Ugh. I think this gets to the central point that people aren't getting here. AE isn't some proprietary technology that HP has. It's a vision of where your business could be, and HP thinks it has the best products and services to help you get there.
Given that this is at a high level, there aren't specific products and services out there that make one company better than the other in anything other than trivial ways (you'd laugh pretty hard if I said "Java" or "Itanium" or "HP-UX" wouldn't you?).
All that any company can bring to the table is a brand that you can trust, and HP probably feels pretty good about competing in that space.
No, the idea is that you don't have to build a whole new application. The idea is that your existing IT infrastructure adapts to the new product without needing a new application. Now, this is an idealized goal, and there are many cases where you can't do this, but it is something that can be done (indeed has been done) for many situations.
If Adaptive Enterprise was described as a strategy and technique for building better communication channels between business and IT within an organization to facilitate rapid rollout of reliable, rock-solid new applications at minimal cost and effort, then why didn't this moron just say so?
From the interview:
"The secret sauce that HP brings is the ability to link business processes--which obviously are a manifestation of a company's strategy--to IT gear. The big breakthrough is when those two things are synchronized, so changes in the business environment can dynamically trigger the IT changes necessary to support that business change."
Admittedly she didn't get in as many buzzwords as you did, but I think she actually did state that very clearly.
The slashdot article makes it sound pretty bad, and admittedly c|net doesn't make it look great (honestly I thought this was a case of a bad interviewer, not a good one). However, this is not really that bad.
AE is more just a term to associate with a different way of looking at the enterprise. While, it is not terribly different from what went on before, it is an evolutionary change. As the HP VP says, it's not a product or a technology, just a way of looking at using technology in an Enterprise.
I can tell you in the Enterprise space 10 years ago, folks used to get excited about being able to add new products to their IT systems within 6 months (I kid you not). The notion of AE is that it should be measured in days. I'm sure some day it'll be down to hours or even minutes.
Traditional Enterprise systems were increadibly static and rigid, and over time they are evolving to be much more dynamic and malleable. While this is nothing new to tech folks like us, it's a bit of a wake up call to the business folks who are just getting used to implications of how to mix business and IT based on how things were 5 years ago.
Again as the VP says, it's not that you can't work towards AE without HP. You can go to anybody for it. His claims about HP's uniqueness are another story (let's face it, all that can be unique when you're talking about providing expertise to execute on an abstract busines strategy is the brand name, and the trust/confidence associated with it).
So yeah, on one hand it is marketing BS, but on the other hand you need a marketing message in order to communicate to business folks how IT capabilities have evolved and how they can go beyond the existing set of limitations they have come to expect of IT.
It is not unusual for contigency deals to have clauses that deal with.... contingencies like the company being acquired. Usually, the idea is if the case is won in court, there is a huge payoff, and if they lose in court, ther eis a huge loss, and anything in between should at least cover their expenses. $50 million would probably leave them with a tidy profit, but depending on how long this case drags on for, perhaps not much.
All in all it really isn't that unusual, including the notion of a contingency lawyer taking on a seemingly hopless case.
Yeah, there is no question the technology is not simple. Would that it were so. Take a look at Nutch if you have any doubts, and keep in mind it's still like a decade behind the major search engines.
Yeah, as I said, they ran it with the various strict conformance flags, and for the code bits they pulled from the standards documents, they saw no improvement for g++ (VC++ demonstrated a measurable improvement). This is partially an indication of how the measurements were arbitrary. Of course, you have to wonder why compiler writers wouldn't focus on getting the examples in the language standard working first when doing their work.
It's not that they didn't know how to do it, it's that doing so in C++ is quite error prone, and they simply did not cover all their errors.
It's true that C++ provides you with constructs that make life a lot easier than C. The whole point of this discussion though is that unless you understand how to use those constructs, you'll frequently find C++ to be a far less effective tool that other alternatives.
It wasn't a library that really saved the Java project so much time. Indeed, because of performance considerations, the standard Java collection classes weren't used. No, the faster development time came from the fact that the C code had to deal with a lot of ownership and synchronization issues, much of which is quite error prone in C. Java's runtime simplifies these issues (and amazingly does it in a way that tends to be faster than what C can do without a LOT of work) such that you don't waste a lot of time on them.
The complexity doesn't just stem from having choices. It's from exposing problems to the programmer that they fundamentally don't understand yet. Dealing with templates in a world where you don't understand generic programming is going to do more harm than good. Dealing with exceptions in a world where you don't understand RAI. Dealing with multithreading in a world where you don't understand how the C++ memory model doesn't grok threads. I could go on.
I've interviewed "senior" programmers a fair bit, and I'm invariably struck by how many of them (basically all) can't do something as simple as a thread-safe getter/setter in C++, but even the more junior programmers can get it right in Java on the first try. These are the kind of mistakes that literally steal weeks of productivity.
Sure, you can simply not use all those features, as a lot of C++ programmers do, but the end result is a crippled language that has most of the disadvantages of Java, without any significant advantages over C or Java. This is exactly the scenario where C++ turns out to be a poor choice.
I think rather than hardware store metaphor, I'd suggest something along the lines of mountain climbing. Free climbing is the "cool" thing to do, and it has certain advantages over the "safer" approach, however the vast majority of folks out there shouldn't do it, as sooner or later it will do more harm than good.
Hmm... as I said before, these kinds of measurements are kind of arbitrary, so I'll concede that in general it is a subjective matter. My experience though is that VC++ rejects a lot more non-standards compliant code than g++, an observation that has been backed up by every test I've seen, including the current one in Dr. Doobs.
Dr. Dobbs did indeed just do a review of various compilers, by using the examples found in the language standard. If you check out the November 2003 issue, on pages 58 & 60 they have the results for the various compilers tested. You will find that VC++ 7.1 gets a 98.22 rating, while gcc 3.3 gets a 96.14. If you don't give VC++ any "strict conformance" flags, it drops to 96.59, which is pretty close to g++'s score, but still above it.
Now, that mechanism for measuring conformance is not particularly good, but then again neither are any of the others.;-) Certainly all of the "serious" compilers out there are getting close enough to standards compliance that the right kind of metric will show one of them to be the leader. My experience has mostly been from writing code in g++, trying to be portable, and then finding out that when I ported it to VC++ 7.1 it finds all these errors that are indeed illegal C++ constructs. YMMV.
I develop in both C++ and Java, and while I like both, it's pretty obvious to me that particularly for Junior and Intermediate level developers, Java development is significantly faster. Java's execution model also makes it much easier to design, implement and use frameworks and libraries. This in terms leads to faster development as well.
While for certain types of problems (for example anything requiring unsigned arithmetic), it's very difficult for Java to outperform C, in other cases I've seen computationally intensive Java code that was written in a few days get within 10-20% of the execution speed of C code that was written in a month (and this was prior to JDK 1.4). That level of performance difference, particularly with reduced development times (which give you more time to improve the efficiency of the overall design) makes Java a worthwhile candidate for a large chunk of the projects out there.
The sad truth is, a lot of C++ programmers are *not* at the skill level Bjarne is talking about. If even most C++ programmers were at that level, you'd suddenly find that C++ is a far better language to work with. Until programmers reach that level, it is a needlessly complex language which provides few useful advantages over it's competitors.
This specific thread was talking about syntactical issues, so "equivalance" was meant in that context.
In a lot of ways, for a lot of projects, developer time is really far more important than execution time (I say this working in an environment where that is not always true). So, sometimes people do focus on the development ease side of things.
Honestly though, assuming you're compiling to byte-codes in Java, a comparison with C++ is pointless. Even when you look at what a JIT produces, or a binary compiler, in a lot of ways the Java runtime is just so dramatically different than the C++ one that meaningful comparisons are difficult.
Measurements of compliance are difficult, but most of the attempts at measurement I've seen have shown that G++ has remained behind at least Comeau, Intel (previously KAI) for basically it's entire existence. Until g++ 3.x came out, g++ was pretty aweful for C++ stuff, such that most of the common Windows compilers (Microsoft, Borland, IBM) were well ahead of it, along with most of the Unix vendor's compilers. 3.x was definitely a huge step forward, but so were compilers released from the above vendors around the same time (with the exception of Borland). If g++ was leading the way, I'd suggest it was merely because g++ got it's release out ahead of the others.;-)
I cannot agree with your statement about VS.NET 2003 being "just about equal to it". By my own experiences, and by any assessment I've seen, VS.NET 2003 is actually head and shoulders ahead of g++ in terms of language compliance (g++ 3.4 may correct this).
I don't disagree that things are more confusing in JDK 1.2, but I'd argue they came from a need to be backwards compatible with JDK 1.1.;-)
Seriously, even the name for the class "Date" is wrong in my opinion, as Date does imply a Calendar context, and formatting rules. The fact that Calendar's getTime() (not getDate()) returns an object of type Date is just crazy.
These problems though are not related to the design decision. The fact that I could explain the design in one sentence is a pretty definitive example that the design itself is actually quite simple.
Slashdot Mirror
I ge the screaming heebie-jeebies thinking about a technology that allows "the business" to implement the first thing that comes into their head.
I don't see that things would change *that* much from how they are now. When a CEO makes a decision on something, he will generally stick to it until completion (or take a job somewhere else), if for no other reason than he/she would lose credibility otherwise. All the important events about whether to go forward with a decision occur *before* the decision is made.
Now, that being the case, I think one of the reasons why businesses make bad decisions is that they have limited information, and the impact of their decisions have significant delays. You see people move up the ranks by making a splashy "initiative", and then they get promoted or take a higher paying job somewhere and some other sucker has to clean up the mess they left behind.
The first problem would almost certain be addressed by the same technologies that allow the business to be so flexible in the first place. The same technologies would allow you to quickly and accurately asses the impact and risks of a decision. This would provide "the business" with a far more rational basis to make a decision.
As to the other problem, I suspect the more responsive a business is to those changes, the faster the feedback. This would probably mean that idiots would have "career changes" sooner, and the rest would learn much more quickly how to make good decisions.
But I agree that the whole thing could have downsides. Rarely is technology anything but a double edged sword.
Well, snake oil only makes you think you are getting closer. ;-)
Actually, even in what I described I made reference to what you call "snake oil" from various vendors. Nobody has a complete solution that would get you down to rolling out new widgets in hours, but you really can get stuff today that will get things down to 30 days. You can also get systems that will respond in seconds to specific
changes (as opposed to the wide ranging changes envisioned in the AE ideal) in the business climate.
I'm not defending the HP sales pitch. I haven't said anything in support of their products (heck, the only product I mentioned was a Sun product). Arguably I'm defending the VP, and the reason I'm doing that is I hate seeing poor journalism mistaken for "hard hitting" journalism. The failure of the audience to distinguish between the two is killing the quality of news media in general.
The problem wasn't that the interviewer didn't know what AE was. The interviewer didn't understand the problem domain.
We're all techies, so were looking at this thing like it's some kind of technology, just like inteviewer did. We do this despite the fact that the VP specifically said it wasn't a technology. The VP actually very clearly defined what is meant by AE. It just turns out it isn't some kind of product you buy. They have a ton of products that can help with that, but there isn't a sound bite that can give an answer like that in the context of a 5 minute interview.
I'd suggest that it's terribly difficult and generally not wise, particularly in a hostile environment, to answer a fluff question with a non-fluff answer.
Sigh. No, they invested 2.5 billion dollars in research and development of products to help make it happen.
While you may think that 2.5 billion is all you need to achieve a working AI, the history of the field suggests otherwise.
You misunderstand what I mean by new products. I'm not talking about new software. I'm talking about whatever widget/service the company sells.
Okay, I'll be more specific: when I did consulting for various retail banking customers 10 years ago, I was involved in a 10 man years in a project that the bank hoped would allow their IT systems to add new mortgage and loan products within 6 months of product conception (without it being in the system, there was no way to actually provide the product). It actually didn't quite succeed in getting it down to 6 months, but it was close.
;-)
It is a bit much to judge me as shill given that you clearly have no background on the subject matter. It makes as much sense as me judging you as a troll based on two sentences.
Nope... that was a good interviewer, since the questions weren't staged so the VP can answer more fluff.
;-)
;-)
Yeah, you know you are seeing an interviewer who's cutting through the fluff when the interviewer (as opposed to the interviewee) introduces terms like "special sauce" and "paradigm shift".
I drew my comments entirely from the content in that interview. What's different was that I had a clue about the subject matter, unlike the interviewer. The interviewer's agenda appears mostly to be just to make the interviewee look bad, rather than to ask probing questions.
Questions like "Is outsourcing part of AE?" are a waste of time. The question that can't be answered with more fluff would be more along the lines of: "Can you give me an example of a customer you're working with on AE, and what the impact of AE has been on their business." If they question with something like, "well, we're just starting this", than you rephrase to "what the expected impact of AE will be on their business". If they answer the question with just a cost savings number, you follow up with, "yeah, but specifically how and what did (or will) it change in terms of the company's capabilities?"
Instead this "probing" interviewer essentially walked into a quagmire of industry jargon and semantics. The interviewer didn't seem to be listening to the answers to the questions. Heck, half a dozen questions after the exec pointed out that the difference was AE and HP was not linked to a particular technology, the interviewer is still thinking in terms of differentiation based on technology.
If you look at the questions, they are mostly the kind of open ended, broadly phrased questions that cannot be answered concretely. I think my favorite was "Do you feel the message is unclear and needs rethinking?"
Um, not to be a jerk, but HOW?
;-)
;-)
Well, if I knew the answer to that I'd be out looking for venture capital. However, there are some obvious pieces of the puzzle needed in order to make that happen. Probably the biggest one is on the IT interface side of things. You'd need a way for the IT system to have business changes communicated to it very quickly and efficiently. This could be through an active interface, something that provides a really clear model of the business such that someone can just manipulate the model to describe the changes (before you think this is impossible, keep in mind that B-school folks do this already). Alternatively, it could be a passive interface that observes changes in the business and adapts to them. Maybe we'll just all have cybernetic implants.
Jini and similar technologies show how you can do this in terms of the implementation side. You have a bunch of federated services that find each other in response to certain needs. They're completely distributed, so changes are immediately reflected across the whole network. So, this part of the equation could easily get to the point where changes effectively take place in milliseconds.
Then you have what is probably the slowest part of the equation: marketing and sales. It's just hard to come up with a new marketing pitch in an hour, so probably what you'll see more likely are things like learning machines hooked up to electronic advertising systems. So, when new products roll out, the learning machine would start making adjustments to what banner ads and search ads you place, and maybe when and where your TV commericals and product placements are made (yup, someday we'll have movies where the soda the star is drinking can dynamically change brands). You already see services out there which will constantly change your banner ads and search ads in order to optimize advertising impact.
Lots of problems with all this, I'm sure, but it's actually not too hard to see that these kinds of things will eventually happen. When it gets there, it'll already be second nature to us tech folks, but the business folks will still be getting used to the notion that they can place a search ad today and have sales within minutes.
Ugh. I think this gets to the central point that people aren't getting here. AE isn't some proprietary technology that HP has. It's a vision of where your business could be, and HP thinks it has the best products and services to help you get there.
Given that this is at a high level, there aren't specific products and services out there that make one company better than the other in anything other than trivial ways (you'd laugh pretty hard if I said "Java" or "Itanium" or "HP-UX" wouldn't you?).
All that any company can bring to the table is a brand that you can trust, and HP probably feels pretty good about competing in that space.
Actually, "secret sauce" was introduced by the interviewer, not the interviewee. Just one of many examples of how the interviewer did a bad job.
No, the idea is that you don't have to build a whole new application. The idea is that your existing IT infrastructure adapts to the new product without needing a new application. Now, this is an idealized goal, and there are many cases where you can't do this, but it is something that can be done (indeed has been done) for many situations.
If Adaptive Enterprise was described as a strategy and technique for building better communication channels between business and IT within an organization to facilitate rapid rollout of reliable, rock-solid new applications at minimal cost and effort, then why didn't this moron just say so?
From the interview:
"The secret sauce that HP brings is the ability to link business processes--which obviously are a manifestation of a company's strategy--to IT gear. The big breakthrough is when those two things are synchronized, so changes in the business environment can dynamically trigger the IT changes necessary to support that business change."
Admittedly she didn't get in as many buzzwords as you did, but I think she actually did state that very clearly.
The slashdot article makes it sound pretty bad, and admittedly c|net doesn't make it look great (honestly I thought this was a case of a bad interviewer, not a good one). However, this is not really that bad.
AE is more just a term to associate with a different way of looking at the enterprise. While, it is not terribly different from what went on before, it is an evolutionary change. As the HP VP says, it's not a product or a technology, just a way of looking at using technology in an Enterprise.
I can tell you in the Enterprise space 10 years ago, folks used to get excited about being able to add new products to their IT systems within 6 months (I kid you not). The notion of AE is that it should be measured in days. I'm sure some day it'll be down to hours or even minutes.
Traditional Enterprise systems were increadibly static and rigid, and over time they are evolving to be much more dynamic and malleable. While this is nothing new to tech folks like us, it's a bit of a wake up call to the business folks who are just getting used to implications of how to mix business and IT based on how things were 5 years ago.
Again as the VP says, it's not that you can't work towards AE without HP. You can go to anybody for it. His claims about HP's uniqueness are another story (let's face it, all that can be unique when you're talking about providing expertise to execute on an abstract busines strategy is the brand name, and the trust/confidence associated with it).
So yeah, on one hand it is marketing BS, but on the other hand you need a marketing message in order to communicate to business folks how IT capabilities have evolved and how they can go beyond the existing set of limitations they have come to expect of IT.
Actually, it looks like it's even worse for the lawyers than I thought, as the CAP is $1 million plus 400,000 SCO shares.
It is not unusual for contigency deals to have clauses that deal with.... contingencies like the company being acquired. Usually, the idea is if the case is won in court, there is a huge payoff, and if they lose in court, ther eis a huge loss, and anything in between should at least cover their expenses. $50 million would probably leave them with a tidy profit, but depending on how long this case drags on for, perhaps not much.
All in all it really isn't that unusual, including the notion of a contingency lawyer taking on a seemingly hopless case.
Yeah, there is no question the technology is not simple. Would that it were so. Take a look at Nutch if you have any doubts, and keep in mind it's still like a decade behind the major search engines.
It's the only way to correct for the submitter's mistake.
Did DDJ run g++ with '-ansi -pedantic'?
Yeah, as I said, they ran it with the various strict conformance flags, and for the code bits they pulled from the standards documents, they saw no improvement for g++ (VC++ demonstrated a measurable improvement). This is partially an indication of how the measurements were arbitrary. Of course, you have to wonder why compiler writers wouldn't focus on getting the examples in the language standard working first when doing their work.
It's not that they didn't know how to do it, it's that doing so in C++ is quite error prone, and they simply did not cover all their errors.
It's true that C++ provides you with constructs that make life a lot easier than C. The whole point of this discussion though is that unless you understand how to use those constructs, you'll frequently find C++ to be a far less effective tool that other alternatives.
It wasn't a library that really saved the Java project so much time. Indeed, because of performance considerations, the standard Java collection classes weren't used. No, the faster development time came from the fact that the C code had to deal with a lot of ownership and synchronization issues, much of which is quite error prone in C. Java's runtime simplifies these issues (and amazingly does it in a way that tends to be faster than what C can do without a LOT of work) such that you don't waste a lot of time on them.
The complexity doesn't just stem from having choices. It's from exposing problems to the programmer that they fundamentally don't understand yet. Dealing with templates in a world where you don't understand generic programming is going to do more harm than good. Dealing with exceptions in a world where you don't understand RAI. Dealing with multithreading in a world where you don't understand how the C++ memory model doesn't grok threads. I could go on.
I've interviewed "senior" programmers a fair bit, and I'm invariably struck by how many of them (basically all) can't do something as simple as a thread-safe getter/setter in C++, but even the more junior programmers can get it right in Java on the first try. These are the kind of mistakes that literally steal weeks of productivity.
Sure, you can simply not use all those features, as a lot of C++ programmers do, but the end result is a crippled language that has most of the disadvantages of Java, without any significant advantages over C or Java. This is exactly the scenario where C++ turns out to be a poor choice.
I think rather than hardware store metaphor, I'd suggest something along the lines of mountain climbing. Free climbing is the "cool" thing to do, and it has certain advantages over the "safer" approach, however the vast majority of folks out there shouldn't do it, as sooner or later it will do more harm than good.
Hmm... as I said before, these kinds of measurements are kind of arbitrary, so I'll concede that in general it is a subjective matter. My experience though is that VC++ rejects a lot more non-standards compliant code than g++, an observation that has been backed up by every test I've seen, including the current one in Dr. Doobs.
;-) Certainly all of the "serious" compilers out there are getting close enough to standards compliance that the right kind of metric will show one of them to be the leader. My experience has mostly been from writing code in g++, trying to be portable, and then finding out that when I ported it to VC++ 7.1 it finds all these errors that are indeed illegal C++ constructs. YMMV.
Dr. Dobbs did indeed just do a review of various compilers, by using the examples found in the language standard. If you check out the November 2003 issue, on pages 58 & 60 they have the results for the various compilers tested. You will find that VC++ 7.1 gets a 98.22 rating, while gcc 3.3 gets a 96.14. If you don't give VC++ any "strict conformance" flags, it drops to 96.59, which is pretty close to g++'s score, but still above it.
Now, that mechanism for measuring conformance is not particularly good, but then again neither are any of the others.
I develop in both C++ and Java, and while I like both, it's pretty obvious to me that particularly for Junior and Intermediate level developers, Java development is significantly faster. Java's execution model also makes it much easier to design, implement and use frameworks and libraries. This in terms leads to faster development as well.
While for certain types of problems (for example anything requiring unsigned arithmetic), it's very difficult for Java to outperform C, in other cases I've seen computationally intensive Java code that was written in a few days get within 10-20% of the execution speed of C code that was written in a month (and this was prior to JDK 1.4). That level of performance difference, particularly with reduced development times (which give you more time to improve the efficiency of the overall design) makes Java a worthwhile candidate for a large chunk of the projects out there.
The sad truth is, a lot of C++ programmers are *not* at the skill level Bjarne is talking about. If even most C++ programmers were at that level, you'd suddenly find that C++ is a far better language to work with. Until programmers reach that level, it is a needlessly complex language which provides few useful advantages over it's competitors.
This specific thread was talking about syntactical issues, so "equivalance" was meant in that context.
In a lot of ways, for a lot of projects, developer time is really far more important than execution time (I say this working in an environment where that is not always true). So, sometimes people do focus on the development ease side of things.
Honestly though, assuming you're compiling to byte-codes in Java, a comparison with C++ is pointless. Even when you look at what a JIT produces, or a binary compiler, in a lot of ways the Java runtime is just so dramatically different than the C++ one that meaningful comparisons are difficult.
Measurements of compliance are difficult, but most of the attempts at measurement I've seen have shown that G++ has remained behind at least Comeau, Intel (previously KAI) for basically it's entire existence. Until g++ 3.x came out, g++ was pretty aweful for C++ stuff, such that most of the common Windows compilers (Microsoft, Borland, IBM) were well ahead of it, along with most of the Unix vendor's compilers. 3.x was definitely a huge step forward, but so were compilers released from the above vendors around the same time (with the exception of Borland). If g++ was leading the way, I'd suggest it was merely because g++ got it's release out ahead of the others. ;-)
I cannot agree with your statement about VS.NET 2003 being "just about equal to it". By my own experiences, and by any assessment I've seen, VS.NET 2003 is actually head and shoulders ahead of g++ in terms of language compliance (g++ 3.4 may correct this).
I don't disagree that things are more confusing in JDK 1.2, but I'd argue they came from a need to be backwards compatible with JDK 1.1. ;-)
Seriously, even the name for the class "Date" is wrong in my opinion, as Date does imply a Calendar context, and formatting rules. The fact that Calendar's getTime() (not getDate()) returns an object of type Date is just crazy.
These problems though are not related to the design decision. The fact that I could explain the design in one sentence is a pretty definitive example that the design itself is actually quite simple.