Warum sollte man "Haskell, OCaml, Scala & Co" lernen?



  • Decimad schrieb:

    Wenn es Dir größte Freude bereitet, den Template-Prozessor Deines Compilers mit abstrusen Aufgaben zu malträtieren, genau dann solltest Du einen näheren Blick in die Welt der funktionalen Programmiersprachen wagen 😃

    sorry, aber versteh ich nicht 😕



  • Naja, Templates sind im Prinzip auch funktionale Programme, außer dass sie in der "normalen" Reihenfolge ausgewertet werden (Was zu den schön langen Fehlermeldungen führt).
    Aber vielleicht bewege ich mich hier auf dünnem Eis.



  • Decimad schrieb:

    Aber vielleicht bewege ich mich hier auf dünnem Eis.

    C++ Templates zu Haskell sind vielleicht wie Brainfuck zu C++

    Brainfuck ist nicht funktional, also bleibt noch imperativ übrig. Man kann zwar damit imperativ programmieren, aber höhere Konzepte wie OOP oder Templates (=funktional) sind quasi unmöglich.

    C++ Templates sind nicht imperativ, also bleibt noch funktional übrig. Man kann zwar damit funktional programmieren, aber höhere Konzepte wie Typklassen (=Concepts, das geht irgendwann vielleicht sogar) und Monaden (=imperativ mit Nebeneffekten) sind quasi unmöglich.

    Sagen wir mal so, wer Templates einigermassen beherrscht kann noch lange nicht funktional programmieren.



  • Na was heißt schon "eingermaßen beherrschen". Wenn's beim Einsetzen von einem int bleibt, hat man natürlich das funktionale daran noch nicht entdeckt. Aber wer trotz der entsetzlichen Syntax und den wenig hilfreichen Fehlermeldungen Freude daran hat, mit templates funktionale Konzepte umzusetzen, der wird wohl auch Freude daran haben, dies mit einer der Herangehensweise angepassten Sprache zu erledigen. Es sei denn, es geht nur um den Masochismus an der Sache.



  • Decimad schrieb:

    Na was heißt schon "eingermaßen beherrschen". Wenn's beim Einsetzen von einem int bleibt, hat man natürlich das funktionale daran noch nicht entdeckt. Aber wer trotz der entsetzlichen Syntax und den wenig hilfreichen Fehlermeldungen Freude daran hat, mit templates funktionale Konzepte umzusetzen, der wird wohl auch Freude daran haben, dies mit einer der Herangehensweise angepassten Sprache zu erledigen. Es sei denn, es geht nur um den Masochismus an der Sache.

    Ich meine damit solchen Code, wie ich zum Beispiel da produziert habe (unter dem Namen templer):

    template <typename TL> struct go {
      template <typename I> struct go2 {
        template <typename J, typename T> struct go3
          : std::conditional<static_cast<bool>(I::value & (1 << J::value)), T, void> {};
        using type = filter<zip_with<go3, make_index_list<size<TL>::value>, TL>,
                            static_not<std::is_void>::template action>;
      };
    };
    
    template <typename... E>
    using all_subsets = transform<make_index_list<(1<<(sizeof...(E)))>, go<type_list<E...> >::template go2>;
    

    Sieht zwar ganz nett aus, aber irgendwo bin ich an eine Grenze gestossen, für die ich eindeutig zu wenig masochistisch veranlagt bin. Zu wenig kann man in allgemeine Interfaces stecken. Schon bei Currying bin ich das letzte Mal gescheitert. Es fehlt einfach der Abstraktionsmechanismus, den eine echte Sprache ausmacht.



  • Sorry Leute, aber ich komme aus dem C-Bereich! Ich hab mit C++ nix am Hut und hab auch keine Ahnung, was Templates sind!

    Was unterscheidet die funktionalen Programmiersprachen untereinander?



  • Nun, Du machst mit templates die kuriosesten Sachen und erscheinst hier zugleich auch als Kenner der echten funktionalen Sprachen. Siehst Du den Zusammenhang, auf den ich hinaus möchte? 😉

    Und ich muss halt offen zugeben: Ich halte templates weder für gute Code-Generatoren, noch für schöne funktionale Programme (so sie denn solchermaßen eingesetzt werden). Aber irgendwie haben sie sich (ich nehme an, aufgrund rübergeschwappter Funktionalisten) zum Selbstläufer in beide Richtungen entwickelt, mit dem wir uns jetzt halt rumschlagen müssen, weil wegen ihnen keine besseren Lösungen mehr ersonnen wurden. Meine Meinung.



  • @TO: Vergiss es! Wenn du schon Fragen wie "Warum sollte ich xyz lernen?" stellst, dann brauchst du dich gar nicht weiter mit der Materie befassen. Auf eine solche Frage muss man sofort mit "Weil es Spaß macht" oder "Weil man etwas neues lernen kann" antworten, ansonsten bringt das alles nichts. Auch noch zulässig wäre "Man bekommt ein Zertifikat/Studienabschluss/Geld/etc.", das funktioniert vermutlich aber nur bei vorhandenem Prüfungs- oder Leistungsdruck, die hier aber nicht gegeben sind.

    Hinzu kommt, dass funktionale Sprachen (insbesondere Haskell und Scala) darauf ausgelegt sind die Messlatte für neue Abstraktionen immer höher zu legen - hier wird versucht mit möglichst wenig Code möglichst viel umzusetzen. Das ist das krasse Gegenteil zu einer Sprache wie C, die außer dem Präprozessor praktisch gar keine Möglichkeiten zur Abstraktion bietet.

    Ich denke, dass du geistig gar nicht darauf eingestellt bist funktionale Sprachen zu verstehen und praktisch für diese Sprachen auch keine Verwendung finden würdest (sofern du bisher wirklich nur mit C like Sprachen zu tun hattest). Guck dir lieber C++ an, das bringt dir mehr.



  • Warum sollte man Haskell, OCaml, Scala Co lernen?

    sollte man das überhaupt ?

    Wenn man sich entsprechend beschränkt, Seiteneffekte vermeidet (-> Interfaces), Zustände vermeidet (-> wann es geht, ohne allzu umständlich zu werden) etc kann man das auch in anderen Prog.Sprachen tun, nur warum sollte man sich selbst derartige Einschränkungen auferlegen, wenn es nicht gerade um statische Datenstrukturen, math. Rechnungen o.ä. geht ?



  • großbuchstaben schrieb:

    Seiteneffekte vermeidet (-> Interfaces)

    Wie sollen Interfaces denn Seiteneffekte vermeiden?



  • icarus2 schrieb:

    großbuchstaben schrieb:

    Seiteneffekte vermeidet (-> Interfaces)

    Wie sollen Interfaces denn Seiteneffekte vermeiden?

    definiere "Seiteneffekte vermeiden".



  • ich finde, ich habe mich klar ausgedrückt. Die Bedeutung des Ausdrucks "Seiteneffekte vermeiden" zu erklären, wäre mir dann auch eine Spur zu trivial, sry.



  • großbuchstaben schrieb:

    ich finde, ich habe mich klar ausgedrückt.

    Ich verstehe deinen Post auch nicht ganz.
    Inwiefern sollen Interfaces Seiteneffekte vermeiden?
    Inwiefern hat "Zustände vermeiden" etwas mit funktionalen Programmiersprachen zu tun?
    Seit wann sind Seiteneffekte und Zustände die Hauptsache, die funktionale Programmiersprachen ausmacht?
    Man bekommt fast das Gefühl, du behauptest funktional = wie Java, nur mit ein paar Einschränkungen.



  • Jetzt geht's hier aber um die Rechthaben-Diskussion. Man wird wohl nicht von der Hand weisen können, dass Seiteneffektfreie Programme und (strikt) funktionale Programme eng miteinander verwoben sind. Man wird auch nicht von der Hand weisen können, dass Seiteneffektrei mit Zustandsfrei viel zu tun hat.
    Die einzige Frage die ich mir hier stelle ist, inwiefern Interfaces Seiteneffekte oder Zustände vermeiden.



  • in einem System von n wechselwirkenden Komponenten können sich O(n^2) Paare von Komponenten gegenseitig beeinflussen. Durch Kapselung und Zugriff über Interfaces läßt sich das reduzieren, und Wechselwirkungsmöglichkeiten werden durch Definition von Interfaces explizit gemacht.



  • 5. Warum sollte man eine funktionale Programmiersprache lernen?

    Es wird oft gesagt, dass funktionale Programmiersprachen den Horizont erweitern. Ich habe etwa 2x ehrlich versucht den Sinn von FP zu verstehen. Ich bin aber nie bis zum Schluss der Weisheit durchgekommen, wohl auch weil ich nicht mit letzter Konsequenz durchgezogen habe. Um das zu tun muss man allerdings enorm viel Zeit investieren. Ich weiss nicht, ob sich das lohnt. Für FP gibt es wirklich so gut wie keine Job-Aussichten. Bei manchen seltenen Stellenausschreibungen werden Kenntnisse in Haskell/Schme/Scala als Plus aufgeführt.

    Meine bisherige Quintessenz aus FP ist die, dass sich verschiedene Dinge gut für konkurrente Programmierung verwenden lassen: Immutable Objects, non-destructive Programming, Rekursionen (weil so Zugriff auf gemeinsame Daten minimiert wird und damit die Fehleranfälligkeit wegen unvollständiger Synchronisierung).

    Es gibt einen guten Spruch von Andrej Breslav (Entwickler von Kotlin): FP makes many things simpler, sometimes at a high price. Ich denke, dass er da recht hat. An einem vernünftigen Punkt mit FP Schluss machen und mit imperativer Programmierung weitermachen.

    -- Oliver



  • Saxo schrieb:

    Es gibt einen guten Spruch von Andrej Breslav (Entwickler von Kotlin): FP makes many things simpler, sometimes at a high price.

    🤡



  • Saxo schrieb:

    Meine bisherige Quintessenz aus FP ist die, dass sich verschiedene Dinge gut für konkurrente Programmierung verwenden lassen: Immutable Objects, non-destructive Programming, Rekursionen (weil so Zugriff auf gemeinsame Daten minimiert wird und damit die Fehleranfälligkeit wegen unvollständiger Synchronisierung).

    interessant, daß du in diesem zusammenhang Rekursion erwähnst.

    Die Speicherung von Zuständen wird auf Logikgatter-Ebene nämlich durch Rekursion bzw Zyklizität modelliert. Ein abstraktes Schaltnetz in Form eines gerichteten *azyklischen* Graphen ist zeitinvariant und kann keinen inneren Zustand speichern.

    Ein Flipflop zur Speicherung von 1 bit ist ein Beispiel für ein zyklisches Schaltnetz mit innerem Zustand.

    sprich, Zustände erfordern auf Logikgatter-Ebene Rekursion, und Funktionale Programmierung will doch gerade Zustände vermeiden - eine gewisse Widersprüchlichkeit. Rekursion in der funktionalen Programmierung scheint mir je nach Aufgabenstellung hin und wieder eher notwendiges Übel als Vorzug zu sein; nämlich, um Zustände zu vermeiden.



  • Zustände erfordern auf Logikgatter-Ebene Rekursion, und Funktionale Programmierung

    Man kann vieles in einen Topf werfen, trotzdem kommt nur Gruetze bei raus. Hier beispielsweise mit Logikgatter und FP. Jeder Integer mit hat einen Wert, also auch einen Zustand. Warum sollte das vermieden werden?

    FP makes many things simpler, sometimes at a high price.

    Meinungen sind wie ... Was fuer ein Preis? Wo sind die Fakten?

    Ich weiss nicht, ob sich das lohnt. Für FP gibt es wirklich so gut wie keine Job-Aussichten.

    Nun, wenn deine Motivation Geld ist, dann unterscheidest du dich wohl kaum von einer Prostituierten.

    kann man das auch in anderen Prog.Sprachen tun

    Ja, man kann auch in anderen Sprachen funktional programmieren. Das ist der Hauptgrund, sich mit FP zu beschaeftigen: Die Erkenntnisse in anderen Sprachen nutzen.



  • knivil schrieb:

    Zustände erfordern auf Logikgatter-Ebene Rekursion, und Funktionale Programmierung

    Man kann vieles in einen Topf werfen, trotzdem kommt nur Gruetze bei raus. Hier beispielsweise mit Logikgatter und FP. Jeder Integer mit hat einen Wert, also auch einen Zustand. Warum sollte das vermieden werden?

    es geht hier um zeitvariable Zustände, also solche, die eine Speicherung erfordern. Ein Integer ist ebenso wie ein azyklisches Schaltnetz zeitlos.

    FP makes many things simpler, sometimes at a high price.

    Meinungen sind wie ... Was fuer ein Preis? Wo sind die Fakten?

    und wo sind die Fakten pro FP ?


Anmelden zum Antworten