Im Rahmen des Scala-Titelthemas sprach das Java Magazin mit dem Scala-Gründer Martin Odersky über die Ursprünge der Sprache, die so genannten "Lessons Learned", warf einen Blick hinter die Scala-Kulissen und nahm auch einen Ausblick in die Zukunft vor.

Java Magazin: Parallel zu dem aktuellen Hype um die dynamischen Sprachen à la Ruby (on Rails), JRuby oder Groovy beginnt sich mit Scala eine so genannte statisch getypte Sprache zu etablieren. Was kann Scala, was andere Sprachen nicht können?

Martin Odersky: Im wesentlichen Skalierbarkeit. Scala ist sowohl für kleine Scripting-Tasks als auch als Ersatz für Java in sehr großen Projekten einsetzbar. Es macht kompetente Programmierer wesentlich produktiver als bestehende Sprachen. Die Systemarchitekten und Programmierer von Twitter haben z.B. Scala als Implementierungssprache für ihr System gewählt, weil es die Stabilität von Java mit höherer Produktivität und Ausdrucksfähigkeit kombiniert.

JM: Was war eure Motivation, Scala zu entwickeln? Allgemeiner akademischer Forschungsdrang oder der Wille, einem konkreten Problem in der Java-Welt Abhilfe zu schaffen?

Odersky: Ich habe schon seit Längerem versucht, Fortschritte in akademischen Sprachen in industriellen Anwendungen zugänglich zu machen. Vor Scala habe ich z.B. zusammen mit Phil Wadler die Sprache Pizza entwickelt, die Java mit drei wesentlichen Elementen der funktionalen Programmierung erweitert hat: Generizität, algebraische Datentypen und Closures. Ich habe dann mit Sun gearbeitet, um die generischen Typen in Java einzuführen. Das Resultat war die Sprache GJ, die 1998 entwickelt wurde und Vorläufer von Java 5 war. Mein GJ Compiler wurde von Sun als der offizielle Javac Compiler übernommen.

Meine Erfahrungen mit Pizza and GJ haben mir gezeigt, dass wirklicher Fortschritt nur erreicht werden kann, wenn man bereit ist, manche Konventionen aufzugeben. Mit Scala wollte ich mit einem relativ weißen Blatt Papier anfangen, d.h. ich wollte erst einmal keine Einschränkungen bezüglich Syntax und Rückwärtskompatibilität mit Java, und habe stattdessen "nur" auf volle Interoperabilität Wert gelegt. Das Ziel war, eine Sprache zu entwickeln, die unseren Kenntnisstand in Programmiersprachen umsetzt, um bessere Sicherheit und Produktivität in praktischen Anwendungen zu ermöglichen.

Java Magazin 4.09

Für alle, die mehr über Scala erfahren wollen: Im aktuellen Java Magazin startet eine mehrteilige Serie zu Scala, welche die Grundzüge, Vererbung, Funktionen und die Bibliotheken der Sprache genau unter die Lupe nimmt. Teil 1 der Serie von Arno Haase im Java Magazin 4.09!

Außerdem finden Sie auf JAXenter eine Keynote von Martin Odersky, die er 2008 auf der JAX über Scala gehalten hat.

JM: Ihr habt mit der Entwicklung von Scala im Jahr 2001 begonnen. Gab es am Anfang irgendwelche Vorbilder für die Sprache?

Odersky: Scala ist grundsätzlich eine Neuentwicklung, die sich nicht an eine bestimmte Sprache anlehnt. Es gibt aber eine ganze Reihe von Elementen, die wir von anderen Sprachen übernommen haben.

Von Java und C# kommen die meisten Syntaxelemente, Datenstrukturen und Bibliotheken. Die Typannotationen kommen allerdings von Pascal und Modula. Von Smalltalk kommt das uniforme Objektmodell, wo konzeptionell jeder Wert ein Objekt ist, und jede Operation ein Methodenaufruf. Von Eiffel kommt das uniforme Zugriffsprinzip, das es ermöglicht, Felder und Zugriffsmethoden frei auszutauschen. Von der Algol-Familie und insbesondere Beta kommt das universelle Schachtelungsprinzip. Von Haskell und ML kommen viele der funktionalen Aspekte von Scala.

JM: Was habt ihr im Verlauf der Entwicklung bis heute gelernt? Sind die Ziele aus der Anfangszeit bis heute identisch geblieben oder hat es eine signifikante Verschiebung der Projektziele gegeben?

Odersky: Es sind zwei neue Aspekte dazugekommen. Am Anfang dachten wir, dass Scala im Wesentlichen eine Synthese aus bekannten Konzepten der objektorientierten und der funktionalen Programmierung sein sollte. Es hat sich dann herausgestellt, dass vor allem auf der objektorientierten Seite noch viel Arbeit nötig war, um eine statisch typisierte Sprache zu erhalten, in der sich Softwarekomponenten gut ausdrücken lassen. Das Resultat waren neue Konzepte der Mixin-Komposition mit abstrakten Typen, die aus Scala eine recht mächtige Sprache für Komponentenentwicklung und Softwarearchitektur machen.

Der zweite Aspekt hat mit der überraschenden Popularität von Scala zu tun. Wir haben wesentlich mehr Benutzer als wir am Anfang erwartet hatten. Allein im Jahr 2008 hatten wir 50 000 Downloads des Entwicklungssystems von unseren Servern. Das heißt, dass wir uns mehr Gedanken machen mussten, wie wir die Benutzung von Scala so einfach wie möglich gestalten können.

JM: Wie kann man sich den Entwicklungsprozess von Scala vorstellen? Arbeitet ihr eng mit der Community zusammen oder stammen die maßgeblichen Impulse von dir und deinem Team an der École polytechnique fédérale de Lausanne?

Odersky: Wir haben mittlerweile eine sehr aktive Community von Benutzern, mir denen wir zusammenarbeiten. Wesentliche Impulse kommen insbesondere von den Entwicklern des "Lift"-Webframworks. Wir haben mittlerweile mehr Committer außerhalb der EPFL als innerhalb. Um die weitere Entwicklung zu managen, haben wir den SIP-Prozess etabliert, der es Benutzern gestattet, Scala Improvement Proposals auszuarbeiten und zu diskutieren. Das läuft ganz ähnlich wie der PEP-Prozess für Python ab. Ich persönlich behalte noch die letzte Autorität, zu entscheiden, was übernommen wird. Aber viele der Initiativen kommen mittlerweile direkt aus der Community.

JM: Wie seid ihr auf die Idee gekommen, den Compiler als Daemon laufen zu lassen? Und wie gut bewährt sich das in der Praxis?

Odersky: Der Scala Compiler ist nicht nur ein Batch Compiler, er ist auch der Präsentations-Compiler des Eclipse-IDE-Plug-ins, und er wird für den Read Eval Print Loop (REPL) der Scala Shell benutzt. Damit das funktioniert, mussten wir den Compiler sehr inkrementell machen. Der Compiler behält z.B. in der Regel kompilierte Versionen aller benutzten Files im Arbeitsspeicher. Da wir also einen sehr schnellen inkrementellen Compiler hatten, schien es sinnvoll, ihn auch für die Batch-Kompilierung zu benutzen. Das heißt, dass Neukompilierungen wesentlich schneller als sonst erledigt werden, weil Start-up-Kosten entfallen. Aus meiner Sicht hat sich das gut bewährt.

JM: Was hältst du von Design by Contract?

Odersky: Ich denke, das ist eine der bewährtesten Methoden, um die Zuverlässigkeit von Software zu erhöhen. Eine interessante Frage in diesem Zusammenhang ist, in wieweit man Contracts statisch überprüfen kann. Das ist ein Feld, an dem wir an der EPFL arbeiten.

JM: Was ist aus deiner Sicht die interessanteste Performanceoptimierung unter der Motorhaube von Scala?

Odersky: Schwer zu sagen. Eine wichtige Optimierung betraf Datenstrukturen. Uns fiel auf, dass eine der ersten XML-Bibliotheken, die in Scala geschrieben wurde, viel zu viel Speicher verbraucht hat. Es stellte sich heraus, dass in dieser Bibliothek die Attribute jedes XML-Knotens mit einer HashMap implementiert wurden. So eine HashMap braucht um die 100 Bytes Speicher. Da die meisten XML-Knoten aber gar keine Attribute haben, ist das eine große Verschwendung. Das führte dann dazu, dass wir in Scala den Schwerpunkt auf persistente Kollektionen gelegt haben, d.h. Kollektionen, die sich nie ändern können, sondern die immer nur neue Kollektionen generieren können. So ähnlich wie das heute mit Strings in Java passiert. Der Vorteil ist, dass kleine persistente Kollektionen optimiert werden können. Die leere Map braucht also gar keinen Speicher, und Maps bis zu vier Elementen werden in einem einzigen Objekt dargestellt. Es hat sich herausgestellt, dass dies die meisten Programme, die mit Kollektionen hantieren beschleunigt, weil eben viele Kollektionen sehr klein sind.

JM: Parallel an der Unterstützung für die Java VM arbeitet ihr auch an einer Version für die .NET CLR. Wie gut klappt die parallele Entwicklung und wie ist die Akzeptanz in den beiden unterschiedlichen Communities?

Odersky: Es kostet viel Arbeit und Ressourcen, beide Versionen in Sync zu halten. In der Vergangenheit fehlten uns die nötigen Mittel, deshalb fiel auch die .NET-Version im Vergleich zur Java-Version immer weiter zurück. Glücklicherweise hat uns Microsoft aber vor Kurzem eine sehr großzügige Unterstützung unseres ProgLab-Projekts zugesagt. Wir hoffen, dass wir im Rahmen dieses Projekts die .NET-Version bald entscheidend vorwärts bringen können.

JM: Welche weiteren Projektziele habt ihr? Wo wollt ihr in einem Jahr und in fünf Jahren stehen?

Odersky: In diesem Jahr werden wir neue Bibliotheken und einige kleinere Spracherweiterungen bringen. Geplant sind insbesondere benannte und Default-Parameter, Parameter für Traits und neue Bibliotheken für Kollektionen und UI-Programmierung. Unser Ziel in fünf Jahren ist es, die praktikabelste Sprache für paralleles und nebenläufiges Programmieren zu haben. Aufbauend auf den Bibliotheken, die wir schon haben, forschen wir intensiv an neuen Methoden der nebenläufigen Programmierung und an Analysen, die ihre Zuverlässigkeit erhöhen.