The question that is often posed in one rhetorical flourish or another is this: Which is better (faster, more efficient, blah blah blah...) Java or C++? The question that is really not being asked is: for what? Selecting a programming language is not like selecting a dinner suit; you are not going to be asking the question that frequently. In fact, this question is more like deciding on a business plan rather than simply selecting a tool from the tool box.

The reality is that the only people that would really ask this question are those that:

1. Are just at the beginning of planning a software effort that will become the basis of a business or business group that has yet to be established.
2. Have a full grasp of and can support apps made with either language
3. Are writers of articles or blogs
4. Have a burning desire to vindicate their own personal preference.

If you are a business and you have a software project that is just starting, there are a number of questions that will be asked before deciding on a programming language. In fact, I am about 110% certain that the question of which programming language to use almost never comes up. Why? Because business managers are going to use the language that their staff knows the best and that the company can best maintain. The only time it would even come into question is if there is some deep need that only a particular language can fulfill. For example: if you needed detailed interaction with the native operating system or hardware you would probably want to use C/C++. If, instead, you needed software that managed a lot of user interactive data with a short lifespan and the runtime environment was ambiguous, you may choose Java.

I can tell you from experience that software decisions become business culture in every business that is serious about the use of computers. If the business decided in the past that C/C++ was the way to go I can assure you that they will not ask that question again unless their current staff cannot produce a satisfactory product for the currently proposed project. It really doesn't matter if one is n milliseconds faster during this operation or that. What matters is using the staff on hand to produce, test and maintain the product.

In every comparison I've seen, the question comes down to performance. but we are at  the point of comparing milliseconds and thus we are in realm of the silly comparisons for most applications. That level of performance really only matters when there are no other performance bottlenecks and where the difference would actually be perceptible (i.e., a 3d interactive adventure game or crunching huge amounts of scientific data). C/C++ was the first programming language I learned but I have been using Java since it became available. The performance comparisons started almost immediately...and it was ridiculous. Java was not originally meant to take over the computing world. It was meant to provide a more feature-rich internet experience. As a web tool, it was also intended to be easy. "Easy" means squishing all the hard stuff into automatic function or succinct APIs. Clearly, Java has come a long way since then and is used for much more. Its platform agnosticism has enabled rapid development of software for all kinds of hardware, leaving (most of) the low-level headaches for the JVM writers. What has actually happened is that Java was chosen for all kinds of good reasons regardless of performance (which was never comparable) and the JVM writers and hardware technology have made the performance discussion effectively irrelevant in most cases.

One part of the comparison debate that has always troubled me was that C/C++ and Java are not equal. C/C++ is a programming language with a rudimentary API (the C Runtime). The operating systems are not designed to accommodate the language and most of the feature-rich class libraries are third-party offerings. Java is more than just the language. It is the common platform (JVM) and it is the enormous class library that simplifies some rather complex low-level tasks, like socket management or stream IO.

The strength (and arguably a weakness) of C/C++ is that it is so fundamental that it is extremely versatile. C/C++ makes relatively few assumptions about how the software will be ultimately be constructed. Ultimately, C/C++ will be compiled to run as close to te machine as the machine allows. Java has many assumptions about the code construction. In fact, it mandates quite a bit. If you don't understand the Java way you are going to have a hard time. Therefore, Java has less flexibility overall. However, the Java way tends to be a good way and although certain architectural decisions are not negotiable, it usually provides a good way to get just about anything you need done and done in a pretty good way. Between that and the JVM specification, Java provides a consistent and clean way of writing software for multiple platforms and with a rotating pool of developers.

If it sounds like I am not making a clear comparison it is because I am not. I don't think that it is an apples-to-apples comparison. In my personal projects, I carefully consider which language I use, whether it will be C/C++, Java or even PHP for that matter. As with anything, I think about where I want to go and then determine how I want to get there. If you follow the C++ road to where it naturally takes you it is a different place than where Java naturally takes you. Sure they can overlap and sure you ride Java or C++ anywhere, but why? Well, in a business environment the whys are plentiful. As a technical lead or manager I am going to think more about getting it done for the least cost and with the fewest future maintenance problems. I am going to use my existing staff and make the most of their expertise. I am not going to create a new management division of development, design, test, build and support for a few milliseconds unless I absolutely have to. And really, unless I am in the business of writing wholly custom software for many different customers with completely different needs, I am most likely not going to be creating new software that departs all that radically from products I have already produced.

As fun as entertaining comparison discussions between C/C++ and Java are (obviously fun enough to inspire me to write this) they are really not practical except under the most unusual circumstances. That decision is made by the inventor of an idea that was probably already inspired during the use of one of the two in the first place. Businesses may consider the choice at the very beginning but as the business culture grows around its offerings the discussion becomes less and less relevant. You may choose the tools that best suit that initial design or outcome but after that, the tools tend to dictate where you go from there, whether it be who you hire or what new feature you add or even what markets you seek. However, as a musing of fancy for journal readers it is most valuable.