Haskell

[volkard]

freakC++ schrieb:

Wir hatten heute eine rekursive Funktion ohne Abbruchbedingung und ich hatte plötzlich "Stack overflow" im Kopf. Mich hat es schon sehr gewundert, dass das Haskell wenig krazt. Das Programm terminiert zwar nicht, aber es stürzt auch nicht ab! Das kann C++ nicht.

Das ist einfach falsch.
Ich habe im Kopf, daß C++-Compiler das seit Jahren können.
Ich teste das doch mal.

#include <iostream>

void test(){
   std::cout<<"hallo\n";
   test();
}

int main(){
   test();
}

Und der Compiler macht daraus

.L5:
	movl	$6, %edx
	movl	$.LC0, %esi
	movl	$_ZSt4cout, %edi
	call	_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
	jmp	.L5   # <-- hier, unbedingte Schleife

Oder mal etwas, was nicht ganz so trivial ist:

#include <iostream>

int gcd(int a,int b){
   if(b!=0)
      return gcd(b,a%b);
   else
      return a;
}

int main(){
   std::cout<<gcd(1024,768)<<'\n';
}

wird zu

_Z3gcdii:
.LFB1003:
	.cfi_startproc
	testl	%esi, %esi
	movl	%edi, %eax
	jne	.L5
	jmp	.L8
	.p2align 4,,7
	.p2align 3
.L4:
	movl	%esi, %eax
	movl	%edx, %esi
.L5:
	cltd
	idivl	%esi
	testl	%edx, %edx
	jne	.L4        # <-- Bedinter Sprung nach .L4, eine Schleife!
	movl	%esi, %eax
	ret
.L8:
	rep
	ret
	.cfi_endproc

[knivil]

Stak schrieb:

Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

Das nicht, es kann aber das Programm verwandeln. Stichwort: Endrekursion. Das kann gcc im uebrigen auch und ich habe es auch hier im Forum oft genug mit Beispielen belegt.

klar, tail recursion kannste primitiv in ne Schleife umfrickeln.

Das hat nichts mit frickeln zu tun und man benoetigt auch keine Schleifen. Es ist ein bestens verstandenes Konzept in Theorie und Praxis. Waehrend volkards Beispiel eine tatsaechliche endrekursive Funktion ist, kann der Kompiler auch in bestimmten Faellen aus einer rekursiven in eine endrekursive verwandeln. Das Beispiel der Fakultaetsfunktion findest hier auch im Forum irgendwo.

[maximAL]

Stak schrieb:

Wieso fast? Wenn tatsächlich rekursiv immer wieder ein Call auftauchen würde, dann gäbe es zu 100% einen Überlauf. Funktionale Programmierung ist schön und gut, aber es verwandelt den Rechner nicht magisch in eine unendlich große Maschine.

Stichwort: Tail-Rekursion.

edit: nächste Seite übersehen

[knivil]

Ach uebrigens: Ich mag den Bergiff Tail-Rekursion nicht!

[ssdd]

Wenn man Haskel mal für was anderes als Rechnen nimmt, ist es garnicht mehr toll.

[otze]

knivil schrieb:

klar, tail recursion kannste primitiv in ne Schleife umfrickeln.

Das hat nichts mit frickeln zu tun und man benoetigt auch keine Schleifen. Es ist ein bestens verstandenes Konzept in Theorie und Praxis.

Sogar Volkard schreibt in seinem Kommentar, dass der Compiler daraus ne unbedingte Schleife macht. Keine Ahnung was du mal wieder hast

[Zeus]

[knivil]

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

[!rr!rr_.]

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

[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