Auf seinem heise developer-Blog Babel-Bulletin schreibt Michael Wiedeking den Beitrag “Runterskaliert” über die funktionale Programmiersprache Scala und seine Probleme damit. Auch wenn dieser Blog-Beitrag schon fast angestaubt ist (einen Monat alt), konnte ich mich in einigen seiner Kritikpunkte wiederfinden, und auch meine Faszination für Scala und die damit umgesetzten Konzepte aus der Welt der Funktionalen Programmierung findet sich in seinem Beitrag wieder.
Und trotzdem hinterlässt der Beitrag einen etwas schalen Nachgeschmack.
Aber erst mal schön der Reihe nach.
Wiedeking zählt zunächst einige der Eigenschaften von Scala auf, die ihm an Scala erwähnenswert erscheinen:
Bei Scala gefällt mir der Ansatz, dass wirklich ausnahmslos alles ein Objekt ist…
Diesen Umstand findet ein Smalltalk-Liebhaber natürlich auch sehr vertraut und attraktiv. Schliesslich ist neben Typecasting und viel syntaktischem Grundrauschen vor allem die seltsam anmutende Tatsache, dass es in (sagen wir mal) Java für z.B. Ganzzahlen zwei Typen existieren, denen man auch erst kurz nach der Pubertät beibrachte, dass sie sich automatisch ineinander umwandeln können (Autoboxing), immer wieder ein Kopfschütteln wert, wenn man das nicht als ein unumstössliches Faktum mit der Muttermilch aufgenommen hat.
…wie schön einige der syntaktischen Probleme gelöst werden…
da der Autor nicht weiter darauf eingeht, was er hier meint, lese ich das als “mir hat die Syntax gut gefallen”. Auch hier finde ich mich wieder, Scala liest sich weitaus angenehmer als Ruby (sic!) oder eine Sprache aus dem C-Dunstkreis. Aber das ist natürlich reine Geschmacks- und Gewöhnungssache. Smalltalk haftet ja auch eine Aura seltsamer Syntax an.
und – nicht zuletzt – dass ich die komplette Java-Bibliothek zur Verfügung habe
Das ist natürlich ein Riesen Vorteil, den es nicht zu verachten gilt. Zwar gibt es einige Beschränkungen in der Scala-Java-Interoperabilität, aber diese betreffen in erster Linie den umgekehrten Weg, also die Nutzung von Scala aus Java heraus. Die Tatsache aber, dass ein Scala-Programm auf so ziemlich jeder (aktuellen) Java-Laufzeitumgebung aufgesetzt werden kann, und dass eine riesige Auswahl an Bibliotheken aus der Java-Welt zur Verfügung stehen, ist ein sehr gewichtiges und stechendes Argument. So ist es denkbar, eine Scala-Anwendung zu schreiben, und die Oberflächen in SWT oder Swing zu implementieren. Dafür stehen dann auch bereits bewährte Werkzeuge wie SWT Designer oder WindowBuilder zur Verfügung. Auch die komplette RCP-Umgebung von Eclipse steht dem Scala-Entwickler offen, um vertraut wirkende Oberflächen bereitzustellen. Bestechend ist auch die Idee, die Persistenz der Scala-Objekte in einem Java-Framework zu implementieren, und damit auf Bewährtes und gut Dokumentiertes zurückzugreifen.
Gerade hier wird aber auch klar, dass es in Scala meist nicht ganz ohne Java gehen wird. Das muss kein Nachteil sein, kann aber.
Schliesslich wird man um ein gerüttelt Mass an Java-Kenntnissen nicht herumkommen, und letztlich in der Wartungsphase eines Projektes immer beide Technologien vorhalten müssen. Ein Mix aus zwei Sprachen, wie nahe sie auch immer beieinander sein mögen, bedeutet immer auch, dass man bei der Käferjagd über Grenzen springen muss. Steckt man mitten im Debugger und ist an einer Stelle angekommen, an der aus Scala heraus Java-Methoden aufgerufen werden (oder umgekehrt), ist erst mal ein Moment des Innehaltens und Kontextumschaltens angesagt. Selbst, wenn ein Debugger zur Verfügung stünde, der den Übergang nahtlos darstellen könnte, befände man sich auf einem neuen Planeten: hier bin ich nicht mehr in der funktionalen Welt, und die Syntax hier vor mir ist Java, nicht Scala…
Ich will das Thema nun aber nicht überstrapazieren, der geneigte Leser kann sich sicher sein Bild davon machen, was ich meine: spätestens bei der Bearbeitung von Troubletickets ist “die andere Seite” nicht mehr als Black Box akzeptabel, auch wenn sich das ganze beim Entwickeln noch so anfühlen mag. Ich bin, wenn ich an einem Java-Debugger sitze, immer wieder irritiert, wenn dieser mir Quelltext vorenthalten will, aber das ist eine andere Geschichte…
Als Smalltalker kann ich auch das Folgende sehr gut nachvollziehen:
Beispielhaft sei hier nur das Operator Overloading erwähnt. Es hatte mich schon bei C++ begeistert, da ich schon immer fand, dass
a ∙ b + c
deutlich einfacher als
a.mul(b).add(c)
zu lesen ist
Denn in Smalltalk gibt es ebenfalls keine Operatoren, sondern nur Methoden, und es ist gar kein Problem, die Methode + zu überschreiben. Natürlich gibt es Punkte, an denen man wissen sollte, was man tut, wenn man es denn tut, aber das sollte kein Argument gegen Operator Overloading sein. In diesem Kontext sei ein kleines Beispiel aus grauer Vorzeit bemüht:
Kaum war der Jahrtausendwende-Spuk vorüber, und wir waren alle knapp dem Weltuntergang entronnen, versank die IT-Welt in der nächsten Katastrophe: Die Euro-Umstellung (manch einer mag sich nun wieder an lange Nächte, Schlaflosigkeit und vor allem eine gewisse Unruhe im Management erinnern, die zu vielen unerquicklichen Reports und Status Meetings führte) . Millionenbeträge wurden investiert, um Programme fit für die neuen Umrechnungs- und Rundungsregeln sowie die Umstellung in zwei Phasen fit zu machen. In einem Smalltalk-Projekt konnten wir hier mit relativ wenig Aufwand eine Klasse für Geldbeträge einführen, die sich nach aussen hin mit dem API einer Zahl präsentierte, und intern den gesamten Verwaltungskram abhandelte (in welcher Europhase sind wir, bin ich eine Summe aus Beträgen in zweierlei Währungen etc.). Für sämtliche Stellen, die also vorher zwei Zahlen unter Verwendung der Methode + addierten, änderte sich gar nichts. Es musste lediglich dafür gesorgt werden, dass alles, was einen Betrag erzeugte, eben nicht mehr nur eine Zahl instanziierte, sondern ein Objekt der Klasse EuroBetrag. Der Rest des Systems blieb unangetastet. So war der ganze Spuk in ein paar Wochen erledigt (inklusive Tests), und wir konnten neue Features implementieren, während andere Projekte enormen Aufwand treiben mussten.
Also, kurz gefasst: Operator Overloading kann extrem mächtig sein, und enorme Produktivitätsvorteile bieten, wenn man sich sparen kann, jeden einzelnen +-Operator darauf zu untersuchen, ob er nun ein Aufruf der add-Methode der neuen EuroBetrag-Klasse sein muss oder nicht.
Jetzt aber kommt der erste Stolperstein für meine positive Grundeinstellung gegenüber Herrn Wiedekings Artikel, in dem er die aus seiner Sicht großen Vorteile des Operator-Overloadings darstellt. So sieht er es als zusätzlichen Vorteil, dass Scala es erlaubt,
beliebige Unicode-Zeichen als Operatoren zu definieren. So konnte ich beispielsweise beim Herumexperimentieren einen regulären Ausdruck der folgenden Art schaffen:
NUMBER = LPAR ∙ (SP↯) ∙ (ALPHANUM ↦ 0) ∙ (SP↯) ∙ RPAR ∙ (SUBNUM ↦ 1)
Ich muss zugeben, dass meine Kenntnisse in der Erfassung von Unicode-Zeichen über die Tastatur eines heute gebräuchlichen PCs oder Macs sicher verbesserungsfähig sind, aber irgendwie kann ich mich des Gedankens nicht erwehren, dass ich hier verloren ging. Nicht nur, weil ich mathematisch nicht mehr mithalten kann, sondern auch, weil ich hier fast glaube, dass diese Unicode-Sache für Operatoren dann doch etwas zu weit geht.
Wobei das vielleicht nicht für Anwendungen im mathematischen oder Engineering-Bereich gilt. Letztendlich liest sich der Code für einen Mathematiker dann doch sehr gut.
Ich fand das Beispiel allerdings sehr esoterisch und nicht wirklich ein gelungenes Plädoyer für Operator Overloading oder Scala.
Nun kommt Wiedeking aber zu einem sehr interessanten Punkt:
So habe ich also Scala schätzen und nutzen gelernt, habe mich aber trotzdem gegen einen professionellen Einsatz von Scala entscheiden müssen. Das ist insofern bedauerlich, weil Scala einen deutlich höheren Wiederverwendungsgrad hat als beispielsweise Java.
So ging es mir auch: Scala gefällt mir gut, und die Möglichkeiten durch die Java-Basis sind sehr bestechend, aber so recht zu Scala konvertiert bin ich auch (noch?) nicht.Während wir gleich noch auf Wiedekings Argumente gegen Scala eingehen, hier ein paar Gedanken von mir:
Ein Aspekt auf den Wiedeking in seinem Artikel nicht wirklich eingeht, sind die funktionalen Ansätze in Scala, die in vielen Problembereichen sehr mächtige Vorteile sein können. So ist es durch die Nutzung von Konstanten (also vals) anstatt Variablen, und durch die Freiheit von Seiteneffekten bei der Bearbeitung von Konstanten sehr schön möglich, sehr gut lesbaren Code zu schreiben, und vor allem, Funktionen so zu formulieren, dass sie gut in einem eigenen Thread ablaufen können. Scala hilft bei der Parallelisierung von Aufgaben und kann so einen wichtigen Beitrag zur effizienteren Nutzung von Multicore-Prozessoren leisten. Wohlgemerkt, solange man Scala als funktionale Programmiersprache nutzt. Nun sind in meiner Projektpraxis ab und an Aufgaben auszumachen, bei denen man sich eine einfach zu implementierende multithreading-Fähigkeit wünschen würde, aber die Regel ist dies nicht. So wäre es manchmal schön, mitten in einem Smalltalk- oder Java-Programm eine solche Funktion zu formulieren und sie parallel ausführen zu lassen. Aber meist lässt sich dies auch mit den Bordmitteln der Sprache auch schon lösen, wenn auch möglicherweise mit etwas mehr Aufwand. Das halte ich für Vertretbar, wenn es um wenige Tasks in einem Programm geht. Smalltalk-Blöcke sind hier sicher ein hervorragender Ersatz für Funtionen in Scala, da diese in ihrer Eigenschaft als Objekte auch herumgereicht und jederzeit mit anderen Inhalten auswerten kann. Sonderlich weit ist ein Smalltalk-Block von einer Funktion in Scala nicht entfernt. Eines jedoch ist ein Vorteil von Scala: eine Funktion kann als nativer Thread ausgeführt werden. In Smalltalks Green Threads – Modell geht dies nicht. Hier sind noch Ansätze gefragt, die auch eine Unterstützung von Multicores in Smalltalk bringt.
Nun aber zurück zu Wiedekings Argumentation:
Der Grund ist ein ganz anderer: Es ist die Entwicklungsumgebung. Ich gehöre eigentlich zu denen, die, bis es nicht mehr anders ging, mit dem “vi”, “emacs” oder vergleichbaren Editoren gearbeitet haben. Und eine Zeit lang war das auch vollkommen ausreichend. Allerdings hatte sich das schlagartig mit dem Einzug der Refactoring-Fähigkeiten moderner IDEs geändert.
Ja, hier wird es düster um Scala (wie auch um andere der aktuell sehr beliebten Sprachen, etwa Ruby, erlang o.ä.). Zwar gibt es ein Eclipse-Plugin, das einge der heute üblichen Werkzeuge, wie man sie aus Eclipse, IntelliJ oder modernen Smalltalk-Entwicklungen kennt, bietet, aber eben leider keinen guten Eindruck hinterlässt. Ich habe es bisher auf den meisten Eclipse-Installationen nicht (oder nicht vollständig) zum Laufen gebracht, auf denen ich es versucht habe. Und die Tools sind noch weit davon entfernt, den Umfang eines Eclipse-Debuggers oder Smalltalk-Inspectors zu erreichen. Geschweige denn deren Stabilität. Das ist nun irgendwo auch nicht verwunderlich, denn die Tools, mit denen ich das Scala-Plugin vergeliche, sind von einem Heer von bezahlten Programmierern erstellt worden, und nicht von einigen wenigen Enthusiasten, Diplomanden und Doktoranden. Insofern ist es ein unfairer Vergleich zwischen Äpfeln und Birnen. Und dennoch zieht es der Mensch eben vor, ein funktionierendes Werkzeug zu nutzen.
So habe auch ich vorerst das selbe Fazit gezogen wie Wiedeking:
Nichtsdestoweniger werde ich die Entwicklungsumgebungen von Scala im Auge behalten. Und sobald sie meinen Ansprüchen genügen, werde ich nie wieder in Java programmieren müssen.
Nur mit dem Unterschied, dass ich mit Smalltalk deutlich weniger unzufrieden bin, als er mit Java 
So stimme ich Herrn Wiedeking zu, dass Scala als Ersatz für unsere jetzige Umgebung nicht in Frage kommt, aber wir beide beurteilen die Sprache Scala in völlig unfairer Weise über die für sie verfügbaren Tools, anstatt uns mit den Fragen auseinander zu setzen, welche konkreten Vorteile die Sprachmittel von Scala uns gegenüber unserer aktuellen Lieblingssprache bietet. Ich glaube aber, wir sind da nicht die einzigen…
