Actually I did a decade of C++ followed by a decade of Java. I would never start a new project in C++ unless memory constraints were absolutely tiny - although for most embedded systems I've worked on these days even Java fits in nicely. Basically my consulting rate is so expensive that by using C++ and its longer development time I would be negligent in using it rather than the massively more productive Java (and its unparalleled tools like JVisualVM, that let you profile and optimize code that was not compiled for profiling and is running live in a production environment. Unfortunately I often come across people who believe C++ is 'l33t', which I find laughable. As I got more experience I realized that among the reasons C++ was worse than Java (and there are plenty) was the fact it was generally harder for the same functionality (which you seem to think makes you a 'real developer') which means slower development times and more expensive projects for the same features - this does not make good business sense for my customers, and they know it (in the Enterprise/government space few projects are started with C++ unless there is some very good reason for it - which there almost never is). I've been able to write systems from complex embedded ones to Internet-scale ones (as part of a large team), including doing it on my MacBook Pro or Linux and deploy to whatever the customer had (Win Server, Solaris, HP-UX, Linux) without porting issues. In short your (C++) "more powerful and complex language" could well from a lack of exposure to all the aspects of development *including the commerical and time-critical ones*. IMHO if you use C++ because you think it makes you l33t then to me you demonstrably are not (and regrettably you can't even grok why).
I can tell you that my 'managed code' has no memory leaks - despite being very heavily asynchronous and multi-threaded in many projects. Just because some developers suck doesn't mean the tech sucks. There is no substitute for competence.
Battery life? only on the desktop (sigh, are you one of the guys who think computers are the things the users see rather than the real computing which is invisible [embedded, and the hordes of servers that run the Interwebs and government]). Actually, it is development cost (not just developers but project management, testers, admins deploying, infrastructure monkeys, etc. all the folks who go into making something work) that matters. Without the dollars nothing gets built - irrespective of the tech. In many applications (although not all) tech that allows something 'good enough' to be built will be the winner (hence all the Visual Basic junk still out there running the companies). This is why Java (and to a lesser extent C#, by a factor of around 5:1) are used in far more new projects than C++. Arguably Java and the Java-esque C# (read the history sometime about the intermediate language 'Cool' from Java which came to be C#) are the better technology but even if they weren't their development speed is sufficiently higher that C++ will never displace them again from an overall market perspective.
Who cares how much code *you* have written - one person simply doesn't write enough code to make a difference on a huge project. It is when you are part of a two dozen developer team or larger that the sorting of the 'men from the boys' happens with technologies. In this case C++ is very hard to get right (when you program is multi-threaded and very non-deterministic with its resources).
I disagree (after using C++ for a decade and Java for another decade). Try writing any large multi-threaded, networked program in C++ and spend as much time on the configuration management as when doing the same in Java. Basically in C++ you can't, you spend time buggering around with your Makefiles and libraries (assuming you can use g++ everywhere, otherwise you have to also frig around with compiler options and the interpretation of C++ that each compiler has). C++ just ain't portable; ain't friendly when used in large teams/very large projects; ain't fast to compile; ain't fast to build large systems in. C++ does have advantages to Java in some respects (very low memory footprint, deterministic memory management for non-threaded programs etc), it just turns our portability is not one of them.
The real problem is C++ programmers who don't understand the need to clean up heap-allocated memory in an asynchronous multi-threaded environment (who 'owns' the memory is a problem that can break both RAII and if the developer forgets to use a smart pointer somewhere [or uses a library that didn't use one] then you'll have problems - with garbage collection it is less of an issue and new garbage collectors like G1 are very efficient compared to the old days).
What a crock of shit. It is far easier to follow than to lead. If the Chinese are so damn smart why didn't they invent the tech themselves? You're one of those fawning folk who who write as if the US can do no write and China can do no wrong. What you are unaware of is the facts in the following article: http://www.heritage.org/research/reports/2010/01/10-china-myths-for-the-new-decade It is good that China is growing an improving, hopefully that'll lead to an improvement in the standard of living and freedoms of its people. If not, then China will never be 'advanced' irrespective of how stealthy its jet fighter copies are. So please stop kowtowing to anyone with your posts (you take the scaremongering news [and Chinese propaganda] at face value instead of delving into the facts) and realise the current situation is like everything else, it too will change in time (even now countries like India, Vietnam and Brazil are starting to out-compete China based on wages).
Thanks for taking the time to elaborate. One question I would have is if your clients are actually sampling data at 500 microseconds per point? Otherwise, why don't they send deltas since their last update (perhaps this is happening). What I'm trying to determine is if the architecture has them sending the same information again and again and again. Would it be possible to exploit the timestamp information in the data to reduce the requirements to store everything. Do you need to update the data set once a second. Otherwise you could load a dataset, do the update, dump the data and continue. Each operation would be slower than how you are doing it now, but you spread it over more machines. You would reduce the power of the machines until you reached the price/performance minima - it would also give you a lot more redundancy - this is the strategy Google appear to use. Also, using a 'smart' pointer or garbage collected object per data point is madness (I made the same mistake 15 years ago when Java came out and I was doing a lot of astrophysics calculations. Once I re-organized my data structures I found that the memory requirements for properly thought about structures did not scale badly as the size of the data increased [except in the very small scale end]). Surely you'd have a class per data set, which reduces your memory overhead by three orders of magnitude which allows you to use a newer programming language which increases your productivity by close to an order of magnitude as your codebase gets near the million line mark. If you use a class to represent each data set with a 64-bit reference plus some 64-bit references to hold each array of the data you are using (one for each database column, and use native types for the array elements where you can) you might use half a dozen references for a total of 48 bytes per in-memory dataset. That means you'll use 5000 * 48 bytes in garbage collected references for your in-memory data (ignoring my suggestion of using more machines). That's around 250 kilobytes of memory to get garbage collection, nice multithreading and synchronization support, the ability to use JVisualVM (which is just a fantastic tool for connecting to any running Java process to see where the memory and CPU is used - just like any profiler - except you don't have to compile anything different or start the program in a profiling mode, you just attach to it). Anyway, sounds like you could organize your datasets to be a lot better organized so that the garbage-collected references were totally negligible compared to your in-process data. Lots of people (including me) have processed much huge datasets using 'managed' languages, but you have to spend some time thinking of optimising in space in time rather than the brute force direct path that C++ coders often take (and since C++ can be used in this way it is an advantage, but you will always end up running out of resources at some point, using C++ just delays it a little in some cases). Good luck.
Regarding the destructors, the problem is when you have several threads accessing memory allocated on the heap. Which thread gets to delete it and when? Then you end up reference counting and doing garbage collection - or allocating everything on the stack. This is problematic when your stack frame goes away. Either that or if you have long-lived objects that you have to try and clean up yourself if you want to release memory before program completion, but then as you program grows you find it hard to manage, so you starting writing yourself a framework to do it for you and end up re-writing a budget version of the Java/C# garbage collection and memory management strategies (which is now very good in Java's case with the G1 'garbage first' collector). With regard to Boost threading, it'll work for sure, but it'll never be as easy or as elegant as a language that was designed with synchronization in mind from the beginning. Even if the source code is cross-platform (although in C++ there are always niggles) the compile and build environment often is not. You can save yourself the hassle by choosing something like Java and spend more time fixing your domain problems instead of implementation problems. Like I said, after doing C++ for a decade and then moving to Java for the past decade (occasionally still doing C and C++ where I had to for native integration or embedded stuff) there's no way I'm personally going back. I'm just trying to impart some of my experience and save people the hassle of a decade of dealing with C++, when really they probably want to be solving problems instead.
Yes. It is awful macro madness at its worst. It's also not particularly natural from an object-oriented point-of-view either. In short, I'd much rather use Swing or Google Web Toolkit than QT.
Good points. I'd like to add that the best (and probably only) way to end up with with an actual defect-free (or fairly close to it) program is a proper testing strategy (eg. automated unit and integration testing).
HFT is a miniscule drop in the ocean. C++ is sluggish compared to assembler, but that doesn't make assembler a better purpose *general* solution language. Again, you're taking the snobby argument that because C++ is good for your tiny niche that it follows that it is better for all applications and then you proceed to rag on C# guys as if they all sucked. Personally, I'm no C# fan, but I'm not stupid enough to think C++ is better for the general scope of applications. Plus, you ignore the fact that in many cases JIT languages are actually faster than C++, due to runtime optimizations not possible to correctly predict at compile time, and the fact that the simpler languages (viz C++) allows some optimizations that cannot be made otherwise (which is why FORTRAN is still so damn fast).
C++ is useful for some tasks. However to make it work with the new multi-core CPU architectures is a total PITA. Not only do you have to choose a non-standardized threading implementation you also get a lot of headaches as to which thread owns which object (since you don't want to clean up too early or too late). That's one of the reasons Java and C# are so popular and even people with a huge amount of C++ time (like me) will never use C++ as our first choice again. Basically for whatever small percentage of extra speed you get with C++ on *one* core is totally lost when Java/C# uses multiple cores. Even if you make C++ multi-threaded and garbage collected it requires a much larger development time to get what Java/C# has built in. Even worse than the multi-core issues with C++ is the fact that it is generally not multi-platform (at least for non-trivial programs using graphics, networking sound etc) due to the platform dependencies of the libraries. These days the computing environment is becoming more heterogenous, not less. Aside from the supposed bragging rights of C++ programmers (feel they are somehow superior by using it, but fail to realize the more experienced you are the more you wanna get things done in the easiest way, not the hardest/l33t-est way) there is not much to recommend C++ apart from the memory footprint (and only a few people work on systems that are *that* memory constrained these days, most single-board-units have *huge* quantities of memory, eg. 512 MB compared to the old days).
Yes, there are alternatives for the language implementation, but check the libraries out. With.NET you are locked into the libraries (unless you can afford to re-write your app in exotic [for Windows] Gnome technologies). Actually I found Java's JNA easier than.NET in working with system libraries, no matter what platform. Shame you don't know about it.
You are talking about desktop apps as if that was the only programs out there. Many apps have moved to the Web, and a very large number of them are built in Java. Just because you can't see Java (because you have your eyes closed) doesn't mean you don't use it whenever you use the Web (same thing with Linux, which handles almost all the external-going mail you'll ever send, but this is also invisible to you because it works so damn well).
Actually a Russian company called 1C rebuilt their product IL-2 Sturmovik (written years ago in Java with some C++, and runs extremely well) into C#.NET (and now it runs like a total dog, although it looks great). A real shame about the performance since the game is otherwise quite nice.
You do know that there a siginificant.NET API that don't run in Mono and never will. Suggest you actually read the Mono compatibility page some time..NET is not cross-platform and was not designed to be (the languages mean nothing, it is the *libraries* that must run everywhere).
Ah, you you're only doing the desktop or small-to-medium enterprise then. Big enterprise (where there is a *lot* of money) has all sorts of environments that you don't get to chose. That's why Java still gets a lot more work than.NET (according to various indexes, eg. Tiobe). You post is typical from a developer used to working in the relatively limited desktop space. We see that kind of post all the time on Slashdot. Shame you guys are oblivious to all the environments (embedded and huge enterprise) away from your limited experience.
Actually we're smart enough to avoid Weblogic. There is more than one way to skin a cat, and we never take contracts that require use of such crappy tech - doing so is not good business.
Three things you have not mentioned in your reply:
1) No matter what technology you use, someone will hold a patent to it. Java is not exceptional in this regard
2) You assume all patents are valid, this is patently untrue (pun untended). Most patents are actually worthless and it is easy to find prior-art for many of them (eg. most of Oracle's patent claims against Google are worthless and have already been dismissed)
3) In the scenario you mention, where you re-invent a technology, well even if you do and someone notices it would be easy to change your re-invention to the standard implementation and thereby comply (in this case, with the Java patent licensing terms put into the JDK license). What you don't have a license to do is create something different and call it 'Java'. But if what you did was different then the patent wouldn't cover it, would it now?
I don't mean to insult your technical skills. However, I would suggest you do a little more research into recent patent cases before making, "the sky is falling" statements about Java on Slashdot. Good luck for your research:)
Slashdot Mirror
Your point is correct. Also note that mixing managed and unmanaged code in C++.NET is awkward to say the least (I've had to do it on occasion).
Actually I did a decade of C++ followed by a decade of Java. I would never start a new project in C++ unless memory constraints were absolutely tiny - although for most embedded systems I've worked on these days even Java fits in nicely. Basically my consulting rate is so expensive that by using C++ and its longer development time I would be negligent in using it rather than the massively more productive Java (and its unparalleled tools like JVisualVM, that let you profile and optimize code that was not compiled for profiling and is running live in a production environment. Unfortunately I often come across people who believe C++ is 'l33t', which I find laughable. As I got more experience I realized that among the reasons C++ was worse than Java (and there are plenty) was the fact it was generally harder for the same functionality (which you seem to think makes you a 'real developer') which means slower development times and more expensive projects for the same features - this does not make good business sense for my customers, and they know it (in the Enterprise/government space few projects are started with C++ unless there is some very good reason for it - which there almost never is). I've been able to write systems from complex embedded ones to Internet-scale ones (as part of a large team), including doing it on my MacBook Pro or Linux and deploy to whatever the customer had (Win Server, Solaris, HP-UX, Linux) without porting issues. In short your (C++) "more powerful and complex language" could well from a lack of exposure to all the aspects of development *including the commerical and time-critical ones*. IMHO if you use C++ because you think it makes you l33t then to me you demonstrably are not (and regrettably you can't even grok why).
I can tell you that my 'managed code' has no memory leaks - despite being very heavily asynchronous and multi-threaded in many projects. Just because some developers suck doesn't mean the tech sucks. There is no substitute for competence.
Battery life? only on the desktop (sigh, are you one of the guys who think computers are the things the users see rather than the real computing which is invisible [embedded, and the hordes of servers that run the Interwebs and government]). Actually, it is development cost (not just developers but project management, testers, admins deploying, infrastructure monkeys, etc. all the folks who go into making something work) that matters. Without the dollars nothing gets built - irrespective of the tech. In many applications (although not all) tech that allows something 'good enough' to be built will be the winner (hence all the Visual Basic junk still out there running the companies). This is why Java (and to a lesser extent C#, by a factor of around 5:1) are used in far more new projects than C++. Arguably Java and the Java-esque C# (read the history sometime about the intermediate language 'Cool' from Java which came to be C#) are the better technology but even if they weren't their development speed is sufficiently higher that C++ will never displace them again from an overall market perspective.
Who cares how much code *you* have written - one person simply doesn't write enough code to make a difference on a huge project. It is when you are part of a two dozen developer team or larger that the sorting of the 'men from the boys' happens with technologies. In this case C++ is very hard to get right (when you program is multi-threaded and very non-deterministic with its resources).
I disagree (after using C++ for a decade and Java for another decade). Try writing any large multi-threaded, networked program in C++ and spend as much time on the configuration management as when doing the same in Java. Basically in C++ you can't, you spend time buggering around with your Makefiles and libraries (assuming you can use g++ everywhere, otherwise you have to also frig around with compiler options and the interpretation of C++ that each compiler has). C++ just ain't portable; ain't friendly when used in large teams/very large projects; ain't fast to compile; ain't fast to build large systems in. C++ does have advantages to Java in some respects (very low memory footprint, deterministic memory management for non-threaded programs etc), it just turns our portability is not one of them.
Pink Unicorns don't exist, but the Flying Spaghetti Monster touches us (not the bad touching!) with his noodly appendage: [cite] http://en.wikipedia.org/wiki/Flying_Spaghetti_Monster
The real problem is C++ programmers who don't understand the need to clean up heap-allocated memory in an asynchronous multi-threaded environment (who 'owns' the memory is a problem that can break both RAII and if the developer forgets to use a smart pointer somewhere [or uses a library that didn't use one] then you'll have problems - with garbage collection it is less of an issue and new garbage collectors like G1 are very efficient compared to the old days).
What a crock of shit. It is far easier to follow than to lead. If the Chinese are so damn smart why didn't they invent the tech themselves? You're one of those fawning folk who who write as if the US can do no write and China can do no wrong. What you are unaware of is the facts in the following article: http://www.heritage.org/research/reports/2010/01/10-china-myths-for-the-new-decade
It is good that China is growing an improving, hopefully that'll lead to an improvement in the standard of living and freedoms of its people. If not, then China will never be 'advanced' irrespective of how stealthy its jet fighter copies are. So please stop kowtowing to anyone with your posts (you take the scaremongering news [and Chinese propaganda] at face value instead of delving into the facts) and realise the current situation is like everything else, it too will change in time (even now countries like India, Vietnam and Brazil are starting to out-compete China based on wages).
Thanks for taking the time to elaborate. One question I would have is if your clients are actually sampling data at 500 microseconds per point? Otherwise, why don't they send deltas since their last update (perhaps this is happening). What I'm trying to determine is if the architecture has them sending the same information again and again and again. Would it be possible to exploit the timestamp information in the data to reduce the requirements to store everything. Do you need to update the data set once a second. Otherwise you could load a dataset, do the update, dump the data and continue. Each operation would be slower than how you are doing it now, but you spread it over more machines. You would reduce the power of the machines until you reached the price/performance minima - it would also give you a lot more redundancy - this is the strategy Google appear to use. Also, using a 'smart' pointer or garbage collected object per data point is madness (I made the same mistake 15 years ago when Java came out and I was doing a lot of astrophysics calculations. Once I re-organized my data structures I found that the memory requirements for properly thought about structures did not scale badly as the size of the data increased [except in the very small scale end]). Surely you'd have a class per data set, which reduces your memory overhead by three orders of magnitude which allows you to use a newer programming language which increases your productivity by close to an order of magnitude as your codebase gets near the million line mark. If you use a class to represent each data set with a 64-bit reference plus some 64-bit references to hold each array of the data you are using (one for each database column, and use native types for the array elements where you can) you might use half a dozen references for a total of 48 bytes per in-memory dataset. That means you'll use 5000 * 48 bytes in garbage collected references for your in-memory data (ignoring my suggestion of using more machines). That's around 250 kilobytes of memory to get garbage collection, nice multithreading and synchronization support, the ability to use JVisualVM (which is just a fantastic tool for connecting to any running Java process to see where the memory and CPU is used - just like any profiler - except you don't have to compile anything different or start the program in a profiling mode, you just attach to it). Anyway, sounds like you could organize your datasets to be a lot better organized so that the garbage-collected references were totally negligible compared to your in-process data. Lots of people (including me) have processed much huge datasets using 'managed' languages, but you have to spend some time thinking of optimising in space in time rather than the brute force direct path that C++ coders often take (and since C++ can be used in this way it is an advantage, but you will always end up running out of resources at some point, using C++ just delays it a little in some cases). Good luck.
Regarding the destructors, the problem is when you have several threads accessing memory allocated on the heap. Which thread gets to delete it and when? Then you end up reference counting and doing garbage collection - or allocating everything on the stack. This is problematic when your stack frame goes away. Either that or if you have long-lived objects that you have to try and clean up yourself if you want to release memory before program completion, but then as you program grows you find it hard to manage, so you starting writing yourself a framework to do it for you and end up re-writing a budget version of the Java/C# garbage collection and memory management strategies (which is now very good in Java's case with the G1 'garbage first' collector). With regard to Boost threading, it'll work for sure, but it'll never be as easy or as elegant as a language that was designed with synchronization in mind from the beginning. Even if the source code is cross-platform (although in C++ there are always niggles) the compile and build environment often is not. You can save yourself the hassle by choosing something like Java and spend more time fixing your domain problems instead of implementation problems. Like I said, after doing C++ for a decade and then moving to Java for the past decade (occasionally still doing C and C++ where I had to for native integration or embedded stuff) there's no way I'm personally going back. I'm just trying to impart some of my experience and save people the hassle of a decade of dealing with C++, when really they probably want to be solving problems instead.
Yes. It is awful macro madness at its worst. It's also not particularly natural from an object-oriented point-of-view either. In short, I'd much rather use Swing or Google Web Toolkit than QT.
Why generate temporary objects in the millions? drawing from an (garbage-collected) object pool can often make a colossal difference to performance.
Good points. I'd like to add that the best (and probably only) way to end up with with an actual defect-free (or fairly close to it) program is a proper testing strategy (eg. automated unit and integration testing).
HFT is a miniscule drop in the ocean. C++ is sluggish compared to assembler, but that doesn't make assembler a better purpose *general* solution language. Again, you're taking the snobby argument that because C++ is good for your tiny niche that it follows that it is better for all applications and then you proceed to rag on C# guys as if they all sucked. Personally, I'm no C# fan, but I'm not stupid enough to think C++ is better for the general scope of applications. Plus, you ignore the fact that in many cases JIT languages are actually faster than C++, due to runtime optimizations not possible to correctly predict at compile time, and the fact that the simpler languages (viz C++) allows some optimizations that cannot be made otherwise (which is why FORTRAN is still so damn fast).
C++ is useful for some tasks. However to make it work with the new multi-core CPU architectures is a total PITA. Not only do you have to choose a non-standardized threading implementation you also get a lot of headaches as to which thread owns which object (since you don't want to clean up too early or too late). That's one of the reasons Java and C# are so popular and even people with a huge amount of C++ time (like me) will never use C++ as our first choice again. Basically for whatever small percentage of extra speed you get with C++ on *one* core is totally lost when Java/C# uses multiple cores. Even if you make C++ multi-threaded and garbage collected it requires a much larger development time to get what Java/C# has built in. Even worse than the multi-core issues with C++ is the fact that it is generally not multi-platform (at least for non-trivial programs using graphics, networking sound etc) due to the platform dependencies of the libraries. These days the computing environment is becoming more heterogenous, not less. Aside from the supposed bragging rights of C++ programmers (feel they are somehow superior by using it, but fail to realize the more experienced you are the more you wanna get things done in the easiest way, not the hardest/l33t-est way) there is not much to recommend C++ apart from the memory footprint (and only a few people work on systems that are *that* memory constrained these days, most single-board-units have *huge* quantities of memory, eg. 512 MB compared to the old days).
That is exactly why .NET was created (as someone who has around for a long time in IT watching it all unfold over the years).
And I hope you get something similar to GWT soon (since Project Volta ain't going anywhere). ASP is horrid.
Yes, there are alternatives for the language implementation, but check the libraries out. With .NET you are locked into the libraries (unless you can afford to re-write your app in exotic [for Windows] Gnome technologies). Actually I found Java's JNA easier than .NET in working with system libraries, no matter what platform. Shame you don't know about it.
You are talking about desktop apps as if that was the only programs out there. Many apps have moved to the Web, and a very large number of them are built in Java. Just because you can't see Java (because you have your eyes closed) doesn't mean you don't use it whenever you use the Web (same thing with Linux, which handles almost all the external-going mail you'll ever send, but this is also invisible to you because it works so damn well).
Actually a Russian company called 1C rebuilt their product IL-2 Sturmovik (written years ago in Java with some C++, and runs extremely well) into C#.NET (and now it runs like a total dog, although it looks great). A real shame about the performance since the game is otherwise quite nice.
You do know that there a siginificant .NET API that don't run in Mono and never will. Suggest you actually read the Mono compatibility page some time. .NET is not cross-platform and was not designed to be (the languages mean nothing, it is the *libraries* that must run everywhere).
Ah, you you're only doing the desktop or small-to-medium enterprise then. Big enterprise (where there is a *lot* of money) has all sorts of environments that you don't get to chose. That's why Java still gets a lot more work than .NET (according to various indexes, eg. Tiobe). You post is typical from a developer used to working in the relatively limited desktop space. We see that kind of post all the time on Slashdot. Shame you guys are oblivious to all the environments (embedded and huge enterprise) away from your limited experience.
Actually we're smart enough to avoid Weblogic. There is more than one way to skin a cat, and we never take contracts that require use of such crappy tech - doing so is not good business.
1) No matter what technology you use, someone will hold a patent to it. Java is not exceptional in this regard
2) You assume all patents are valid, this is patently untrue (pun untended). Most patents are actually worthless and it is easy to find prior-art for many of them (eg. most of Oracle's patent claims against Google are worthless and have already been dismissed)
3) In the scenario you mention, where you re-invent a technology, well even if you do and someone notices it would be easy to change your re-invention to the standard implementation and thereby comply (in this case, with the Java patent licensing terms put into the JDK license). What you don't have a license to do is create something different and call it 'Java'. But if what you did was different then the patent wouldn't cover it, would it now?
I don't mean to insult your technical skills. However, I would suggest you do a little more research into recent patent cases before making, "the sky is falling" statements about Java on Slashdot. Good luck for your research :)