Doug Ross @ Journal

The Next Language

After almost 9 years of programming in Java, I have been thinking about where Java is going and how it fits into the continuum of programming languages in the enterprise... ...What Java didn’t provide was 4GL type tools, but then again nobody had 4GL type tools for web applications, so it was no big deal. It was expected that those would come. However, many years have past, and the vast majority of J2EE applications are still built by hand. A lesson that Microsoft has learned well is that for API’s to be toolable, they need to be developed concurrently with the tool and both the API and tool should depend on easily externalizable metadata. Java API’s were always written on the merits of the API’s themselves, and subsequent tools were predominantly code generators shunned by programmers. The Java API’s grew into a morass of inconsistent and incomprehensible API’s, even the most simple things proved to be very complicated. The vast majority of J2EE deployments (over 80% according to Gartner) are simply Servlet/JSP to JDBC applications. Basically HTML front-ends to relational databases. It is ironic that much of what makes Java complicated today is all of its numerous band-aid extensions, such as generics and JSP templates, which were added to make these types of simple applications easier to develop... ...So let’s look at the requirements for today’s corporate applications: # Handle XML (dynamic data with fluctuating types) well # Quickly process text into objects and out of objects # Most apps have limited logic consisting mainly of control flow # No need for portability beyond Linux/x86 and Windows/x86 # Very thin veneer over the operating system for system services # Tuned for 1-2 processor x86 machines Given these requirements, Java does not fare very well: # XML data is inherently unstructured and it has to be shoehorned into and out of Java, which is a strongly typed language that does not like new types of objects popping into its applications. # Java is horrific at processing text since it can’t manipulate strings directly. # While Java is great for complicated applications, it is not ideally suited for specifying control flow. # Java is a magically portable platform, but there is no longer a requirement for portability other than Linux and Windows. # Since there is no longer a portability requirement, developers want only a very thin veneer over operating system services like sockets, while Java provides a huge virtual machine in between the application and the operating system. # Most J2EE implementations are tuned for 4-16 processor SMP boxes So if Java does not meet these requirements, what does? Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text. It should be very well suited for specifying control flow. And it should be a thin veneer over the operating system. Most Linux distribution in fact bundle three such languages, PHP, Python, and Perl. PHP is by far the most popular, Python is considered the most elegant (if not odd), and Perl the tried-and-true workhorse. All three languages are open source and free. As the following graphs show, PHP use has skyrocketed over the past few years...

The next language