Wasch mich, aber mach mich nicht nass!


Es ist kein Geheimnis: Java macht keinen richtigen Spaß mehr, wenn man es mit anderen modernen Sprachen vergleicht. Was macht man, wenn man weiter die JVM und die unzähligen Java-Bibliotheken nutzen will? Richtig, man schaut kräftig beim Marktführer Scala ab, und schreibt eine eigene Sprache. Die natürlich besser ist. So geschehen bei Gosu, RedHat’s Ceylon und nun JetBrain’s Kotlin.

Ich finde das traurig. Richtig, es heißt „Konkurrenz belebt das Geschäft“, aber diese drei Sprachen sind unnötig wie ein Kropf. Es stimmt, Scala kann kompliziert sein und hat auch einige weniger schöne Stellen. Auf der anderen Seite ist es einsteigerfreundlich, innovativ und mächtig, aber vor allem ist es da. Es hat lange gebraucht, um wirklich Bewegung in die Sache zu bringen, eine Community aufzubauen, Tool-Support zu organisieren, ja überhaupt wahrgenommen zu werden. Was inzwischen fast wie ein Selbstläufer aussieht, ist das Ergebnis langer, harter Arbeit. Ich denke, die neuen Sprachschöpfer unterschätzen diesen Aspekt einer Sprache ganz gewaltig.

Viel eigene Innovation ist bei keinem der Kandidaten zu sehen. Aber was mich wirklich stört, ist der Versuch, sich nur die Rosinen aus dem Kuchen zu picken. Das ist nämlich die Art von Geisteshaltung, die Java’s Stillstand erst verursacht hat. Eine gute Sprache ist offen für neue Entwicklungen, und lenkt diese in geordnete Bahnen. Gerade diese Offenheit macht Scala so attraktiv. Doch die Strategie der neuen Sprachen ist die gleiche wie Java: Wasch mich, aber mach mich nicht nass! Features, die „zu kompliziert“ sind oder eventuell missbraucht werden können, werden abgelehnt. In Java waren das etwa Operator-Überladungen, Closures oder Konzepte zur Erweiterung von Interfaces (wie Extensionsmethoden oder Mixins). Jetzt werden aus den gleichen fadenscheinigen Gründen Dinge wie implizite Umwandlungen, abstrakte Typ-Member oder Typpolymorphismus höherer Ordnung abgelehnt – obwohl diese Ideen längst den Praxistest bestanden haben. Was immer wieder übersehen wird ist, dass viele Features, die für die tägliche Arbeit unnötig scheinen, in Bibliotheken und Frameworks essentiell sein können: Jeder, der in Scala eine Liste mapped, verwendet dabei Typpolymorphismus höherer Ordnung – aber er muss dazu nicht einmal wissen, was das ist.

Ich denke dass für viele Detail-Lösungen der neuen Sprachen auch Platz in Scala gewesen wäre, wenn die Macher auf Kooperation gesetzt hätten. Aber jetzt wird viel Arbeit und Gehirnschmalz in Dinge investiert, die es zum größten Teil schon gibt, und Projekte gestartet, die keinen Erfolg haben können. Ein Blick in die Geschichte zeigt, was mit gut gemeinten, aber zu konservativen Ansätzen passiert: Nice hatte viele gute Ideen und nette Details, aber nicht genug, um die Java-Community wirklich zu begeistern, und neue Perspektiven zu eröffnen.

Ich will kein aufgehübschtes Java, und auch kein weichgespültes Scala. Sicher ist es nett, wenn hier und da eine Syntax-Kante geglättet wird. Aber wenn mir am Ende die Ausdrucksstärke fehlt, um meine Gedanken in Code umzusetzen, nützt mir das alles nichts. Ich will keine Sprache zwischen Java und Scala – wenn überhaupt, dann zwischen Scala und Haskell, mit mehr Abstraktionsmöglichkeiten, nicht weniger. Scala ist sicher nicht der Endpunkt der Entwicklung, aber es schwimmt in die richtige Richtung. Nass, aber sauber.

Update

Hier noch ein interessanter Blog-Post, der in die gleiche Richtung und dabei etwas mehr ins Detail geht: Scala, Kotlin, Ceylon… let’s start by being honest.

Advertisements

6 Gedanken zu “Wasch mich, aber mach mich nicht nass!

  1. Ich verstehe die Aufregung ehrlich gesagt nicht. Mit dem Argument, man solle lieber bei dem bleiben, was da ist und nicht neu Experimente wagen, hätte es Scala nie gegeben.

    Ich arbeite seit Jahren mit IDEA von JetBrains und man merkt sehr schnell, dass dort Entwickler arbeiten, die ihr Handwerk wirklich verstehen und immer wieder mit innovativen Ideen meinen Arbeitsalltag erleichtern.
    Da JetBrains auch Plugins für Scala, Groovy, Python und Ruby anbietet, sowie an einer separaten IDE für Objective-C arbeitet (und auch im .Net-Bereich aktiv ist), bin ich sehr sicher, dass die JetBrains-Entwickler ein extrem tiefes Verständnis für die Architektur und das Design einer Sprache haben.
    Insbesondere denke ich aber, dass bei JetBrains der Praxis-Bezug bei der Entwicklung der Sprache eine Hauptrolle spielt – das kann man schon jetzt daran erkennen, was Kotlin z.B. gegenüber Java anders macht in Bezug auf Exception-Handling, Getter/Setter, Typsicherheit, Closures usw.

    Vielleicht wird Kotlin keinen großen Nutzerkreis finden, aber die Voraussetzungen für einen Erfolg sind aus meiner Sicht exzellent, da bei JetBrains eine extrem große, fachliche Expertise mit dem richtigen Praxisbezug zusammen kommt. Ob Kotlin am Ende durchstartet oder nicht, wird die Zukunft zeigen.

    Zu guter Letzt noch ein paar Gedanken, warum JetBrains nicht an Scala mitarbeitet. Zum Einen kann man nicht alle Ansätze von Kotlin auf Scala übertragen ohne den Kern von Scala anzufassen – das dürfte nicht realisierbar sein.
    Zum Anderen hätte JetBrains nicht die Option, die Sprache exakt so zu gestalten, wie sie es wollen. Bei einer eigenen Entwicklung kann man viel radikalere Entscheidungen treffen und Dinge genau so gestalten, wie sie es wollen. Das muss man nicht gut finden – aber aus JetBrains‘ Sicht ist das sicher ein Vorteil.

    Das Beste aber ist doch: niemand wird gezwungen, Kotlin einzusetzen. Mit welche Sprache man baden geht, bleibt jedem selbst überlassen 😉

  2. „Mit dem Argument, man solle lieber bei dem bleiben, was da ist und nicht neu Experimente wagen, hätte es Scala nie gegeben.“ Das stimmt, aber dieses Argument habe ich gar nicht gebracht. Ich kreide Kotlin & Co ja gerade an, dass sie zuwenig experimentieren, sondern im Wesentlichen nur Bauteile aus dem Fertigbausatz Scala recyclen. Aber wozu brauche ich eine Fußbank, wenn ich schon eine stabile, TÜV-geprüfte Trittleiter habe?

  3. java macht sehr wohl spass. es hat ecken und ist einige jahre alt. spass macht es auf jeden fall immer noch.
    warum auch nicht?

    zu sagen diese neuen sprachen sind unnoetig halte ich fuer arrogant oder dumm. dann haette man genauso auf scala verzichten, mehr energy in java selbst stecken koennen.

    sich rosinen heraus zu picken ist das recht von allem neuen und hinterlaesst den eindruck eines eifersuechtig blickenden scala anhaengers. da ist man sonst mehr von deinem blog gewohnt.

    • Viele Leute haben versucht, Java zu verbessern, sind aber gegen Beton gelaufen, und haben sich frustriert abgewandt. Inzwischen ist auch bei Oracle angekommen, dass Java Innovation braucht, und dass es Jahre hinter der Konkurrenz zurückgeblieben ist, und Engagement könnte sich wieder lohnen. Eifersüchtig bin ich bestimmt nicht, ich wünsche mir mehr Innovation, das Problem ist, dass ich bei den genannten Sprachen nicht viel davon sehe. Vielleicht täusche ich mich, und das kommt alles in den nächsten Versionen, aber ich halte es für wahrscheinlicher, dass die Sprachen in ihren Nischen verkümmern werden.

      • manche verwechseln gegen beton laufen damit, dass gefaelligst die eigenen wuensche realisiert werden sollen. dies ist bei projekten wie java genausowenig moeglich wie bei csharp.

        python hat schmerzhaft gezeigt, dass innovation behutsam erfolgen muss. und scala kann nur so lange derart innovativ sein (ist es das wirklich?), so lange es nicht im konservativen enterprise feld angekommen ist.

        scala wird in der gleichen nische wie gosu, kotlin, etc. verkuemmern. es ist zu avantgarde aber schafft nicht den wechsel in den mainstream.

    • Generell halte ich es für ein gutes Zeichen, dass derzeit viele verschiedene Ansätze auf der JVM „ausprobiert“ werden.
      Konkurrenz ist nichts negatives. Im Gegenteil – fehlende Konkurrenz auf der JVM hat den Java-Stillstand überhaupt erst ermöglicht und dazu geführt, dass der „billige Abklatsch C#“ inzwischen sprachlich deutlich mächtiger ist als das Original.

      Zu Scala und seiner „Komplexität“ ist im Netz bereits genug gesagt worden (nur soviel: ich teile diese Ansicht nicht).

      Welche Sprache sich industriell durchsetzt wird letztendlich „mit den Füßen“ abgestimmt.
      Wichtige Faktoren sind hierbei IMHO

      * professioneller Support
      * existierende Frameworks
      * Ersparnis an Supportkosten / Entwicklungskosten
      * Stabilität
      * Dokumentation / Entwicklergemeinde
      * Marketing & Rechtsabteilung (-> Patentfragen)

      Wenn’s an einer dieser Stellen entscheidend klemmt, dann wird es für das entsprechende Produkt eng. Mag sein, dass ShinyScript das Non-Plus-Ultra an Sprachfeatures bereithält, wenn man an einem der obigen Punkte ein „kein“ an den Anfang setzen muss, dann ist das Teil tot – oder zumindest in Gefahr plötzlich getötet zu werden (Patentklagen/USA).

      Was nur „nachrangig“ in Erscheinung tritt sind Dinge wie

      * Sprachfeatures
      * Toolsupport

      Beides kann durch geschicktes Marketing ausgeglichen werden, solange es nicht zu deutlich auf die Entwicklungskosten oder Betriebskosten durchschlägt (PL/SQL + notepad? Leider immer noch Berufsalltag – und es funktioniert letztendlich, wenn es sein muss).

      bjo

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