Monday, June 15, 2009

Java, reversed evolution

Once again I was bombarded with statements like “Java is an unstoppable tsunami”. Having designed interpreted and compiled languages, used about a dozen languages for commercial products, studied and researched close to a hundred programming and specification languages that is not how I see things. This note presents one aspect of my view about Java.

A baby in uterus does not start out looking like a human and evolve backwards to a chimpanzee at the time of its birth. Nonetheless, in the uterus of programming, IBM can sell Smalltalk as a solution to Y2K and deliver its adopters straight to their bankruptcy. Leading technologies do not worry about the consequences of what they advertise and sell. Buyers must know what they are getting into.

In order to make the point clearer, consider starting with C++ as an improvement to C. The term improvement implies getting more without losing major capabilities. Now, start peeling off expressiveness one by one. First take the pointer and multiple-inheritance out and then drop enumeration, next discard templates, on and on, until you get Java. All that is needed is an innocent child to scream, “Why is the king naked”?

Having said that, Java has its uses. Libraries similar to Qt provide API in the context of an existing language, usually C++. These libraries strive to standardize commonalities among a few systems for purposes of source code portability. On the other hand, Java is a platform independent graphic library that uses a language of its own rather than depending on API in another language. This makes Java useful in several ways, but solutions for end-to-end enterprise problems are not among them. Here are a couple of recent uses of Java.

When an operating system, such as Android, is written in C, there must be sufficient support available in C in order to make a JVM. Yet, one finds all kinds of support for Java and none for C. The promoters of Android are hoping that a large population will engage in making the kind of applications one can create in Java. Once the momentum is built they can introduce serious end-to-end enterprise solutions in C before anyone else can beat them to it. Thus, in this scenario Java is used as a baiting stage. It makes little sense, if any, to put the entire power of a Linux-like operating system in the service of JVM, and Java applications.

Blackberry is effectively unknown outside the borders of America. The economic downfall made future enterprise sales within the country hopeless for RIM. RIM’s strategy was to use Java to encourage sales among younger generation. Many with the hope of making a few dollars per download would create amusing Java applications for the device. The strategy has resulted in a temporary spike in sales of devices.

Java portrays an interesting interpretation of the process of compilation. Generally, when the execution engine needs to be aware of names as provided by the programmer, we speak of interpretation. For a compiled language the execution engine does not use the actual names (identifiers) in a program. Otherwise, the execution of a virtual engine is not different from a hardware processor in its operation of fetch, decode and execute. In other words, the term interpretation does not refer to the execution cycle. Rather, it refers to what is executed by those cycles. At the front end, an interpreted language lacks a compilation phase known as linkage for resolving external symbol references. Java incorrectly pretends that remote linkage and compilation linkage phase are mutually exclusive.

Natural evolution may not necessarily retain all the good qualities. However, it is almost impossible to find any evolutionary path on any planet that evolves a human into a monkey, except The Planet of the Apes. Eiffel and C++, among other significant languages, were already mature programming languages when Java was hastily put together. Now after over a decade Java has not been able to incorporate at least one major concept, say invariants. Perhaps now you see the relevance of the title, reversed evolution.

Eclipse is a reasonable IDE. However, one can also make an IDE using Qt that will run on as many platforms as Eclipse does, except more efficiently than Eclipse. Moreover, IDE is a standalone application. Simply put, a platform independent graphic library is not sufficiently expressive as a medium for providing reliable solutions to complex distributed end-to-end enterprise problems. Making no distinction between Eiffel and Java is equivalent to making no distinction between Mozart and the monkey in the British Museum.

Labels: , ,