Javas 2 lessons learned

I think Java taught us two important lessons in the IT landscape and was thus very helpful to bring forward the state of art in programming.
The lessons come from both a success and a failure of Java. Now, while most people will agree on the positive lesson learned many people might not have realized yet the negative one which is equally (or even more) important though.

Without doubt, Java was the language which established Garbage Collection in the mainstream. Before Java, Garbage Collection (GC) was not taken seriously by most programmers and languages with GC were brand-marked as academic niche languages unsuitable for real world applications.

This has changed radically. Today, no new language without GC would be able to succeed anymore, so this positive lesson of Java was learned quite quickly.

The negative lesson learned from Java - at least for me - is that making multithreading too easy is not a good thing to do. At my first contact with Java (in the mid 90s) I was fascinated how easy it was to create new threads and that the language offered keywords to create monitors - i.e. synchronized objects.

But this initial fascination quickly turned into deep objection as I gradually found myself thinking more about possible side effects done by concurrent threads than the business logic itself. What Garbage Collection has achieved - relief the programmer from thinking about memory management issues so that he can concentrate on the real problems again - was counter-achieved by multithreading.

With more insight on concurrency problems I found that most - if not all - of my own Java programs were flawed with respect to concurrency in one way or another. And maybe worse - most of any Java program I looked at are unsound too from a multithreading point of view.

The temptation to use multiple threads is increasing further with the advent of multi-core CPUs. But we humans are not especially good in thinking about the countless implications concurrency can have on our code.

To bring back productivity to programming we have to accept the lesson Java has taught us and prevent the easy creation of threads in future languages. How to utilize the power of multiple core CPUs in this case will be on of the hottest topics in the coming years.

Cheers

JavaScript 2.0 - ActionScript 3.0 - ECMAScript Edition 4

In a previous blog I praised the Scala programming language as the 21st century Scheme.

Since that time I got into contact with ActionScript 3.0 though and have to admit that the title for a 21st century Scheme (at least for the first decade of that century ;-) probably goes to JavaScript 2.0.

To cleanup a potential confusion here, both ActionScript and JavaScript are following the ECMAScript-262 standard and so are brothers if not geminies. The Edition 4 of ECMAScript is now the base for ActionScript 3.0 and JavaScript 2.0. Unfortunately Edition 4 is not finalized yet - neither is JavaScript 2.0 - but ActionScript 3.0 is already shipping. It seems that Adobe - the 'creators' of ActionScript - want to speed up the standardization process by taking some decisions on their own. Decisions which can take forever in a gremium - as many of you know by your own experiences.

JavaScript is one the the worlds most used programming languages as it works in nearly every browser out there. The great thing here is that it is a true functional language which I define as having closures. So, at the beginning of the 21st century one of the most used languages is a functional one and that really gives hope.

ActionScript3.0 (i.e. ECMAScript Edition 4) improves a lot on the previous versions and introduces packages and classes as familiar concepts:

* Packages allow to group names into APIs and prevent clashes between same names of different APIs.
* Classes allow an object orient programming style which is more in-line with what most people expect and know from other languages than the prototype based approach of previous ECMAScript Editions. The prototype mechanism is still there in Edition 4 but I expect that most people will switch to the class based concepts instead.

Other new features include optional type annotations (with algol like colon separated postfix syntax ;-) and properties (a.k.a. getter and setter functions).

Independent from Edition 4 is the E4X (ECMAScript for XML) standard which allows to structure and destructure XML within the language. Such a feature is invaluable in todays XML centric worlds and corresponds to the s-expr readers and writers of Scheme.

Missing from ActionScript3.0 is a pattern matching facility as in Scala or other functional languages like ML. But I could imagine that an Edition 5 could include this as the literal object notation '{}' of ECMAScript is beneficial for this task.
Finally, macros are missing but I expect that this could become a trend in the second decade of this century for several languages.

So, contrary to my previous believes the quest for a Scheme successor has not stopped and will go on and on.
JavaScript2.0 - ActionScript3.0 - ECMAScript Edition4 are good contenders though and really fun to program in.

The fun has just begun.