It is if a) you are not dealing with legacy code or 3rd party libs, and b) you are not trying to milk every last bit of performance (e.g. you're trying to port Rock Band to the PSP).
In my team, it was because many of the scientists writing the prototype code used for our back-end algorithms came from a Matalab and C++ background (while the developers of the UI came from a Java background) so to have have more common ground between developers and scientists for the production version of the algorithms, they were done in C++.
Much as I loves me some obscure template bobbins, I *suspect* now that performance is comparable, human factors like this are the only reason to pick C++ over Java/C#.
The theory is that runtime optimising bytecode interpreters can outperform almost all native fixed-form compiled code provided the programs run for long enough. Not that practice reflects that yet I don't think. But the theory is that long-running programs (especially e.g. J2EE server apps) could perform pretty damn well. See Yegge for details.
Personally I enjoy C++ coding more than Java and I don't think there's that much to pick between the two for ease of development. If I wanted real ease of development I'd go for something ... easier ... than Java, and more dynamic. Perhaps Clojure if I was fixated on the JDK for some reason, but probably Python.
I'm not sure who this Yegge is but I suspect I can see where you're going with this. With enough predictability of execution the program could be more-or-less stored in native form once run for a sufficient time through the L3 cache, branch prediction, etc.
Worth remembering though, PATA was far superior to SATA in theory because no-one accounted for the cross-talk interference that occurred at high speeds.
There are a lot of things that seem to make sense in theory but require that equipment works as well as it should in thoery (which it never does). The only other option I can think of is to native compile at runtime which would bring its own problems and defeat a lot of the purpose of using Java in the first place.
On the one hand Java (and C#) is very useful for RAD and deploying applications on a wide range of machines without difficulty or too many issues with compatibility as the underlying hardware and O/S is largely abtracted; even deploying on different PCs with the same release of Windows can be problematic but if the JRE (or .Net environment) runs on a computer your app probably will. Java is very good for business applications precisely because they do so little actual computation (99% of the time waiting for the user to either read or respond to information) that performance is a complete non-issue but fast development of a usable GUI, rapid deployment, availability and reliability are key
( ... )
Comments 33
Reply
Honestly though, it depends on what you wanna do...
Reply
Reply
(The comment has been removed)
Reply
Much as I loves me some obscure template bobbins, I *suspect* now that performance is comparable, human factors like this are the only reason to pick C++ over Java/C#.
Reply
Reply
Personally I enjoy C++ coding more than Java and I don't think there's that much to pick between the two for ease of development. If I wanted real ease of development I'd go for something ... easier ... than Java, and more dynamic. Perhaps Clojure if I was fixated on the JDK for some reason, but probably Python.
Reply
Worth remembering though, PATA was far superior to SATA in theory because no-one accounted for the cross-talk interference that occurred at high speeds.
There are a lot of things that seem to make sense in theory but require that equipment works as well as it should in thoery (which it never does). The only other option I can think of is to native compile at runtime which would bring its own problems and defeat a lot of the purpose of using Java in the first place.
Reply
Reply
Reply
Reply
Leave a comment