Why You Should Ditch C++ For Java
In the 8 years I've been developing in Java, I've heard of numerous arguments about why it is better than C/C++. Some rave about the garbage collection that frees you from (most) memory management tasks. Others are swearing by the thread awareness of the language and the libraries. Or the design patterns that are elegantly embedded in its library implementation. Or the VM abstraction that makes it possible to run the same code in multiple operating systems. And of course you can always find the weirdos that mumble things like type safety and automatic bounds checking. These are all nice indeed, but it is something else that fills my heart with joy each and every time I stumble upon it.
Pretend for a minute that you make a living programming computers. I know, why would someone in his right mind do something like that, but bear with me. Let's also assume that for reasons unknown even to the Creator himself, you are using a development environment (IDE in geek-speak) written in C++. Suppose that while banging merrily at the keyboard you hit an IDE bug. Kaboom!
Segmentation fault. Core dumped.
Or perhaps you got a pretty little window on the screen that informs you that something terrible happened to your IDE and suggests to notify the proper authorities (that is, the IDE maker). After recovering from such a traumatic experience, you will eventually have to relaunch your IDE, curse for the Loss of Unsaved Changes and do them all over again.
Now let's assume you were using an IDE written in Java. Click, click, click: bug. But this time no kaboom. You clicked on some button-shaped thingy but nothing happenned. You click again, nada. The IDE is still there but something went obviously wrong. You call for help and your friendly sysadmin shows up. He digs up the IDE's log file and he shows you what happenned:
java.lang.NullPointerException
at org.eclipse.update.internal.ui.wizards.ReviewPage$TreeContentProvider.getParent(ReviewPage.java:181)
at org.eclipse.update.internal.ui.wizards.ReviewPage.getSite(ReviewPage.java:1370)
at org.eclipse.update.internal.ui.wizards.ReviewPage.access$29(ReviewPage.java:1367)
at org.eclipse.update.internal.ui.wizards.ReviewPage$13.run(ReviewPage.java:816)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
What do you do? You just forget about clicking that button-shaped thingy ever again (or maybe for a day) and get back to coding frenzy.
The important thing to realize is that in both cases the same problem emerged. A reference or pointer to something was accidentally pointing to something else instead, and it was being forced to behave, perhaps a bit abruptly. After all, we should all be careful where we point to. It's the noble thing to do. But the impact of such an accident was fundamentally different. In the first case the operating system killed the process, while in the second case an exception was propagated up the stack. Both programs are multi-threaded and therefore capable of doing many things in parallel, yet the first one could not avoid having all its threads killed because one of them messed up. Oh, the cruelty! How would that make the other threads feel, I wonder. The Java program on the other hand, rightfully punished the offending thread (to make an example perhaps), while the others were left alone to go about their businesses. My guess is they all chatted quietly afterwards about it and everyone agreed that the grounded thread was a troublemaker, who got what she deserved.
The same thing happens all the time on server programs, too: big, heavy applications that serve legions of users. When the administrators are least expecting it, a stray pointer causes havoc. The service goes down, the call center is flooded with support calls and the administrator's pager goes nuts. That is for C++ server programs, of course. Java-based server applications go on serving people, even while a few threads get kicked in the bottom every now and then. (And in case some smartass mentions using watchdog daemons to restart servers: would you rather have a staff that worked via self-motivation or a staff that needed angry, big dogs to watch them while they do their job?)
So, in a nutshell, that's why you should not be using C++. Not if you pity the poor program's users, that is. Or its undeservedly punished threads. C++ is a hard, cruel language. Come and join me in the heavenly world of Java.