Programming Language Lifecycles - Where's Java At?

By Robin Sharp
March 11, 2002

There is a programming language lifecycle. Understanding and predicting this lifecycle is tremendously important for IT directors and technical architects. It is even more important for those with a vested interested in the language succeeding, to know when to switch to a new language.

Many languages have been through lifecycles. Languages have met purposes, and languages have continued to fulfil purposes.

But those with the most to lose are often the slowest to recognise change when it occurs. Most people simply follow the herd, but vendors and companies who are sufficiently aware can take market leading positions.

The older you get the faster time flies. Having been involved in the lifecycles of several languages, I'm beginning to recognise some of the signs and wonder where Java is.

Often the time to change is when you least expect to. I was involved in the end of the 'C' lifecycle, and involved at the beginning of the C++ lifecycle. I remember sitting at a desk in 1988 thinking "These C stuct pointers are such a pain"; six months later I was handed Borland's C++ pre-compiler at a conference.

I was also involved at the end of the C++ cycle and beginning of the Java lifecycle when I adopted the Beta versions of Java back in 1996.I remember programming on a trading floor in 1995 thinking: "These C++ libraries are such a pain"; six months later I found the Oak project (which later turned into Java).

The stages of any lifecycle are based on the natural principles of growth, maturation and decay. Whilst these stages are not a judgement on the language, they do reflect a general community opinion. The same processes of natural advantage and mutation operate in the world of programming languages in the same way that they operate in the biologic domain.

In the case of languages, the main forces are efficiency of expression vs. profitable adoption. New languages must compete with older languages; if they are general purpose, functional, expressive and marketed then they stand a chance of being adopted.

Interestingly, it is the application market that drives language evolution. This is because the application market is where the profitable adoption is most significant. Beyond that, Investment Banks are often at the forefront of profitable adoption because with such high profits, they can afford to pay for maturation costs.

I have divided the lifecycle into the following stages:

Conception
Adoption
Acceptance
Maturation
Inefficiency
Deprecation
Decay

Conception
A language is conceived to meet a requirement that other languages do not meet. Countless languages have been written but of those C++, MFC, Java have been backed by budgets.

Adoption
Languages are adopted to make the programmer more efficient. This is driven by the programmers because they are bright and don't like mundane coding. Languages have API's back into the libraries of those they are replacing.

Acceptance
Once the market sees that tools are sufficiently bug free and early adopters have made profits, there is a general acceptance of a language. Green field projects expose requirements and ideas for tools, and libraries are conceived.

Maturation
Languages, libraries and tools mature. They are capable and deliver profitable solutions. There is an increased demand for functionality, rather than efficiency, in order to reap profits. Standards bodies attempt to control the spread of ideas.

Inefficiency
Development has become slow as libraries become more inefficient. The rush to provide functionality has created a market that is subtly fragmented by vendors implementing standards differently. There is a large increase in the number of case tools and code generators.

Deprecation
Developers start to understand that it is costly to develop using the language. Frustration begins to set in, and designers take a deeper look at the issues causing the inefficiencies.

Decay
A young pretender appears and challenges the leader. Lean, mean and fast, the new language has apparently come from a research department of a large technology company. Marketing departments lock horns and invariably the old order is overthrown.

Interestingly, I have noticed that programming language lifecycles have a relationship with general economic cycles. Competition between languages takes place when a language has become inefficient.

At the beginning of the upturn in an economic cycle, resources are scarce and development is required. It is then that the more efficient languages win out.

Going into a recession, resources are cheap, efficiency and expressiveness are not high priorities, and languages become bloated and inefficient.

C, C++ and Java were all taken up by the early adopters at the start of an economic upturn. Fundamentally a new language is smaller, lightweight and more efficient. The choice between an old and a new language is often one between a ready made, but inefficient architecture and architectural building blocks.

So where does that leave Java?

Certainly we are now getting into the Inefficiency phase of the Java Lifecycle. J2EE and EJB form a ready made architecture that is expensive to develop. It would be hard to see small companies justifying the current development costs when we come out of the downturn in a year or so.

I believe that a similar event will occur as with previous language-shifts: a young pretender will appear from a research project, probably as early as the beginning of next year. As with the last shift, the new language will adopt the hard-learnt application semantics from the previous languages.

For C++ this was OO, for Java this was libraries and standardised API's. For the next language, the clear application semantics 'discovered' by Java is the bean/EJB semantics of properties, events, homes and sessions.

.NET from Microsoft has several bean-like properties built into the language, making it a potential contender. Like Java's adoption of C++ syntax, C# has adopted Java's libraries. However, I believe Microsoft made a strategic error in adopting Java's libraries, and not building bean/EJB-like semantics deeper into the .NET language. They could now be leveraging this functionality to automatically persist and deploy beans.

I don't really see C# as being significantly better than Java to challenge it on that basis.

Similarly, I believe Sun made a strategic error in sitting back and not developing a Java++ language that builds bean/EJB-like muscle into the language rather than fat on top of it, as EJB does.

Given the history of language evolution, the shift from C to C++ marked a requirement for extensive libraries to be made available. Having said that, both C++ and Java made an effort to reuse the existing code base of their predecessor.

One of the most promising areas of research is the design of the so called 'component-oriented' languages. These differ from object-oriented languages in that they offer messaging, properties, events, sessions and homes all built into the language.

Importantly, they also distinguish between definition of the components and the components implementation. This means that it will be possible to define an application without actually saying what will be rendered into the technology; for example how it is presented or how it will be persisted.

Whatever happens next, the next few years are going to be interesting.

About the author:
Robin Sharp is the Managing Director of Javelin Software (http://www.javelinsoft.com).
He can be reached at

Talkback:

Post a new message

Like Moore's Law....
Laurence Vanhelsuwe 
Totally agreed to Mr. Vanhelsuwe
Sidney Fortes 
Agreed
robin.sharp robin.sharp@javelinsoft.com
Why no mentioning of scripting languages?
Jack Herrington jack_d_herrington@pobox.com
2cents
Joubin joubin@inch.com

Post a new message

Related Articles:

Component-Oriented Software

The State of Web Services

Research Projects

<< Back to Programming