Then again, it could also cause some of the issues LISP macros can cause. Powerful language features aren't inherently bad things, but powerful language features in the hands of unskilled users are dangerous things, so it depends a lot on who you're trying to help.
Sorry, I took your post the wrong way. I find it's best to put a smiley when you mean one around these parts, or you just look like yet another troll, and get a suitably sarcastic reply (or ignored) accordingly...
OK, I'll start. I believe the following people have been acting suspiciously, and may represent a serious danger to our fundamental way of life here in the UK. I suggest that they be arrested and put on trial as soon as possible.
No one reads field manuals while under fire, so you can just drop that entire train of thought.
Now who shall I believe, a friend whom I know to be a medic and to have served in the military, or an AC on Slashdot? It's a toughie.
The version I heard was that the manual is written that way precisely because the medics are trained to read it and follow it, because otherwise they forget the simple things while under pressure.
And when I say "For Dummies" I really mean it, those field manuals are written for the lowest common denominator.
To be fair to the boys and girls in the field, I think military field manuals are often written for people who may need to read things in a hurry, while under pressure. (Being under fire will do that to you, I hear.) A medic friend who served in the military for a while sometimes noted the apparently simplicity of the army field medic's handbook, which says things like this on page 1:
Is the casualty conscious?
If no, leave him.
If yes, turn the page.
It's assumed that while under fire, you might forget the basic things, so they state everything, clearly and simply.
As a wise man once taught me: the only rights you truly have are those which you are willing to die defending; anything else is an illusion that can be taken from you.
And, as with much in life, you get what you pay for. I may command at least 3x the salary of a new grad programmer at the age of 28, but I bet my work produces at least 10x the benefit to my employer in the long run. I rather doubt I'm exceptional in this, either.
Most of the Really Good Developers I've worked with have been in their 40s. After all, they can read the same books on buzzwords I can, and they've also had 3x the experience in seeing through the hype, learning what works, and understanding common ideas that last longer than $FAD_OF_DAY.
I prefer the UK version of this one. Courtesy of the Guardian:
The law lords' judgment was so damning of the anti-terror legislation that one of the panel, Lord Hoffman, went as far as saying: "The real threat to the life of the nation, in the sense of people living in accordance with its traditional laws and political values, comes not from terrorism but from laws like these."
I agree wholeheartedly. My parents used tools known as enhanced youngster examiners to monitor my siblings' and my behaviour. These remarkable devices (also known as EYEs) allow the enforcement of all kinds of policies, not just those related to computer use, allowing the parent to ensure that their child's behaviour is appropriate at all times. Used regularly, they can even distinguish between time spent on the computer playing the latest MMORPG and time spent browsing educational web sites and learning new things, allowing the amount of computer time permitted to vary with the way the time is spent! Best of all these devices are available free to nearly all parents, and require very little ongoing maintenance. I highly recommend them!
You're right that we don't use the STL for some of these projects. Unfortunately, our code has to be portable to a lot of platforms, and some of the more obscure ones still haven't caught up with the standard when it comes to templates and exceptions, which basically means we can't use them and have to resort to the kind of arcane hackery that was common a decade ago. It sucks, but it goes with the territory for that kind of work.
Regarding the recent versions of VS, it's one of those love-it-or-hate-it things.
I'll ignore VC++ 7.0, which had more bugs than a David Attenborough documentary.
Version 7.1 wasn't too bad, but it removed the browse toolbar, which was one of the most useful features of version 6. Also, it wasn't backward-compatible with some of the useful plug-ins for version 6, so using things like WndTabs was out. Builds took significantly longer than under version 6, which matters a lot for projects that already take minutes or hours to make. These IDE issues were enough for most of my colleagues to decide it wasn't worth the upgrade. More seriously than the IDE issues, the machine code it produced for floating point calculations did strange things at times, and it had some pretty fundamental bugs in the optimiser. The latter is kinda show-stopping, unless you like spending several days wading through assembly language to spot the time it lost track of how many values were on the FPU stack 10 functions up the call stack!:o)
The 2005 version would be a lot better -- if it worked. On about half the machines in our office, it has show-stopping IDE performance bugs (as in, the whole application goes into a trance for minutes at a time while messing around with the Intellisense data it now updates in the background). We haven't pinned down exactly when this does and doesn't happen yet, but it's certainly not restricted to older machines with low amounts of RAM as some Internet forum posts have suggested. Again, this alone was enough to get half the office to stick with an older version, or uninstall and revert. Then there's the performance of the generated floating point code, which since the beta seems to have dropped by a very significant margin (we've been talking about this amongst our development groups and with other contacts, and slow downs of as much as 50% have been reported). There is obviously something seriously wrong with the FP code generation/optimisation, and this is a clear show-stopper if you write mathematical code. Then there's the fact that the much-vaunted Intellisense doesn't always work: in some ways, it's much nicer (for example, handling of macros -- which we use extensively because we can't use templates -- is much better) but then you load up the debugger, try to hop up the call stack from a breakpoint, and get silly messages about the code in the source file not matching the compiled code -- which it just built from that source file 10 seconds ago. Some of the browse info lost after version 6 has made a welcome return in 2005, but it's still not as useful as the simple-but-effective tools that were there before.
The jury here is out on 2005 at the moment. Right now, we have about 80% of staff who've tried it reverting to older versions. Given that the performance issues with both the IDE and the generated FP code are pretty severe and pretty obvious, and that by the MS dev team's own admission in some of their blogs the product was released before it was really ready, we're expecting some sort of service pack will appear early next year. If that fixes up the major issues, 2005 should be much better than version 6 was. Otherwise, since we really couldn't care less about.Net or intricate template support but we do need solid basic code optimisation and reliable floating point math, we'll relegate 2005 to a "build the code for customers who want it, otherwise ignore it" role, just as we did with the last two versions.
Thanks for the tip. I've just installed it, and it looks very impressive so far. I was starting to wonder if the only way to get a decent syntax-highlighting text editor that could handle several common programming languages was to use Eclipse and about 5GB of plug-ins, and I'm very pleased to find that it's not!:o)
The more toolmakers who drop plug-in support for Microsoft's windows only junk in favor of cross-platform targeted tools, the better.
That depends entirely on your point of view.
We write very portable C++ at work, but most of us use some version of Visual Studio as the IDE, because it's simply better than anything else available (even if it has been going backwards in several areas since they started going all.Netty, with the result that several of my colleagues have deliberately reverted to VC++ 6 from newer versions).
We also use a lot of Perl scripts, for which having a decent editor is handy. Ironically, I was thinking just the other day that it might be worth buying VisualPerl for those of us who write and maintain the scripts. Now it sounds like they're going to give it away for free anyway, which would no doubt be very useful to us.
So in our case, I have no problem with using software that only runs on a Microsoft platform. None of the stuff we write is Windows-only: both the C++ we develop and the scripts we use to support it run on many UNIX-based platforms as well. However, since I develop on a Windows box, using a Windows-based product, why would you want to stop me using something that fits in well with my development environment and helps me do my job?
Re:Why Java still isn't faster than C++
on
Java Is So 90s
·
· Score: 1
The thing about that sort of benchmark is that it's mostly a waste of time. The data structures and algorithms tested are usually so trivial that I'd expect any half-decent compiler, traditional or run-time, to produce almost identical machine code. If any don't, that's a pretty damning indictment. Keeping up with the field isn't any particular recommendation, though.
I'm afraid I just don't understand your arguments about Hotspot. I have suggested -- and thus far you haven't challenged my claim -- that even for precompiled code, it takes a lot of overhead in instrumentation to yield enough results even to get a modest performance boost. If you're saying that Hotspot runs in the background, and does less work in order to keep its own overheads down, I can't see how you expect it to produce better optimised code than a classical precompiled language. I'm not disagreeing that precompilation would be difficult with Java; I just don't see how Hotspot is doing any more than levelling the playing field at best, never mind overcoming all those inherent difficulties in Java that I mentioned.
The widespread use of Java in whatever industry you are is not likely to happen no matter what the performance, as areas of the IT industry are very conservative - for example, much game development is still in assembler, and COBOL is far from dead.
And yet we have customers writing applications in newer languages like C#, which address some of the performance criticisms of Java. (The code I write is for libraries, so our customers are typically developers of end-user applications.) Similarly, the games company down the road from me is asking for C++ as a primary skill on its recruitment advertising, but not assembler. If Java were truly on a par with C++ for performance and significantly more productive, I think at least someone in the industry would have attempted a switch by now. But it's not. You couldn't get near the performance that we get routinely in C++ using Java, because things like its floating point model and lack of precise control over data structures and memory allocation strategies simply won't allow it!
Web designers should design their pages to accomodate whatever font the user requires.
I honestly don't see why. Unless you're paying for it, it's up to the person providing the page to style it however they like. You can override that in your browser if you want to and know how to, but you have no right to bitch if you ignore the intent of the page designer and it looks bad. It may be bad business to present a page that doesn't play nicely with customisations, but (legalities regarding disability discrimination and such aside) that's their problem.
At the end of the day, no-one's forcing you to go back to a site whose design you don't like normally and/or after you've messed around overriding bits of it. However, most people won't override the defaults, so why should a designer go out of their way to support the few who do at the expense of the many who don't?
Someone should tell the design community that every user can't read every point size or font face well on their computer.
Ah, stylistic advice from someone who's just advocated using sans-serif for scanning but serif for extended reading on a computer monitor. How quaint.:-)
I would like a requirement that this law is repealed unless there is a significant increase in successful prosecutions of terrorists or at least one attack is foiled as a direct result of this legislation.
If it's any consolation, we whine about the government here, too. Most of us tried to vote them out last time, and only failed because of some convenient (for Tony) loopholes in our "democracy". We'll get them next time.
One day, the governments will learn that just because you can do something doesn't mean you should. They'll end up with so much noise, they just can't pick out the signal.
Western governments have failed to stop major terrorist attacks in the US, Spain, the UK and elsewhere, despite having later found numerous clues that might have tipped them off to some of these attacks. I'd say we're already at the point where the signal-to-noise ratio is beyond their ability to handle reliably.
The really interesting question, to which the true answer probably won't be revealed within our lifetimes, is how much they really do stop by getting the analysis of intercepted data right.
Another interesting question is how much damage is actually caused by the retention: how many innocent people are inconvenienced or have their privacy invaded unnecessarily?
I'd like to give governments credit for doing the right thing for the right reasons, but when you look at the few things we do know -- such as tens of thousands of arrests under anti-terrorism legislation since 9/11 but almost no convictions for terrorism-related offences -- it's hard to take anything they say (including claims to have foiled other attacks in London recently, for example) on faith alone.
Why Java still isn't faster than C++
on
Java Is So 90s
·
· Score: 2, Informative
They can routinely equal C++ in terms of performance.
Oh, man, do we have to do this again?
Java has theoretical limitations that mean it will always have difficulty keeping up with a well-optimised C++ program.
For a start, let's get over the Hotspot thing. It's an optimiser. C++ has had them for a year or two, now, I hear. If Hotspot had revolutionary new techniques, why haven't they been adopted en masse in the C++ world? Presumably you can cite patents or similar that would prevent this?
There is a theoretical possibility that a dynamically-optimised Java application could do better than something compiled with C++ on a given data set. However, recent advances like profile-guided optimisation in the C++ world suggest that data-based optimisation doesn't help that much.
Moreover, there are very significant overheads incurred in the monitoring and, if necessary, compilation and optimisation steps running in the background. A compiled C++ program instrumented for use with a profiler will typically run several times more slowly than the equivalent uninstrumented code, unless you're running on something like an Itanium that has handy hardware support for these things, and there's no silver bullet that allows a JVM to magically collect the equivalent data without overhead, nor to collect a much smaller set of data yet still optimise to the same extent based on it.
Right, now we've got the Hotspot stuff out of the way, let's do the inherent difficulties with GC. To release memory, sometime, somewhere, you have to update whatever tables you use to indicate what's allocated. That's it. Anything you can do with a flashy GC in Java, you can code up the same memory management algorithms in C++ if you really need it. In C++, you can also write more specialised alternatives for different data types, and of course many objects are simply allocated on the stack anyway. Java is just about catching up with the advantages of that one with techniques like escape analysis today, yet it's standard, chapter 1 fare in the C++ world.
And of course, there are still the same fundamental weaknesses in Java's design that there always have been...
Java doesn't have value types, so everything's dynamically allocated by default.
Not everything is an object, so you have boxing overheads even in simple things like containers unless you use generics.
Those generics have only just been introduced into the language, and are a poor imitation of C++ templates, offering few of the advantages that template metaprogramming has been providing to serious, high performance libraries in C++ for a few years now.
Java's floating point model is constrained by its portability requirements -- for a while it was even theoretically impossible for a JVM to meet them, IIRC -- which unavoidably prevents the use of many math optimisations.
I could go on, but I'm getting bored, so I'll leave the record straight enough and stop there.
One last thing: before you reply and tell me to do research rather than rant as you have with other posters, you should know that I write high-performance, highly portable code for a living, and I work with countless other people in the industry who do the same. If the Java evangelists were right, and Java really was rivalling the performance of C++ and easier/safer/more productive today, then it's strange that the entire industry I work in, with all its R&D, hasn't noticed.
Indeed even many of the "classics" fall under this umbrella. The Mythical Man Month, Peopleware, and Code Complete are fantastic books, and everyone and their brother lauds them, yet if you talk to people you discover that, overwhelmingly, they haven't actually read them
That's an interesting perspective. IME, a lot of people speak highly of these books in particular precisely because among all the good books out there, these are the ones many people actually have read. YMMV, of course.
Incidentally, I think the first edition of Code Complete was better than the second. The principles in the first were timeless, and every bit as applicable to OO code as to anything else. I felt that the second edition, for all its OO-friendliness and trendy language examples, lacked the depth of understanding based on real experience that made the first volume so good.
Even after several years in the business, I picked up plenty of helpful ideas from the original. I rarely found anything that actually contradicted my own experience.
In contrast, I found little extra value in the new edition. I strongly disagreed with some of the "conventional wisdom" it presented on things like OO and exceptions, and I found it telling that the suggestions I disagreed with were often presented without citing case studies and real world experience to justify the position the author recommends.
The original was a classic. The newer version is still worth a read, but IME most of its value is inherited, and it's more like Code Complete Lite (+ a big splash on the cover that says "Now with OO stuff!").
Because it's easier to read a book than a screen for extended periods.
Because you can have n books open on your desk without wasting monitor space.
Because books can have bookmarks, possibly with notes, inserted.
And by far the most important reason: because the quality of writing, consistency of editing, overall design, and presentation standards of decent books are all still years ahead of nearly all web-based pretenders to the throne. It's a rare web site indeed that features truly well thought out content, well presented and written in good style, uncluttered by ads and irrelevancies, that fits into a coherent overall plan. Sure, the web is faster and bigger, but neither of those is spelt b-e-t-t-e-r. Read books when you want quality, not quantity.
I guess I can start driving drunk, as I have never been in an accident while on the phone.
I've never been in an accident at all, but I've surely avoided several when other drivers made mistakes. A high proportion of those drivers appear to be chatting away as they drift across lanes/go through on red/fail to give way as directed/etc.
Slashdot Mirror
Then again, it could also cause some of the issues LISP macros can cause. Powerful language features aren't inherently bad things, but powerful language features in the hands of unskilled users are dangerous things, so it depends a lot on who you're trying to help.
Sorry, I took your post the wrong way. I find it's best to put a smiley when you mean one around these parts, or you just look like yet another troll, and get a suitably sarcastic reply (or ignored) accordingly...
And the other 29,950 people arrested?
Arrests under anti-terror legislation since 11 September 2001: 10,000s.
Convictions under anti-terror legislation since 11 September 2001: 10s.
Can anyone tell me what's wrong with this picture?
OK, I'll start. I believe the following people have been acting suspiciously, and may represent a serious danger to our fundamental way of life here in the UK. I suggest that they be arrested and put on trial as soon as possible.
Now who shall I believe, a friend whom I know to be a medic and to have served in the military, or an AC on Slashdot? It's a toughie.
The version I heard was that the manual is written that way precisely because the medics are trained to read it and follow it, because otherwise they forget the simple things while under pressure.
To be fair to the boys and girls in the field, I think military field manuals are often written for people who may need to read things in a hurry, while under pressure. (Being under fire will do that to you, I hear.) A medic friend who served in the military for a while sometimes noted the apparently simplicity of the army field medic's handbook, which says things like this on page 1:
It's assumed that while under fire, you might forget the basic things, so they state everything, clearly and simply.
Is it?
As a wise man once taught me: the only rights you truly have are those which you are willing to die defending; anything else is an illusion that can be taken from you.
And, as with much in life, you get what you pay for. I may command at least 3x the salary of a new grad programmer at the age of 28, but I bet my work produces at least 10x the benefit to my employer in the long run. I rather doubt I'm exceptional in this, either.
Most of the Really Good Developers I've worked with have been in their 40s. After all, they can read the same books on buzzwords I can, and they've also had 3x the experience in seeing through the hype, learning what works, and understanding common ideas that last longer than $FAD_OF_DAY.
I prefer the UK version of this one. Courtesy of the Guardian:
I agree wholeheartedly. My parents used tools known as enhanced youngster examiners to monitor my siblings' and my behaviour. These remarkable devices (also known as EYEs) allow the enforcement of all kinds of policies, not just those related to computer use, allowing the parent to ensure that their child's behaviour is appropriate at all times. Used regularly, they can even distinguish between time spent on the computer playing the latest MMORPG and time spent browsing educational web sites and learning new things, allowing the amount of computer time permitted to vary with the way the time is spent! Best of all these devices are available free to nearly all parents, and require very little ongoing maintenance. I highly recommend them!
You're right that we don't use the STL for some of these projects. Unfortunately, our code has to be portable to a lot of platforms, and some of the more obscure ones still haven't caught up with the standard when it comes to templates and exceptions, which basically means we can't use them and have to resort to the kind of arcane hackery that was common a decade ago. It sucks, but it goes with the territory for that kind of work.
Regarding the recent versions of VS, it's one of those love-it-or-hate-it things.
I'll ignore VC++ 7.0, which had more bugs than a David Attenborough documentary.
Version 7.1 wasn't too bad, but it removed the browse toolbar, which was one of the most useful features of version 6. Also, it wasn't backward-compatible with some of the useful plug-ins for version 6, so using things like WndTabs was out. Builds took significantly longer than under version 6, which matters a lot for projects that already take minutes or hours to make. These IDE issues were enough for most of my colleagues to decide it wasn't worth the upgrade. More seriously than the IDE issues, the machine code it produced for floating point calculations did strange things at times, and it had some pretty fundamental bugs in the optimiser. The latter is kinda show-stopping, unless you like spending several days wading through assembly language to spot the time it lost track of how many values were on the FPU stack 10 functions up the call stack! :o)
The 2005 version would be a lot better -- if it worked. On about half the machines in our office, it has show-stopping IDE performance bugs (as in, the whole application goes into a trance for minutes at a time while messing around with the Intellisense data it now updates in the background). We haven't pinned down exactly when this does and doesn't happen yet, but it's certainly not restricted to older machines with low amounts of RAM as some Internet forum posts have suggested. Again, this alone was enough to get half the office to stick with an older version, or uninstall and revert. Then there's the performance of the generated floating point code, which since the beta seems to have dropped by a very significant margin (we've been talking about this amongst our development groups and with other contacts, and slow downs of as much as 50% have been reported). There is obviously something seriously wrong with the FP code generation/optimisation, and this is a clear show-stopper if you write mathematical code. Then there's the fact that the much-vaunted Intellisense doesn't always work: in some ways, it's much nicer (for example, handling of macros -- which we use extensively because we can't use templates -- is much better) but then you load up the debugger, try to hop up the call stack from a breakpoint, and get silly messages about the code in the source file not matching the compiled code -- which it just built from that source file 10 seconds ago. Some of the browse info lost after version 6 has made a welcome return in 2005, but it's still not as useful as the simple-but-effective tools that were there before.
The jury here is out on 2005 at the moment. Right now, we have about 80% of staff who've tried it reverting to older versions. Given that the performance issues with both the IDE and the generated FP code are pretty severe and pretty obvious, and that by the MS dev team's own admission in some of their blogs the product was released before it was really ready, we're expecting some sort of service pack will appear early next year. If that fixes up the major issues, 2005 should be much better than version 6 was. Otherwise, since we really couldn't care less about .Net or intricate template support but we do need solid basic code optimisation and reliable floating point math, we'll relegate 2005 to a "build the code for customers who want it, otherwise ignore it" role, just as we did with the last two versions.
Thanks for the tip. I've just installed it, and it looks very impressive so far. I was starting to wonder if the only way to get a decent syntax-highlighting text editor that could handle several common programming languages was to use Eclipse and about 5GB of plug-ins, and I'm very pleased to find that it's not! :o)
That depends entirely on your point of view.
We write very portable C++ at work, but most of us use some version of Visual Studio as the IDE, because it's simply better than anything else available (even if it has been going backwards in several areas since they started going all .Netty, with the result that several of my colleagues have deliberately reverted to VC++ 6 from newer versions).
We also use a lot of Perl scripts, for which having a decent editor is handy. Ironically, I was thinking just the other day that it might be worth buying VisualPerl for those of us who write and maintain the scripts. Now it sounds like they're going to give it away for free anyway, which would no doubt be very useful to us.
So in our case, I have no problem with using software that only runs on a Microsoft platform. None of the stuff we write is Windows-only: both the C++ we develop and the scripts we use to support it run on many UNIX-based platforms as well. However, since I develop on a Windows box, using a Windows-based product, why would you want to stop me using something that fits in well with my development environment and helps me do my job?
The thing about that sort of benchmark is that it's mostly a waste of time. The data structures and algorithms tested are usually so trivial that I'd expect any half-decent compiler, traditional or run-time, to produce almost identical machine code. If any don't, that's a pretty damning indictment. Keeping up with the field isn't any particular recommendation, though.
I'm afraid I just don't understand your arguments about Hotspot. I have suggested -- and thus far you haven't challenged my claim -- that even for precompiled code, it takes a lot of overhead in instrumentation to yield enough results even to get a modest performance boost. If you're saying that Hotspot runs in the background, and does less work in order to keep its own overheads down, I can't see how you expect it to produce better optimised code than a classical precompiled language. I'm not disagreeing that precompilation would be difficult with Java; I just don't see how Hotspot is doing any more than levelling the playing field at best, never mind overcoming all those inherent difficulties in Java that I mentioned.
And yet we have customers writing applications in newer languages like C#, which address some of the performance criticisms of Java. (The code I write is for libraries, so our customers are typically developers of end-user applications.) Similarly, the games company down the road from me is asking for C++ as a primary skill on its recruitment advertising, but not assembler. If Java were truly on a par with C++ for performance and significantly more productive, I think at least someone in the industry would have attempted a switch by now. But it's not. You couldn't get near the performance that we get routinely in C++ using Java, because things like its floating point model and lack of precise control over data structures and memory allocation strategies simply won't allow it!
I honestly don't see why. Unless you're paying for it, it's up to the person providing the page to style it however they like. You can override that in your browser if you want to and know how to, but you have no right to bitch if you ignore the intent of the page designer and it looks bad. It may be bad business to present a page that doesn't play nicely with customisations, but (legalities regarding disability discrimination and such aside) that's their problem.
At the end of the day, no-one's forcing you to go back to a site whose design you don't like normally and/or after you've messed around overriding bits of it. However, most people won't override the defaults, so why should a designer go out of their way to support the few who do at the expense of the many who don't?
Ah, stylistic advice from someone who's just advocated using sans-serif for scanning but serif for extended reading on a computer monitor. How quaint. :-)
I would like a requirement that this law is repealed unless there is a significant increase in successful prosecutions of terrorists or at least one attack is foiled as a direct result of this legislation.
If it's any consolation, we whine about the government here, too. Most of us tried to vote them out last time, and only failed because of some convenient (for Tony) loopholes in our "democracy". We'll get them next time.
Western governments have failed to stop major terrorist attacks in the US, Spain, the UK and elsewhere, despite having later found numerous clues that might have tipped them off to some of these attacks. I'd say we're already at the point where the signal-to-noise ratio is beyond their ability to handle reliably.
The really interesting question, to which the true answer probably won't be revealed within our lifetimes, is how much they really do stop by getting the analysis of intercepted data right.
Another interesting question is how much damage is actually caused by the retention: how many innocent people are inconvenienced or have their privacy invaded unnecessarily?
I'd like to give governments credit for doing the right thing for the right reasons, but when you look at the few things we do know -- such as tens of thousands of arrests under anti-terrorism legislation since 9/11 but almost no convictions for terrorism-related offences -- it's hard to take anything they say (including claims to have foiled other attacks in London recently, for example) on faith alone.
Oh, man, do we have to do this again?
Java has theoretical limitations that mean it will always have difficulty keeping up with a well-optimised C++ program.
For a start, let's get over the Hotspot thing. It's an optimiser. C++ has had them for a year or two, now, I hear. If Hotspot had revolutionary new techniques, why haven't they been adopted en masse in the C++ world? Presumably you can cite patents or similar that would prevent this?
There is a theoretical possibility that a dynamically-optimised Java application could do better than something compiled with C++ on a given data set. However, recent advances like profile-guided optimisation in the C++ world suggest that data-based optimisation doesn't help that much.
Moreover, there are very significant overheads incurred in the monitoring and, if necessary, compilation and optimisation steps running in the background. A compiled C++ program instrumented for use with a profiler will typically run several times more slowly than the equivalent uninstrumented code, unless you're running on something like an Itanium that has handy hardware support for these things, and there's no silver bullet that allows a JVM to magically collect the equivalent data without overhead, nor to collect a much smaller set of data yet still optimise to the same extent based on it.
Right, now we've got the Hotspot stuff out of the way, let's do the inherent difficulties with GC. To release memory, sometime, somewhere, you have to update whatever tables you use to indicate what's allocated. That's it. Anything you can do with a flashy GC in Java, you can code up the same memory management algorithms in C++ if you really need it. In C++, you can also write more specialised alternatives for different data types, and of course many objects are simply allocated on the stack anyway. Java is just about catching up with the advantages of that one with techniques like escape analysis today, yet it's standard, chapter 1 fare in the C++ world.
And of course, there are still the same fundamental weaknesses in Java's design that there always have been...
Java doesn't have value types, so everything's dynamically allocated by default.
Not everything is an object, so you have boxing overheads even in simple things like containers unless you use generics.
Those generics have only just been introduced into the language, and are a poor imitation of C++ templates, offering few of the advantages that template metaprogramming has been providing to serious, high performance libraries in C++ for a few years now.
Java's floating point model is constrained by its portability requirements -- for a while it was even theoretically impossible for a JVM to meet them, IIRC -- which unavoidably prevents the use of many math optimisations.
I could go on, but I'm getting bored, so I'll leave the record straight enough and stop there.
One last thing: before you reply and tell me to do research rather than rant as you have with other posters, you should know that I write high-performance, highly portable code for a living, and I work with countless other people in the industry who do the same. If the Java evangelists were right, and Java really was rivalling the performance of C++ and easier/safer/more productive today, then it's strange that the entire industry I work in, with all its R&D, hasn't noticed.
In the vicinity of a level 14+ cleric?
That's an interesting perspective. IME, a lot of people speak highly of these books in particular precisely because among all the good books out there, these are the ones many people actually have read. YMMV, of course.
Incidentally, I think the first edition of Code Complete was better than the second. The principles in the first were timeless, and every bit as applicable to OO code as to anything else. I felt that the second edition, for all its OO-friendliness and trendy language examples, lacked the depth of understanding based on real experience that made the first volume so good.
Even after several years in the business, I picked up plenty of helpful ideas from the original. I rarely found anything that actually contradicted my own experience.
In contrast, I found little extra value in the new edition. I strongly disagreed with some of the "conventional wisdom" it presented on things like OO and exceptions, and I found it telling that the suggestions I disagreed with were often presented without citing case studies and real world experience to justify the position the author recommends.
The original was a classic. The newer version is still worth a read, but IME most of its value is inherited, and it's more like Code Complete Lite (+ a big splash on the cover that says "Now with OO stuff!").
I've never been in an accident at all, but I've surely avoided several when other drivers made mistakes. A high proportion of those drivers appear to be chatting away as they drift across lanes/go through on red/fail to give way as directed/etc.