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



  • Hallo!

    ich bin hier eher zufällig auf dieses Unterforum gestoßen, die letzten Male hab ich das hier wohl überlesen.

    Meine Fragen sind:
    1. Wie aktuell sind die oben genannten Programmiersprachen in Zeiten von eher einfachen imperativen Programmiersprachen (z. B. C)?
    2. Wie "schwer" sind die Sprachen im Vergleich zu C?
    3. Welche (aktuelle und bekanntere) Software wurde in den Sprachen geschrieben?
    4. Welche "Funktionale Programmiersprache" würdet ihr einem C-Programmierer für den Anfang empfehlen?
    5. Warum sollte man eine funktionale Programmiersprache lernen?

    Ich bedanke mich schonmal im Vorraus für Antworten.
    LG



  • 1.) Sehr aktuell aber nicht weit verbreitet.
    2.) Schwerer, da sie auf einer breiten Basis Mathematik aufbauen.
    3.) http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/A-Means-to-Many-Ends-10-Years-of-Haskell-at-Galois
    4.) Scheme, ML
    5.) Es ist eine andere Art zu denken.



  • Ist Scheme eigentlich eine Programmiersprache oder eine Skriptsprache?



  • scheme ist eine Programmiersprache.
    der Begriff der Skriptsprache wird sehr schwammig verwendet:
    skriptsprache: Erweiterungssprache für ein Programm
    -ja dafür kannst du scheme benutzen
    skriptsprache: eine dynamisch typisierte sprache (meist auch imperativ) (zB Python, Perl)
    -ich würde sagen hier passt scheme mehr oder weniger hinein es hat eine sehr andere Syntax die ohne passenden editor sehr unübersichtlich werden kann
    skriptsprache: Sprache für kleine schnell geschriebene Programme die automatische Konfiguration und Verwaltung von zB Servern erledigen (zB bash, perl)
    -ja geht auch



  • ok, als mit "Skriptsprache" bezog ich mich eher auf "Eingebettete Erweiterungssprache" für Programme.

    Sowas wie z.B. Lua. Könnte man Scheme auch als eine eingebettete Skriptsprache für Computerspiele verwenden? Ich hab mal irgendwo irgendwann gelesen, dass man für KI-Programmierung in Computerspielen manchmal Scala einsetzt.

    Trotzdem würde mich mal was anderes als das übliche C/C++ interessieren.

    Wie siehts da aus?



  • Scheme kann als Skriptsprache verwendet werden. Kommt halt auf verwendetes System/Interpreter an.



  • 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 😃



  • 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.


Log in to reply