Wahrscheinich überrascht es keinen, wenn ich schreibe, damit verbringe ich einen Teill meines Lebens. Mich haben Programmiersprachen schon immer interessiert und ich habe wirklich einiges auf mich genommen um in bestimmten davon arbeiten zu können. Zu meiner Zeit an der Uni war es die Möglichkeit eiffel zu benutzen.
https://de.wikipedia.org/wiki/Eiffel_(Programmiersprache)
Die Idee dahinter scheint mir heute noch eine der wirkich besseren zu sein. Es gibt dort ein Prinzip, nennt sich CQS (command query separation) und es meint. Das nur Methoden den Zustand eines Objektes ändern sollte, es in Abfragen aber nicht vorkommt.
Beispiel set_x(some_Value) enthält nur x := someValue
Aber get_x():someValue enthält nur result := x
Bei dem einen ändert man den Zustand einer Variiablen bei der anderen darf/sollte man es nicht.
C Programmierer kennen das Problem mit Rückgabewerten. Wo packt man den/die hin? In C gibt es kein „Tupel“ Konzept und man kann nur einen Wert zurückgeben, dieser eine Wert kann aber auch ein void* sein und das kann wirklich alles sein. Auf der anderen Seite, wie informiert man den Benutzer, daß etwas schief gegangen ist. Das wird in sehr vielen Bibliotheken eben über den Rückgabewert erledigt. Darum findet man in C so etwas
#define ERROR_SUCCESS 0
#define ERROR_WHATEVER 1
Vielleicht in angenehmeren Code in einem enum. Der Rückgabewert gibt also an ob alles „glatt“ ging oder nicht, damit ist dannn aber der Rückgabewert „weg“ und man muß sich mit globalen Variablen oder veränderbaren Parmetern behelfen.
Hier zwei Lösungen aus anderen Programmiersprachen:
https://doc.rust-lang.org/book/ch09-00-error-handling.html
https://go.dev/doc/tutorial/handle-errors
In Smalltalks gibt es nur Messages die etwas zurückgeben…
Aber nun kommen wir zu Programmiersprachen, die Seiteneffekte gar nicht leiden können und nur auf „pure“ Funktionen setzen. Das bedeutet, wenn man diese aufruft ergeben die mit denselben Eingabedaten immer, diegleichen Ergebnisse. Die „dreckige“ Arbeit von Seiteneffekten muß speziell gekennzeichnet werden. Prominentestes Beispiel dürfte Haskell sein (dazu eines der besten Bücher, was man auch online finden kann http://book.realworldhaskell.org/read/)
In jedem Buch wird die „Reinheit“ der Sprache gelobt, handelt es sich um eine „unreine“ Methode also mit Seiteneffekten wird es immer irgendei IO type werden, das nennen die Monad.
Nun, die Autoren behaupten es sei der größte Vorteil. Ich stimme soweit durchaus mit ihnen überein, aber ich behaupte auch es ist der größte Nachteil, damit stimme ich als nicht mit Ihnen überein.
Ich bin immer mehr zur Überzeugung gekommen, daß der ausbleibende Erfolg von funktionalen Sprachen damit zusammenghängt. Es sieht so aus als ob Zustand – Zustandsänderung -> neuer Zustand für wirklich die allermeisten Programmierer einfacher verständlich ist und dem normalen Denkmodell entspricht. Was man uns nicht verdenken kann. Sitzen Sie in einem Auto und wollen los fahren, müssen Sie etwas tun. Einen Gang einlegen, Kupplung kommen lassen und entsprechend Gas geben, dann fährt ein Auto eben los, der Zustand ändert sich von stehendem Auto -> fahrendem Auto.
Ich denke auch, daß eben Zustandveränderungen genau das sind was man in allen anderen Bereichen macht. Dieses hinter einem Monad zu verstecken, scheint für mich einer der Hauptgründe zu sein, warum man Funktionale Programmiersprachen nicht in größeren Bereichen kennt. Betrachtet man unsere gesamte Infrastruktur, dann wird man eher früher als später auf C treffen. Trotz aller Probleme damit, trotz der problematischen nebenläufigen Programmierung. So gut wie alle Betriebsysteme benutzen C als Basis und es gilt selbstredend speziell auch für jedes Unix, heiße es LInux, BSD, Solaris, HP-UX, AIX. So gut wie jeder relationale Datenbank ist in C geschrieben und manche davon werden tatsächlich milliardenfach benutzt (z.B. sqlite)
Ich persönlich kenne wirklich kein Programm, welches ich täglich benutze, daß in einer funktionalen Sprachhe implementiert wurde. Man kann behaupten, das derzeitige vorherrschende Programmiermodel basiert auf Klassen, Objekten und Messages.
Ja, es ziehen funktionale Elemente in OO-Sprachen ein, aber Blöcke sind in Smalltalk ein uraltes Konzept! Kurz die neuen PS müssen sich an einer der ältesten noch benutzen PS anlehnen. Das finde ich höchst interessant und erklärt vielleicht zu einem Teil warum ich Smalltalk für eine der besten Programmiersprachen halte.