Clojurians Log v2

Morgen!

Wobei es ja doch recht viele funktionale OOP Sprachen gibt ;)

moin moin

Das nachträgliche Einbauen von FP Konstrukten in Java macht die ganze Sprache nicht einfacher. Man läuft schnell in das Missverständnis rein, dass man glaubt, nun könnte man man das gleiche machen, wie in Clojure. Aber da 97% aller deiner Java-Klassen mutable sein werden, kann man es eben nicht tun. Im Labor ist dann alles grün, aber in Produktion unter Load macht der Code irgendwas - aber bestimmt nicht mehr das Richtige. Die lustige Sache mit dem Classloading-Synchronized-Lock ist nur die Spitze des Eisbergs. Ich habe schon erlebt, dass Leute im Fachcode parallel streams verwenden wollten und sich dann wunderten, dass sie keinen Transaktionskontext der DB Verbindung hatten. Es sieht syntaktisch so harmlos aus, ein pmap anstatt eines map zu machen, aber es sind riesen Unterschiede in Java. In Clojure kann es dich natürlich auch beißen, aber deutlich seltener.

Das nachträgliche und abwärtskompatible ist halt immer ein Kompromiss. Sieht man ja z.B. an Optional in Java. Es ist jetzt da, aber im Vergleich zu anderen Sprachen nicht ganz rund. Ich finde es beeindruckend was Java in den letzten Releases alles liefert. Ich denke die Kombination aus Value Types, Records, Patternmatching wird ein paar „echtere“ funktionale Ansätze zulassen, da bin ich ziemlich gespannt drauf

Ich bin schon lange raus aus Java und was wir jetzt and Sprachfeatures sehen, hätte es vor 10 Jahren geben sollen. Aber das ist ein schritt in die richtige Richtung. Nur auf lange Sicht skaliert es aben auch nicht Features oben drauf zu packen.

Ich bilde seit 20 Jahren Fachinformatiker für Anwendungsentwicklung aus. Für die nachfolgende Entwicklergeneration kommen OOP und FP in einer Sprache zusammen (auch in C#). Beide Paradigmen sind zu lernen und zu verstehen. Ebenso ein Gefühl dafür, wann das eine oder das andere einzusetzen ist. Und was, wenn in einem Projekt zwei Bibliotheken oder gar Frameworks aufeinandertreffen, die sich für unterschiedliche Schwerpunkte entschieden haben? Dann haben wir auch lustigen FP/OOP Glue-Code. Das gleiche Problem haben wir ja schon bei anderen Spracherweiterungen.

Ich finde es super, dass auch Leute aus dem OOP/Javaland FP Paradigmen lernen/nutzen. Aber ohne 'immutability-by-default' steht das FP in Java meiner Meinung nach auf extrem wackeligen Beinen. Neben Parallelisierung fällt mir auch lazy-eval ein. Und da mutability transitiv infektiös ist, ist es extrem schwer, solche FP Features in Java sicher zu verwenden.

Ich denke halt immer viel und oft und gerne an die Generation, die nach uns kommt und was das für sie bedeutet. Wieviel Zeit möchten wir als Entwickler Community aufbringen, damit ein neuer Java (oder C#) Entwickler (m/w/x) sicher im Sattel sitzt, was nur die Sprachfeatures selbst angeht? 2 Jahre? 4?

(Und die fehlende immutability-by-default macht's ja noch ungelenker. Abgesehen davon, dass Immutability noch on Top kommt, zusammen mit Werttypen und Referenztypen. Es ist wirklich, wirklich viel Stoff.)

(Und alles Accidental Complexity. Das kommt nur durch die Sprachen rein.) Sorry. Bin ja schon ruhig...

Es wird halt auch immer mehr. Ich konnte meinen Ex-Kollegen im FE Bereich dabei zuschauen, wie sie versuchen mussten den Auszubildenden den gesamten Web Stack von HTML über CSS bis hin zu React, npm, webpack, usw usw beizubringen…

> Es wird halt auch immer mehr. Das ist aber kein Naturgesetz. "Wir" steuern das so. Und ich rege an, das anders zu steuern. Und damit anzufangen, das eben nicht gut zu finden.

Da bin ich absolut dafür. Ich sehe nicht, dass (zumindest bei Enterprise Software) irgendwas komplexeres gemacht wird als vor 10 Jahren…

#ejb2

Wobei das noch ne Ecke länger her ist

Wie war das? “Kubernetes is the new WebSphere, change my view”

Kubernetes ist ja auch wie die Blockchain der Ops-Welt

Fast niemand braucht das, aber alle wollen es irgendwie unbedingt im Stack haben

Software-Enwicklung ist immer noch kein Ingenieurstaetigkeit. Change my view 🙂