Funktionen und die Zukunft von Java

Der Kollege Ingo schreibt drüben über funktionale Programmierung in Java.  Ein immer wieder spannendes, letztendlich aber leider auch immer frustrierendes Thema. Da ich noch exakt 30 Minuten habe, bevor ich ans Seminar muss, schaue ich mal, ob ich dazu was raushauen kann.

Der mittlerweile klassische Text* dazu ist wohl Steve Yegges „Execution in the Kingdom of Nouns“. Kurzfassung: Java kennt nur Substantive (sprich: Klassen), es fehlen die Verben (sprich: Funktionen, Closures, Blocks, wie auch immer) – dabei machen die doch die Hauptarbeit, egal ob in einer natürlichen oder in einer Programmier-Sprache.

Das muss man nicht so sehen.  Aber wer schon mal versucht hat, sagen wir, einen Taschenrechner zu simulieren, der wird an Java verzweifelt sein.  Dass der Taschenrechner viele verschiedene Zahlen verarbeiten kann: für Java kein Problem!  Dem Taschenrechner aber verschiedene Rechenoperationen beibringen: unglaublich kompliziert!  Für jede braucht man eine eigene Klasse (z.B. Addition, Subtraktion, Potenz, Wurzel, …) die letztzlich alle nicht viel mehr tun werden als eine Methode rechne() aufzurufen, die dann je nach Klasse addiert, subtrahiert, potenziert, usw. Verben machen die Arbeit!!!  Aber die gibt es in Java nur durch die Hintertür.

Ohne das überprüft zu haben (korrigiert mich, wenn ich falsch liege) behaupte ich:  Mehr oder weniger alle Sprachen, die seit Java populär wurden, haben First-Class Funktionen. Python, JavaScript, die neuen funktionalen Sprachen wie Clojure und F# sowieso.  Java hat anonyme innere Klassen und bekommt… vielleicht… demnächst… irgendwann… Closures.

Das reicht nicht.  Spätestens seit sich mit JavaScript ein Standard (ja, das muss man wohl so sagen) für die Web-Programmierung etabliert hat, der vieles hat, was Java fehlt (leider auch manches andere, das man eigentlich lieber nicht möchte), sehen die Leute Java sehr kritisch.

Meine Prognose: Wir werden in 5 Jahren nicht mehr Java unterrichten!

So, und jetzt muss ich gehen und kann das nicht mehr ausführen.  Was meint ihr?

*Aber: Für den Einstieg und für alle, denen Yegge zu lang oder zu laut ist, noch viel besser geeignet (da kürzer und leichter verständlich), ist dieser Artikel von Joel Spolsky „Can Your Programming Language do This?“

Advertisements

16 Gedanken zu „Funktionen und die Zukunft von Java

  1. Der Artikel von Spolsky sieht wirklich gut aus. Muss ich mal unbedingt lesen.
    Aber das mit „In 5 Jahren gibt es kein Java mehr…“ glaube ich eher nicht. Dazu ist es im Moment immer noch viel zu sehr verbreitet. Auch an der Uni. Aber lass uns in 5 Jahren nochmal drüber reden 😉

    • Zugegeben: So richtig glaube ich daran eigentlich auch nicht. Natürlich mahlen die Mühlen an den Schulen und Unis langsam. Was ich aber wirklich glaube: Der Höhepunkt des unbedingten Glaubens an die objektorientierte Programmierung im Allgemeinen und an Java im Besonderen ist überschritten.

      Java ist an so vielen Stellen, gerade für die Schule, frustrierend, weil so unnötig komplex. Warum muss es denn Java sein? Die allermeisten Schüler werden nach der Schule niemals wieder Java programmieren! Warum dann nicht Smalltalk (wenn man die reine OOP predigen will) oder Python (wenn man’s klar, nah am Pseudocode, multiparadigmatisch mag) oder Scratch/BYOB (wenn man in erster Linie informatisches Denken schulen will)?

      Oder eben JavaScript (noch besser: CoffeeScript). Denn durch den aktuellen Siegeszug der Tablets und der Idee vom „Browser als Plattform“ wird sich vieles ändern. Und fürs Web ist Java einfach nicht die Sprache der ersten Wahl. Vielleicht am ehesten noch in solchen Hybridformen wie Processing.js.

      Aber abgemacht, wir reden in (spätestens) 5 Jahren wieder drüber!

  2. Es gab keine Funktionen in Java als First-Class-Citizens, weil man es nicht wollte. Gosling hat sich dagegen entschieden, weil damit auch ein Grad Komplexität in die Sprache kommt, der nicht für jedes Softwareprojekt gut ist.

    Konzepte wie Call-Back-Funktionen in der Webprogrammierung scheinen von Sprachen wie JavaScript aber gut unterstützt zu werden.

    Bevor man Funktionen als Parameter verstehen kann, muss man zunächst gewöhnliche Objekte als Parameter verstehen. Und selbst dabei stoßen viele Programmierer an ihre Grenzen und fallen zurück in Prozedurales Denken.

    Der Grund, warum Funktionale Programmierung so erfolglos ist: Es existieren keine guten Debugging-Strategien im Fehlerfall.

    • Das sehe ich ein wenig anders 😉 Ich halte die Funktion für ein wesentlich grundsätzlicheres Element der Programmierung als das Objekt. Funktionen als Parameter sind natürlich nicht ohne. Aber was man als OO Programmierer für einen Aufwand treibt, um ihr Fehlen wettzumachen, ist schon erstaunlich! 90 Prozent aller „Design Patterns“ würden obsolet, wenn Funktionen first class wären (http://programmers.stackexchange.com/questions/148797/peter-norvigs-paper-cited-by-brendan-eich).
      Das geht jetzt natürlich weit über alles, was wir in der Schule machen hinaus – insofern kann es schon sein, dass OOP für die Schule das anschaulichere und deshalb bessere Modell ist. (Aber warum dann nicht Smalltalk??? Warum müssen Schüler eine Sprache lernen, in der es beides gibt, Integer und int? Wie erklärt man ihnen das?)

      • Schon klar, dass Peter Norvig als alter Lisper die Patterns nicht mag. Aber er argumentiert auf einer Ebene, die viele Programmierer nie errichen: Das Erstellen einer eigenen Domänensprache.

        Smalltalk halte wegen der komplizierten Syntax und vor allem der fehlden starken Typisierung für schwierig. Aber denkbar wäre die Sprache schon und sie wird auch stellenweise benutzt.

  3. Ich denke auch, dass die Objektorientierung in Zukunft nicht mehr ganz den Raum einnehmen wird wie jetzt. Dafür kommt dann mehr Algorithmik und vielleicht schon etwas funktionale Programmierung.

    Für pädagogische Zwecke halte ich Python für hervorragend – kann man sofort einsteigen; 3D-Grafiken sind im Nu gemacht; objektorientiert oder nicht. Dürfen wir ja auch jetzt schon, im Lherplan steht nichts von Java. Aber die Bücher sind darauf eingerichtet, und der Elftklasslehrer wird mich rügen, wenn ich in der 10. nicht genug Java vorbereite.

    Übrigens: Inform 7 kennt Funktionen als Argumente oder Variablen. 🙂

    • Python: Alleine die „list comprehension“ wäre es schon wert, voll auf Python zu setzen! Wunderbare Notation; ganz nahe an derjenigen, die die Schüler aus Mathe sowieso schon kennen.
      Bsp.: odd_squares = [x*x for x in range(10) if x % 2 == 1]
      Wie viele Zeilen benötigt der entsprechende Java-Code? Und, v.a., wie viel Ablenkung vom Wesentlichen bringt das mit sich?

      Inform 7: Dazu würde ich ja gerne mal wieder einen Post von dir lesen! Benutzt du es noch? Kommt es an?

      • Ich bin auch sehr skeptisch, ob komplett funktionale Sprachen jemals Mainstream werden. (Obwohl ich deine Skepsis, was das Debuggen angeht, *nicht* teile. Seiteneffektfreies Programmieren ist ein Segen beim Debuggen!) Aber schau dir JavaScript, Ruby, Python, Scala, Objective-C an: Alle Sprachen jenseits von C++ und Java, die zurzeit wichtig sind oder werden, haben first-class functions/closures/blocks. JavaScript wird von vielen als „Lisp mit Java-Syntax“ bezeichnet. (Keine Ahnung, ob das trifft; dazu kenne ich beide Sprachen zu schlecht.) Das ist kein Zufall, sondern das Resultat davon, dass Objektorientierung bis zu einem gewissen Punkt ein anschauliches Modell ist, aber dann manche Dinge irre kompliziert werden – ohne dass sie es sein müssten. Deswegen werden die Sprachen um solche Features erweitert. Bei manchen Sprachen ist das leichter, bei manchen schwerer und dauert deshalb ewig.
        Der letzte Punkt ist es, der mich für Java pessimistisch stimmt. Aber jetzt habe ich gerade diesen Folien von Oracle entdeckt: https://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf Und da steht das schöne Zitat: „It’s about time! Java is the lone holdout among mainstream OO languages at this point to not have closures“ Der ganze Vortrag ist sehr interessant übrigens. Also warten wir mal ab, was da passiert.

        Dann ist natürlich v.a. die Frage, was das für den Schulunterricht bedeutet. Vielleicht erstmal gar nichts. Aber schau dir in dem Vortrag mal S. 33 an. Welche Version von sort() würdest du einem Oberstufenschüler erklären wollen? Wir sind als OO-Programmierer so darauf gepolt zu glauben, dass Sortieren *beliebiger* Daten total kompliziert ist – wegen der Komparatoren usw. Aber wenn die Syntax es erlaubt, ist plötzlich wieder alles ganz einfach und man kann einen Bubblesort auch mal mit Strings machen statt immer nur mit Zahlen!

      • Noch ein allerletzter Kommentar: Der Hauptgrund für das (Wieder-)erstarken der FP ist sicher die Hoffnung auf eine bessere *Parallelisierbarkeit* von Algorithmen im Zeitalter von Multicores und Cloud-Computing. Googles MapReduce zeigt im ganz großen Stil, wie’s gehen kann. Auch darauf bin ich gespannt.
        Aber für die Schule ist Parallelismus irrelevant, oder?
        (Ich meine mich aber zu erinnern, dass irgendjemand, du vielleicht oder Ingo, mal was über „Threads in der Schule“ geschrieben hat… Uiuiui, würd ich mich nie trauen. Dann noch lieber Lisp – da kann man wenigstens irgendwie nachvollziehen warum etwas passiert, wenn es passiert!)

  4. @Marco (aber auch die anderen) noch ganz kurz zur Typisierung: Wie sind denn da eure Erfahrungen mit den Schülern? Ich erlebe den Zwang zur Typdeklaration in Processing (d.h. Java) ja gerade eher als Stolperstein für die Schüler. Und ihr?

    • Ich empfinde es als übersichtlicher, wenn mir die IDE weiterhelfen kann und sagen kann, welche Methoden ich im aktuellen Kontext verwenden kann.

      Aber ich gebe dir Recht: Eine Dose, in die ich alles mögliche reinstecken kann (keine Typen), ist zunächst einfacher zu bedienen als eine Dose, die nur spezielle Inhalte aufnehmen kann (starke Typen). Die schwachen Typen kommt auch dem Konzept aus der Mathematik nach, wo eine Variable erst recht spät im Schulleben typisiert wird, indem ihr Definitionsbereich angegeben wird.

  5. @embee: Ich frage mich, warum funktionale Konzepte gerade jetzt nötig sind, wenn ganze Industrien ihre Software in OO entwickeln. Die funktionalen Sprachen sind sehr alt und haben tatsächlich keinen Einzug in den Mainstream gehalten – da sind wir einer Meinung.

    Wenn Closures kommen, werden sie für Traversierungsprobleme ihre Anwendung finden – die du auch genannt hast. Ich überlege nur gerade, ob das Konzept der Closures ähnlich weitreichend ist, wie es MVC für die OO war und ist. Ich denke vielmehr, dass es Software komplizierter macht und wohl an Stellen Anwendung finden wird, wo es keine ausgereifte OO-Modellierung gibt. Leider gibt es viele Programmierer, die falsch ausgebildet werden und wurden (mich eingeschlossen), da ihnen die Objektorientierung als „verdinglichte-prozedurale Programmierung“ beigebracht wird. Häufig von Menschen, die selbst aus einer prozeduralen Welt kamen.

    Beim Durchsehen der Smalltalk-libs staune ich gerade selbst, wie weit man ohne prozedurale Konzepte wie if-then-else und Schleifen kommen kann.

    Mein Fazit: Zukünftige Sprachen werden vermutlich immer mehrere Paradigmen in sich vereinen und ausschlaggebender für die Durchsetzbarkeit ist am Ende häufig eher das Ökosystem um eine Sprache herum als die Sprache selbst. Virtuelle Maschinen werden evt. auch mehre Sprache in einer Laufzeitumgebung zulassen.

    Ich bin gespannt, ob ich bald einen bunten Strauß von Problemen finden werde, die mit Closures besser gelöst werden können als mit OO. 🙂

  6. Threads macht man in Bayern in der 12. Jahrgangsstufe, da kann man schon mal ein paralleles Bubblesort neben einem einfachen programmieren und vergleichen.
    Funktionales Programmieren ist mir gar nicht so wichtig wie die Algorithmik, die über die Objektorientierung zu kurz kommt. Ich will, dass Schüler einfach mal schnell einen Algorithmus in eine Programmiersprache umsetzen können, ohne eine Klasse drumrum bauen zu müssen.
    Datentypen: noch nicht genug Erfahrung. Was Datentypen sind, kapieren Schüler schnell; aber jedes Fitzelchen Code ist eine weitere Schwierigkeit, und bei Funktionen den Überblick zu haben, welche Variable deklariert werden muss und welche nicht (weil schon anderswo geschehen), das fällt meinen Schülern schwer.

    • Ja, ja und ja! Mir ist FP über das hinaus, was ich in dem Logo-Artikel geschrieben habe (Funktion als Abstraktion), auch gar nicht so wichtig in der Schule. Mehr Algorithmik wäre toll, der Zwang zur „Klasse drumrum“ nervt (deshalb hab ich hier ja mit Scratch und Processing angefangen: „objects later“ in Reinform). „Jedes Fitzelchen Code ist eine weitere Schwierigkeit“ -> besser kann man das nicht sagen. Auch deshalb ist Python gut: weniger Fitzelchen! Und das Deklarieren von Variablen/Parametern/Attributen, v.a. auch deren Gültigkeitsbereich (scope) usw ist ein Riesenproblem, das ich zuerst, zugegeben, ziemlich unterschätzt habe. Dabei sind meine Schüler 17! Aber sie haben halt noch nie in ihrem Leben Quellcode gesehen 😦

  7. Pingback: Das Wunschblog | Zurück in die Schule

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