1 Warum Scala?
Ja, warum sollten wir uns eigentlich mit Scala beschäftigen? Mit Blick auf die schiere Vielzahl an Programmiersprachen eine berechtigte Frage. Wir können diese auch anders formulieren, und zwar: Welche Vorteile bringt Scala gegenüber anderen Programmiersprachen?
Mit der Antwort wollen wir es uns hier ein bisschen einfacher machen, indem wir ausschließlich die Java-Plattform betrachten. Das bedeutet, dass wir nur solche Programmiersprachen unter die Lupe nehmen, die auf der Java Virtual Machine (JVM) laufen. Diese Einschränkung halten wir deswegen für legitim, weil die Java-Plattform sehr weit verbreitet ist und gerade im Bereich der Unternehmensanwendungen eine durchaus dominante Stellung innehat. Gute Gründe hierfür sind – ohne Anspruch auf Vollständigkeit – das Write-once-run-everywhere-Prinzip1 sowie die große Menge an verfügbaren Bibliotheken für nahezu alle denkbaren Anwendungsfälle.
1.1 Was ist Scala?
Vor der Frage nach dem Warum steht erst einmal diejenige nach dem Was. Auf einen Satz kondensiert lautet unsere Antwort: Scala ist eine moderne und dennoch reife, objektfunktionale, praxisorientierte, statisch typisierte und trotzdem leichtgewichtige Sprache für die JVM, die vollständig kompatibel zu Java ist. Wir wollen im Folgenden kurz ein paar dieser Eigenschaften herauspicken und genauer erläutern. Alles Weitere bzw. sich ein Bild von Scala zu machen, überlassen wir dann dem Leser für den weiteren Verlauf dieses Buchs.
Scala wurde von Martin Odersky, Professor an der Schweizer Hochschule EPFL2, erfunden, der zuvor bereits an wichtigen konzeptionellen Neuerungen für Java gearbeitet hatte, zum Beispiel an den Generics3. Die erste Version wurde bereits 20044 veröffentlicht, sodass wir bereits auf über ein Jahrzehnt mit Scala zurückblicken können.
Anfangs, als die Nutzerbasis noch nicht so groß war, leistete sich Scala bei neuen Versionen – auch bei so genannten Minor-Releases – immer wieder binäre Inkompatibilitäten zu vorherigen Versionen. Aber spätestens seit der Version 2.9, die zeitlich ungefähr mit der Gründung der Firma Typesafe5, die kommerziell hinter Scala und anderen Technologien wie Akka6 und Play steht, zusammenfällt, ist das Geschichte: Seitdem sind alle Minor-Releases mit derselben Major-Release-Nummer binär kompatibel, also z. B. 2.9.1 und 2.9.2. Nur bei Major-Releases, die 18 Monate oder länger auseinanderliegen, wird es notwendig, ein gesamtes Projekt einschließlich aller Bibliotheken auf die neue Version zu heben. Aber auch das ist in der Regel ein Einfaches, weil dank der Community Builds7 die meisten populären Bibliotheken quasi gleichzeitig mit einem Major-Release von Scala für genau dieses veröffentlicht werden.
Scala kann also getrost als reife Sprache betrachtet werden. Zur weiteren Charakterisierung ist vermutlich der hybride Charakter der Sprache das hervorstechendste Merkmal: Scala ist einerseits objektorientiert8, und das sogar viel stringenter als Java. Andererseits ermöglicht Scala funktionale Programmierung9, also „so etwas mit Lambdas“, die ja spätestens seit Java 8 auch unter Java-Entwicklern steigende Bekanntheit genießen. Scala bietet nicht nur das Beste aus beiden Welten, sondern vereinigt die zwei Paradigmen weitreichend zu einer objektfunktionalen Sprache aus einem Guss.
Abschließend noch das aus unserer Sicht wichtigste Kriterium für den großen Erfolg von Scala: Wir können aus Scala heraus jeglichen Java-Code nutzen, egal ob unsere liebgewonnenen Bibliotheken für Logging, Persistenz etc. oder unsere eigenen Java-Projekte. Durch diese Abwärtskompatibilität müssen wir nicht bei Null anfangen, sondern können unsere bestehenden Java-Aktiva ver- und aufwerten.
1.2 Warum Scala statt Java?
Das führt uns direkt zur Frage, warum wir uns mit Scala beschäftigen sollten, wo es doch Java gibt. Die Antwort fällt uns sehr leicht, und wir können sie sehr deutlich formulieren: Im Vergleich zu Java können wir mit Scala sowohl produktiver arbeiten, als auch die Qualität steigern. Abgesehen davon macht das Programmieren mit Scala einfach mehr Spaß, wobei das natürlich eine subjektive Einschätzung aus unserer Sicht ist.
Zugegebenermaßen benötigen wir zunächst ein wenig Zeit, um mit Scala durchzustarten, aber die langfristigen Vorteile überwiegen mit Sicherheit den Nachteil des Lernaufwands, den jede neue Technologie mit sich bringt. Gerade Java-Programmierer sollten hierfür ein offenes Ohr haben, denn auch Java ist noch recht jung, weshalb nicht wenige von uns zuvor von anderen Programmiersprachen auf Java umgestiegen sind. Welches sind nun die Gründe dafür, dass Scala Produktivität und Qualität im Vergleich zu Java zu steigern vermag? Wir wollen hierfür die folgenden ins Feld führen: weniger Code und höheres Abstraktionsniveau.
Wie wir im weiteren Verlauf dieses Buchs sehen werden, benötigen wir mit Scala signifikant weniger Code als mit Java, um ein Programm zu realisieren, das dieselben Anforderungen erfüllt. Mit signifikant meinen wir mindestens eine Reduktion von 50 Prozent, möglicherweise bzw. situativ sogar bis zu 80 Prozent.
Es ist zwar richtig, dass moderne Java-Entwicklungsumgebungen beim Schreiben eines großen Teils des eingesparten Codes sehr gut unterstützen können; man denke zum Beispiel an Funktionen zur Erzeugung von Zugriffsmethoden – also Getter und Setter – wie sie jede moderne integrierte Entwicklungsumgebung (IDE) bietet. Somit sind wir beim Codeschreiben nicht unbedingt schneller. Aber wenn wir an unseren Alltag als Programmierer denken, dann werden die meisten von uns feststellen, dass wir insgesamt mehr Zeit darauf verwenden, Code zu lesen und zu verstehen, als zu schreiben. Das betrifft nicht nur fremden Code, den wir übernehmen oder warten dürfen, sondern auch eigenen, den wir vor Wochen oder gar Monaten geschrieben haben und dessen Verständnis uns heute einiges abverlangt.
Es gibt Untersuchungen10, die belegen, dass die Geschwindigkeit, wie schnell wir Code lesen und verstehen können, ganz entscheidend von der Codemenge bestimmt wird. Wenn wir zum Beispiel an eine typische JavaBean denken, die quasi nur einen Datencontainer für eine Handvoll Properties darstellt, dann sehen wir uns einer gewaltigen Menge an semantisch wenig wertvollem Code gegenüber: Getter, die nur ein privates Feld zurückgeben. Oft auch Setter, die nur ein privates Feld verändern. Vermutlich auch mehrere Konstruktoren, mit denen alle oder zumindest einige der Felder initialisiert werden können. Und nicht selten auch noch Implementierungen der Methoden equals, hashCode und toString. Wenn wir nun diesen Code lesen und verstehen wollen, dann müssen wir im Verstand einen Filter aktivieren, der all den überflüssigen Kitt ausblendet und nur die eigentliche Intention durchlässt.
Ein explizites Beispiel gefällig? Wie wäre es mit einer Klasse für eine Person, die Vor- und Nachname haben soll. Im Vorgriff auf die Prinzipien der funktionalen Programmierung soll diese Person unveränderlich sein, d. h. einmal erzeugt können deren Attribute nicht mehr verändert werden. Dieses Prinzip des Immutable Object11 ist natürlich auch in Java bekannt, nicht erst seit dem Buch „Effective Java“12 von Joshua Bloch. Zunächst zeigen wir den Java-Code, bei dem die Methoden equals und hashCode von der Entwicklungsumgebung generiert wurden:
public class Person {
private final String firstName;
private final String lastName;
public Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public String getFirstName() {
return firstName;
}
public String getLastName() {
return lastName;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Person person = (Person) o;
if (firstName != null ?
!firstName.equals(person.firstName) :
person.firstName != null) return false;
if (lastName != null ?
!lastName.equals(person.lastName) :
person.lastName != null) return false;
return true;
}
@Override
public int hashCode() {
int result = firstName != null ? firstName.hashCode() : 0;
result =
31 * result + (lastName != null ? lastName.hashCode() : 0);
return result;
}
}
Und nun zum Vergleich der äquivalente Scala-Code, der wirklich funktional vollständig identisch ist, wie wir im Verlauf dieses Buchs noch sehen werden:
case class Person(firstName: String, lastName: String)
Nur eine einzige Codezeile in Scala im Vergleich zu – je nachdem wie wir zählen – zwanzig oder mehr in Java. Das liegt daran, dass wir nicht all die kleinen Details wie zum Beispiel die Zugriffsmethoden oder equals und hashCode ausprogrammieren müssen, sondern der Scala-Compiler diese Arbeit für uns macht. Zwar haben gerade erfahrene Java-Entwickler einen besonders gut geschulten kognitiven Filter für irrelevante Details, sodass wir beim Geschwindigkeitsvergleich für Lesen und Verstehen natürlich nicht von einem Verhältnis 1:20 ausgehen dürfen. Aber...
