Programming Languages

Does event processing need a new programming language? And what are the prospects of programmers adopting a new language?

The answer to both questions seems to hinge on the word "new". If we add a few constructs to an existing programming language, does that count as new?

Louis Lovas (Progress Apama) and Mark Tsimelzon (Coral8) agree that a programming language for event processing needs to be familiar, easily recognizable, explained in five minutes. In other words, new but not very new.

Louis Lovas (Progress Apama): Successful languages - show me the code please
Mark Tsimelzon (Coral8): What Makes a Programming Language Successful?

As individuals, programmers may be attracted by new and innovative languages, but there is a collective conservatism. There are always many interesting niche languages, sometimes with a devoted fanbase but with practically no chance of achieving critical mass; very few languages ever achieve widespread adoption and popularity. Louis attributes the current dominance of Java to a process of natural selection, but of course this is a selection based on the fact that popularity breeds popularity and does not indicate any intrinsic superiority of Java over the thousands of unheard-of alternatives.

And adoption is only half the story. Programmers may indeed be unwilling to invest more than five minutes in checking out a new programming language, and this unwillingness possibly filters out a lot of potentially valuable innovations. But what if new types of software application require new types of thinking? If programmers are only using language constructs that they are comfortable with, this suggests that they are also only using familiar styles of thinking, and may fail to pay attention to some important new aspects and issues. Consequently some errors may creep into their programs.

Obviously brilliant programmers never make any errors, but programming languages must be designed for not-so-brilliant programmers as well. So we must ask what are the pattern of errors associated with using a particular language in a particular context, and what can we do to reduce the error rate?

Some of the advocates of niche programming languages get rather smug at this point. They argue that although their favourite programming language may be a bit more difficult to learn if you are only familiar with C or Java, it is far less error-prone. But that argument is pretty academic if noone is using or interoperating with these languages.

There is sometimes therefore a trade-off between adoption and correct use. A language that is easy to adopt may also be easy to use badly. Whereas one that is more fail-safe in use may initially be more difficult to adopt. While language vendors undoubtedly care a little about correct use, they obviously care a great deal more about adoption and adoptability. Whereas the users of these languages should care equally about both.

Update

In a post entitled On the Right Event Processing Language, Opher Etzion adds: "abstractions that enable to think naturally about a certain type of functions is more important than familiar syntax". Actually I'm not convinced that programmers think naturally about anything - that's what makes them programmers in the first place - but apart from that I think he's got a point.