Funktionales C++



  • Vermutung: Sie wollten eigentlich Scheme oder sowas lehren (tolle Sprache, SICP sollte man IMHO einmal in seinem Leben gelesen haben), aber irgendwer weiter oben oder extern ("die Industrie") will lieber Leute, die Mainstream-Programmiersprachen können. Also macht man einen faulen Kompromiss. Natürlich kann man in C++ ohne weiteres pseudo-funktional programmieren, für in funktionalen Sprachen selbstverständliche Dinge wie Closures muss man aber schon ziemliche Geschütze auffahren, und irgendwann ist dann auch einfach mal Ende der Fahnenstange.

    (Der einzige Schwachpunkt dieser Theorie ist, dass in solchen Fällen normalerweise Java genommen wird.)



  • Bashar schrieb:

    (Der einzige Schwachpunkt dieser Theorie ist, dass in solchen Fällen normalerweise Java genommen wird.)

    Groovy? Scala?



  • Haskell 🙂



  • Die Haskell Syntax ist aber doof! 😉



  • Erlang!



  • unskilled schrieb:

    Die Haskell Syntax ist aber doof! 😉

    Nicht doof. Eher zu komplex. Die Sprache hat mindestens so viel Syntax wie C++. Eher noch mehr :(. Und Ganz unkomplex sind die einzelnen Features auch nicht.



  • Die Haskell-Syntax ist halt gewöhnungsbedürftig, besonders wenn man von C-ähnlichen Sprachen kommt. Ich finde sie inzwischen recht intuitiv, besonders Listen oder Fallunterscheidungen. Vor allem kann man mit ihr sehr kompakte und dennoch verständliche Ausdrücke formulieren. Nur ein paar einfache Beispiele:

    [b]-- Fakultät[/b]
    fac :: Int -> Int
    fac n = product [1..n]
    
    [b]-- Nimm alle geraden Elemente aus Liste[/b]
    filter even [1,2,3,5,6,8]
    
    [b]-- Prüfe, ob Zahl prim ist[/b]
    isPrime :: Int -> Bool
    isPrime n | n < 2     = False
              | otherwise = and [mod n m == 0 | m <- [1..n]]
    

    Ich habe mich allerdings noch nicht allzu stark mit weiterführenden Techniken beschäftigt (etwas mehr als obere Beispiele kann ich allerdings schon ;)), von daher kann ich die Komplexität der Syntax in fortgeschrittenen Haskell-Programmen schlecht einschätzen.



  • Nexus schrieb:

    von daher kann ich die Komplexität der Syntax in fortgeschrittenen Haskell-Programmen schlecht einschätzen.

    Es gibt ganz viel Syntax für Spezialfälle. Unter anderem mehrere Syntaktische Möglichkeiten, Funktionen und Argumente zu binden, etc. Ich kenn Haskell nicht perfekt, aber neben so Sachen wie funktion1.funktion2 meine ich auch sowas wie Funktion1<.>Funktion2 gesehen zu haben. Leider hatte ich nie die Chance, mich näher damit zu beschäftigen, weil Prolog dazwischen kam.



  • Hier kann man sehr viele Sprachen vergleichen:

    http://99-bottles-of-beer.net/

    EDIT:
    Ich weiss direkt nichts mit dem Thema zu tun, aber man kann auch sehr schön sehen, welche Sprachen für gewisse Probleme überhaupt nicht gedacht sind, respektive zu komplex dafür sind. Und im übrigen nette Seite zum stöberen. :p



  • Nexus schrieb:

    Die Haskell-Syntax ist halt gewöhnungsbedürftig, besonders wenn man von C-ähnlichen Sprachen kommt

    Jopp - nichts anderes wollte ich sagen^^
    Ich muss für die Uni jz bissl Haskell lernen und hab bisher ehrlich gesagt noch nicht so die Ahnung davon - aber die operatoren find ich teils unlogisch und noch viel schlimmer ist halt, dass man so viel mit der sprache machen kann und es deshalb auch so viel gibt, was man nicht weiß ;o)

    bb



  • otze schrieb:

    Es gibt ganz viel Syntax für Spezialfälle. Unter anderem mehrere Syntaktische Möglichkeiten, Funktionen und Argumente zu binden, etc. Ich kenn Haskell nicht perfekt, aber neben so Sachen wie funktion1.funktion2 meine ich auch sowas wie Funktion1<.>Funktion2 gesehen zu haben.

    Das ist doch keine Syntax, das sind einfach zwei Infix-Operatoren, also im Grunde nur Funktionen. Man kann ja in Haskell beliebige eigene Infix-Operatoren definieren, dadurch wird sowas wie <.> zu einem einfachen Identifier degradiert.



  • otze schrieb:

    Es gibt ganz viel Syntax für Spezialfälle. Unter anderem mehrere Syntaktische Möglichkeiten, Funktionen und Argumente zu binden, etc. Ich kenn Haskell nicht perfekt, aber neben so Sachen wie funktion1.funktion2 meine ich auch sowas wie Funktion1<.>Funktion2 gesehen zu haben. Leider hatte ich nie die Chance, mich näher damit zu beschäftigen, weil Prolog dazwischen kam.

    Tja, wenn du nicht weist, was ein Operator macht, dann kannst du doch leicht mittels :t (oder :type im Interpreter) die Signatur herausfinden. Auch kannst du in der Prelude.hs dir die Implementation ansehen. Du kannst dir auch neue Operatoren neben den unzaehligen vorhandenen ( !!, !, ., ...) definieren. <.> kenne ich auch nicht, aber er kann auch ein selbst definierter sein. Er ist auch nicht in Prelude.hs definiert.

    teils unlogisch und noch viel schlimmer ist halt, dass man so viel mit der sprache machen kann und es deshalb auch so viel gibt, was man nicht weiß ;o)

    Gerade unlogisch ist diese Sprache nun wirklich nicht. Die Leute haben sich dabei wirklich was gedacht. Nicht im Sinne von "Design by Accident". Wer sich mit den Hintergruenden beschaeftigen will, sollte sich aber auf einen Brocken Mathematik gefasst machen. Auch ist die Auswahl an Funktionen der Standardbibliothek als auch an Modulen ziemlich gross. Dort den Ueberblick zu gewinnen, braucht Zeit.

    Und man lernt nie aus. Gerade eine weitere Moeglichkeit gefunden die Fibonaccifolge zu definieren: fibs = 0 : scanl (+) 1 fibs. Ich loese ab und an einige Sachen auf http://projecteuler.net/, schaue mir auch die anderen Haskell-Implementationen an und mache Zeitmessungen.


Anmelden zum Antworten