Ich melde mich mal nach langer Zeit wieder zu Wort. Ich habe Erfahrung in vielen Programmiersprachen und Paradigmen. Ich kannte Basic, Pascal, C/C++, Java, Lisp, Python und habe mich dennoch mit Scala, Clojure und Groovy beschäftigt. Mein Geld verdiene ich im Java-Umfeld.
Obwohl ich sehr gute Erfahrungen mit Python gemacht habe, hielt ich Scala für einen sehr guten Ansatz, da ich ein Faible für strenge Typisierung habe. Nur empfand ich Scala selbst bei kleinen Aufgaben recht anstengend. Syntax muss intuitiv sein, ich empfinde sie bei Scala aber nicht intuitiv. Ständig ist man am nachbessern und versteht eigentlich nicht, warum der Scala-Compiler so komisch reagiert. Das konnte aber auch an mir liegen, nur gebe ich zu bedenken, dass ich schon viele verschiedene Programmiersprachen und Paradigmen kannte und auch hartnäckig bin, wenn ich etwas neues lerne.
Groovy verwende ich schon seit einigen Jahren für kleinere Sachen. Zu Jahresbeginn aber habe ich eine DSL in Groovy geschrieben und bin hellauf begeistert und Groovy bringt vieles mit, was ich mir eigentlich immer schon gewünscht habe, z. B. die Memoized-Annotation (die ich mir schon zu Python-2-Zeiten mal programmiert habe, als Dekoratoren eingeführt wurden.), oder die Möglichkeit, Klassen als Immutable zu annotieren, was garantiert, dass höchstens ein Exemplar pro möglichen Objektzustand existiert.
Viele mögen das für esoterischen Kram halten, ist es aber nicht. Das sind genau die Dinge, die man braucht, um die Gesamtfunktionalität
einer Software zu gewährleisten. Ich habe Kollegen, die das alles für "syntactic sugar" halten. Es ist es nicht, es ist "semantic sugar". Wenn ich einfach nur eine Annotation irgendwo ranklatschen muss, dann ist das ästhetischer und wirkungsvoller. Wer eine Annotation entwickelt, um sich Programmierarbeit zu sparen, hat gezeigt, dass er ästhetisch denken kann. Kollegen von mir schreiben Java-Klassen mit über 3000 Zeilen und halten sich für gute Programmierer. Ich sehe es genau anders herum, denn wenn so viele Zeilen zusammenkommen, wurde etwas falsch gemacht. Ich komme dann häufig in die Verlegenheit, seinen Code zu patchen. Ich habe den Eindruck, dass er sich recht häufig wiederholt. Mir ist dabei immer sehr schummrig und mich ärgert's, wenn ich was vergessen habe, weil so viel gleiches an Code an vielen Stellen verborgen ist und man alles gar nicht überblicken kann. Ich starte die Software, nach wenigen Minuten kracht's, weil das DRY-Prinzip einfach nicht eingehalten wurde.
Ich merke auch immer wieder, dass viele Programmierer selbst die alten Konzepte aus der prozeduralen Programmierung (d.h. Funktionen, Prozeduren) zur Code-Reduktion nur unzureichend beherrschen. Ich kam mal in ein Katastrophen-Projekt. Ich habe da eine 3000 Zeilen lange Klasse gesehen, die nur so gespickt war, mit duplizierten Code. Einfache erste Maßnahmen von mir haben alleine da 20 % gespart. In einem anderen Projekt bin ich mal auf eine Testklasse gestoßen. Ich weiß nicht, was der Programmierer sich dabei gedacht hat, jedenfalls waren da ca. 30 Testmethoden und alle gleich, bis auf wenige Strings und Zahlen. Das sprang mir sofort ins Auge und habe einfach nur den Testrunner "Parameterized" verwendet, sodass das, was vorher dreißig Testmethoden à ca 40 Zeilen war, plötzlich auf ein DIN-A4-Blatt passte. Selbst ohne Kenntnis jenes Testrunners hätte man sehr viel reduzieren können.
Mit Jython beschäftige ich mich partout nicht. Ich kenne Python, ich kenne Java, nur das Problem ist, dass ich kein alten Python-Standard in Java haben will. Ich nutze seit über fünf Jahren Python 3.