Kommentar: Scala-Bashing – Was ist anders?

Michael Johann
Michael Johann

Ich versuche mal eine Erklärung der gerade laufenden Scala-Debatte, da ich in den letzten 25 Jahren genug Sprachen kommen und gehen gesehen habe:

Smalltalk war und ist eine tolle Sprache, aber als Java kam, hatte Java den tollen „Killer-App“-Aspekt: Write once, run everywhere (speziell im Browser). Dieser Effekt war zwar nicht von langer Dauer (Java ist heute primär auf dem Server), allerdings konnte man mit Java und der Java-EE-Spezifikation einheitlich Business-Anwendungen entwickeln.

Die JVM ist ohne Frage bis heute und weit in die Zukunft eine stabile und nutzenswerte Runtime, die sich praktisch alle ernst zu nehmenden „neuen“ Sprachen zu nutze macht. Also könnte man auch sagen, dass die Killer-App von Java bis heute eigentlich die JVM ist.

Ruby gab es noch vor Java, aber interessiert hat das lange Zeit wirklich niemanden. Die „Killer-App“ von Ruby ist das Web-Framework Ruby on Rails und speziell in der JVM-Fassung JRuby fand Ruby eine stabile Verbreitung. Auch hier wurden immer wieder die Community und die Rubyisten angegriffen, als die Popularität signifikant anstieg.

Speziell bei Ruby on Rails ist der Hintergrund für den Erfolg ein signifikant anderer als bei Scala. Hier die Unterschiede:

David Heinemeier Hansson (DHH) hat Rails entwickelt, als er nach einer passenden Sprache für das Framework gesucht hat. Die Auswahl stand zwischen Java und Ruby. Ruby ist eine Sprache, die bekanntermaßen mehr für den Menschen als für den Computer gemacht wurde. DHH versprach sich also einen enormen Produktivitätsgewinn bei der Verwendung von Ruby.

Über die Hintergründe warum Scala entwickelt wurde, taucht meines Wissens nach kein solcher „Praxisfall“ auf. Soll heißen, es wurde primär eine Sprache entwickelt. Die „Killer-App“ fehlt noch.

Viele Java-Entwickler neigen dazu, komplizierte Lösungen mit möglichst vielen Eventualitäten zu bevorzugen, schließlich weiß man ja nie, wann welches Framework oder welche Bibliothek wie ausgetauscht werden wird. Aus meiner persönlichen Sicht bedient Scala genau diese Klientel. Man kann undurchschaubaren Code schreiben und man kann Sprachkonstrukte entwickeln. Alles in allem eine sehr flexible Umgebung, die einem das Gefühl vermittelt, man könne alles damit machen.

Hin und wieder entsteht der Eindruck, dass Entwickler, die Scala nicht schnell genug „gefressen“ haben, schnell als „intellektuell minderbemittelt“ abgestempelt werden. Auf der anderen Seite wird Scala auf Konferenzen und von den Machern sehr stark gepusht und als das „Allheilmittel“ bei der Suche nach neuen Möglichkeiten gepriesen.

Die Häme und den Widerstand bekommt Scala (allein meine persönliche Meinung), weil es allerorts gepusht wird aber niemand versteht, was man damit machen soll. Zudem fällt einem Einsteiger nicht gleich die Sprache in den Schoß.

Zusammenfassend könnte man sagen: Die Scala-Protagonisten pushen Scala, weil sie es um jeden Preis wollen, während viele Entwickler keinen echten Zugang finden und ihren Frust direkt wieder beim Hersteller abladen. Würde es eine „Killer-App“ (oder besser: Anwendungszweck) geben, hätte Scala das Problem des „Bashings“ überhaupt gar nicht.

Geschrieben von
Michael Johann
Michael Johann
Michael Johann war Chefredakteur des Magazins RailsWay und Autor des Buches „Ruby on Rails für JEE-Experten“ (Hanser Verlag). Er ist Berater und Trainer für JRuby on Rails und regulärer Sprecher auf Konferenzen rund um den Globus. Vor dem Switch zu Ruby on Rails wurde er als JEE-Experte und als Chefredakteur von Java-Spektrum bekannt.
Kommentare
  1. Ban Foy2013-12-05 09:23:15

    Zum Glück hat Scala je nach Sichtweise keine oder ziemliche viele "Killer"-Apps, und das ist genau das, was den nachhaltigen Erfolg garantiert. Wenn RoR einmal aus der Gunst gefallen ist (was bereits passiert), wird es auch mit der Verbreitung der Sprache bergab gehen. Man kann ähnlich zu Groovy spekulieren re Grails und Gradle.

    Scala ist ideal in vielen verschiedenen Szenarios, von heavy duty Server Anwendungen zu Desktop oder Scientific Computing und Machine Learning. Wenn ich mir vorstelle, ich hätte irgendeine der Anwendungen oder Bibliotheken, die ich in den letzten Jahren in Scala gechrieben habe, in Java oder Ruby oder Python oder... schreiben müssen, wird mir ganz anders. Das wäre nicht einmal möglich gewesen in meiner Restlebenszeit.

    Wenn man den dämlichen Begriff von der Killer-App überhaupt verwenden wollte, dann wäre Scala (die Sprache + das Ecosystem) die Killer-App schlechthin.

    Der Kommentar liest sich leider genau so, wie momentan die meisten Deutungen der Scala Ablehnung ausfallen, nämlich als Furchtreaktion, dass man vielleicht eines Tages gezwungen sein wird, doch eine andere Technologie als EJB lernen zu müssen.

  2. Jochen Theodorou2013-12-05 13:42:33

    Ich kann dem Artikel so nicht zu 100% zustimmen. Die Kritik an Scala ist meiner Meinung nach ein Gemisch aus Angst, durchs Dorf getriebene Sau, Wichtigtuerei und berechtigter Kritik. Das kenne ich schon von Groovy.

    Die Angstreaktionen kommen sicher auch daher, eine Sprache mit einem noch komplexerem Typsystem lernen zu müssen. Aber gerade darin liegt einer der Kritikpunkte: Die Sprache ist für viele zu komplex.

    Als "Entwickler" der Sprache muss man die Kritik analysieren, die Kernelemente herausnehmen und versuchen diese zu Aufzulösen indem man die Sprache entsprechend verändert.

    Bei Groovy wurde damals oft kritisiert, dass Zeilenenden im falschem Maße signifikant sind. Also haben wir den Parser leicht verändert und uns bemüht so was wie "Styleguides" durchzusetzen.

    Diese Probleme von Groovy in der Zeit um 1.0 sind jedoch verschwindend gering zu den Problemen von Scala heute. Den Parser ein wenig zu verändern ist meist nicht so schwer, die Komplexität einer Sprache zu reduzieren, die gerade wegen ihrer Komplexität so interessant ist, ist wie ein Gordischer Knoten. Man müsste versuchen die Lernkurve bei Scala zu verflachen. Doch sehe ich derzeit nicht wie.

    Das ist auch einer der Gründe warum Scala aus meiner Sicht niemals einen Ersatz für Java darstellen wird.

    Und ich habe noch einen Punkt: das Mischen von der Sprachen. Mischt man intensiv Scala und Java, dann muss man weitgehend auf die interessantesten Dinge aus Scala verzichten. Und verzichtet man nicht darauf, wird aus dem ohnehin aufgeblasenem Java ein extrem hässliches Entlein, welches niemals zum Schwan werden wird. Also vergrault man entweder die Javaleute, weil man implicit conversions und traits verwendet (und so einiges anderes wie Operatoren, function classes, ...) - oder man kettet die Scalaleute an, weil man sie solche Dinge nicht mehr benutzen lässt. Das bedeutet Konflikte. Und das solche Probleme bestehen sieht man ja oft genug an in Scala geschriebenen Bibliotheken, die dann noch eine Art Kompatibilitätsschicht, sprich Hilfsbibliothek, brauchen um von Java besser benutzbar zu sein.

    Will man Scala also intensiv nutzen, und die Sprache drängt einen dazu, dann läuft es oft auf ein Scala oder Java hinaus.

    Bei Groovy haben wir uns immer bemüht dass man solch eine Entscheidung nicht treffen muss. Und wir arbeiten mit dem nächsten MOP daran das noch wesentlich zu verbessern.

  3. Ban Foy2013-12-05 18:02:11

    @Jochen Ich stimme Dir zu, dass Scala nicht der Java Ersatz sein wird. Dafür sind die Sprachen einfach zu verschieden, und Scala hat in der Tat eine deutlich steilere Lernkurve, womit eine ganz Zahl von Leuten sicher außen vor gelassen wird.

    Ich stimme allerdings ganz und gar nicht Deiner Einschätzung zum Mischen von Scala/Java Projekten zu. Man muss klar unterscheiden zwischen Projekten, in denen Java ein Zulieferer ist für Scala, und solchen wo die Java Codebase auch in den Scala Teil rufen können soll. Ich habe eine ganze Zahl von Projekte des ersten Typs, und sehe ehrlich gesagt wenig Anreize für den zweiten Fall. In diesem ersten und häufigen Szenario muss man überhaupt nicht "weitgehend auf die interessantesten Dinge aus Scala verzichten". Dort kann ich das volle Repertoire ausschöpfen. Die Integration von Java code ist absolut flüssig. Ich gehe damit täglich um, ohne irgendwelchen Schwierigkeit oder rauhe Kanten zu haben.

    In der Tat sind gemischte Scala/Java Projekte ein sehr pragmatischer Ansatz, da man unmittelbar auf bestehende Codebases zugreifen kann, und wenn die dann stärkerem Refactoring unterworfen werden, kann man graduell zu Scala wechseln.

  4. Jochen Theodorou2013-12-06 13:48:49

    @Ban Foy:
    Einerseits sagst du das Projekte in denen die Java Codebase auch in den Scala Teil rufen können soll wenig Anreiz hätten... andererseits sind für dich gemischte Scala/Java-Projekte ein sehr pragmatischer Ansatz. Das kann ich nur so verstehen, dass wenn du ein Projekt portierst, dass du dieses vom "aufrufenden Code" her machst.

    Mal ganz davon abgesehen, dass dies bedeutet dass du nicht den anderen Weg gehen kannst, weil sonst wäre das ja Fall 2, ist Portierung zwar ein Mischen, aber nur für begrenzte Zeit. Das Ziel ist es schließlich nachher allen Code in Scala zu haben und nicht dauerhaft eine gemischte Codebasis zu haben.

    In Groovy zum Beispiel war es für uns nie ein Ziel die gesamte Codebasis nach Groovy zu portieren. Vielmehr ist es für uns ein Ziel, dass man eine Bibliothek in Groovy schreiben kann und diese dann ganz normal von Java aus benutzen kann...

    Stell dir vor man würde eine weithin benutze Bibliothek nach Scala portieren... was machen dann die Javaleute? Die Benutzen dann die Alte Version, oder einen Adapter oder man pflegt beide Versionen parallel (ist aber eher unwahrscheinlich).

  5. Ban Foy2013-12-06 22:53:35

    @Jochen Du verstehst mich glaube ich falsch. Ich sage gerade nicht, dass man jede Java Bibilothek portieren soll. Es ist oft besser, ein dünnes Wrapper Layer zu schreiben, damit die Aufrufe des Java API ein bisschen hübscher in Scala sind.

    Ich _kann_ schon auch den umgekehrten Fall haben. Es ist ja nicht so, dass Du nicht Scala von Java aus verwenden kannst. Viele grössere Projekte passen im übrigen auf, dass das Java API gut ist. Akka und Play mal als Beispiele. Ich halte es nur nicht für das Hauptanliegen in 95% der Fälle.

    Groovy ist in der Hinsicht sicherlich anders, weil es sich—soweit mein Wissen geht—immer eher als Java Superset Syntax verstanden hat, d.h. Du kannst letztlich Java Sources unverändert mit Groovy kompilieren. Insofern ist die Sprache wohl eher mit z.B. Xtend zu vergleichen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.