In einer zeitweise etwas hitzigen Diskussion hat sich wieder einmal gezeigt, wie hartnäckig sich Gerüchte und Halbwahrheiten halten, nicht nur über Scala, sondern auch 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 eigentlich den Typ noch angeben, wenn er er das selbst herausfinden kann - und sowieso immer alles besser weiß? Probieren wir das einmal in Scala, am besten online:
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 Draufscheuen 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.
Fällt euch was auf? Genau, die Scala-Schreibweise ist einheitlicher. Nach der Eingewöhnungszeit fallen einem mehr und mehr Dinge auf, 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 beim ersten Anblick 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.
(Diesen Text habe ich auch in mein Blog übernommen)
"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 eigentlich den Typ noch angeben, wenn er er das selbst herausfinden kann - und sowieso immer alles besser weiß? Probieren wir das einmal in Scala, am besten online:
Code:
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()
//--> ^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 Draufscheuen 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.
Code:
//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 { ...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 beim ersten Anblick 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.
(Diesen Text habe ich auch in mein Blog übernommen)
Zuletzt bearbeitet:
