BOF. Die Zukunft der Programmiersprachen

Der Raum war ausgerichtet auf eine Art Panel-Diskussion - vorne Stühle für die Speaker und hinten Stühle für die Zuschauer. Markus Völter meinte, ein BOF sei anders. Mehr so, dass Speaker und Teilnehmer zusammen im Kreis sitzen und miteinander diskutieren.
Dazu waren aber definitiv zu viele Leute (100?) da. Also hat Markus vorne Zettel mit Thesen hingelegt. Wir sind dann einmal nach vorne gegangen, haben uns ein Thesenpapier genommen und das dann "vertreten". Natürlich waren die Zettel nur die Startpunkte für die Diskussion.
Die Diskussion selbst war lebhaft, aber dann doch auf wenige beschränkt. Manchmal driftete sie vom eigentlichen Thema ab, aber das haben die Speaker dann wieder eingefangen.
Zuerst ging es um das Thema AOP. Ca. die Hälfte der Anwesenden nutzt AOP. Die meisten aber nur dadurch, dass sie Spring einsetzen. Nur ein kleiner Teil benutzt AspectJ. Niemand benutzt AOP für was anderes als die üblichen rein technischen Beispiele Logging, Tracing, Transaktionshandling und Security. Die meisten finden AOP eine interessante Technologie, hatten aber im Ansatz eine Vorstellung davon, wie man funktionale Aspekte definieren soll. Ein Teil der Teilnehmer fand AOP in Gesamtgröße a la AspectJ auch viel zu kompliziert.
Bei der Komplexität fanden einige, dass Java zu kompliziert wird. Dierk König (sinngemäß): "Für mich hat JDK 1.4 gereicht. Java 5 ist für mich zu kompliziert." Es gab eine ziemliche Einigkeit darüber, dass die Zukunft der Programmiersprachen in Einfachheit liegen müsste. Dabei gingen die Meinungen auseinander, ob man ein einfacheres Java braucht, eher was Dynamisches a la Ruby oder Groovy oder gar etwas Funktionales a la Scala. Dabei gab es ein erstaunliches Interesse an funktionaler Programmierung. Das rekursive Programmieren sei vielleicht am Anfang gewöhnungsbedürftig, aber das sei OO auch. Außerdem bieten funktionale Programmierung den Vorteil, dass man das Programm transparent parallel ausführen kann. Das ist vor der Diskussion um Multi-Core-Prozessoren und ihre Auswirkungen auf die Programmierung natürlich ein echtes Argument - jedenfalls, wenn man glaubt, dass man in seinen Programmen die Multi-Core-Fähigkeit ausnutzen muss und nicht sowieso durch die Datenbank ausgebremst wird.
Dann gab es noch eine Diskussion um Closures. Alle wollen Closures. Dierk sagt, dass noch nicht raus ist, ob und wenn ja in welcher Form Closures in Java 7 enthalten werden. Er glaubt, dass man in Java über anonyme Inner-Classes letztlich nicht herauskommen wird.
Insgesamt war es eine interessante Session.