Die von Professor Martin Odersky (derzeit Swiss Federal Institute of Technology in Lausanne (EPFL)) entwickelte Programmiersprache Scala wird derzeit als Nachfolger von Java heiß gehandelt.

Hier meine Einschätzung zu Scala, ein Review.

Vorbemerkung:

Die meisten Teile dieses Blog-Artikels habe ich im Sommer/Herbst 2010 geschrieben (oder inhaltlich erarbeitet). Aufgrund anderer, dringlicherer Aufgaben und einer Reise ist die Sache dann etwas liegengeblieben. Zudem habe ich überlegt, den Artikel nicht auf deutsch, sondern in meinem geplanten englischsprachigen Blog aufzunehmen, was aber noch eine Weile dauern wird.

Aufgrund einer aktuellen Meldung auf dem Heise Newsticker (vgl. auch diese ältere Meldung der iX zur EU-Förderung) ist mir eingefallen, daß ich da ja noch was liegen habe, was ins Blog will. Da ich nun nicht alles neu nachlesen und ausprobieren möchte, sind einige Aussagen hier auf dem Stand von Herbst 2010 und möglicherweise nicht mehr so ganz aktuell, zumal inzwischen gegenüber der von mir verwendeten Version 2.7.7 zwei neuere Versionen von Scala verfügbar geworden sind, 2.8 und 2.9.

Warum eine Kritik an Scala?

Sprach-Hintergrund und Maßstab

Ich bin Informatiker und habe vor über 30 Jahren mit dem Programmieren angefangen. Mit wievielen Programmiersprachen ich mich bisher befasst habe, weiß ich nicht mehr, über 30 werden es gewesen sein, davon habe ich mit mehr als einem Dutzend konkret programmiert. Ad hoc fallen mir da C, C++, Basic, Pascal, Algol, Modula-2, Occam, Fortran, Cobol, Smalltalk, PL/I, APL, Ada, Occam, Perl, PHP, Java, JavaScript, Tcl, Shell, Postscript, Ruby, Forth, Lisp, Scheme, Prolog ein, dazu Assembler Z80, 6502, 65000, VAX, Sparc, T800, 68000, 56001, MiniMa. (Die Lust am Assembler ist mir allerdings mit dem chaotischen und un-orthogonalen x86-Befehlssatz nachhaltig vergangen.)

Die meisten dieser Sprachen halte ich historisch und evolutionär für sehr wichtig, aber inzwischen für veraltet und eigentlich obsolet – wenn wir denn was besseres hätten. Ihr Nutzen besteht heute darin zu lernen, was man besser machen kann und muß.

Beispielsweise war C damals eine ganz tolle Sprache, die für mich erste, in der man knackig programmieren konnte. Ohne C hätte es kein Unix und damit kein Linux gegeben. Aber C war und ist auch primitiv, kaum mehr als ein verallgemeinerter Assembler. C war eben ein Produkt des Zeitalters der knappen Resourcen – Rechenzeit, Speicher, Compilerzeit, Entwicklungszeit – und der Frühzeit der Programmiersprachen. Was damals ein Riesenfortschritt war, ist heute eine Sicherheitskatastrophe, und die meisten Sicherheitsprobleme gehen auf die in C völlig fehlenden Sicherheitsmechanismen zurück. Die Standardbibliothek ist voller Entwurfsfehler und Sicherheitslücken, und die von C++ ist katastrophal schlecht.

Dummerweise konzentriert man sich heute aber nicht darauf, eine gute Sprache zu produzieren, sondern viele schlechte (Nischen-)Sprachen. Wer was auf sich hält, produziert heute irgend eine Sprache für irgendein Problem und bringt irgendein Buch darüber in den Buchhandel. Allein zum Design von Webseiten müßte man im Prinzip PHP, Java und JavaScript beherrschen, die alle zueinander inkompatibel sind und alle ihre Spracheigenheiten haben. Wenn ich heute in eine gut sortierte Buchhandlung gehe und mir das Bücherregal zu Programmiersprachen anschaue, dann habe ich von vielen der Sprachen, über die da Bücher stehen, noch nie was gehört – und will auch nichts darüber hören.

Außerdem habe ich die Universität 1998 verlassen und bin seither in der Industrie tätig, und habe dadurch eine andere Sichtweise und andere Anforderungsmaßstäbe erlangt (gewonnen). Scala ist dagegen ein Produkt aus dem akademischen Universitätsbereich.

Java

1997 habe ich die damals neue Programmiersprache Java ausprobiert und war von der Idee begeistert, im Browser Mini-Applikationen laufen zu lassen. Damit wollte ich meine Krypto-Vorlesung an der Uni mit Animationen und Experimenten zur Nachbereitung für die Hörer aufpeppen: Handchiffren, die Enigma, Kryptoanalyse usw. wollte ich nicht als dröges Skript, sondern gleich zum Ausprobieren anbieten.

Nach den ersten Applets habe ich mich jedoch mit Grausen abgewandt und Java seither nicht mehr angerührt – viel zu ungelenk, plump, umständlich war Java. Zu deutlich merkte man, daß die Entwickler von Java kein Sprachgefühl und sich nur an C orientiert hatten, und daß nicht der Compiler nach der Sprache gebaut war, sondern umgekehrt die Sprache auf das beschränkt war, was die Macher damals als Compiler zustandebrachten. Schon für einfache und kleine Algorithmen programmmierte man sich in Java die Finger wund, und sehr unleserlich war es obendrein.

Java war keine ordentliche Programmiersprache, sondern ein proof of concept, der zu früh und unreif dem Labor entlaufen war. Ich habe nie verstanden, warum so viele Leute, Firmen, Universitäten auf Java gesprungen sind. Lag es vielleicht daran, daß die meisten Informatiker und Programmierer auf einem so niedrigen Ausbildungsstand sind, daß sie solche stark auf das nötigste beschränkten und simplen Sprachen bevorzugen (was durchaus der Fall zu sein scheint und den Erfolg von C und den sehr fragwürdigen Erfolg von PHP erklärt)? Beruht der Erfolg von Java allein in der Anspruchslosigkeit der Anwender?

Ruby

Die Sprache, mit der ich aktuell am zufriedensten bin, ist Ruby. Ruby ist sehr leistungsfähig, man kann unglaublich dicht und knapp, und trotzdem einfach und sehr lesbar, fehlerarm, beeindruckend elegant, schnell und schön programmieren. Ruby ist in meinen Augen die derzeit mit Abstand geilste Programmiersprache. In Ruby kann man Software so unglaublich prägnant und elegant hinschreiben, daß es eine Freude ist. Dazu kommt eine wirklich gut durchdachte und sehr gut strukturierte und umfangreiche Laufzeitbibliothek. Ruby macht einfach Spaß. Aber Rubys Konzept bringt leider auch deutliche Nachteile mit sich:

• Ruby ist eine Interpretersprache und dadurch sehr langsam.
• Ruby hat keine Typbindung und keine Deklaration, sondern macht alles dynamisch unbekümmert und setzt auf das sog. Duck-Typing. Damit kann man zwar unglaubliche Dinge tun – aber auch deftige Fehler bauen, die jeder Compiler sofort erkennen würde.
• Es gibt keine API-Definitionen (Java: Interfaces). Man schreibt einfach was hin und hofft auf die eigene Disziplin.

Und deshalb „skaliert” Ruby nicht. Zur Man kann keine großen Projekte schreiben. Man klopft irgendwas zusammen und zur Laufzeit zeigt sich dann, ob es geht oder nicht. Grenzenlosigkeit als Philosophie.

Deshalb bin ich auf der Suche nach einer Sprache, die Ruby möglichst nahe kommt, besonders was die Syntax und die Laufzeitbibliothek angeht, aber Rubys Nachteile vermeidet. Also quasi Ruby mit fester Typbindung und API-Definitionen als Compilersprache. Eine ordentliche Sprache, die auch für größere Projekte taugt. Das wär’s.

Odersky gibt zu Scala bisweilen an, sich auch an Skriptsprachen wie Ruby orientiert zu haben, wovon ich allerdings wenig bis gar nichts bemerkt habe. Das scheint mehr eine Marketing-Aussage zu sein. Im Vorgriff auf meine Bewertung muß ich sagen, daß es hier deutlich besser gewesen wäre, gut von Ruby zu plagiieren, als es schlecht selbst zu machen.

Warum nun doch zur Java Virtual Machine und warum Scala?

Im Sommer/Herbst 2010 stand ich vor drei Problemen, die alle auf eine Programmierung unter der JVM hinausliefen:

• Ich wollte mich mit der Android-Programmierung befassen, die auf der JVM aufbaut (genauer gesagt wird dort eine andere Maschine verwendet, aber der Code aus JVM-Code erzeugt, man braucht eine Sprache für die JVM).
• Ich habe überlegt, mein Blog auf einen Java Servlet Container wie Tomcat zu portieren, weil mir das in PHP geschriebene WordPress auf den Wecker geht.
• Ich habe damals als Security Manager Schulungen für Webapplikationsprogrammierer geplant, die in Java für Servlet Container programmierten, und mir überlegt, wie ich denen bessere und sicherere Programmierwerkzeuge anbieten kann.

So kam ich trotz meiner Abneigung zwangsläufig wieder zur JVM zurück.

Welche Sprachen bleiben für die JVM? Java selbst finde ich grauslich. Groovy? Nicht ganz schlecht, aber der irgendwie mißlungene Versuch, Ruby mit Java-Syntax zu kreuzen. Ein Nischenprodukt ohne große Zukunftsaussicht, als langsam berüchtigt. JRuby? Käme mir sehr gelegen, weil Ruby auf der JVM, es erzeugt aber keine Java-Klassencode, ist nur schwierig mit anderen Java-Bibliotheken zu verbinden, gilt als langsam und hat wieder die benannten Ruby-Schwächen. Clojure? Ein Lisp-Dialekt. Schauderhaft. Bleibt derzeit also nur Scala.

Scala wird als der Nachfolger von Java hochgejubelt. Was nicht viel heißt, denn fast dieselben Leute haben vorher schon über Java gejubelt, obwohl Java keinen Anlaß zu Jubel gab.

Verwendete Dokumentation zu Scala

Ich habe zum Testen Scala 2.7.7 unter Ubuntu 10.04 und 11.04 und folgende Doku herangezogen (es gibt inzwischen aber weitere freie und käufliche Werke):

Kostenlos zum Herunterladen

• Scala Overview
• Scala Reference Manual
• Scala by Example

Martin Odersky u.a.: Programming in Scala

Ich hatte mir zuerst die erste Auflage (als PDF) gekauft, meine Kritik hier beruht wesentlich auf dieser Auflage. Nach dem Schreiben der meisten Teile dieses Artikels habe ich mir auch die zweite Auflage gekauft, aber keine Lust gehabt, das alles nochmal durchzuarbeiten, weshalb sich die Kritik, die Hinweise und die Seitenzahlen noch auf die alte, erste Auflage beziehen.

Allgemeine Kritik

Hier zunächst eher allgemeine Kritikpunkte.

Absurde Komplexität

Für gewöhnlich lese ich ein Buch über eine neue Programmiersprache an einem Wochenende durch. Dazu schaue ich mir zunächst die Syntax-Beschreibung und die Grundelemente der Syntax an, wie „sieht” die Sprache so aus. Dann lese ich mir in der Dokumentation die Beschreibungen der einzelnen Syntaxelemente durch, die für gewöhnlich in den Büchern zu den Programmiersprachen nach einer Einführung und manchmal einem Kurzüberblick („Hello World!”) hintereinander dargestellt werden. Dazu schaue ich mir dann die Beispiele an und probiere diese aus. Wenn ich das im Griff habe, schaue ich mir die verfügbaren Standardbibliotheken an. Normalerweise habe ich dann nach ein paar Stunden oder Tagen eine neue Programmiersprache so weit drauf, daß ich schon mal anfangen kann, darin zu programmieren. Wenn ich dann mal zwei oder drei Wochen oder Monate in der Sprache programmiert habe, hat sich das Gehirn dann soweit auf den neuen Sprachstil eingestellt (falls es denn überhaupt einen neuen gibt und es nicht der 147. Aufguß einer einfachen prozeduralen Sprache ist, die sich durch nichts als neue Syntax-Varianten von den anderen 146 unterscheidet), daß ich das, was ich bisher in der Sprache geschrieben habe, als nicht richtig zum Stil passend auffassen und korrigieren oder neu schreiben kann oder will.

Bei Scala war das ganz anders.

An dem Scala-Buch von Odersky habe ich wochenlang herumgelesen, immer mal so ein paar Seiten, ohne wirklich voranzukommen. Dadurch bin ich in die dumme Situation gekommen, daß ich im hinteren Ende noch nicht so viel über die Sprache wußte, um beim Programmieren loslegen zu können, während ich schon wieder vergessen habe, was ich vorne gelesen habe, weil ich es noch nicht einsetzen konnte.

Das hat im wesentlichen zwei Ursachen. Einmal die grottenschlechte und vermurkste Dokumentation Oderskys über „seine” Programmiersprache, dazu aber unten mehr.

Und zum anderen eben die Komplexität – nein, eigentlich muß man sagen Kompliziertheit – der Sprache. Scala enthält diverse Sprachkonstruktionen, die nicht nur schwer zu verstehen sind (was auch daran liegt, daß die Komplexität von Scala weitaus höher als die didaktischen Fähigkeiten von Odersky sind, Scala verständlich darzustellen), sondern die in ihrer Denkweise so komplex sind, daß sie für eine Programmiersprache kontraproduktiv wirken.

Ich habe nichts gegen komplexe Programmelemente. Aber sie müssen sich als Vorteil und nicht als Nachteil erweisen. Das heißt,

• Eine allgemeine Sprache sollte auch für allgemeine Anwendungen gebaut sein. Sprachelemente sollten nicht zur Lösung bestimmter Nischenaufgaben aufgenommen werden – oder zumindest nur zusätzlich zu einem allgemeinen Sprachstock.
• Es sollte eine klare Trennung zwischen der eigentlichen Syntax und Semantik der Sprache selbst, und der Standardbibliothek geben, auch wenn letztere zur Sprache gehört.
• Der Arbeitsaufwand zur Nutzung der komplexen Elemente muß niedriger sein, als wenn man es als geübter Programmierer von Hand mit einfachen Standardelementen ausprogrammiert. Es muß die Arbeit erleichtern, und nicht belasten.
• Es muß so übersichtlich und verständlich sein, daß die komplexen Elemente gegenüber den einfachen Standardelementen das Programm leichter lesbar machen und die Gefahr von Programmfehlern vermindern.
• Der Aufwand zum Erlernen – und damit die Schwelle – darf nicht zu hoch sein, denn eine Programmiersprache darf nicht nur dem akademischen Lustgewinn dienen, sondern muß auch betriebswirtschaftlichen Anforderungen genügen.
• Der Portierungsaufwand zwischen den Sprachen – also von und zur Sprache X – darf nicht zu hoch sein. Eine Sprache sollte nicht auf Sprachelementen beruhen, die nur mit großem Aufwand in anderen Sprachen nachzubilden wären, damit man keine Programme schreibt bzw. Algorithmen entwickelt, die nur in genau dieser einen Sprache funktionieren.

Scala erfüllt diese Anforderungen in meinen Augen nicht. Scala macht aus mehreren Gründen auf mich nicht den Eindruck einer systematischen, geschlossenen Programmiersprache, sondern den eines Compilergerüstes, in das man verschiedene Sprachkonstrukte unterschiedlicher Herkunft eingehängt hat, die eher dem Laborversuch, als dem professionellen Programmieren dienen, und die dem zwanghaften (Forschungs-)Druck entstammten, unbedingt Neuigkeiten statt Bewährtem bieten zu müssen. Ich werde dies weiter unten in einigen Details aufgreifen und näher beleuchten.

Generell halte ich Scala deshalb derzeit für nicht wirklich einsetzbar. Nicht, weil man als Informatiker Scala nicht lernen könnte. Kann man schon. Sondern weil es im großen Maßstab, für Industrieanwendungen, im Bereich des bezahlten Massenprogrammierens, nicht effektiv und kosteneffizient einsetzen kann. Den Schulungs- und Kapier-Aufwand schätze ich als betriebswirtschaftlich zu hoch ein, und ich glaube, daß so manche Programmiertruppe (und die bestehen ja meist nicht aus studierten Universitätsinformatikern) damit überfordert ist. Nicht umsonst gehören ganz einfache Sprachen wie C, Java, PHP zu den meistverwendeten. Man braucht daher schon eine gewisse Rechtfertigung, um eine so komplexe Sprache zu bauen.

Schlechte Dokumentation

Oderskys u.a. Buch: Programming in Scala

Eine wesentliche Ursache für meine schlechte Meinung von Scala ist das Buch über Scala, das von Odersky selbst (und anderen) stammt. Das Buch ist herzlich schlecht.

Ich habe hier weit über ein Dutzend Bücher über verschiedene Programmiersprachen im Regal stehen. Die folgen mehr oder weniger alle demselben Schema: Einführung mit „Hello World!”, Kurzüberblick, Vorstellung der Sprachelemente und Grunddatentypen, eins nach dem anderen, mitunter noch eine Sprachreferenz, und eine Übersicht oder Referenz der zur Sprache fest gehörenden Standard-Bibliothek. Das ist schnöde, einfach, billig, ausgelutscht, einfallslos – und sehr bewährt. Es funktioniert einfach. Man kann es schnell lesen, man kann direkt dahin springen, wonach man sucht, man findet sich zurecht.

Das Buch von Odersky hingegen ist anders aufgebaut. Und es funktioniert so nicht. (Ich habe zwar auch die zweite Auflage, aber ich fand schon das Lesen der ersten so zäh, langatmig, schwergängig, daß ich mir das nicht ein zweites Mal antun wollte und mich daher hier auf die erste Auflage beziehe. Die zweite scheint aber nicht besser, sondern nur 100 Seiten länger zu sein.)

Ein Hauptproblem des Buches ist seine Struktur. Das sieht nicht wie ein Lehrbuch oder eine Einführung aus, sondern als ob es aus Vorlesungsfolien oder einem Vorlesungsskript entstanden wäre, wie man am Inhaltsverzeichnis sieht. Da wird ein Thema nach dem anderen in etwa 30 Kapiteln behandelt, und das dann auf jeweils 20-30 Seiten durchgekaut, gerade so, als wäre das Buch eine Mitschrift aus einer 15-wöchigen 4-SWS-Vorlesung. Und innerhalb der Kapitel wird dann ein Thema in zäher Prosa zerrieben, eben als ob man eine 90-Minuten-Vorlesung mit Blabla zu füllen hätte.

Will man sich mit diesem Buch in Scala einarbeiten, muß man den ganzen Schmonzes von vorne bis hinten lesen – 700 Seiten in der ersten Auflage, 800 in der zweiten. Wer soll denn das alles lesen? Man findet auch nicht wirklich was in dem Buch, weil das alles irgendwo in diesem riesigen Sprachschwall versteckt ist. Eine Sprachreferenz? Eine Übersicht der Syntax? Fehlanzeige. (Kann man allerdings separat und kostenlos runterladen.) Oder mal eine saubere, nach Klassen geordnete Übersicht der Standardbibliothek? Is nich.

Das zweite Problem des Buches ist, daß Odersky, bzw. die Autoren, sich nicht entscheiden konnten, ob sie eine Einführung in die Programmiersprache Scala oder ein Evangelium für einen gewissen Programmierstil schreiben wollten. Das ganze ist ein fürchterliches Gemisch aus einer kaum strukturierten, nur aufzählerischen Beschreibung von Scala und ständigen Ermahnungen und Erleuchtungen, wie gutes Programmieren nach Meinung der Autoren aussehen sollte. Das wirklich Dumme daran ist, daß das nicht wirklich gut ist (dazu unten mehr). Diese Vermischung aus zwei völlig unterschiedlichen Themen und Büchern macht dieses Buch so unglaublich langatmig und schwer zu lesen. Die hätten viel besser daran getan, das auf zwei Bücher aufzuteilen, eines über Scala und eines über den von ihnen favorisierten Programmierstil. Dann könnte man das erste flott lesen und das zweite einfach wegwerfen.

Das dritte Problem hängt mit dem zweiten zusammen. Was mich beim Lesen unheimlich genervt hat, war der immer wieder aufflammende missionarische und oberlehrerhafte Stil, der einem einen bestimmten Programmierstil aufdrängen will. Nun habe ich zwar nichts dagegen, wenn jemand guten Programmierstil lehren will, das tut tatsächlich not. Aber ich hatte den beständigen Eindruck, daß weder Scala, noch die Programmierfähigkeiten der Autoren auf einem Niveau sind, bei dem man sich dieses belehrende und besserwisserische Auftreten leisten könnte.

Oder anders gesagt: Die Autoren – wohl vor allem Odersky – leiden unter dem „Schaden”, den sie sich durch den dauerhaften Aufenthalt im Elfenbeinturm geholt haben. Man merkt überaus deutlich, daß die sich hier einen universitätstypischen Vorlesungsstil vor einem Zwangspublikum, das weder fliehen noch kritisieren oder in Frage stellen kann, angewöhnt haben. Wie jemand, der schon so lange aus dienstlicher Stellung heraus Recht hat (weil er in Prüfungen willkürlich selbst beurteilt, was richtig und was falsch ist), daß er inzwischen schon fest glaubt, wirklich Recht zu haben. Wie Vogonen, die vogonische Dichtkunst vortragen.

Dieses Buch entspricht ganz dem Stil der Universitätsbücher, die man nicht kauft, weil sie gut sind oder man will, sondern weil sie auf der Literaturliste der Vorlesung stehen, man sie für die Prüfung braucht (und vielleicht einen Hörerschein bekommt).

Ich kenne die alternativen Bücher der einschlägigen Verlage nicht, aber würde einfach mal blind tippen, daß die viel besser sind, weil die auf normales Publikum ausgerichtet sein müssen.

Das vierte Problem ist nicht spezifisch, sondern ein Problem, was ich im Bereich der IT-Bücher und auch der Open-Source-Szene immer häufiger beobachte: Die Leute können nichts mehr erklären. Stattdessen werden immer mehr und fast nur noch Beispiele gebracht.

Das scheint seinen Ursprung einmal in der amerikanischen Publikationsmode zu haben, bei denen man durch viele Beispiele die Bücher immer fetter aufblähte, während man immer billigere Autoren einstellt, denen die Erklärfähigkeiten fehlen, aber auch in dem anspruchsloseren Massenpublikum. Und in Windows. Seit Windows sind diese Lehrmaterialen groß in Mode gekommen, in denen man gar nichts mehr erklärt (wie auch bei Windows…), sondern nur noch seitenweise Screenshots zeigt, wo man hinklicken soll.

Auch im Scala-Buch von Odersky u.a. fällt mir immer wieder auf, daß sie Strukturen aus Scala nicht erklären, sondern nur vorführen. Hier, so sieht die Struktur aus, probier mal das und jenes, achte auf dieses, das und das sollst Du tun. Ich hatte immer wieder das Problem, daß ich mehrfach vor- und zurücklesen mußte, weil die da im Buch irgendwas vorturnen ohne zu erklären, was da genau abläuft. Entweder soll der Leser anhand des Beispiels selbst erahnen, was da abläuft (was etwa bei den Case Classes so nicht funktioniert), oder er soll es nicht verstehen, sondern einfach tun, was man ihm sagt.

Ich habe – gerade auch wegen der inkonsistenten und überladenen Struktur von Scala – den schweren Verdacht, daß die das bisweilen selbst nicht so richtig verstanden haben und erklären können, weil Scala wohl nicht systematisch, sondern organisch gewachsen ist und sie den Status Quo, aber nicht die Konstruktionsgedanken beschreiben können.

Gerade bei einer komplexen Struktur wie den Case Classes hätte ich erwartet, daß die einfach mal hinschreiben und verbal erklären, was das Ding eigentlich genau macht. Nöh. A simple example, dann wird alles mal vorgeführt, am Schluß ein larger example. Und das Einführungspaper „Scala by Example”. Auch im Reference-Manual gibt es jede Menge Syntax-Bäume und Examples. Aber keine Erklärung, was das System da eigentlich treibt.

Scala by Example

Völlig vom Stuhl gehauen hat mich dann das Paper Scala by Example von Odersky selbst. Sowas abgedreht Bizarres ist mir da noch nicht untergekommen. Als ich das gelesen habe, ging mir unwillkürlich durch den Kopf, daß so ein Autist schreiben würde.

Tatsächlich ist es aber eher so, daß das Paper nicht an die Öffentlichkeit gerichtet ist, sondern auf eine sehr kleine Zahl von Lesern aus einer spinnerten Professorenschaft ausgerichtet ist, von denen jeder so sein persönliches Steckenpferd hat, deshalb irgendeine Exotensprache favorisiert und damit sein Studentenschaft zu dieser Sprache zwingt.

Irgendwo anders stand, daß Scala diesen Zoo aus Akademiker-Sprachen ablösen und durch eine Standardsprache ersetzen soll (was ich als zentralen Entwurfsfehler von Scala ansehe). Man merkt beim Lesen des Papers förmlich, wie Odersky so reihum einzelne Wissenschaftler damit anspricht und jedem darlegt, daß auch sein persönliches Steckenpferd und Hobby in Scala aufgenommen wurde und er deshalb von seiner bisherigen Lieblingssprache zu Scala wechseln kann.

Anstatt einfach mal ein paar vernünftige Beispiele zu bringen (wie der Titel verheißt), kommt nur theorielastiges Zeug.

Da wird gleich zu Anfang mit Actors und Messages herumhantiert, was für mich beim ersten Lesen schlichtweg nicht nachvollziehbar war. Zudem war für mich nicht klar, was der Vorteil dessen gegenüber einer herkömmlichen Objekthierarchie sein soll.

Später kommt ein lausiges Beispiel dafür, wie Scala die (angebliche) Rekursion für factorial (Fakultät) von Scala in eine Endrekursion aufgelöst und abgewickelt wurde. Was Bockmist ist, denn die Funktion für die Fakultät ist eigentlich keine Rekursion sondern eine Iteration. Und diese durch funktional-dämliches Programmieren erst zur Rekursion zu machen um sie dann vom Compiler per Endrekursion wieder aufwickeln zu lassen, ist blöde. Aber da mußte wohl auf Teufel komm raus ein Beispiel für Endrekursionsauflösung rein, um irgendwen von Scala zu überzeugen, der auf sowas steht.

Ein anderes schlechtes Beispiel ist 5.2 Currying. Schon mal gehört, den Begriff? Ich bis dahin jedenfalls nicht. Odersky schafft es, ein ganzes Kapitel über Currying zu schreiben, ohne ein einziges Mal zu sagen (bzw. erst am Ende anzudeuten), was das eigentlich genau ist. Woran man schon merkt, welche enormen didaktischen Probleme Odersky haben muß. Ich hab’s damals mal nachgelesen. Ist nicht wichtig, braucht man im Normalfall nie. Es hat mit mathematischen Funktionenklassen zu tun und erfüllt folgende drei Zwecke:

• Akademische Selbstbefriedigung
• Die Verwirrung zu heben und die Lesbarkeit zu senken, auf Kosten der Fehleranfälligkeit
• Programme zu schreiben, die man nicht in andere Sprachen portieren kann

Was soll der allgemeine Leser mit so einem Beispiel wie dem zu Currying anfangen können? Das ist ganz offensichtlich auf einen ganz eng beschränkten Anwenderkreis – vornehmlich der Mathematik – und vermutlich auf ein oder zwei Zielpersonen ausgerichtet, die von Currying feuchte Träume bekommen und deshalb bisher auf irgendeine Spezialsprache abfahren.

Dazu kommt eine ziemlich verquaste Wissenschaftssprache, die vor lauter Exaktheit kaum in der Lage ist zu sagen, was sie will. Da steht jemandem seine eigene „Wissenschaftlichkeit” im Weg, von der dann auch nicht mehr viel übrig bleibt als nur die Unfähigkeit, sich noch normal auszudrücken. Dieses Paper hinterläßt bei mir außerdem den nachhaltigen Eindruck, daß Odersky nicht zwischen Theoretischer Informatik, akademischer Softwaretechnik und einer realen Programmiersprache unterscheiden kann (und will).

An welches Publikum schreibt der eigentlich?

Den Zweck, jemanden vom Gebrauch der Sprache zu überzeugen, dürfte das Paper wohl nur bei einer Hand voll akademischer theoretisch orientierter Käuze erfüllen. Auf die Mehrzahl der Leser dürfte das Paper ziemlich abstoßend wirken. Nicht mal mir macht sowas Spaß, obwohl ich Informatiker bin und mich früher durchaus sehr für theoretische Informatik begeistert habe.

Wenn ich mir allerdings vorstelle, daß ich mit diesem Paper in eine Firma gehen und gewerbliche Programmierer davon überzeugen sollte, auf Scala umzusteigen – die würden mich auslachen und für verrückt erklären. Ich habe eingangs geschrieben, daß einer der Gründe, mich mit Scala zu befassen, war, daß ich damals eine Reihe von Sicherheitsschulungen für ein Rudel Java-Programmierer in einer Firma geplant hatte. Hätte ich denen sowas vorgeschlagen, wäre der Workshop geplatzt.

Als nützlich erscheint mir dieses Paper nur in einer Hinsicht. Man bekommt anhand der Beispiele ein sehr deutliches Gefühl dafür, welche Sichtweisen und Motivationen hinter der Entwicklung von Scala stehen – und warum Scala daran leidet, woran es leidet. Insofern ist der Titel „Scala by Example” gar nicht mal so verkehrt. Nur anders, als der Autor sich das dachte.

Fragwürdige Standard-Bibliothek

Zwar betonen die Autoren im Buch mehrfach, daß viele Sprachelemente in Wirklichkeit nicht Teil der Syntax seien, sondern nur Teil der Standard-Bibliothek, die unter Ausnutzung von Scala so wirkt, als wären es Syntax-Elemente.

Aus technischer Sicht ist das keine schlechte Idee. Irgendwelche Sonderlocken in die Bibliothek zu packen ist immer besser, als in die Sprache selbst irgendwelche Spirenzchen einzbauen.

Schlecht daran ist aber, daß im Buch dann nicht klar dargestellt und vor allem nicht inhaltlich unterschieden wird, was nun Sprache und was Standard-Bibliothek ist. Denn aufgrund der unsystematisch-aufzählenden Struktur des Buches und der Komplexität (um nicht zu sagen Undurchsichtigkeit) der Sprache, kann man das nicht ohne weiteres selbst ersehen, wenn man die Sprache noch nicht ganz genau kennt.

Und dann kommt eben dazu, daß die Autoren nicht erst die Sprache und dann die Bibliothek, sondern nach Kraut und Rüben schreiben (bzw. sich an ihrer Programmierstilmission hochziehen). Insofern ist es ziemlich schwer, sich da ein Bild über die Standard-Bibliothek zu machen. Die Autoren machen jedenfalls kein schlüssiges Bild.

Insgesamt macht das, was ich nun für diese Bibliothek halte, auf mich einen ziemlich aufaufgeräumten, inkonsistenten, unlogischen und damit vermurksten Eindruck. (Vor allem, wenn man die exzellente und hervorragend strukturierte Bibliothek von Ruby gewöhnt ist.)

So gibt es vom Datentyp der linearen Sammlung nicht ein oder zwei, sondern sage und schreiben mindestens (evtl. mehr) 10 verschiedene Datentypen, nämlich

• array
• list
• listbuffer
• arraybuffer
• mutable queue
• immutable queue
• mutable stack
• immutable stack
• strings
• tuples

und alle sind sie zueinander inkompatibel. Mal fügt man neue Elemente mit += an, mal mit enqueue und mal mit ::. Und man findet sie nicht einmal beieinander oder im Vergleich im Handbuch, sondern das eine ist mal da und so, das nächste woanders und anders beschrieben, und so weiter. Man muß das ganze Buch lesen, um an allen mal vorbei zu kommen, und dann ist man auch nicht schlauer, sondern nur verwirrt. Daß man die vielleicht mal alle in einem Kapitel zusammenstellt und tabellarisch deren Eigenschaften und Operatoren vergleicht, das kommt denen wohl nicht in den Sinn. Es riecht danach, als ob diese diversen Datentypen von verschiedenen Leuten implementiert wurden, die sich nicht miteinander abgesprochen haben (die Sache mit den Köchen und dem Brei).

Als Informatiker würde ich sagen, daß das so richtiger Murks ist. Vor allem sollte man die Implementierung immer von der Schnittstelle trennen, das heißt, daß man nur eine Art hat, einen Array zu benutzen, und dann beim Anlegen über einen Parameter auswählt, welche Implementierung dahinterstecken soll. Aber nicht so, das ist einfach nur Mist. Das ist, als hätte jemand im Labor verschiedene Dinge experimentell ausprobiert und hinterher nicht saubergemacht, sondern den Dreck liegen lassen.

Daß man hier mehrere Datentypen braucht, ist unvermeidlich, denn man muß ja auch die alten Datentypen zur Kompatibilität mit Java unterstützen. Aber so viele neue Typen müssen es nicht sein. Und daß jede dieser Listen andere Operatoren verwendet, ist unvertretbar.

Wie inkonsisent das alles ist, merkt man auch an vielen Unlogiken. So haben sie Listen wie in LISP, wo man mit :: zusammenkleistert und mit car und cdr herumhantiert, einen erheblichen Aufwand treiben muß, um das vorderste Element zu entfernen, oder nicht trivial am Ende anhängen kann. (Sie empfehlen allen Ernstes, die Liste verkehrtherum aufzubauen und dann am Ende zu invertieren, weil das einfacher wäre. Solche Listen besser zu implementieren ist eine Übungsaufgabe für das Vordiplom.) Auch hier wieder das Problem, daß sie Datentyp und Implementierung nicht auseinanderhalten können.

Man muß allerdings dazusagen, daß ich auf der Scala-Webseite letzten Herbst irgendwo eine kurze Notiz gesehen habe (ein ganz kurzes Paper), wonach man selbst damit unzufrieden sei, das Problem erkannt habe und an einer Verbesserung arbeite. Leider finde ich das Paper gerade weder bei meinen Downloads, noch auf dem Server wieder.

Aber so programmiert man das nicht. Das ist Pfusch.

Seltsamkeiten

Was ich im Zusammenhang mit diesen Datentypen auch nicht verstanden habe: Eine immutable Map braucht kein Import, sondern ist der Sprache allgemein bekannt. Eine mutable Map braucht einen Import. Beide heißen aber Map. Wie kommt man an die immutable Map, falls man einmal die mutable Maps importiert hat? (vgl. Buch 1. Auflage Seite 84)

LISP

Scala stinkt an zu vielen Stellen nach LISP. LISP ist nicht gesund. Und LISP ist auch nicht toll.

Rechtslage

Was mir auch nicht klar ist, weil ich mehrfach danach gesucht aber nichts gefunden habe, ist die Urheber-, Nutzungs- und Lizenzlage.

Wenn man in Scala Software schreibt, hat man zwangsläufig Code-Stücke aus dem Compiler, der Laufzeit- und der Standard-Bibliothek im Code. Brauche ich eine Lizenz, um das kommerziell zu nutzen?

Ich habe nichts dazu gefunden. Zwar hab ich irgendwo gelesen, das wäre Open Source. Das sagt aber nicht viel, und greifbar gefunden habe ich es auch nicht.

Gefunden habe ich, daß man den Compiler selbst weitergeben darf, man darf ihn also etwa auf eine Linux-Distribution mit draufpacken.

Darf ich aber Scala beruflich nutzen und das Kompilat dann verkaufen? Muß ich den Quelltext dann beilegen? Dazu habe ich bisher gar nichts gefunden. Und so ist das dann nicht ernsthaft nutzbar.

Und wie das mit der Java Virtual Machine und den Rechten am Java Code nach der Übernahme von Sun durch Oracle weitergeht, und ob man das weiterhin frei benutzen kann, ist auch unklar.

Unter diesen Rahmenbedingungen erscheint es mir als riskant, Software unter Scala zu entwickeln, die dann nur schwer auf andere Sprachen portierbar ist.

Akademisch

Das größte Problem von Scala ist die Herkunft aus dem akademischen/universitären Bereich und die negativen Auswirkungen, die das hatte. Scala ist viel zu sehr an der Denkweise der theoretischen Informatik und der wissenschaftlichen „Softwaretechnik” ausgerichtet, um eine zum allgemeinen Programmieren taugliche Sprache zu sein (was als Widerspruch paradox wirkt). Daß sich diese Universitätsherkunft auf die Dokumentation negativ auswirkt, habe ich schon angesprochen. Daß es sich auch auf die Sprache selbst negativ auswirkt, will ich hier und den nachfolgenden Abschnitten (wie dem zum Funktionalen Programmieren) erläutern.

Ein Brei, entworfen von vielen Köchen verdorben zu werden

Scala macht in dreierlei Hinsicht auf mich den Eindruck, daß es ein Brei ist, der von vielen Köchen verdorben wurde.

Der erste Eindruck ergab sich schon aus der Dokumentation und dem oben beschriebenen Anbiedern an verschiedene Lehrstühle oder „Schulen”, um als Substitut für möglichst viele derer speziellen Nischenprogrammiersprachen dienen zu können und akzeptiert zu werden. Scala ist gebaut, um von allen diesen fremden Köchen mit ihren unterschiedlichen Stilen akzeptiert zu werden, und verzettelt sich damit in unterschiedlichen Paradigmen. Scala will alles sein und alles machen, aber das Ergebnis ist leider, daß es nichts davon richtig macht. Obwohl Scala eigentlich keine Gremiensprache ist, wird es so quasi zu einer gemacht (nur daß die Gremienmitglieder nichts davon wissen, weil jemand anderes ihre Vorlieben nachbaut). Sowas hatten wir schon mal, es hieß Ada und sollte hundreds of programming languages then used by the DoD ersetzen. Ada lebt noch, aber führt ein Nischendasein, und seine Sprachelemente wurden nie ganz genutzt.

Der zweite Eindruck ergibt sich aus der inkonsistenten und unsystematischen Zusammenstellung von Sprachelementen und Bibliotheksfunktionen in Scala. Ich habe oben schon das Problem der zehn verschiedenen Typen von Sammlungen angesprochen. Sowas wirkt, als hätten da mehrere Leute unabgesprochen verschiedene aber ähnliche Sachen windschief implementiert und das dann halt alles mit reingeworfen.

Der dritte Eindruck ergibt sich daraus, daß der Scala-Compiler erweiterbar ist, daß man neue Sprachelemente (sogar selbst) hinzufügen kann. Das erschien mir anfangs wie eine sehr gute Idee. Als ich aber mal gemerkt habe, wie zusammengewürfelt Scala ist, kam mir dann doch der Verdacht, daß da der Chef nur das Gerippe, das Grundkonzept hingestellt hat, und dann – wie das an Uni-Instituten eben so läuft, vor allem, wenn der Chef von Uni zu Uni durch mehrere Länder reist – und dann viele Mitarbeiter damit beschäftigt sind, und die – wie das an der Uni eben so läuft – keine Projekterfahrung haben, sondern jeder so für sich vor sich hinpuzzelt. Das wirkt auf mich, als habe da jemand zentral nur das Compilergerüst vorgegeben, und dann hätten Hinz und Kunz drin eingehängt, was sie gerade cool fanden. Das würde erklären, warum der Compiler erweiterbar ist – so ist er von Anfang an gebaut. Als Labor- und Experimentalplattform für den Compilerbau, nicht als Programmiersprache für die Welt. Und dann lief das womöglich, wie mit den Büchern der Professoren: Der Professor gibt den Titel und die Rückenbindung vor, die Mitarbeiter machen die Arbeit Kapitelweise, ohne sich abzusprechen, und am Schluß erscheint es unter dem Namen des Professors.

Akademische statt realer Ziele

Je mehr ich mich in Scala eingelesen habe, desto stärker kamen mir Assoziationen aus dem Universitätsbetrieb an einer Informatik-Fakultät. Man kann förmlich spüren, welche Aufgaben und Tätigkeiten eines typischen Informatik-Instituts mit den Eigenschaften von Scala korrespondieren:

• Viele Eigenschaften von Scala und viele Beispiele aus dem Handbuch schreien geradezu danach, für Übungsaufgaben in Informatik-Vorlesungen des Vordiploms Bachelors verwendet zu werden. Dieses Muster aus kleinen nutzlosen realitätsfernen Knobelaufgaben wird da immer wieder erkennbar. Und ich hatte immer wieder den Eindruck, daß Scala auch nicht für viel mehr als diese kleinen Programmieraufgaben taugt, sondern genau daran entlangentwickelt wurde.
• Die schon oben erwähnte Modularität und Erweiterbarkeit des Compilers ist zwar an sich schön, brachte aber einen heterogenen Brei hervor. Im Zusammenhang damit drängt sich mir der Eindruck auf, daß Scala als Experimentalplattform, nicht als Programmiersprache entwickelt wurde, und das Ziel hat, für möglichst viele Papers, Diplomarbeiten, Dissertationen Themen zu generieren. Da sind Sachen in Scala, bei denen ich nicht weiß, was die in einer Programmiersprache zu suchen haben und wozu sie gut sind. Vielleicht sind sie nur das Thema eines Papers?
• Wie oben ebenfalls schon erwähnt, soll Scala offensichtlich (und erklärtermaßen) einige andere Sprachen ablösen und dazu eine Art Obermenge der charakteristischen Eigenschaften bilden, damit jeder Verfechter der anderen Sprachen seine Pläsierchen wiederfindet und zu wechseln bereit ist. So war ich ziemlich (aber nicht positiv) überrascht, als da plötzlich LISP-artige verlinkte Listen auftauchten.
• Ein wesentliches Konstruktionsmerkmal von Scala dürfte auch gewesen sein, daß der Compiler sich selbst übersetzen kann bzw. den Compiler selbst in Scala zu schreiben. Wenn ich mir die Case Classes und Pattern Matches anschaue, dann fällt mir nicht so allzuviel ein, wofür das gut ist. Gut allerdings für die Optimierung im Compilerbau und Formelevaluatoren wie etwa in Algebrasystemen.
• Einwerben von Drittmitteln

Wär ja alles schön und gut. Nur eine gute, allgemeine, leicht verständliche, für ein großes Anwenderpublikum zugängliche, robuste, fehlerarme Programmiersprache zu bauen, das scheint nicht Entwurfsziel gewesen zu sein.

Schlechte Lesbarkeit

Ich halte Scala für schlecht lesbar, was ich als schweren Nachteil betrachte.

Geschweifte und andere Klammern

Ich hasse geschweifte Klammern. Aus zwei Gründen.

Der erste ist, daß sie auf der deutschen Tastatur (und übrigens auch vielen anderen nicht-amerikanischen) nur schwer erreichbar sind, man so einen Affengriff einsetzen muß und das den Schreibfluss hemmt. Ich schreibe schneller begin oder end als eine geschweifte Klammer.

Der zweite ist, daß ich es für sehr schlecht lesbar und für unübersichtlich halte. Klammern bilden kein optisches Gleichgewicht zur Anfangsanweisung einer Klammer, und das Auge muß lange suchen (und womöglich noch anfangen zu zählen), bis man zu einer Klammer das Ende findet.

Scala produziert ziemliche Klammernhaufen. Nicht so schlimm wie Java oder LISP, aber immer noch zu schlimm. Viel zu schlimm.

Dazu kommt, daß Scala auch die anderen Klammern in ungünstiger Weise verwendet. Die eckigen Klammern dienen im wesentlichen dazu, Typparameter zu übergeben. Damit bleiben für alles andere nur die runden Klammern. Egal ob man Formeln klammert, parametrisiert, indiziert, Listen, Arrays, Maps oder Tupel bildet, alles mit runden Klammern. Von einem gewissen funktionalen Standpunkt aus ist das durchaus logisch, weil das ja alles Parameter sind. Aber ich finde es scheußlich zu lesen. Ich empfinde es als viel angenehmer, Indexe und Listen mit eckigen Klammern zu bauen, so wie etwa die deutsche Grammatik auch nicht durchgehend logisch ist, aber die Unlogiken das Lesen erleichtern. Man braucht viel zu lange, um den Aufbau eines Programmstückes optisch zu erfassen.

Ich verstehe nicht, warum so viele an diesen Klammernhaufen hängen. C hat das eingeführt, C++ weitergeführt, Java hat es von C abgekupfert und verschlimmert, und Scala orientiert sich daran. Ruby zeigt, daß das alles deutlich einfacher und lesbarer (und damit viel weniger fehlerträchtig) funktioniert.

Keine einfache Syntax

Im Buch wird behauptet, Scala habe eine ganz einfache Syntax, und alles würde sich daraus ergeben. Ich halte die Syntax nicht für einfach. Im Buch gibt es diverse Beispiele, bei denen man eine ziemliche Weile braucht, bis man sie syntaktisch verstanden hat. Es ist ein Unterschied, ob eine Syntax für den Compiler oder für den Menschen leicht zu analysieren ist.

Was mir vor allem negativ auffällt ist, daß sich manche syntaktische Konstruktionen an mathematischen Formeln orientieren und darauf ausgelegt sind, dieser Sichtweise möglichst nahe zu kommen. Ein typischer Denkfehler.

Gute Programmiersprachen orientieren sich – und das wird an den Universitäten so eben nicht gelehrt – eher an der Darstellung, die das Gehirn bei einer natürlichsprachlichen Beschreibung wählen würde. Im Buch findet sich etwa das Beispiel

args.foreach ( arg => println(arg) )

Ich bevorzuge eher etwas der Art

for arg in args ; println(arg) ; end

Auch so eine von Java übernommene Krankheit ist, daß es keine Zuweisungsprozeduren gibt. man kann also nicht sowas wie

a.val=5 als Prozedur schreiben, sondern muß dann sowas wiea.setVal(5) definieren.

Daß sie mit ihrer eigenen Syntax nicht klar kommen, sieht man an solchen Krücken wie der Match-Anweisung, bei der Scala nicht unterscheiden kann, ob man eine Konstante oder eine Laufvariable angibt und es deshalb dann plötzlich darauf ankommt, ob der Variablenname mit kleinem oder großem Buchstaben anfängt.

Umbenennerei

Wie das eben in der Universitäts-Wissenschaft so ist, steht Scala unter dem Existenzberechtigungs- und Rechtfertigungsdruck, auf Teufel komm raus Neues zu bringen. Sie täuschen aber mehr Neues vor, als sie tatsächlich haben, indem sie alles neu benennen, obwohl es nicht neu ist. Das erschwert das Lernen, Verstehen und Lesen unnötig, ist aber typisch akademisch, wo man man sich gerne zusammendefiniert, wie es einem gerade einfällt.

Was ist beispielsweise ein Trait? Hat man eine Chance, das zu verstehen ohne vorher das Buch ausgiebig gelesen zu haben? Warum nennt man es nicht Modul oder Mixin, wie in anderen Sprachen?

Warum deklariert man Variablen mit name:typ und nicht typ name?

Was würde der unbefangene Leser erwarten, wenn eine Funktion als Typ für den Rückgabewert Unit angibt? Warum nicht void oder irgendwas, wo man versteht, daß sie gar nichts zurückgibt, also eine Prozedur ist?

Was würde der Leser unter „Pattern Matching” verstehen? In den meisten Sprachen versteht man darunter, ob ein regulärer Ausdruck auf einen String paßt. In Scala ist es eine wüste Konstruktion, die Datenstrukturen vergleicht, und die ich – ehrlich gesagt – nach dem ersten Lesen nicht richtig verstanden und bis zum zweiten Lesen jedesmal wieder vergessen habe, also immer neu nachlesen muß.

Operatoren-Eldorado

Man merkt sehr deutlich, daß die Leute, die an Scala mitentwickelt haben, eher mathematisch, als praktisch-informatisch orientiert sind. Scala wimmelt von Operatoren wie <:>: /: :\ // \\ . Und nun merkt Euch das mal alles, damit Ihr das auch lesen könnt. Hat mich manchmal an die Programmiersprache APL erinnert, die man auf einer normalen Tastatur nicht eingeben konnte, weil sie ziemlich viele Operatoren hatte, die nur aus einem Phantasiesymbol bestanden.

Kuriosität dabei: Die Operatoren ? und : sind in vielen anderen Sprachen längst als Quasi-Standard für bedingte Ausdrücke akzeptiert, etwa in der Form wie a = (b > 5) ? 7 : 8

Kurioserweise machen sie trotz ihrer Liebe zu wilden Operatoren gerade das aber nicht, sondern setzen da auf if/else in der form a = if (b>5) 7 else 8, was für das Auge meines Erachtens schon wieder schwer zu erfassen ist, weil man dazu neigt, if für eine Kontrollanweisung und nicht für einen Ausdruck zu halten.

Lacher zum Schluß

Auf Seite 54 des Buches findet man folgendes Zitat:

Typically, useful documentation is what readers of a program cannot easily derive by themselves.

Scala macht es dem Leser leider an vielen Stellen besonders schwer. In guten Programmiersprachen kann man durchaus „selbstdokumentierende” Programme schreiben. Scala erschwert das unnötig.

Korrektheit und Sicherheit

Ich habe es eingangs schon angesprochen, vor 20 Jahren fand ich die Sprache C ganz toll. Heute nicht mehr. Da habe ich meine Meinung ganz erheblich geändert, denn heute lege ich großen Wert auf Korrektheit und Sicherheit einer Sprache, daß sie Rechenfehler, Indexfehler usw. abfängt. Deshalb sollte eine neue Sprache heute die Sicherheitsmechanismen unterstützen, die Stand der Technik sind, wie das Verhindern von Pufferüberläufen, Taint-Mechanismen, die Java Sandbox, Exceptions, Abfangen von Arithmetikfehlern usw.

Einiges davon bringt Scala (oder genauer gesagt, meist die darunterliegende JVM) tatsächlich mit. Gut ist beispielsweise, daß die match-Anweisung eine Exception werfen kann, wenn nichts paßt. An anderen Stellen jedoch ist Scala auf dem technischen Stand von vor 20 Jahren (was ebenfalls eher an der JVM und nicht an Scala selbst liegt, aber nichts am Ergebnis ändert).

Integer-Arithmetik

Was soll ich sagen, es ist halt wie in C, eine schöne 32-Bit-Arithmetik ohne jede Überlaufprüfung. Exceptions gibt es nur bei der Division durch 0. Das führt zu einigen Rechenfehlern:

scala> 65000*65000
res0: Int = -69967296

scala> 65536*65536
res1: Int = 0

scala> 65536L * 65536L
res2: Long = 4294967296

Und die Autoren von Scala und dem Fachbuch fallen natürlich auch gleich drauf rein. So gibt es auf Seite 135/136 (1.Auflage) bzw. 145/146 (2.Auflage) ein Beispiel zur Implementierung von rationalen Zahlen als Bruch in einem Objekt. Die Funktion zur Abfrage, ob eine rationale Zahl kleiner ist als die andere wird im Buch mit

def lessThan(that: Rational) =
this.numer * that.denom < that.numer * this.denom

angegeben. Das beißt einen direkt in die Nase, daß das nicht funktioniert, weil man durch die Multiplikation schnell in den Zahlenüberlauf kommt. (So ein typischer Übungsaufgabenlösungs-Schrott.) Rechnet man das nach, dann stellt man fest, daß diese Funktion zwar die Frage, ob 1/50001 < 2/50002 wäre, richtig mit Ja beantwortet, aber die Frage ob 49000/50001 < 2/50002 ebenfalls mit Ja beantwortet, obwohl es nicht stimmt, weil 49000*50002 = -1844869296 ist. Exceptions oder sowas gibt es auch nicht. Weiter oben haben sie noch die Funktion zum Addieren zweier rationaler Zahlen, die ist genauso falsch.

Das ist ein typischer Fall dafür, wie diese eigentlich veraltete Java-Arithmetik zu ernomen Programmausführungs- und damit Sicherheitsproblemen führen kann. Jeder Assembler-Programmierer weiß, daß man zwei Integer-Zahlen nicht einfach so miteinander multiplizieren kann. Entweder muß man den Überlauf abfangen, oder die Arithmetik muß ein Ergebnis der doppelten Breite liefern. (Übung für den Leser: Schreibt die Funktion lessThan mal korrekt ohne auf Long Integer zurückzugreifen. Gar nicht so einfach.)

Ich habe wenig Verständnis dafür, daß man heute als moderne und mit Steuergeldern massiv geförderte Programmiersprache noch so einen Mist produziert. Solche Rechenfehler können auch zu Sicherheitsproblemen führen. Da muß man nur mal die Höhe mit der Breite eines Fotos multiplizieren, und schon geht es schief.

Kurzer Seitenblick zu Ruby: Dort ist 65536*65536 = 4294967296 , weil Ruby automatisch auf den Datentyp Bignum umschaltet. So soll es sein.

Fließpunktarithmetik

Ähnliche Probleme hat man mit der Fließpunktarithmetik. Die ist zwar IEEE-konform, aber trotzdem Bockmist. Unter Scala ist wie unter IEEE-Arithmetik üblich

scala> Math.asin(1.001)
res0: Double = NaN

NaN steht für Not a Number = Undefiniert. Rechnet man damit weiter ohne es geprüft zu haben, kommt es zu falschen Ergebnissen:

scala> Math.asin(1.001) < 0.3
res1: Boolean = false

Das heißt, daß man unter Scala fälschlich den Wert False erhält und wieder mit gültigen Werten weiterrechnet, obwohl das Zwischenergebnis undefiniert ist. Das ist fatal.

Kürzlich ist mir unter Ruby genau so ein Programmierfehler unterlaufen. Ich habe ein kleines Programm geschrieben, das aus geographischen GPS-Aufzeichnungen etwas berechnet und dafür Formeln zur sphärischen Trigonometrie eingegeben. Das Programm war im Prinzip eine korrekte Umsetzung trigonometrischer Formeln. Für die ersten Zweihunderttausend GPS-Koordinaten hat das auch wunderbar funktioniert und richtig gerechnet. Und dann ging's bei einer schief. Weil die Fließpunktarithmetik des Prozessors nur endlich genau ist und Rechen- und Rundungsfehler erzeugt. Dadurch war ein Zwischenergebnis, das rein mathematisch zwischen -1 und +1 liegen muß, eben doch geringfügig größer als +1 und es wurde etwas wie Math.asin(1.0000000000000000000342) berechnet. Ruby hat die Berechnung sofort mit einer Exception abgebrochen, ich habe sofort bemerkt, wo der Fehler liegt. Unter C, Java oder Scala wäre der Fehler nicht aufgefallen und hätte unbemerkt zu falschen Ergebnissen geführt.

Und nun stellt Euch vor, das Programm wäre Teil einer wichtigen Anwendung gewesen. Flugzeugnavigation. Ein Navigationsgerät für den Rettungswagen. Das Handnavigationsgerät in der Wüste. Das hätte falsch geleitet. Oder irgendwas anderes falsch berechnet. Stellt Euch vor, im Medizinwesen läuft eine Bestrahlung falsch. Oder irgendwo werden Kosten falsch berechnet. Oder ein teures Werkstück falsch hergestellt.

Ich bin der Meinung, daß so eine Drecksarithmetik in einer neuen modernen Programmiersprache nicht mehr vorkommen darf. Das ist veraltet, das ist der Stand von vor 20 Jahren.

Sicher, das liegt nicht eigentlich an Scala, sondern an der darunterliegenden JVM und der verwendeten Java Laufzeitbibliotheken. Das ändert aber nichts daran, daß das Ergebnis falsch ist und man Scala so nicht ohne weiteres einsetzen kann. Man muß mehr Arbeit darauf verwenden, die einzelnen Zwischenergebnisse zu prüfen, als man für die eigentliche Berechnung aufwendet. Ich komme unten im Abschnitt über funktionales Programmieren darauf zurück.

Taint-Mechanismen

halte ich gerade für die Programmierung von Anwendungen, die mit potentiellen Angreifern kommunizieren wie Web-Applikationen, für eine sehr wichtige Sicherheitseinrichtung gegen Programmierfehler. Perl und Ruby haben so etwas. Daten, die von außen eingegeben werden (etwa über Benutzereingaben, Sockets, Environment-Variablen usw.) werden als Tainted, schmutzig, markiert. Die Markierung überträgt sich auf weitere Werte, die daraus errechnet werden. Schreibe ich a=b+c, und c ist markiert, dann ist danach auch a markiert. Und gewisse, sicherheitsrelevante Funktionen akzeptieren keine markierten Parameter. Beispielsweise kann man einen markierten Wert nicht als Teil eines Dateinamens verwenden, mit dem man auf Dateien zugreift.

Bei einer Compiler-Sprache wie Scala könnte man sogar einiges dazu zur Kompilationszeit berechnen, ohne irgendetwas an den tatsächlichen Datenstrukturen oder der Java-Kompatibilität zu ändern.

Gibt's aber nicht. Scala wurde von Softwaretechnikern entwickelt. Und Softwaretechniker denken nicht an sicheres Programmieren.

Objektorientiertheit

Objektorientiertes Programmieren halte ich für die derzeit wichtigste Programmiertechnik.

Leider ist das in Scala nur beschränkt ausgebildet, obwohl Scala ja explizit als objektorientiert beschrieben wird. Während in manchen Sprachen wie Smalltalk oder Ruby alles ein Objekt und Teil der Hierarchie ist, hat Scala kei vollständiges und homogenes Klassenmodell.

Zahlen sind in Scala zwar prinzipiell in das Klassenmodell eingebunden, aber die Klasse ist geschlossen, man kann nichts hinzufügen oder ableiten. Sie sind als abstract und final definiert.

Während ich in Ruby ohne weiteres auch die Standardtypen wie Zahlen und Strings „aufmachen” und erweitern kann, um etwa Funktionsaufrufe wie 5.km , 8.Megabyte , 30.Tage , 9.Fakultaet zu erzeugen, oder auch einfach ein Interval mit 4..7 ist das in Scala nicht möglich. Was hier noch als Bequemlichkeit erscheinen mag, wird schon schwieriger, wenn man Algorithmen schreibt, die für Zahlen ebenso wie für andere Objekte funktionieren sollen, etwa wenn man auf algebraischen Gruppen rechnet. Eine Fouriertransformation kann auf Vektoren aus Fließpunktzahlen, aber ebenso auch anderen Elementen arbeiten, die sich wie in einem Körper verhalten. In Scala kann man das nicht elegant einheitlich für die Standardtypen und eigene Objekte schreiben.

Funktionales Programmieren

Derzeit gibt es an den Hochschulen einen unglaublichen Hype um das Funktionale Programmieren. Ich halte den Hype für groben Unfug.

Funktionales Programmieren sollte man durchaus als eine von vielen Programmiertechniken (oder ein Programmierparadigma, wenn man so will) beherrschen und anwenden, wenn es angemessen ist. Aber es ist nicht mehr und nicht weniger als das.

Wenn ich manchmal sehe, was an den Hochschulen als Funktionales Programmieren getrieben und gelehrt wird, dann habe ich jedoch den Eindruck, daß es nur eine euphemistische Umschreibung dafür ist, daß man nicht richtig programmieren kann oder zu faul ist, eine richtige Programmiervorlesung zu halten. Denn vieles, was da als „Funktionales Programmieren” verkauft wird, ist bei Licht betrachtet nur schlechtes, schlampiges Programmieren.

Viele glauben auch, daß Funktionales Programmieren etwas neues wäre, was sich durchsetzten müßte und wofür man neue Sprachen braucht. Meistens wissen gerade die, die am meisten für das Funktionale Programmieren und funktionale Sprachen trommeln, am wenigsten darüber, was es da alles gibt. Schon vor Jahrzehnten wurden in der Assemblerprogrammierung Sprungtabellen für Prozeduren verwendet - nichts anderes als Funktionales Programmieren, die Funktion wird als Parameter übergeben. In C gibt es Funktionspointer, mit denen man Funktionen als Parameter mitgeben kann, im Prinzip auch Funktionales Programmieren. Und die virtuellen Klassenfunktionen, die man in C++ überladen kann, sind eigentlich auch nichts anderes als eine Funktion, die als Parameter übergeben wird, nur daß der Pointer fest an Daten klebt (was eigentlich richtiger ist).

Gerade im Vergleich mit den virtuellen Klassenfunktionen sieht man, daß das Funktionale Programmieren in vielen seiner Erscheinungsarten kein eigenes Programmierparadigma ist, sondern nur eine abgestrippte Version des Objektorientierten Programmierens. Es bilden sich da nur viele ein, daß das was eigenes, tolles wäre.

Scala kommt explizit als Funktionale Programmiersprache daher und wird damit angepriesen. Das Scala-Handbuch von Odersky u.a. nervt massiv mit seinen häufigen Belehrungen und Besserwissereien, wie toll und wichtig es doch wäre, funktional zu programmieren, dabei stimmt vieles so nicht.

So predigen die Verfechter der Funktionalen Programmierung - auch Odersky - gerne, seiteneffektfreie Funktionen zu schreiben. Das ist naiv. Stellt Euch mal vor, wir treiben Bildverarbeitung mit einem Bild von sagen wird 50 Megapixel, also etwa 150 Megabyte. Und auf dem malen wir jetzt rum, indem wir einzelne Pixel setzen. Funktional und seiteneffektfrei programmiert würde eine Funktion zum Setzen eines Pixels das Bild nicht verändern, sondern eine veränderte Kopie als Ergebnis zurückgeben. Man sieht leicht ein, daß das absurd wäre.

Funktionales Programmieren funktioniert vor allem dann besonders gut, wenn man nicht so wirklich ernsthaft programmiert, sondern nur im Hörsaal Thesen an die Tafel schreibt, selbst festlegt, was gut und richtig ist, und die Programmieraufgaben auf ein paar Matheformeln oder realitätsferne Miniübungsaufgaben beschränkt ist. Deshalb ist das Funktionale Programmieren auch vor allem bei denen beliebt, die im Elfenbeinturm sitzen. Da macht das nichts und es fragt auch keiner so genau, ob's eigentlich funktioniert. Und es fördert halt auch so eine labormässige ad-hoc-Murkserei beim Programmieren.

Der geneigte Leser möge sich in Scala by Example mal ab Seite 99 das Beispiel zum Berechnen einer Summe von Primzahlen anschauen. Zunächst gibt Odersky ein Beispiel für die iterative Version. Schnell, effizient, einfach, gut lesbar. Braucht aber 9 Zeilen Code weil Scala im prozeduralen Stil nicht schön geraten ist. (Das allein gerät schon zum Zirkelschluß. Erst bauen sie Scala so, daß das prozedurale Programmieren vernachlässigt wird und nicht kompakt dasteht, und dann nehmen sie das als Beispiel, warum funktionales Programmieren kürzer sein soll, bestätigen sich damit also nur mit ihren eigenen Präferenzen. Darf einem Wissenschaftler nicht passieren.)

Dann wird das einfache interative Beispiel künstlich auf funktional umgestrickt und erst einmal aufgezeigt, daß es eigentlich Unsinn ist, weil eine Schleife von a nach b stattdessen durch eine Liste der Zahlen von a bis b ersetzt wird und enorm Speicherplatz benötigt (und damit natürlich auch langsamer ist). Dann folgen erstaunlich krampfige Klimmzüge um zu zeigen, daß es funktional mit allerlei Tricks dann doch so ähnlich wie iterativ hinzukriegen (aber schwer zu lesen und zu debuggen) ist. Warum macht man es dann überhaupt?

Das nimmt schon religiöse Züge an. Hätten die Jungs sich mal Ruby oder andere moderne Sprachen reingezogen, hätten sie das interativ deutlich besser gestalten können. Wie so oft habe ich den Eindruck, daß der Hauptgrund für Funktionales Programmieren in Defiziten bei der Befähigung zu „normalem” Programmieren liegt.

Java Virtual Machine für Funktionales Programmieren ungeeignet

Ich verstehe nicht, warum jemand wie Odersky so intensiven Wert auf das FP legt, und dann auf eine Maschine wie die JVM und deren Laufzeitbibliothek aufsetzt. Die ist nämlich für das FP ziemlich ungeeignet, das funktioniert so nicht.

Ich habe oben aufgezeigt, daß Scala (über die JVM) unter diversen Rechenfehlern bei Integer- und Fließpunktarithmethik leidet, die nicht durch Exceptions abgefangen werden. Wenn man korrekt arbeiten will, dann muß man nach jedem Rechenschritt und nach jedem Funktionsaufruf das Ergebnis prüfen, ob es innerhalb der Spezifikation liegt. Und damit ist man zwangsläufig im iterativen, prozeduralen Programmierstil. Dieses Abprüfen und Abbrechen, wenn die Werte nicht stimmen, ist mit dem Funktionalen Programmierstil eigentlich unvereinbar. Damit man funktional programmieren kann, muß jeder Fehlerzustand zu einer Exception führen. Nur so kann man etwas als geschlossenen und einfachen Formelausdruck hinschreiben.

Es ist seltsam. Odersky überschlägt sich fast vor Begeisterung und Trommeln für Scala als Funktionale Programmiersprache und nötigt dem Leser in seinen Belehrungen das FP geradezu auf. Er merkt aber nicht, daß die JVM und damit Scala für das funktionale Programmieren nicht geeignet sind.

Scala schlecht in Funktionaler Programmierung

Ich möchte die Kritik vertiefen. Das Problem liegt nicht nur in der JVM, sondern auch in der Sprache Scala selbst. Wollen wir das ganze Elend mal am Beispiel betrachten.

Als Beispiel für die vermeintliche Überlegenheit des FP bringen Odersky u.a. im Buch ab Seite 168 (1. Auflage) bzw. 179 (2.Auflage) in Listing 7.18 ein ganzseitiges (!) schlechtes iteratives Beispiel einer Prozedur mit dem Namen printMultiTable(), die einfach eine 10x10-Tabelle mit dem kleinen Einmaleins der Multiplikation ausdruckt (bemüht schlecht programmiert um es lang aussehen zu lassen).

Drei Seiten später stellen sie in Listung 7.19 zum Vergleich die angeblich bessere funktionale Variante vor und brauchen sage und schreibe drei (!) verschiedene Funktionen um das zu implementieren:

// Returns a row as a sequence
def makeRowSeq(row: Int) =
  for (col < - 1 to 10) yield {
    val prod = (row * col).toString
    val padding = " " * (4 - prod.length)
    padding + prod
  }

// Returns a row as a string
def makeRow(row: Int) = makeRowSeq(row).mkString

// Returns table as a string with one row per line
def multiTable() = {
  val tableSeq = // a sequence of row strings
    for (row <- 1 to 10)
    yield makeRow(row)
  tableSeq.mkString("\n")
}

Drei Funktionen! Versucht's mal zu lesen und durchzusteigen. (Und als Vorteil gegenüber der iterativen geben sie noch an, daß der Vorteil die Seiteneffektfreiheit wäre, weil es nicht druckt.)

Und mit so einem Käse und Unsinn wollen die einem das Funktionale Programmieren und die Überlegenheit von Scala schmackhaft machen.

Schreibt man etwas gleichwertiges und ebenfalls funktionales (!) in Ruby, dann sieht das so aus:

def multiTable
  (1..10).collect do |row|
    (1..10).collect {|col| "%4d" % (row*col) }.join(" ")
  end.join("\n")
end

Das ist doch ganz eindeutig kürzer, besser, lesbarer, übersichtlicher, flexibler. Und funktionaler, obwohl Ruby sich selbst nicht mal als explizit funktionale Sprache sieht!

Da machen die großes Geschrei um funktionales Programmieren (mit bewußt schlecht gemachten iterativen Beispielen, um vorzugaukeln, daß funktional besser wäre), und werden dann von Ruby locker funktional überholt.

Ganz ehrlich? Da sieht Scala aus wie gewollt und nicht gekonnt.

Schwafelbegriff Funktionales Programmieren

Was mich an dem Universitäts-Geschwätz über das angeblich so tolle Funktionale Programmieren am meisten stört ist, daß es so ein nicht näher spezifiziertes nebulöses Buzz-Word ist. Und auf Buzz-Words und Marketing-Begriffen reiten sie halt sehr gerne. Weil das ist da jetzt auch in Mode, und jeder will ja vorne mit dabei sein, auch wenn er nie ernsthaft programmiert und die eigenen Programme nur deshalb gut bewertet werden, weil man Wissenschaftlern das Recht einräumt, sich selbst für gut zu befinden. Ich habe noch nie einen getroffen, der – wie viele Wissenschaftler eben – so auf Funktionales Programmieren stand und genau sagen konnte, was es eigentlich ist. Da kommt dann meist wieder die Unfähigkeit zu erklären zum Vorschein, und sie kommen wieder mit irgendwelchen Beispielen.

Würde man es genau nehmen, würde man Funktionales Programmieren nur als allgemeinen Oberbegriff von (mindestens) fünf verschiedenen Eigenschaften einer Sprache ansehen, die sich teils nur auf die Syntax, teils aber auch auf die Mächtigkeit beziehen:

• Behandelt die Sprache Funktionen wie normale Objekte? (vgl. First-Class Function)
• Erlaubt die Sprache Aufrufe von Funktionen, die erst zur Laufzeit ausgewählt werden?
• Erlaubt die Sprache syntaktisch anonyme und verschachtelte, also direkt als Parameter anzugebende Funktionen? (Auch als Lambda-Ausdrücke bekannt.)
• Erlaubt eine Sprache die Kompilation oder Interpretation von erst zur Laufzeit im Quelltext erzeugten Funktionen?
• Ist die Sprache (d.h. der Compiler oder Interpreter) in der Lage, nur funktional hingeworfene Funktionsdefinitionen darauf zu untersuchen, ob sie als Anfangs- oder Endrekursion ausgeführt oder zur Iteration umgewandelt werden können und dies gegebenenfalls auch so auszuführen?

Außerdem wird ja immer so großer Wert darauf gelegt, daß man zu Programmen die Korrektheit nachweist. Wie das bei erst zur Laufzeit erzeugten und ausgewählten Funktionen gehen soll, wäre eine interessante Frage.

Davon ganz abgesehen kann man durchaus auch der Meinung sein, daß es Funktionales Programmieren im engeren Sinne nicht geben kann, weil das dann kein Programmieren, sondern nur noch ein Parametrisieren ist, und man die eigentliche Arbeit dem Compiler und dem Laufzeitsystem überläßt.

Ich habe jedenfalls schon viele Leute gesehen, die Funktionalen Rotz abgeladen und sich eingebildet haben, sie könnten programmieren, aber nicht mehr sagen konnten, was dann da eigentlich passiert und ob und wann es terminiert und warum. Funktionales Programmieren ist halt immer auch ein Feigenblatt derer, die nicht programmieren können.

Unausgewogen – Abgefahrenes statt Grundhandwerkszeug

Ohne Zweifel, Scala enthält eine Menge neuer Ideen und Elemente, die ich so vorher in keiner gebräuchlichen Sprache gesehen habe. Was ich ja prinzipiell sehr begrüße, sonst hätte man ja nie einen Fortschritt, sondern immer nur Variationen der alten Suppe.

Nicht alle dieser Neuerungen gefallen mir oder machen auf mich den Eindruck, gelungen und ausgereift zu sein. Manches wirkt labormäßig-experimentell. Dagegen wäre auch noch nicht viel einzuwenden, wenn es Sprachoptionen sind, die man nicht verwenden muß sondern kann, wenn man will (und die vielleicht sogar als experimentelle Bestandteile der Sprache gekennzeichnet sind, bei denen man damit rechnen muß, daß sie sich in zukünftigen Versionen ändern).

Nach dem schnöden Grundhandwerkszeug, das meines Erachtens jede moderne universelle Programmiersprache haben sollte, und das die anderen Sprachen auch fast alle haben, sucht man bei Scala bisweilen vergeblich. Die haben da offenkundig nur das reingepackt, was sie in wissenschaftlichen Papers als Neuerung verkaufen können (und ich habe auch den Eindruck, daß sie deshalb so viele neue Begriffe einführen und Bekanntes umbenennen, um den Eindruck der Neuerung künstlich zu erhöhen). Ein paar Beispiele:

• Ich verwende gerne und häufig case-Anweisungen statt if/else. Gerade unter Ruby sind die wirklich genial und leistungsfähig, weil sie eigentlich nur ein Eye-Candy sind und das in eine if/else-Kette umsetzen, die Muster und Wert über einen speziellen Operator === vergleichen, den man beliebig definieren und überladen kann. Dadurch (und durch das sehr universelle Klassenkonzept) sind ganz erstaunliche Dinge möglich, die auch ein sehr gut lesbares und fehlerarmes Programmieren ermöglichen. Ein Beispiel aus Ruby:

  case wert
    when nil            # Null-Wert,...
    when "abc"          # String-Vergleich
    when /gh?j(\d+)/    # regular Expression
    when 5..8           # Zahlenbereich
    when Integer        # Typ
    else	              # irgendwas anderes tun
  end
  

  Scala hat sowas nicht.

  Es hat zwar eine entfernt ähnliche Case-Anweisung mit Case Classes, Pattern matching und Extraktoren, die nicht nur einen einzelnen Wert, sondern ganze Datenstrukturen vergleicht, aber die ist großer Overkill. Das Kapitel im, was diese Kontrollstruktur beschreibt, ist ganze 35 Seiten lang und das über Extraktoren nochmal 16 Seiten. Und um ehrlich zu sein, ich habe es immer noch nicht so ganz und 100%ig verstanden, wie diese Case-Classes exakt funktionieren und wie man sie effizient anwendet. Man kann das in vielen Fällen auch nicht einfach so hinschreiben wie in anderen Sprachen, sondern muß case classes definieren, wenn man nicht gegen literale Konstanten vergleicht. Das Laufzeitsystem versucht dann, einen zur Laufzeit gegebenen Wert auf verschiedene Datenstrukturen und Klassen zu matchen, die als Typen in der Anweisung angegeben werden.

  Man sieht aber an dem, wie das funktioniert, und auch an den Beispielen, daß dieses Sprachelement gebaut wurde, um Compilergenerierte Sprachbäume, Formeln usw. zu vereinfachen und zu evaluieren. Irgendwer hat das für irgendwas geschrieben, wohl ein Algebra-System oder den Scala-Compiler selbst und dann in die Sprache geworfen. Sowas hat eigentlich in einer Programmiersprache selbst überhaupt nichts verloren, sondern gehört in eine Bibliothek (und damit ganz nach hinten in den Anhang des Buches). Keinesfalls aber darf es die normalen Sprachelemente verdrängen.

  Eine solche Case-Anweisung in Scala zu produzieren, wird leicht zum größeren Projekt und zur eigenen Programmieraufgabe. Daß man case wie in anderen Sprachen als einfache, schnelle, unkomplizierte Kontrollanweisung wie if/else hinschreibt, scheint da nicht vorgesehen zu sein.

  Die Scala-Entwickler scheinen schon manchmal nach dem Motto „Warum einfach und normal, wenn’s auch zwei Nummern komplizierter und umständlicher geht” verfahren zu sein. Die alte Faustregel „keep it smart and simple” gilt im Akademischen nicht, da gilt das Gegenteil.

• Reguläre Ausdrücke – und damit meine ich die Regular Expressions für Strings, wie sie unter Unix oder perl und ruby üblich sind – sind eines meiner am häufigsten gewählten Sprachwerkzeuge. Sprachen wie perl und ruby unterstützen das enorm, indem sie durch eigene Syntax ( wie /abc/ ) erlauben, Reguläre Ausdrücke direkt als Literale bzw. Konstanten in den Programmlauf zu schreiben, und sie dann mit Operatoren wie =~ und === oder case-Anweisungen direkt zu verwenden. Schnelles, einfaches, fehlerarmes, gut lesbares Programmieren.

  Geht in Scala so nicht. Natürlich gibt es dort auch Regular Expressions, indem man sie aus der Java-Runtime benutzt. Aber das ist dann schon wieder umständlich und sperrig, weil man sie nicht als Literale schreiben, sondern nur über einen Funktionsaufruf generieren und in einer Variable speichern muß – der Expression also nicht da steht, wo man ihn verwendet. Umständlich und schlecht lesbar.

• String-Interpolation haben sie auch nicht, das muß man alles mühsam über Operatoren und Ausdrücke selbst zusammenklopfen.
• Ein amüsantes Detail ist, daß man in Scala XML-Daten direkt als Literal hinschreiben kann. Man kann also direkt in den Code

  var text = <p>Hello World</p>
  

  schreiben und text hat dann den Datentyp scala.xml.Elem .

  Ob das aber sinnvoll ist, eine einzelne Datenbeschreibungssprache direkt als Literal zuzulassen, darüber kann man sich trefflich streiten. Gibt ja auch andere Datenformate, und man kann durchaus die Auffassung vertreten, daß das in eine Bibliothek und nicht in die Scala-Syntax gehört.

  Auch das verstärkt bei mir wieder den Eindruck, daß Scala keine systematisch geplante Sprache ist, sondern ein experimentelles Sammelbecken, in dem jeder Mitarbeiter oder Diplomand reinwirft, was der in den letzte 3 Wochen so gebastelt hat, weil es ihm in irgendeiner Anwendung gerade gelegen kam (man sieht auch am Reference Manual, daß der Abschnitt über XML von einem anderen Autor stammt. Auch das deutet darauf hin. War vielleicht eine Studien- oder Diplomarbeit.

  Geschenkt. Kann ja ganz nett und manchmal nützlich sein, und man muß es ja nicht verwenden.

  Man merkt aber dann, wie unausgewogen (oder windschief) Scala ist, wenn man dagegen hält, daß es für andere, viel häufiger verwendete und wichtigere Datentypen keine Literale gibt. Beispielsweise habe ich in Scala bisher keine Möglichkeit gefunden (vielleicht habe ich es auch einfach nur in diesem verfilzten ungeordneten Lehrbuch nicht gefunden), einen mehrzeiligen Text (String) als Literal hinzuschreiben.

  Viele andere Sprachen erlauben das. Da kann man einfach ein \ vor das Zeilenende setzen, oder es gibt eigene Literale wie die Konstruktion <

• Manchmal erstaunt das schon, wie schwerfällig und plump Scala an manchen Stellen daherkommt. Will eine Funktion mehrere Werte zurückgeben, muß sie das in ein Tupel packen, das man dann wieder zwischenspeichern und entpacken muß. In modernen Sprachen kann man stattdessen einfach a,b,c=funktion(...) schreiben und gut is.

  Wenn die unterliegende JVM die Rückgabe nur eines Wertes erlaubt, würde ich eigentlich erwarten, daß der Compiler selbst in der Lage ist, das automatische ein- und auspacken zu erledigen.

Lift und Entwicklungsumgebungen

Brrr.

Ich mag Ruby on Rails sehr gerne. Ist nicht perfekt, aber macht vieles gut und schnell.

Nachdem ich gelesen habe, daß man sowas in der Art unter dem Namen Lift auch für Scala baut, wollte ich mir das mal anschauen (halte es aber für ineffizient und ungünstig, daß man es als Filter für den Servlet Container implementiert hat). Dreimal habe ich es versucht, und dreimal entnervt abgebrochen. Weil immer irgendetwas gerade nicht verfügbar war.

Bei den ersten beiden Versuchen beruhte das Einführungsbeispiel (Sie erklären bei Lift auch nicht viel, sondern bringen irgendwelche Beispiele und fragen dann „Pretty cool huh?”. Nee, is nich cool.) auf Maven. Dazu muß man Maven mit einigen Optionen starten und dann lädt Maven erst mal einen großen Haufen Module und Funktionen aus dem Internet nach, die ihm erzählen, wie man denn ein Lift-Projekt bauen könnte. Von irgendwoher. Weiß man nicht so genau, von wem. Und ohne Breitband-Internet kann man es nicht mal starten. Und damit soll man dann ein verlässliches vertrauliches Projekt bauen.

Funktionierte auch nicht. Irgendeines der vielen heruntergeladenen Module hatte gerade irgendeine Macke. Von den Lift-Leuten wußte auch keiner, woran es liegen könnte. Ja, das stimme schon, momentan ginge es gerade nicht. Aber wo man suchen und reparieren oder auch nur fragen könnte, war nicht ersichtlich. Sowas ist professionell nicht einsetzbar.

Selbst wenn Maven mal funktioniert und das ganz Zeug von irgendwo herunterlädt, man weiß nicht, was das Ding da eigentlich treibt und warum.

Nicht viel besser sieht das mit der Standard-Entwicklungsumgebung für alles aus dem Java-Umfeld Eclipse aus. Da lädt man sich auch von irgendwo aus dem wilden Internet erst mal irgendwelche wilden Module herunter, damit Eclipse dann weiß, wie man das bauen könnte.

Dann gibt es noch ant, da ist einem aber auch nicht immer so richtig klar, was das macht, wenn irgendwelche Funktionen in Java Klassen versteckt sind.

Und weil ihnen das alles nicht so richtig gefallen hat, entwickeln irgendwelche Leute aus dem Scala-Umfeld noch sbt, das Simple Build Tool.

Manchmal habe ich den Eindruck, daß sich in dieser ganzen Java-Welt so ein Biotop aus Knallfröschen und Halbprofis gebildet hat, die auf solche halbgaren Hypes abfahren.

Fazit

Richtig viel Positives fällt mir an Scala nicht auf – oder dazu ein. Besser als Java ist es, das stimmt. Und es kann voll mit Java-Programmen zusammenarbeiten, man kann es also ohne weiteres in einer Java-Umgebung einsetzen. Ein paar nette Ideen sind auch drin, deren Nutzen aber sehr beschränkt ist. Die Idee, mal etwas frischen Wind in die muffige Programmsprachenszene mit ihrer soundsovielten Me-Too-Version überflüssiger, weil entweder gleichmächtiger oder nutzloser Sprachen zu bringen, wäre eine tolle Idee, wurde aber irgendwie vergeben.

Zum Einsatz erscheint mir Scala so nicht geeignet. Ich habe eingangs geschrieben, daß ich überlegt habe, für eine Sicherheitsschulung für Web-Applikations-Programmierer den Umstieg auf eine modernere, bessere aber kompatible Sprache vorzuschlagen. Die Idee habe ich mir sofort aus dem Kopf geschlagen, als ich mich mit Scala näher befasst habe. Sowas wie Scala hätte ich den Leuten dort wirklich nicht vorschlagen können. Die wären damit überfordert gewesen und hätten mich für verrückt erklärt. Zu Recht. Ich habe davon abgesehen, Scala dafür zu verwenden.

Scala zeigt, was an den Universitäten in Softwaretechnik alles schief läuft. Da rennen irgendwelche Evangelisten rum, die sich den ein oder anderen Spleen in den Kopf gesetzt haben und sich für besonders richtig halten, weil niemand außer ihnen selbst sie bewertet. So entstehen dann auf der einen Seite solche Hypes wie Funktionales Programmieren, die arge Theorie- und Formellastigkeit und die Vorliebe für irgendwelche exotischen Spielsprachen. Auf der anderen Seite fehlt es den Leuten echt an Programmierwissen und -erfahrung und an Bezug zur Realität. Dazu kommt der ständige Druck an der Universität, vorrangig oder nur irgendwas Neues, Publikationsfähiges zu bauen. Ordentliche Lehre, sondern eine Sprache mal sorgfältig auszuarbeiten paßt da nicht rein.

Scala macht mir keinen Spaß. Zu sehr muß man beim Programmieren das Handbuch danebenliegen haben, was einem nichts nützt, weil man das, was man sucht, entweder gar nicht oder nur nach Lesen ätzender Prosa findet.

Bei vielen Aufgabenstellungen, die ich in Ruby aus dem Stand schnell, elegant, lesbar, kurz, locker, flockig, flexibel und fehlerarm hinschreiben könnte, müßte ich in Scala erst mal eine Weile überlegen und lange abwägen, welchen der diversen Datentypen ich verwende – was man wegen der Inkompatibilität der Operatoren nachträglich ja nur mit größtem Aufwand ändern kann.

Bei manchen Aufgaben würde ich mir in Scala – ähnlich wie in Java – echt einen abbrechen, um das irgendwie hinzubekommen, Scala ist oft viel zu umständlich. Und da bin ich nicht der einzige. Ich war beim Lesen des Buches erschreckt, wie sehr sich sogar Odersky selbst einen abbricht, um Beispiele in Scala zu liefern. Wenn der nicht mal in seiner eigenen Programmiersprache gut, elegant und fehlerfrei programmieren kann, wie sollen es dann andere können?

Auf mich wirkt das meiste in Scala wie gewollt und nicht gekonnt. Oder wie von wissenschaftlichen Mitarbeitern entworfen, die noch keine Berufserfahrung haben, und nicht viel mehr kennen als Java und die Universitätsüblichen Exotensprachen. Und die noch nie unter Industriebedingungen programmiert haben, sondern deren Erlebnisuniversum sich auf die typischen Übungsaufgaben einer Informatikvorlesung beschränkt. Denn Scala erscheint mir auf genau diese zugeschnitten zu sein.

Scala will/soll möglichst viele der anderen Sprachen ersetzen. Man hat aber den fundamentalen Fehler begangen, daß man sich dabei nicht die Features anderer Sprachen angeguckt hat, sondern offenbar die persönlichen Ticks und Macken einiger Professoren erfüllen wollte, die als Meinungsführer gelten und willkürlich festlegen, welche Sprache sie in ihrer Vorlesung lehren lassen. Das merkt man vor allem an der Dokumentation sehr deutlich, wenn Odersky nicht Scala beschreibt sondern auflistet, welche der Ticks und Macken es erfüllt.

Scala erscheint mir wunderbar für folgende Zwecke geeignet:

• Für den Dualismus aus Übungsaufgabe und Musterlösung, die man nie wieder braucht.
• Als Compiler-Experimentalplattform.
• Als Themengrundlage für Papers, Dissertationen, Diplomarbeiten, Studienarbeiten
• Zum Beantragen von Forschungsgeldern und Drittmittel
• Zum So-tun-als-habe-das-Institut-ein-tolles-Forschungsthema
• Zur Masturbation in theoretischer und formaler Informatik

Nur eben nicht zum normalen Programmieren.

Oder wenn ich es anders, konstruktiv-kritisch formulieren und zu vier kurzen Punkten zusammenkochen soll, die die Probleme von Scala beschreiben:

• Scala ist keine geplante Sprache, bei der man ein Design, einen durchgehenden Sprachstil als roten Faden festgelegt und dann die Elemente und Bibliotheken daran ausgerichtet hat, sondern es ist eine eingesammelte Sprache. Typisch für das Abmelken von Diplomanden und Doktoranden. (Ich weiß nicht, ob es wirklich so war. Aber so riecht es.)
• Scala ist nicht von Leuten mit Profi- und Industrieerfahrung, sondern von Elfenbeinturmartisten geschrieben, deren Horizont sich vornehmlich auf Formeln, Papers schreiben und Übungsblätter in Programmiervorlesungen konzentriert. Bei vielen Scala-Elementen sieht man als Informatiker förmlich die Übungsaufgaben oder die Titel der Papers vor dem geistigen Auge. Das kann nicht Entwurfsziel einer professionellen Programmiersprache sein.
• Scala basiert auf der Java Virtual Machine und der Java Laufzeitumgebung. Ich hielt diese schon 1997 für unzureichend und veraltet. Jetzt haben wir 2011.
• Auch wenn man Scala zugestehen muß, noch in der Entwicklung zu sein, wurden meines Erachtens Entwurfsfehler begangen, die nur unter Aufgabe der Verträglichkeit und Kompatibilität zu den bestehenden Scala-Versionen zu korrigieren sind. Wenn Scala besser werden soll, muß man alles, was man jetzt in Scala schreibt, später überarbeiten (oder verschiedene Scala-Versionen mischen).

Ach ja, und das noch: Wer solche Bücher, Dokus und Beispiele schreibt wie Odersky, der muß noch einige Butterbrote essen, bevor er sich anderen als den ihm untergebenen Studenten gegenüber solche oberlehrerhaften Belehrungen zum Programmierstil leisten kann.