Haskell

[otze]

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_.]

!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

[ertes]

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.

[volkard]

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.

[gasterkenner]

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

[erstaunlich]

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?

[Bashar]

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

[knivil]

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

[ertes]

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.

[Artchi]

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?

[audacia]

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

[Bashar]

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?

[Irgendwer]

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.

[knivil]

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.

[audacia]

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.

[maximAL]

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"

[Bashar]

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?

[Irgendwer]

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.

[ertes]

Artchi schrieb:

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.

Einen Echo-Server bekommst auch du hin. Die Zeit zum Lernen von Konzepten rechne ich natürlich nicht dazu, sondern die reine Entwicklungszeit, sobald du sie verstehst. Nehmen wir an, ich hätte noch nie einen Echo-Server geschrieben, aber ich wüsste, was ein Echo-Server ist und verstünde die Grundlagen des Laufzeitsystems von Haskell (was eine Voraussetzung ist, um konkurrente Programme zu schreiben). Dann hätte ich 10 Minuten gebraucht. Mit anderen Worten: Mein Vergleich gilt C++-Programmierern, die die nötige Erfahrung dazu haben.

Außerdem: Ein Echo-Server ist nunmal etwas Triviales im Server-Bereich. Er ist der kleinste gemeinsame Nenner von Multi-Client-Server-Programmen; daher das Beispiel. Warum? Er muss mit mehreren Clients gleichzeitig klarkommen, er muss empfangen, er muss senden und dann die Verbindung sauber beenden; nicht mehr, nicht weniger.

Und jetzt zu meinem eigentlichen Punkt, den du offenbar nicht verstanden hast: Nur mit den Socket- und Handle-Funktionen (Entsprechung in C: int (für reine Sockets) und FILE (für verwaltete Sockets)) allein erreiche ich eine hohe Produktivität, die du in C++ aufgrund der Maschinennähe nicht haben kannst. Du brauchst dafür schon mal eine high level-Bibliothek, und selbst, wenn du die hast, ist der Haskell-Code wahrscheinlich trotzdem sowohl leichter zu lesen als auch schneller.

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!

Mich mit Sicherheit. Da besteht kein Zweifel.

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.

Genau. Und addiere noch die Debugging-Zeit dazu.

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.

Klar. In reellen Aufgaben handelt es sich auch nicht um einen Echo-Server. Das Plus, das Haskell mir gibt, ist prägnanter, eleganter, wartbarer Code. Vielleicht sollte ich dazusagen: Ich bin nach Jahren von C++ auf Haskell umgestiegen. Meine Flames sind also keineswegs willkürlich. Und jetzt mach es dir nicht einfach, indem du mir irgendwas unterstellst. Es ist einfach ein Fakt, dass Haskell mich produktiver gemacht hat. Die Lernkurve war zwar wirklich steil (wohl einer der Nachteile von Haskell), aber das Lernen zahlt sich heute aus.

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?

War das meine Aussage? Nein. Dennoch ist es so, dass Haskell schon per Konzept wesentlich weniger Fehler durchlässt als etwa OCaml. Das ist die Kombination aus referentieller Transparenz (was OCaml eben fehlt) und dem kräftigen Typensystem, das noch eine große Spur anspruchsvoller ist als das von OCaml. In Haskell ist es üblich, seine Intention in den Typen auszudrücken, und man erkennt oftmals an der Struktur der Typen, was eine Funktion macht.

Anders: Wenn du einen Funktionstypen vorgesetzt bekommst, dann kommt nur noch eine kleine Teilmenge aller Funktionen als Definition infrage. Die anderen verweigert der Compiler schon mal, weil die Typen keinen Sinn ergeben. Von dieser Teilmenge tut natürlich genau eine genau das, was du willst. Die anderen sind dann oftmals so absurd, dass du vorsätzlich Müll schreiben musst, damit was Falsches rauskommt. Und dann geht es weiter. Dann hat ja nicht nur diese eine Funktionen einen bestimmten Typen, sondern auch jeder andere Wert. Je mehr du kombinierst, desto geringer ist die Fehlerwahrscheinlichkeit, was in den gängigeren Hochsprachen ja genau andersrum ist. Es ist also tatsächlich wahrscheinlicher, in einem kleinen Programm etwas falsch zu machen als in einem großen.

Und was deinen Punkt betrifft, dass 99.9% aller Entwickler etwas verpasst haben: Wie lange gibt es die Konzepte, die in heutigen Hochsprachen erst allmählich Einzug finden? Oftmals schon länger als es elektronische Computer gibt. Ja, 99.9% aller Entwickler verpassen tatsächlich etwas, und das zu einem großen Teil sogar aus Überzeugung. Programmiersprachen sind eben auch Religionen, wie dieser Flamewar hier beweist (und nein, ich schließe mich da nicht aus).

Und damit gilt meine Anfrage immer noch: Ein netzwerkerfahrener C++-Programmierer möge meinen Code in C++ nachstellen. Es handelt sich um eine reelle, naheliegende Anwendung, denn es wird ja oft behauptet, dass C++ gut für Server-Programmierung ist. Ich nehme sogar ein Handicap in Kauf und erlaube dem C++-Programmierer, fertige Bibliotheken für Threading und Sockets zu benutzen. Wenn schon ein skalierbarer Echo-Server so umständlich zu programmieren ist, was passiert dann, wenn der Server noch mehr machen muss?

audacia schrieb:

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.

Wie ich sehe, hast du meine Aussage verstanden.

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.

Dass ich langjähriger Haskell-Programmierer bin, ist so zu verstehen, dass ich dadurch einen Vorteil habe, weil ich zu denen gehöre, die wissen, wie man Haskell ausreizt. Das macht mich nicht "toll", aber vor meinem Post haben nur Leute gepostet, die wenig Erfahrung mit Haskell zu haben schienen. Deswegen ist auch die Frage vom OP hier total fehl am Platz. Dass die ganzen überzeugten C++-ler ihren Liebling verteidigen, obwohl sie Haskell nicht mal verstehen, ist ja wohl klar.

ertes schrieb:

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

Ich verstehe nicht, wieso das ein Vorteil sein soll.

Zwei Vorteile: 1. Es macht die Sprache simpel und damit leicht zu durchschauen. Es gibt weniger Sonderfälle und damit mehr sprachliche Integrität. 2. Aufgrund der Struktur der Sprache sind viele Dinge, die in anderen Sprachen Sprachelemente sind, in Haskell ganz normale Funktionen. Du kannst vollwertiges Exception-Handling in reinem Haskell schreiben, ohne "hacken" zu müssen, und das ist noch ein relativ harmloses Beispiel. Parser sind ein gutes Beispiel. Du kannst sogar das gute alte Goto selber programmieren, ebenfalls ohne jegliche Sprachhacks.

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.

Du und der andere. In C++ kannst du nur glauben. In Haskell weißt du.

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.

Blödsinn. Mit der gleichen Argumentation müsste man auch von C++ abraten.

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

Du bist eben kein Haskell-Programmierer. Würde ich C++ nicht kennen und wäre stattdessen immer mit funktionalen Konzepten aufgewachsen, würde ich auch mit den effektvollen C++-Beispielen nichts anfangen können. Ich mute niemandem zu, Haskell zu lernen, nur um meine Argumente zu verstehen.

knivil schrieb:

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

Auch wieder ein Beweis dafür, dass du Haskell nicht verstanden hast. Du hast wahrscheinlich nur irgendwelche Blog- oder Wikipedia-Einträge gelesen, und wenn es hochkommt, einen Haskell-Compiler/Interpreter installiert und ein Bisschen herumexperimentiert. Und weil Haskell so anders ist als dein geliebtes C++, hast du dich wieder aus dem Staub gemacht.

Im Gegensatz zu C++ hat Haskell tatsächlich eine handfeste theoretische Grundlage, die auch tatsächlich aus der Mathematik kommt. Allerdings: Man muss diese Grundlage nicht verstehen, um Haskell lernen oder benutzen zu können. Und außerdem kannst du gar nicht beurteilen, wieviele das mathematische Teilgebiet verstehen, auf dem Haskell aufbaut, denn es gibt nur sehr wenige, die überhaupt jemals mit der Kategorientheorie in Kontakt kommen. Ich für meinen Teil habe keinen Plan von Kategorientheorie, obwohl ich es schon oft versucht habe. Ich habe einen sehr guten Tag, wenn ich die Definition einer Kategorie noch richtig zusammenkriege.

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.

Bis auf das "Falsch" ist an deiner Aussage hier nichts auszusetzen. Haskell arbeitet auf zwei Ebenen: Typen und Werte. Was Typen anbelangt, hat die Sprache das Sagen. Und solange die Typen passen, kannst du mit Werten machen, was du willst. Und wie du an meinem Beispiel gesehen hast, führt dieser Grundgedanke keineswegs zu schwerer lesbarem Code.

[RedPuma]

Also wir haben Haskell an der Uni in der ersten Hälfte von Softwareentwicklung 1 gemacht. Ich fands am Anfang etwas sperrig und komisch, hab aber spätestens seit ich mal Quicksort geschrieben hab umgedacht:

quicksort [] = [];
quicksort (x:xs) = quicksort (filter (<=x) xs) ++ [x] ++ quicksort (filter (>x) xs);

Mag nicht am effizientesten sein, aber sehr intuitiv und "schön".

/Edit: Als jemand der beides kennt muss ich jetzt auch mal meinen Senf dazugeben. Beide Sprachen haben ihre Einsatzgebiete und beide Sprachen haben Vor- und Nachteile. Und ein Flamewar wie er einst zwischen OpenGL und DirectX Jüngern stattfand hilft keinem. Punkt.