Haskell



  • Du kannst schon vorher analysieren, was alles auf den Heap landet, ohne eine Schleife draus zu machen.



  • mit welchem switch wandelt g++ tail-recursions nochmal in loops? Bei meinen Tests war kurz vor Tiefe 262000 Schicht im Schacht.



  • knivil schrieb:

    Du kannst schon vorher analysieren, was alles auf den Heap landet, ohne eine Schleife draus zu machen.

    Was ändert das an meinem Punkt? Die Schleife brauchste am Ende sowieso, denn solange du die Rekursion hast, musst du dir die Stackframes merken. Und sobald du die stackframes rausoptimierst hast du eine Schleife.
    War dein Post also einzig und allein der Tatsache geschuldet, dass man die beiden Dinge vertauschen kann?



  • !rr!rr_. schrieb:

    mit welchem switch wandelt g++ tail-recursions nochmal in loops? Bei meinen Tests war kurz vor Tiefe 262000 Schicht im Schacht.

    geklärt, -O1 tut schon



  • Mal an die ganzen Zweifler: Haskell schlägt C++ haushoch in praktisch jeder Hinsicht außer OOP, und die braucht man in Haskell nicht, und zwar gar nicht. Praktisches Beispiel: Es folgt ein vollwertiger, hochskalierbarer, von Haus aus threading-fähiger, epoll benutzender Echo-Server in Haskell:

    module Main where
    
    import Control.Concurrent
    import Control.Exception (finally)
    import Control.Monad
    import Network
    import System.IO
    import Text.Printf
    
    main :: IO ()
    main = do
        -- Logger thread.
        logVar <- newEmptyMVar
        forkIO . forever $ takeMVar logVar >>= hPutStrLn stderr
    
        -- Echo server.
        socket <- listenOn (PortNumber 4000)
        forever $ do
            (handle, clientHost, clientPort) <- accept socket
            hSetBuffering handle NoBuffering
            putMVar logVar (printf "Connection from %s." clientHost)
    
            -- Client thread.
            forkIO $ do
                (hGetContents handle >>= hPutStr handle) `finally` hClose handle
                putMVar logVar (printf "Client %s disconnected." clientHost)
    

    Wie bereits erwähnt: Dieser Echo-Server ist thread-fähig, und zwar nicht in dem Sinne, dass jeder Client einen eigenen Thread bekommt, sondern dass beim Programmstart per Kommandozeilenparamter eine feste Anzahl Threads festgelegt werden kann. Innerhalb der Threads wird epoll benutzt. Und ja, der Client-Thread braucht konstanten Speicher, unabhängig davon, wieviel der Client sendet.

    Das Gleiche in C++, bitte. Und nein, ich habe keinerlei Netzwerkbibliotheken für Server oder sonstiges verwendet. Das sind alles ganz normale Socket/Handle-Funktionen.

    Fairnesshalber möchte ich dazusagen, dass ich ein langjähriger Haskell-Programmierer bin, der viele "real world"-Anwendungen entwickelt. Dazu zählt auch die Erstellung von Server-Software und dynamischen Webseiten in einer Geschwindigkeit, von der C++- (aber auch PHP-) Programmierer nur träumen können.



  • ertes schrieb:

    dynamischen Webseiten in einer Geschwindigkeit, von der C++- (aber auch PHP-) Programmierer nur träumen können.

    Mit PHP und C++ hast Du zwei Enden der Skala genannt. Ich glaube Dir, daß Du in der schnelleren Hälfte bist. Viel mehr aber auch nicht.



  • volkard schrieb:

    ertes schrieb:

    dynamischen Webseiten in einer Geschwindigkeit, von der C++- (aber auch PHP-) Programmierer nur träumen können.

    Mit PHP und C++ hast Du zwei Enden der Skala genannt. Ich glaube Dir, daß Du in der schnelleren Hälfte bist. Viel mehr aber auch nicht.

    hahahahaha 🤡



  • ertes schrieb:

    Mal an die ganzen Zweifler: Haskell schlägt C++ haushoch in praktisch jeder Hinsicht außer OOP, und die braucht man in Haskell nicht, und zwar gar nicht. Praktisches Beispiel: Es folgt ein vollwertiger, hochskalierbarer, von Haus aus threading-fähiger, epoll benutzender Echo-Server in Haskell:

    module Main where
    
    import Control.Concurrent
    import Control.Exception (finally)
    import Control.Monad
    import Network
    import System.IO
    import Text.Printf
    
    main :: IO ()
    main = do
        -- Logger thread.
        logVar <- newEmptyMVar
        forkIO . forever $ takeMVar logVar >>= hPutStrLn stderr
    
        -- Echo server.
        socket <- listenOn (PortNumber 4000)
        forever $ do
            (handle, clientHost, clientPort) <- accept socket
            hSetBuffering handle NoBuffering
            putMVar logVar (printf "Connection from %s." clientHost)
    
            -- Client thread.
            forkIO $ do
                (hGetContents handle >>= hPutStr handle) `finally` hClose handle
                putMVar logVar (printf "Client %s disconnected." clientHost)
    

    Sieht ja fast wie ein normales Programm aus. Wo ist jetzt das Haskel ist so komplett anders und man muss ganz neu lernen?



  • erstaunlich schrieb:

    Sieht ja fast wie ein normales Programm aus.

    Du bist wahrscheinlich eine Parodie auf den Threadstarter, falls nicht: Nein, bzw. nur für seltsame Vorstellungen von "fast".



  • schlägt C++ haushoch in praktisch jeder Hinsicht außer OOP

    Bullshit, Haskell hat besseres OOP! 🙂 Und Type classes will ich auf keinen Fall missen.

    Echo-Server

    Haha ... http://abstractabsurd.blogspot.com/2007/05/couple-of-silly-examples.html



  • volkard schrieb:

    ertes schrieb:

    dynamischen Webseiten in einer Geschwindigkeit, von der C++- (aber auch PHP-) Programmierer nur träumen können.

    Mit PHP und C++ hast Du zwei Enden der Skala genannt. Ich glaube Dir, daß Du in der schnelleren Hälfte bist. Viel mehr aber auch nicht.

    Wenn du eine Produktivitätsskala meinst, dann ist der erste Satz schon mal Quatsch. Ansonsten möchtest du vielleicht meine Anfrage mit einem entsprechenden Programm in C++ oder PHP beantworten. Und bitte mit Angabe, wie lange du gebraucht hast. Wenn du das nicht kannst oder länger brauchst als ich, ist C++ schon mal weiter unten als Haskell in der Produktivitätsskala; zumindest für das gegebene Beispiel.

    Nur, um dir einen Vergleich zu ermöglichen: Den o.g. Server habe ich in ca. fünf Minuten geschrieben, inkl. Kompilieren und Testen (ich bin kein besonders schneller Tipper, deshalb die lange Entwicklungszeit). Das ist der erste Punkt. Der Zweite ist, sobald ein Haskell-Programm kompiliert, funktioniert es in den allermeisten Fällen auch. Das spart eine Menge Debugging-Zeit — eine Ersparnis, die du in C++ nicht hast. Klar kann auch ein C++-Programm auf Anhieb funktionieren, aber würdest du denselben Server wie oben in einem Zug schreiben, ohne mittendrin nochmal zu testen? Nein.

    In Haskell debuggst du quasi schon, bevor der Compiler ein ausführbares Programm stricken kann. Somit musst du Fehler nicht erst zur Laufzeit suchen, sondern sie springen dir schon beim Kompilieren entgegen. Das ist einer der Vorteile von Haskells Typensystem. Auch C++ fängt einige Fehler in der Kompilierzeit ab, aber Haskell treibt das an die Spitze und lässt C++ in dem Bezug sehr weit hinter sich zurück. Das geht so weit, dass nach dem Kompilieren sämtliche Typeninformationen verloren sind, weil sie zur Laufzeit nicht mehr gebraucht werden. Es gibt keine RTTI wie in C++.

    Und noch ein Vergleich: Web-Applikationen in Haskell sind ebenso knapp und prägnant, ohne dafür auch nur einen Funken Performance, Sicherheit oder Skalierbarkeit aufzugeben.

    erstaunlich schrieb:

    Sieht ja fast wie ein normales Programm aus. Wo ist jetzt das Haskel ist so komplett anders und man muss ganz neu lernen?

    Es ist total anders. Die Unterschiede zu etwa C++ in dem Code sind allerdings sehr subtil. Beispiel: Anders als ein C++-gewohnter Programmierer im ersten Augenblick annehmen würde, hat forkIO wenig mit Betriebssystem-Threads zu tun (Suchbegriff: "lightweight concurrency"). Das forever ist auch keineswegs eine Entsprechung zu while(1) in C++, obwohl das in diesem Beispiel (also in der IO-Monade) im Großen und Ganzen hinkommt. Auch fordert der Code-Schnipsel hGetContents h >>= hPutStr h etwas Erklärung. Ich empfange vom Client alle Daten und sende sie ihm zurück. Das ist, was der Code wörtlich bedeutet. Derselbe Code in genau der wörtlichen Bedeutung würde in C++ tatsächlich erst alles vom Client einlesen und entsprechend RAM verbrauchen, und wenn der Client die Verbindung beendet hat, würde er die Daten wieder an den Client zurücksenden. Das ergibt in C++ keinen Sinn, aber aufgrund von lazy evaluation tut der Code in Haskell tatsächlich genau das Richtige: Er liest und schreibt zurück, bis keine Daten mehr kommen, mit Buffering und allem drum und dran. Haskell-Threads kommunizieren mit high level-Konstrukten wie etwa in meinem Beispiel MVars, eine sehr nützliche Abstraktion.

    Und noch etwas: Der Code verwendet keinerlei Kontrollstrukturen. All diese hübschen Wörtchen und Symbole wie "forkIO", "forever", ">>=" und sogar "finally" sind ganz gewöhnliche Haskell-Funktionen. Ja richtig, Exception-Handling erfordert in Haskell keine Sprachkonstrukte. Das ist der Vorteil von Monaden. Es gibt in Haskell relativ wenige Schlüsselwörter. In meinem Beispiel sind es gerade mal vier: "module", "where", "import" und "do". Daneben noch ein paar operatorähnliche Symbole, die auch der Sprache gehören: "::", "<-" und "=". Und nein, "=" ist in Haskell kein Operator. Das Gleichheitszeichen drückt tatsächlich das aus, was es ausdrücken sollte: eine Gleichung — etwas, das in C++ nicht möglich ist. Das macht Haskell nicht zu einem CAS, aber es erlaubt, Code flüssig zu lesen und leicht zu verstehen, auch völlig ohne Kommentare, und selbst bei kompliziertem Code (wenn man Haskell kann!). Man kann in gewissem sinne lokal lesen und muss sich nicht darum kümmern, ob etwa eine Variable irgendwoanders im Programm verändert wird.

    Die wirklich signifikanten Unterschiede merkt man, wenn man mehr macht als stumpfes Verbindungen entgegennehmen und ein Bisschen was lesen und schreiben, ohne die Daten dabei zu interpretieren. Es geht los, wenn man einen Parser schreibt oder bestimmte Kontrollstrukturen. Und so richtig los geht es dann, wenn man monad transformers, Iteratees und STM benutzt und anfängt, richtig mit dem Typensystem zu spielen. Ich könnte nun Code-Beispiele liefern, aber du würdest wahrscheinlich mit ihnen nichts anfangen können (außer vielleicht mit STM-Beispielen, wenn du bereits weißt, was STM ist).

    Übrigens: Würde ich es wirklich ernst meinen mit dem Echo-Server, hätte ich ihn noch eine Spur anders geschrieben. Obwohl in diesem Beispiel kein Problem, bin ich kein großer Fan von lazy I/O, weil das bei komplexeren Anwendungen mit Problemen verbunden ist. Ich hätte die o.g. Iteratees verwendet, ein Konzept, das in C++ unpraktikabel ist. Der Code wäre nicht länger, aber wäre für jemanden, der kein Haskell kann, völlig undurchdringlich. Daher habe ich mich für dieses Beispiel für lazy I/O entschieden.



  • ertes schrieb:

    Nur, um dir einen Vergleich zu ermöglichen: Den o.g. Server habe ich in ca. fünf Minuten geschrieben, inkl. Kompilieren und Testen (ich bin kein besonders schneller Tipper, deshalb die lange Entwicklungszeit). Das ist der erste Punkt.

    Das ist doch schon mal Quatsch. Du hast doch selber gesagt, das du sowas regelmäßig machst. Und wahrscheinlich hast du das Beispiel (in einer ähnlichen Fall) schon mehrmals geschrieben. Ja, das kannst du natürlich in 5 Minuten erreichen. Aber das schafft jemand auch in C++, wenn er solche Beispiele schon mehrmals geschrieben hat. Weißt du wie man sowas nennt? Erfahrung! Du kannst gerne die Zeichen im Code zählen, und dann als Maß nehmen. Aber etwas "erarbeiten" ist was ganz anderes. Und vergleichen kannst du sowas nur, mit zwei Personen, die die gleichen Skills in ihrer Sprache haben. Ich z.B. habe zwar Erfahrung mit C++, aber ich habe noch nie Netzwerk-Programmierung gemacht. D.h. ich kann definitiv sowas nicht in 5 Minuten machen. Aber das ist nicht die Schuld der Sprache. Es sind meine Skills.

    Jemand der täglich OpenGL/Direct3D-Programmierung macht, wird dich in Grund und Boden programmieren, wenn du in Haskell noch nie Grafik programmiert hast. Wette ich!

    Dieses "Ich mache das in 5 Minuten, du braucht 50 Minuten!" ist Quatsch. Das glaube ich erst, wenn der Code auch nachher 10 Mal länger ist, weil ich wirklich 10 mal mehr tippen mußte. Was du ja mit deinem kindischen "Ich bin kein schneller Tipper" ja implizierst.

    Beim Entwickeln zählen aber ganz andere Dinge. Und ich habe noch nie jemanden gesehene, der für die Entwicklung 100% Zeit für Coden (also Tippen) aufwendet. Wenn du sooo erfahren bist, muß ich dir nicht sagen, was man eigentlich in der Entwicklungszeit statt dessen macht.

    ertes schrieb:

    Der Zweite ist, sobald ein Haskell-Programm kompiliert, funktioniert es in den allermeisten Fällen auch. Das spart eine Menge Debugging-Zeit — eine Ersparnis, die du in C++ nicht hast. Klar kann auch ein C++-Programm auf Anhieb funktionieren, aber würdest du denselben Server wie oben in einem Zug schreiben, ohne mittendrin nochmal zu testen? Nein.

    Ach du heilige Sch***! Was für ein Gelaber. Schon alleine dein "in den allermeisten Fällen" hat deine Behauptung ad absurdum geführt. Das die Fehlererkennung in zwei unterschiedlichen Zeitpunkten auftreten kann (Compiletime vs. Runtime) ist klar. Aber dieses Absolute "beim Kompilieren" kommt mir suspekt vor. Findet der Haskell-Compiler Logikfehler? Kann ich mir nicht vorstellen. Weil das hieße ja, das 99,9% der Entwickler auf diesem Planeten irgendwas verpasst haben, was die Lösung aller Entwicklerprobleme zu sein scheint.

    Wenn du sagst, die Typsicherheit ist in Haskell sehr hoch, glaube ich das aufs Wort. Ist nämlich in OCaml auch so. Und in C++ ist es nicht so, sagt selbst Bjarne Stroustrup (wegen C-Altlasten). Aber was hat das damit zu tun, das jedes Haskell Programm nach dem Kompilieren ohne Fehler läuft?



  • Vorab: ich finde Haskell auch sehr schön und beschäftige mich hin und wieder damit, allerdings eher zum Vergnügen. Ich bin fasziniert von einem Typsystem, das es mir erlaubt, so lustige Dinge wie einen symbolischen Differentiator zu schreiben, der eine Haskell-Funktion in ihre Ableitung transformieren kann. Aber bis Haskell für Alltagsaufgaben tatsächlich produktiver ist als gewöhnlichere Hochsprachen, muß man schon ziemlich sattelfest sein.

    ertes schrieb:

    Wenn du das nicht kannst oder länger brauchst als ich, ist C++ schon mal weiter unten als Haskell in der Produktivitätsskala

    Pauschalaussagen, die auf zwei Meßpunkten basieren, sind doof.

    ertes schrieb:

    Nur, um dir einen Vergleich zu ermöglichen: Den o.g. Server habe ich in ca. fünf Minuten geschrieben, inkl. Kompilieren und Testen (ich bin kein besonders schneller Tipper, deshalb die lange Entwicklungszeit). Das ist der erste Punkt. Der Zweite ist, sobald ein Haskell-Programm kompiliert, funktioniert es in den allermeisten Fällen auch.

    Meine bisherigen Versuche mit Haskell haben selten auf Anhieb zum gewünschten Ergebnis geführt; was mich betrifft, sehe ich hier keinen systematischen Unterschied. Aber es kann natürlich auch daran liegen, daß ich kein "langjähriger Haskell-Programmierer" bin, oder daß du einfach ganz toll bist.

    Es kann schon sein, daß Haskell zur Übersetzungszeit mehr für die Integrität des Programmes tun kann als C++. Aber sobald du es mal geschafft hast, einen Fehler in dein Programm einzubauen, sieht es ganz anders aus. Das Debuggen von prozeduralem Code ist zum Großteil trivial; da man den Vorgang niederschreibt und nicht das Ergebnis, kann man die Ausführung Zeile für Zeile nachvollziehen, gerade mit einem modernen Debugger, wie er in den meisten Mainstream-Hochsprachenumgebungen üblich ist. Das Debuggen funktionaler Programme ist dementgegen durchaus nichttrivial.

    ertes schrieb:

    Es gibt in Haskell relativ wenige Schlüsselwörter.

    Ich verstehe nicht, wieso das ein Vorteil sein soll.

    ertes schrieb:

    Man kann in gewissem sinne lokal lesen und muss sich nicht darum kümmern, ob etwa eine Variable irgendwoanders im Programm verändert wird.

    Das ist in C++ nicht anders, wenn du dein Handwerk beherrschst.

    ertes schrieb:

    aber wäre für jemanden, der kein Haskell kann, völlig undurchdringlich.

    So was ist im Übrigen ein massives Argument gegen den produktiven Einsatz von Haskell.

    Aber ich denke, die weitere Diskussion erübrigt sich ohnehin, denn:

    ertes schrieb:

    Ich könnte nun Code-Beispiele liefern, aber du würdest wahrscheinlich mit ihnen nichts anfangen können

    🤡

    Edit: Typographie 😞



  • audacia schrieb:

    ertes schrieb:

    aber wäre für jemanden, der kein Haskell kann, völlig undurchdringlich.

    So was ist im Übrigen ein massives Argument gegen den produktiven Einsatz von Haskell.

    Warum?



  • Aber bis Haskell für Alltagsaufgaben tatsächlich produktiver ist als gewöhnlichere Hochsprachen, muß man schon ziemlich sattelfest sein.

    Ne, also das ist Quatsch. Um nichttriviale Programme zu schreiben musst du auch in einer "gewöhnlichen" Hochsprache sattelfest sein. Das "Problem" ist nunmal, das die meisten mit einer Sprache anfangen, die besonders gute OOP Unterstützung bringt. Das macht das Umdenken schwer, wodurch es dann zu der falschen Annahme kommt, dass funktionale Sprachen schwerer seien als andere.

    Das Debuggen funktionaler Programme ist dementgegen durchaus nichttrivial.

    Das stimmt nicht. Funktionen in Haskell lassen sich sehr einfach debuggen, da sie keine Seiteneffekte haben. Du kannst also sehr modular testen, indem du z.B. mit QuickCheck Eigenschaften der einzelnen Funktionen testen lässt. Wenn es dann zu IO kommt, sind viele Haskellprogramme auch prozudural aufgebaut (wie z.B. der Codeschnipsel von ertes) und du musst hier genauso debuggen wie in jeder anderen Programmiersprache auch.

    Ich verstehe nicht, wieso das ein Vorteil sein soll.

    Ein schlanker Sprachkern ist eigentlich immer von Vorteil, da man weniger lernen muss.

    So was ist im Übrigen ein massives Argument gegen den produktiven Einsatz von Haskell.

    Du meinst also Code muss auch für Außenstehenden, die die Sprache nicht können, verständlich sein? Des Weiteren ist Haskell Code eigentlich meist sehr verständlich, denn darauf legt man in Haskell meist sehr großen Wert.
    Im Gegensatz dazu ist das, was z.B. die boost-Leute machen, absoluter Horror - selbst für gestandene C++ler ist das nicht immer einfach zu verstehen.



  • Weil das hieße ja, das 99,9% der Entwickler auf diesem Planeten irgendwas verpasst haben, was die Lösung aller Entwicklerprobleme zu sein scheint.

    Beweis: Da 99% Java-Programmierer sind, liegst du damit voellig richtig. 🙂 qed.

    Des Weiteren ist Haskell Code eigentlich meist sehr verständlich, denn darauf legt man in Haskell meist sehr großen Wert.

    Gegenbeweis: Haskell ist programmierte Mathematik. Fuer die wenigsten ist Mathematik verstaendlich. Fuer die wenigsten ist Programmieren verstaendlich. Die Schnittmenge beider Mengen ist nochmals um vieles kleiner. qed

    Ein schlanker Sprachkern ist eigentlich immer von Vorteil, da man weniger lernen muss.

    Falsch: Die noetige Abstraktion liegt dann nicht in der Sprache sondern in den Design-Pattern. qed.



  • Bashar schrieb:

    audacia schrieb:

    ertes schrieb:

    aber wäre für jemanden, der kein Haskell kann, völlig undurchdringlich.

    So was ist im Übrigen ein massives Argument gegen den produktiven Einsatz von Haskell.

    Warum?

    Weil es nicht von besonderem Vorteil ist, wenn kaum einer der durchaus fähigen C++- oder Java-Programmierer, die den Personalmarkt größtenteils ausmachen, in der Lage ist, mit solchem Code zu arbeiten. Bei einem hochqualifizierten Forschungsteam an einer Universität oder in einem gut ausgestatteten Unternehmen ist das natürlich etwas anderes - aber wenn es um eher handelsübliche Dinge wie Webapplikationen geht, würde ich mir das gut überlegen.

    Irgendwer schrieb:

    Aber bis Haskell für Alltagsaufgaben tatsächlich produktiver ist als gewöhnlichere Hochsprachen, muß man schon ziemlich sattelfest sein.

    Ne, also das ist Quatsch. Um nichttriviale Programme zu schreiben musst du auch in einer "gewöhnlichen" Hochsprache sattelfest sein.

    Das stimmt schon. Ich gehe in diesem Punkt auch von mir aus; vielleicht liegen deine Erfahrungen ja ganz anders. Aber:

    Irgendwer schrieb:

    Das "Problem" ist nunmal, das die meisten mit einer Sprache anfangen, die besonders gute OOP Unterstützung bringt. Das macht das Umdenken schwer, wodurch es dann zu der falschen Annahme kommt, dass funktionale Sprachen schwerer seien als andere.

    Diese Behauptung halte ich gar nicht für abwegig. Ohne grundlegende algebraische Kenntnisse sind viele Konstrukte in Haskell IMO äußerst schwierig zu verstehen.

    Irgendwer schrieb:

    Das stimmt nicht. Funktionen in Haskell lassen sich sehr einfach debuggen, da sie keine Seiteneffekte haben.

    Klar. Aber das Debuggen und Testen einzelner isolierter Funktionen ist ja nicht alles. Du hast ein komplexes Programm entworfen (möglicherweise auf Anraten unseres begabten Freundes in einem Zug heruntergetippt und zwischendurch nicht getestet), und nun verhält es sich in irgendeinem Detail völlig anders, als du erwartest.

    Irgendwer schrieb:

    Wenn es dann zu IO kommt, sind viele Haskellprogramme auch prozudural aufgebaut (wie z.B. der Codeschnipsel von ertes) und du musst hier genauso debuggen wie in jeder anderen Programmiersprache auch.

    Eben - und spätestens hier macht sich der fehlende Tool-Support bemerkbar. Sicherlich hast du schon mal einen ausgewachsenen Debugger benutzt, also mit Evaluations-Tooltips, Live-Stacktraces, einem flexiblen Evaluator, Watches, etc. - evtl. sogar Edit&Continue. Das macht schon etwas aus.

    Irgendwer schrieb:

    Ein schlanker Sprachkern ist eigentlich immer von Vorteil, da man weniger lernen muss.

    Wie knivil ganz richtig anmerkt, lernst du dann eben nicht den Sprachkern, sondern das Drumherum. Für den Lernaufwand ist der Schlüsselwortumfang meines Erachtens völlig unerheblich.

    Irgendwer schrieb:

    Des Weiteren ist Haskell Code eigentlich meist sehr verständlich, denn darauf legt man in Haskell meist sehr großen Wert.

    Manche legen offenbar großen Wert darauf, daß man den Code nicht versteht 😉

    Irgendwer schrieb:

    Im Gegensatz dazu ist das, was z.B. die boost-Leute machen, absoluter Horror - selbst für gestandene C++ler ist das nicht immer einfach zu verstehen.

    Das ist leider richtig.



  • audacia schrieb:

    Weil es nicht von besonderem Vorteil ist, wenn kaum einer der durchaus fähigen C++- oder Java-Programmierer, die den Personalmarkt größtenteils ausmachen, in der Lage ist, mit solchem Code zu arbeiten. Bei einem hochqualifizierten Forschungsteam an einer Universität oder in einem gut ausgestatteten Unternehmen ist das natürlich etwas anderes - aber wenn es um eher handelsübliche Dinge wie Webapplikationen geht, würde ich mir das gut überlegen.

    Man kann es durchaus als Vorteil betrachten, wenn sich die übliche "Ich kann nur C++/Java/C#" Gruppe gar nicht erst bewirbt. Bei einem Haskell-Programmierer kannst du fast immer davon ausgehen, das er einigermaßen was drauf hat, schon allein weil er sich sonst nie mit so einer "exotischen" Sprachen beschäftigen würde.
    Gibt auch ein schönes Screencast von einer Firma die mit OCaml arbeitet und genau das als Vorteil anführt. Es ist zwar schwieriger Leute zu finden, die das können (oder lernen wollen), aber die haben dafür wenigstens was drauf. Bei den Mainstream-Programmieren scheitert ja angeblich einen Großteil der Bewerber am "FizzBuzz-Test" 😃



  • audacia schrieb:

    Bashar schrieb:

    audacia schrieb:

    ertes schrieb:

    aber wäre für jemanden, der kein Haskell kann, völlig undurchdringlich.

    So was ist im Übrigen ein massives Argument gegen den produktiven Einsatz von Haskell.

    Warum?

    Weil es nicht von besonderem Vorteil ist, wenn kaum einer der durchaus fähigen C++- oder Java-Programmierer, die den Personalmarkt größtenteils ausmachen, in der Lage ist, mit solchem Code zu arbeiten. Bei einem hochqualifizierten Forschungsteam an einer Universität oder in einem gut ausgestatteten Unternehmen ist das natürlich etwas anderes - aber wenn es um eher handelsübliche Dinge wie Webapplikationen geht, würde ich mir das gut überlegen.

    Und diese Programmierer wären dann in er Lage, mit weniger "undurchdringlichem" Haskell-Code zu arbeiten? Man sollte schon keine Java-Programmierer in C++-Projekte lassen und umgekehrt, warum sollte das ausgerechnet bei Haskell bedenkenlos möglich sein?



  • Gegenbeweis:

    Thema verfehlt.
    Ich habe geschrieben, dass Haskell Code (zumindest der, den ich bisher gesehen habe) eigentlich vergleichsweise verständlich ist. Das gilt natürlich nur, wenn man zumindest die Grundlagen der Sprache versteht.

    Haskell ist programmierte Mathematik. Fuer die wenigsten ist Mathematik verstaendlich. Fuer die wenigsten ist Programmieren verstaendlich. Die Schnittmenge beider Mengen ist nochmals um vieles kleiner. qed

    Von welchen "die wenigsten" sprichst du denn? Wenn du von der Allgemeinheit sprichst, dann hast du recht, aber über die spricht hier doch niemand.
    Wir sprechen über Programmierer und man kann davon ausgehen, dass diese über (überdurchschnittlich) gutes logisches und mathematisches Verständnis verfügen.

    Falsch: Die noetige Abstraktion liegt dann nicht in der Sprache sondern in den Design-Pattern. qed.

    Ich stimme audacia zu, dass man dann eben das "Drumherum" lernen muss. Trotzdem halte ich es für "schön" (ja, das ist subjektiv), dass man Dinge wie Exception-Handling, Schleifen, etc. nicht fest in die Sprache einbauen muss, sondern über Bibliotheken implementieren kann.

    vielleicht liegen deine Erfahrungen ja ganz anders.

    Die liegen inzwischen tatsächlich anders. Natürlich war anfangs die Sprache ein Problem, aber inzwischen bewege ich mich relativ viel in dieser Sprache und merke, dass die Probleme, auf die ich stoße, sprachunabhängig sind. Die gleichen Probleme hätte ich auch in C++ gehabt, da sie meist daher kommen, dass das Problem noch nicht voll und ganz verstanden und der Lösungsweg noch nicht absolut klar ist.

    Ohne grundlegende algebraische Kenntnisse sind viele Konstrukte in Haskell IMO äußerst schwierig zu verstehen.

    Welche denn? Monaden etwa? Wie bereits oben geschrieben, kann man von einem Programmierer allerdings auch grundlegende algebraische Kenntnisse erwarten.

    Eben - und spätestens hier macht sich der fehlende Tool-Support bemerkbar. Sicherlich hast du schon mal einen ausgewachsenen Debugger benutzt, also mit Evaluations-Tooltips, Live-Stacktraces, einem flexiblen Evaluator, Watches, etc. - evtl. sogar Edit&Continue. Das macht schon etwas aus.

    Ja, das ist leider wahr. An einen Debugger à la Visual Studio 2010 kommt bei Haskell bisher nichts heran.


Anmelden zum Antworten