Ein ganz großes Thema auf der JAX08 und in der Entwicklergemeinschaft sind Sprachen.
Groovy, Ruby, JRuby, Skala und viele mehr. Warum?

Ich denke Prof. Dr. Nikolaus Wulff hat hier wertvolle Erklärungsansätze geliefert. In seiner Session Die Grenzen der Komplexität stellt er auf hoch amüsante Weise die folgende These auf: Ein komplexes System, also eins mit vielen Beziehungen zwischen den Teilen des Systems wechselt zwischen stabilen und instabilen Gleichgewichten. Die Java Gemeinschaft befand sich für lange Zeit in einem stabilen Gleichgewicht. Die anstehenden Probleme konnten mit Java gelöst werden, sie konnten insbesondere mit Java wesentlich besser gelößt werden, als z.B. durch C++ oder gar C. Aber viele dieser Probleme sind gelößt. Dadurch werden neue Probleme in Angriff genommen und hier stoßen wir an die Grenzen von Java. Dinge, die man früher nicht wahrgenommen hat, da man die Features von Java noch untersuchte. Vor ein paar Jahren hat fast niemand Closures vermisst, heute schreit die halbe Welt danach. Ebenso wie z.B. Struts 1 an seine Grenzen gestoßen ist, und wie die klassischen Prozessor Architekturen an ihre Grenzen stoßen. Oder alternativ formuliert: Wir suchen uns immer komplexere Probleme, bis wir sie mit den bisherigen Mitteln nicht mehr Lösen können.

Nun gibt es (wiederum nach Herrn Wulff) drei wesentliche Strategien.
1. abwarten, vielleicht löst sich das Problem von alleine. Das funktioniert gut für lange Zeit, wenn man zufrieden damit ist in der 3. oder 4. Reihe mitzuspielen. Dies ist auch als Quake Tuning: Um eine Anwendung um den Faktor 2 zu beschleunigen, schließt man sich für 18Monate Quake. Danach ist die Anwendung schneller.

2. Horizontale Ausweichbewegungen. Das Problem wird nicht wirklich gelößt sondern nur temporär umgangen. Als Beispiel nennt Herr Wulff Mehrkernarchitekturen, die nicht wirklich das Problem lösen, dass Schaltkreise nicht beliebig weiter verkleinert werden können. Oder auch das Verhalten einiger Entwickler bezüglich neuer Sprachen: Der Java Stack ist unglaublich kompliziert, mit Tausenden von Klassen und Bibliotheken. Die Ausweichbewegung: Man wähle eine neue Sprache und bekommt sofort Erfolgserlebnisse, ohne sich mit den nicht existenten tausenden von relevanten Bibliotheken herumzuschlagen: "Toll, es funktioniert: 'Hello World'".

3. Etwas wirklich Neues entsteht. Dies sind die wenigen Durchbrüche, die wirklich weiterhelfen. In der Hardware könnte dies vielleicht aus der Quantenmechanik kommen. In der Softwarebranche sind die neuen Sprachen die Suche nach etwas Neuem, auch wenn es für viele Entwickler nur eine Ausweichbewegung ist. Auch bei diesen Lösungen gilt aber der Satz von der Erhaltung der Komplexität: Komplexität verschwindet nicht. Sie kann versteckt werden, insbesondere in eine Sprache oder eine Bibliothek ausgelagert werden.

Und was bedeutet das für mich (und für euch)? Verschiedenes:

1. Wir werden nicht immer alle die nötige Genialität besitzen um eine Strategie der 3. Art zu fahren, aber wenigstens die 1. sollten wir vermeiden und man sollte sich bewusst sein, die 2. Strategie zu fahren, wenn man es tut.

2. Java wird verschwinden oder sich radikal ändern , aber nicht morgen. Man kann dies schön an den folgenden Graphen sehen. Sie stellen die Entwicklung und das Absolute Verhältnis von Jobangeboten für verschieden Programmiersprachen dar. Die Graphen werden bei www.indeed.com gezogen:

java, ruby, groovy, skala Job Trends

java jobs - ruby jobs - groovy jobs - skala jobs

Wie man sieht, wachsen die neuen Sprachen rasant, während Java stagniert.
Aber Java stagniert auf hohem Niveau, um nicht zu sagen, sie sind irrelevant für Jobs

java, ruby, groovy, skala Job Trends

java jobs - ruby jobs - groovy jobs - skala jobs

3. Die aktuell diskutierten Sprachen bieten eine Menge tolle Werkzeuge um Komplexität in den Griff zu bekommen. ABER. Es sind Tools. Nicht mehr, nicht weniger. Neal Ford vergleicht Metaprogramming gerne mit medizinisch Opertationen. Ein wunderbarer Vergleich: Skalpelle sind toll und man kann da tolle Dinge mit dem menschlichen Körper tun. Aber ich möchte nicht, dass dies irgendwer tut, sondern jemand, der sich auskennt. Und keins unserer Probleme wird einfach verschwinden, weil wir nicht mehr in Java programmieren. Wir brauchen immer noch die Experten, die sich einen Teil der Komplexität schnappen, und damit in den Tiefen einer Bibliothek verschwinden, damit wir diese Komplexität nie wieder sehen. Der Experte darf nach einiger Zeit wieder rauskommen. :)
4. Es stehen uns allen Interessante Zeiten bevor. Entscheidet selbst, ob ihr das im Sinne von Terry Pretchet versteht.