Scala-Mythologie


In einer zeitweise etwas hitzigen Diskussion auf www.java-forum.org hat sich wieder einmal gezeigt, wie hartnäckig sich Gerüchte und Halbwahrheiten halten, nicht nur über Scala, sondern auch über andere JVM-Sprachen wie Groovy – und über funktionale Sprachen sowieso. An dieser Stelle möchte ich die Mythenforschung aber auf Scala beschränken.

„Scala ist eine Skriptsprache“
Das ist eine dieser nicht auszurottenden Halbwahrheiten. Zuallererst sei bemerkt, dass man in Scala sehr bequem und einfach Scripte schreiben kann, diese Aussage also tatsächlich ein Körnchen Wahrheit enthält. Die erste Sache, die mich daran stört ist, dass sich viele „Skriptsprachen“ zwar gut für die Automatisierung von Abläufen oder kleine Tools eignen, aber kaum für komplexere Systeme. Das trifft für Scala definitiv nicht zu, der Name wurde ja gerade deshalb gewählt, weil Skalierbarkeit eines der Hauptmerkmale sein sollte, und das ist gelungen: In Scala funktionieren fünfzeilige Scripts, aber auch riesige, verteilte Anwendungen – die Sprache wächst tatsächlich mit ihren Aufgaben. Der zweite Kritikpunkt ist die Gleichsetzung von „Skriptsprache“ mit „dynamisch getypter Sprache“. Aber das ist in Wahrheit sowieso nur ein „statistischer“ Zusammenhang (obwohl die meisten Skriptsprachen dynamisch sind, gibt es doch genügend Ausnahmen). Der Fehlschluss in Bezug auf Scala ist allerdings leicht verständlich, denn viele Programmierer glauben immer noch, dass nur wo Typen „dranstehen“ auch Typen drin sind. Aber Scala verfügt über Typinferenz, ein Feature, dass es seit Ewigkeiten in vielen funktionalen Sprachen wie z.B. Haskell findet. Kann der Compiler einen Typ „ableiten“, muss ich ihn nicht angeben, so einfach ist das. Warum muss ich in Java einer Variable, der ich den Wert „Das ist ein interessanter Text“ zuweise, noch den Typ String mitgeben? Der Compiler meckert doch, dass er einen String will, wenn ich als nächstes ein Date hineinstopfen will, warum muss ich dann den Typ angeben, wenn er das selbst herausfinden kann – und sowieso immer alles besser weiß? Probieren wir das einmal in Scala, am besten online:

var x = "Das ist ein interessanter Text"
//--> x: java.lang.String = Das ist ein interessanter Text
x = new java.util.Date()
//--> error: type mismatch;
//-->  found   : java.util.Date
//-->  required: java.lang.String
//-->        x = new java.util.Date()
//-->            ^

Obwohl ich nirgendwo einen Typ erwähne, hat meine Variable x den Typ „String“, und der Compiler protestiert auch lauthals, wenn ich etwas anderes hineinstecken will. Messerscharfe Schlussfolgerung: Scala ist statisch getypt, auch wenn es auf den ersten Blick vielleicht nicht so aussieht!

Scala ist nur eine Java-Variante
Das ist dermaßen starker Tobak, dass ich bisher dachte, dass man darüber eigentlich nicht diskutieren bräuchte. Um Scala als eine Art aufgebohrtes Java mit verrückter Syntax zu sehen, muss man beim Draufschauen schon ziemlich weit wegstehen und auch noch gegen die Sonne blinzeln.
Natürlich ist es ein Trugschluss, dass Scala „eigentlich“ eine Art Java ist, nur weil es auf der JVM läuft. Dann wären nicht nur JRuby und Jython „Java-Varianten“, sondern auch Clojure, was total absurd ist, denn die Sprache ist so deutlich an Lisp angelehnt, dass man zweimal hingucken muss, um zu erkennen, was was ist. Ein weiteres Gegenargument ist, dass Scala auch auf Dot.Net läuft, was es nach dieser Logik gleichzeitig zu einer Visual Basic-Variante oder was auch immer machen würde.
Die beste Entkräftung dieses Mythos ist natürlich schlicht der Blick in Scalas Feature-Liste: Pattern-Matching, Closures, Typen höherer Ordnung, implizite Konvertierungen, strukturelle Typen und so weiter und so fort. Wer das nicht als Argument gelten lassen will, den frage ich ganz ernsthaft, warum er in dieser komischen COBOL-Variante namens Java arbeitet, denn beide Sprachen haben mindestens genausoviel miteinander gemein wie Java und Scala.

Scala ist eine dieser akademischen Spielsprachen
Natürlich wird dabei übersehen, dass viele der heute eingesetzten Mainstream-Sprachen aus dem akademischen Bereich stammen. Aber der Irrtum geht noch tiefer, denn es wird unterschwellig unterstellt, Akademiker wüssten nicht, was „im richtigen Programmierleben“ gebraucht wird.
Das mag für einige Professoren zutreffen, aber bestimmt nicht für den Vater von Scala, Martin Odersky. In dieser Frage erübrigt sich jede Diskussion, denn seine bisherige Arbeit spricht für sich: Die von Sun verwendete Version von javac ist eine Weiterentwicklung eines Prototypen, den er geschrieben hat, und von ihm stammt Generic Java, das die Grundlage für die Generics in Java 1.5 war. Nur weil ein paar Papiere mit (für Otto-Normal-Programmierer) esotherischen Themen veröffentlicht wurden, heißt das noch lange nicht, dass Scala nicht praxisorientiert wäre. Im Gegenteil, gerade die für die Praxis so wichtige Interoperabilität mit Java zwingt Scala zu Kompromissen, durch die es aus akademischer Sicht ein wenig „unsauber“ geworden ist. Wer einmal eine wirklich kompromisslos „akademische“ Sprache erleben will, sollte sich Haskell anschauen. Aber selbst das findet mehr und mehr praktische Anwendung, was wiederum zeigt, wie schwach das „akademische“ Argument in Wirklichkeit ist.

Die Syntax von Scala ist häßlich und unverständlich
Nun ja, die Schönheit liegt im Auge des Betrachters. Und natürlich ist vieles einfach Gewohnheit. Dass der Typ hinter der Variable kommt, ist nicht unüblich, wie man an den Vertretern der pascalartigen Sprachen (Pascal, Delphi, Modula, Oberon usw) sehen kann, und passt einfach besser mit dem Konzept der Typinferenz zusammen. Anderes Beispiel: vergleichen wir einmal die verschiedenen Deklarationensarten in Java und Scala.

//Java
String foo = ...
final String foo = ...
String foo(Bar bar){ ...
class Foo{ ... 
interface Foo{ ...

//Scala
var foo = ...
val foo =
def foo(bar:Bar) = { ...
class Foo { ...
trait Foo { ...

Fällt euch etwas auf? Genau, die Scala-Schreibweise ist einheitlicher. Nach der Eingewöhnungszeit entdeckt man mehr und mehr Dinge, die in Scala syntaktisch sauberer und „orthogonaler“ gelöst worden sind: Keine Extrawürste für primitive Typen oder Arrays, keine statischen Methoden, keine unnötigen returns, if-Anweisungen geben Werte zurück und so weiter. Und gepriesen sei, dass Semikolons optional sind, amen!
Natürlich gibt es auch Teile der Syntax, die erst einmal absolut abschreckend wirken, wie das „berüchtigte“ List(1,2,3).foldLeft(0)(_+_). Waaaah, zwei Argumentlisten und dann noch ein japanisches Emoticon! Aber erinnert euch doch einmal an die Zeit, als ihr Java gelernt habt: Habt ihr nicht ähnlich geguckt, als ihr über die erste anonyme Klasse oder den ersten statischen Initialisierungsblock gestolpert seid? Mir sind jedenfalls damals fast die Augen rausgepurzelt. Aber ich habe gelernt, damit umzugehen und diese Feautures mehr oder weniger sinnvoll einzusetzen. Und es hat mir auch nicht gescha.. gescha.. geschadet.

Scala hat als JVM-Sprache die gleichen Beschränkungen wie Java
Diese Aussage ist absolut richtig. Jede turing-vollständige Sprache hat die gleichen Beschränkungen wie das ebenfalls turing-vollständige Java, genauso wie ich jedes Java-Programm (bis auf Systemzugriffe wie I/O) auch in Brainfuck implementieren kann. Bezieht man die Aussage allerdings auf die Mächtigkeit der Sprachmittel, sieht man schnell, dass Scala vorne liegt. Scala implementiert Features wie Closures, Typen höherer Ordnung oder Endrekursion, die weit über „syntaktischen Zucker“ hinausgehen.
Es ist natürlich ein Fehlschluss zu glauben, nur weil Java in Bytecode übersetzt wird, würde es die Möglichkeiten, die die JVM mit ihrem Bytecode bietet, auch optimal nutzen. Es ist eine altbekannte Tatsache: Nicht jedes valide Bytecode-Programm lässt sich in ein valides Java-Programm „übersetzen“. Also müsste obige Aussage korrigiert werden zu: Scala ist als JVM-Sprache auf die Möglichkeiten von JVM-Bytecode beschränkt. Diese Aussage ist wahr, aber ebenso trivial und tautologisch wie die anfängliche Aussage über die Äquivalenz aller turing-vollständigen Programme.

So, das war meine persönliche Hitliste der Vorurteile. Welche Scala-Mythen sind euch schon begegnet?

Advertisements

3 Gedanken zu “Scala-Mythologie

  1. Mir fallen die Augen raus, wenn ich lese, daß in Deinem Text ‚esoterisch‘ als Synonym für ‚wissenschaftlich‘ verwendet wird. 🙂

    An manche Syntaxelemente habe ich mich schon gewöhnt, und war selbst überrascht, wie schnell das ging. Andere schauen mich immer noch sehr fremd an, weil ich sie noch nicht oder nur einmal verwendet habe. Aber das wird schon! 🙂

    Es ist wie mit einem kalten Bergsee: Man muß reinspringen, dann ist es erfrischend.

  2. Für viele Programmierer ist bereits alles, was nicht zehplusplus- oder pascalartig aussieht, Teufelswerk, aber auch die etwas experimentierfreudigeren unter uns stutzen erst mal bei „Monaden“, „Higher Kinded Types“ und „Continuation-passing Style“ – insbesondere wenn diese wissenschaftlich korrekt und mit den entsprechenden Formalismen dargestellt werden – und das wirkt dann eben von dieser Warte heraus für mich (mit etwas Augenzwinkern) „esoterisch“. Aber vielleicht wäre „exotisch“ die bessere Wortwahl gewesen. Ich sehe schon, dass ich meine geneigte Leserschaft mit Fremdwörtern nicht imprägnieren kann…

  3. Lustig, ich war drauf und dran, ‚exotisch‘ als Alternative zu empfehlen, aber da fiel mir ein, daß Lausanne so exotisch nicht ist, zumal Martin Deutscher ist, und die mathematische Notation ist, ohne mich zu weit aus dem Fenster lehnen zu wollen, vielleicht auch etwas sehr europäisches? 🙂 Bezüglich Exotik wäre ich aber nicht so sensibel – immerhin ist Exotik eher positiv besetzt – 2 Apfelsinen im Haar, und an den Hüften Bananen … aber Esoterik?

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s