Haskell

@knivil
Soll ich dir nochmal den Diskussionsverlauf schildern (Achtung, rhetorische Frage, ich mache es sowieso)?

audacia: "Ohne grundlegende algebraische Kenntnisse sind viele Konstrukte in Haskell IMO äußerst schwierig zu verstehen. "
Ich: "Welche denn? Monaden etwa? Wie bereits oben geschrieben, kann man von einem Programmierer allerdings auch grundlegende algebraische Kenntnisse erwarten.*"
Du: "Kategorientheorie wird an den seltensten Universitaeten im Fach Informatik gelehrt. Nein, dieses Wissen kann nicht vorausgesetzt werden."

Du gehst also davon aus, dass man Monaden nur verstehen kann, wenn man Kategorientheorie versteht. Mag sein, dass sie daher kommen, aber eigentlich hätte man sie auch selbst "erfinden" können (siehe den von mir vorher verlinkten Artikel). Ich behaupte nicht, dass sie super einfach zu verstehen sind und ich finde es auch unglücklich, dass man gerade "return" gewählt hat um einen Wert in eine Monade zu heben, da das eher verwirrt, aber wenn man sich etwas mit ihnen beschäftigt und nicht immer die do-Notation verwendet, sind sie eigentlich ganz "harmlos".

* hiermit ist nicht die Kategorientheorie gemeint. Diese fällt wohl kaum unter "grundlegende algebraische Kenntnisse".

Bringt einen das denktechnisch weiter, Haskell zu lernen? Ist das ne gute Übung?

Also, ich finde schon. Man löst Probleme einfach in den meisten Fällen ganz anders als in hauptsächlich imperativen Sprachen, häufig auch deutlich eleganter (wobei das natürlich im Auge des Betrachters liegt).
Und Aufgaben mal mit einer etwas anderen Sichtweise lösen schadet sicherlich nicht.

knivil

@volkard: Natuerlich ist es moeglich in imperativen Sprachen die Korrektheit zu beweisen. Es ist aber a) aufwendiger oder b) nur fuer "kleine" Programme durchfuehrbar. Desweiteren legst du mir Worte in den Mund: KOENNTE. Hoer auf damit. Ich meinte: kann!

@Irgendwer:
1.) Monaden Grundlage reicht nicht
2.) Kategorientheorie besteht aus mehr
3.) Haskell besteht aus mehr als nur Kategorientheorie

Du gehst also davon aus, dass man Monaden nur verstehen kann, wenn man Kategorientheorie versteht. Mag sein, dass sie daher kommen, aber eigentlich hätte man sie auch selbst "erfinden" können

Der erste Satz hat nichts mit dem zweiten zu tun. Du bringst Scheinargumente.

Jetzt merkt knivil in seiner Haskell-Verleibtheit nicht mal mehr wie sehr er übertreibt.

@Irgendwer:
1.) Monaden Grundlage reicht nicht
2.) Kategorientheorie besteht aus mehr
3.) Haskell besteht aus mehr als nur Kategorientheorie

Was soll 1) bedeuten?
Was hat 2) damit zu tun?
3) hat so doch auch niemand behauptet. Du warst übrigens derjenige der die Kategorientheorie erst ins Spiel gebracht hat.

Der erste Satz hat nichts mit dem zweiten zu tun.

Was besseres ist dir nicht eingefallen?
Wie stehst du denn zu meiner Aussage im ersten Satz: "Du gehst also davon aus, dass man Monaden nur verstehen kann, wenn man Kategorientheorie versteht."

Sag doch mal klar und deutlich was du meinst, anstatt dir irgendwelche Einzelaussagen herauszugreifen und diese zu kritisieren. Das würde eine Diskussion deutlich einfacher machen...

audacia

Irgendwer schrieb:

Sag doch mal klar und deutlich was du meinst, anstatt dir irgendwelche Einzelaussagen herauszugreifen und diese zu kritisieren. Das würde eine Diskussion deutlich einfacher machen...

Ein anderes Vokabular übrigens auch.

knivil schrieb:

Bullshit! [...]
@volkard: Bullshit! [...]

Warum nicht auch mal Schafkot oder Ziegenmist? Oder Argumente stattdessen?

knivil schrieb:

Bullshit, Haskell hat besseres OOP!

... besser als wer?

Und mal her mit einem Beispiel, an dem man das erkennen kann!

@Irgendwer:
Nun, ich nehme dieses Thema sehr locker, da ich etwa die gleiche Ansicht vertrete wie Paul Graham, aber nicht auf Common Lisp bezogen, sondern auf Haskell. Mir kommt es zugute, dass meine Konkurrenz Haskell nicht kennt oder davon nicht viel hält. Das bringt mir bares Geld, und keiner scheint zu verstehen, wie ich das mache. Das ist gut für mich. In diesem Sinne schneide ich mir eigentlich ins eigene Fleisch, indem ich hier poste, aber ich bin eben nicht so konsequent wie Paul.

Fakt ist: Haskell hat meine Entwicklungszyklen dramatisch verkürzt. Ich mache praktisch kein Debugging mehr, denn sobald meine Programme kompilieren, funktionieren sie auch. Nein, ich meine nicht nur, dass ihre Korrektheit bewiesen ist, sondern dass sie sich auch in der Praxis beweist. Und dabei geht es nicht um irgendwelchen akademischen Kram, sondern um praktische Anwendungen, mit denen ich Geld verdiene (Webseiten hauptsächlich).

Es kommt nicht selten vor, dass ich seitenweise Code schreibe, bevor ich auch nur ein einziges mal kompiliere. Meistens habe ich dann ein bis zwei Typfehler drin (die in C++ zu 99% zu Laufzeitfehlern führen würden). Die behebe ich, und schon funktioniert mein Code. Da können die ganzen C++-Freaks hier noch so wenig von automatischen Beweisverfahren durch Typentheorie halten. Es ist Fakt. Und dadurch kann ich mich auf die eigentliche Aufgabe konzentrieren und Code schreiben, der etwas tut. Das ist vielleicht auch der Grund dafür, dass es keinen anspruchsvollen Debugger für Haskell gibt. Er wird schlicht und ergreifend nicht gebraucht. Und nochmal: Klar werden jetzt jedem C++-Programmierer die Finger jucken, mir zu widersprechen, aber das interessiert mich nicht. Es ist Fakt, und mit diesem Fakt verdiene ich Geld.

Mir wird so oft widersprochen, wenn ich sage, dass Haskell eine geniale Sprache ist. Inzwischen spare ich mir diese Aussage, denn ich kenne die Macht von Haskell und weiß sie zu schätzen, und ich gehöre zu denen, die den direkten Vergleich haben und demnach objektiv beurteilen können. Und wenn man mir nicht glaubt, ist das besser für mich.

DrGreenthumb

ertes schrieb:

Klar werden jetzt jedem C++-Programmierer die Finger jucken, mir zu widersprechen

nicht jedem! manch einer beneidet dich und würde viel lieber auch haskell programmieren...

ertes schrieb:

Fakt ist: Haskell hat meine Entwicklungszyklen dramatisch verkürzt. Ich mache praktisch kein Debugging mehr, denn sobald meine Programme kompilieren, funktionieren sie auch. Nein, ich meine nicht nur, dass ihre Korrektheit bewiesen ist, sondern dass sie sich auch in der Praxis beweist. Und dabei geht es nicht um irgendwelchen akademischen Kram, sondern um praktische Anwendungen, mit denen ich Geld verdiene (Webseiten hauptsächlich).

Müssen aber total simple Seiten sein. Wie kann man überhaupt die Korrektheit von Webseiten beweisen?

Bei den meisten Anwendungen ist das Problem doch, dass die Kunden etwas wollen und wenn man das macht, merken sie, dass sie was anderes brauchen.

DrGreenthumb

wersglaubt schrieb:

Müssen aber total simple Seiten sein. Wie kann man überhaupt die Korrektheit von Webseiten beweisen?

hinter den Webseiten die Du als Benutzer siehst, arbeiten Programme...

Bei den meisten Anwendungen ist das Problem doch, dass die Kunden etwas wollen und wenn man das macht, merken sie, dass sie was anderes brauchen.

darum lieber schnell Ergebnisse schaffen.

CStoll

@ertes: Auch auf die Gefahr hin, bereits genannte Argumente zu wiederholen:
Es ist mathematisch (?) nicht möglich, die Korrektheit eines Programms zu beweisen - außer du schränkst die Sprache so weit ein, daß du nicht mehr jedes Problem damit lösen kannst. Damit haben sich schon Generationen von Informatikern beschäftigt (Stichwort: Berechenbarkeit).
Und selbst wenn der Compiler dein Programm akzeptiert, wer sagt dir, daß es wirklich die Aufgabe löst, die du gestellt bekommen hast? Vielleicht hattest du ja auf deinen "seitenweise Code" einen Denkfehler, der das komplette Ergebnis verfälscht.

ertes schrieb:

Es kommt nicht selten vor, dass ich seitenweise Code schreibe, bevor ich auch nur ein einziges mal kompiliere. Meistens habe ich dann ein bis zwei Typfehler drin (die in C++ zu 99% zu Laufzeitfehlern führen würden). Die behebe ich, und schon funktioniert mein Code.

Und was wenn man mal etwas komplexere Aufgaben hat? Beweist Haskell auch gleich numerische Stabilität und ähnliches? Sinnhaftigkeit von Spezifikationen? Wie sichert man ab, dass der Code im realen Umfeld überhaupt läuft (hinsichtlich Resourcen)? Dieses ganze blabla von wegen kompiliert also läufts ist einfach nur oberflächlicher Bullshit.

Edit: Und nein, ich habe nichts gegen Haskell, würde ich mir gerne mal anschauen wenn ich Zeit dazu hätte.

ertes schrieb:

@Irgendwer:

Huch, warum denn an mich gerichtet? Ich sehe das eigentlich so ähnlich wie du.

Tim schrieb:

Dieses ganze blabla von wegen kompiliert also läufts ist einfach nur oberflächlicher Bullshit.

Er spricht doch nur von seiner Erfahrung, wobei ich schon von vielen anderen Haskellern ähnliches gehört habe. Sind aber wahrscheinlich alles Lüger.

CStoll schrieb:

Vielleicht hattest du ja auf deinen "seitenweise Code" einen Denkfehler, der das komplette Ergebnis verfälscht.

Es sagt doch niemand, dass man nicht testen darf. Ich bin sicher selbst ertes wird kein Programm an einen Kunden ausliefern, dass er nicht vorher getestet hat.

knivil

Es ist mathematisch (?) nicht möglich, die Korrektheit eines Programms zu beweisen

Falsch! Die richtige Aussage lautet: Es ist allgemein nicht moeglich ... . D.h. fuer ausgewaehlte Programme ist durchaus moeglich. Es hat nichts mit der Sprache sondern nur was mit dem Anwendungsfall zu tun. Und es gibt recht viele Anwendungsfaelle, wo das moeglich ist. Meist geht es auch nicht um ein gesamtes Programm angefangen bei Userinput bis hin zum Drucken von Dokumenten.

Und was wenn man mal etwas komplexere Aufgaben hat?

Was sind komplexe Aufgaben?

Beweist Haskell auch gleich numerische Stabilität und ähnliches? Sinnhaftigkeit von Spezifikationen?

Na, nu uebertreib mal nicht!

Wie sichert man ab, dass der Code im realen Umfeld überhaupt läuft (hinsichtlich Resourcen)?

Die statische Analyse von ghc ist recht gut.

Dieses ganze blabla von wegen kompiliert also läufts ist einfach nur oberflächlicher Bullshit.

Nur solange man nicht unter die Haube von ghc geschaut hat. Was man dort sieht, kann man nicht Forum-gerecht wiedergeben. Jeder muss sich selbst ueberzeugen.

volkard

knivil schrieb:

Es ist mathematisch (?) nicht möglich, die Korrektheit eines Programms zu beweisen

Falsch! Die richtige Aussage lautet: Es ist allgemein nicht moeglich ... . D.h. fuer ausgewaehlte Programme ist durchaus moeglich. Es hat nichts mit der Sprache sondern nur was mit dem Anwendungsfall zu tun. Und es gibt recht viele Anwendungsfaelle, wo das moeglich ist. Meist geht es auch nicht um ein gesamtes Programm angefangen bei Userinput bis hin zum Drucken von Dokumenten.

Du kannst beweisen, daß das Richtige gedruckt wird?

wenn die Spezifikation vom Kunden von vornherein unabänderlich feststeht, kann man fast in jeder Programmiersprache zügig und korrekt implementieren.

Wie hier schon gesagt wurde, trennt sich die Spreu vom Weizen, wenn der Kunde hinterher merkt, daß er eigentlich was anderes will, als er vorher gesagt hat.

Bezweifle mal, daß funktionale Sprachen in solchen Fällen ggü "klassischen" Sprachen im Vorteil sind. Tippe da eher auf dynamische OO-Sprachen.

Bashar

wenn die Spezifikation vom Kunden von vornherein unabänderlich feststeht, kann man fast in jeder Programmiersprache zügig und korrekt implementieren.

Unabänderlich reicht nicht, sie muss auch vollständig und widerspruchsfrei sein. Das ist bei komplexen Aufgaben in der Regel nicht gegeben.

knivil

Du kannst beweisen, daß das Richtige gedruckt wird?

Ich versuchte auszudruecken, dass es gerade darum nicht geht.

wenn die Spezifikation vom Kunden von vornherein unabänderlich feststeht, kann man fast in jeder Programmiersprache zügig und korrekt implementieren.

Das bezweifelt niemand. Es ist aber ein Unterschied ob man Assembler, C++ oder gar Haskell verwendet.

Tippe da eher auf dynamische OO-Sprachen.

Raten hilft nicht, nur ausprobieren! Warum sollten OO-Sprachen besser geeignet sein als funktionale? Fuer einen Vergleich reicht es nicht, nur eine Seite zu kennen!

knivil schrieb:

Und was wenn man mal etwas komplexere Aufgaben hat?

Was sind komplexe Aufgaben?

Ich sag mal: Das Generieren von Webseiten als Ein-Mann-Projekt zählt nicht dazu.

knivil schrieb:

Beweist Haskell auch gleich numerische Stabilität und ähnliches? Sinnhaftigkeit von Spezifikationen?

Na, nu uebertreib mal nicht!

Da ich nicht derjenige hier bin der sagt "kompiliert also geht" bin ich wohl kaum der Übertreibende. Aber so langsam bekomme ich den Eindruck, dass ihr euch dieses "geht" einfach anders hindefiniert.

knivil schrieb:

Dieses ganze blabla von wegen kompiliert also läufts ist einfach nur oberflächlicher Bullshit.

Nur solange man nicht unter die Haube von ghc geschaut hat. Was man dort sieht, kann man nicht Forum-gerecht wiedergeben. Jeder muss sich selbst ueberzeugen.

Dann überzeuge mich. Was passiert wenn ich z.B. die Klammerung in einer Berechnung falsch setze? Das Programm wird idR kompilieren, aber das Ergebnis wird nicht das sein das ich will. Wie geht man dieses Problem in Haskell an? Testen tut man ja offensichtlich nicht, also wie beweist man sowas?

knivil

@Tim:

Wie geht man dieses Problem in Haskell an?

Die Programmiersprache kann nur im Rahmen der Programmiersprache unterstuetzend wirken, also auf Basis von Typen, Rekursion und Funktionen. Sie wird schwer ein + anmahnen, wenn ein - gemeint ist. + und - besitzen den gleichen Typ. Sowas wuerde ich persoenlich als Schusselfehler einstufen.

Beweisen ... kann man natuerlich nur Behauptungen. Behauptungen in der Mathematik sind Aussagen der Form A = B, wobei vielleicht A eine Funktion f(x) ist und B das Programm. Testen ist ein Spezialfall: 55 = B(1,2,3). Wenn ich aber zeigen kann, dass f(x) = B(a,b,c) ist, dann brauche ich nicht zu testen. Ein sehr einfaches Beispiel ist:

filter p (xs ++ ys) = (filter p xs) ++ (filter p ys)

Ich kann also die gesamte Liste (xs ++ ys) am Stueck verarbeiten oder die Arbeit auf beiden Teillisten erst ausfuehren und das Ergenis danach zusammenfuehren. Ein guter Ansatz fuer Parallelisierung, wenn das Zerlegen in Teile billig im Vergleich zu p ist.

map f (map g xs) = map (f.g) xs

Ein Beispiel fuer Programmfusion (light). Ich brauche nur einmal ueber die Liste xs iterieren. Wie weit man damit kommt, laesst sich beispielsweise in Programming in Haskell Kapitel 11 nachlesen.

Andersherum kann man aus einem Programm durch aequivalente Umformung ein neues ableiten, dass womoeglich ein besseres Laufzeitverhalten hat. In Grundlagen funktionaler Programmierung von Martin Erwig wird fuer die maximale Teilsumme aus einem O(n^3) der Algorithmus mit O(n) durch aequivalente Umformungen angegeben. Der Kompiler selbst kann diese Umformungen nicht automatisch ausfuehren, er braucht zumindestens gelegentliche Hinweise oder Annotationen. ghc selbst enthaelt schon viel von diesem Expertenwissen und kann auf dieser Basis gut Optimieren. Weitere anlaufstelle: Bird-Meertens Formalism. Das sind nur die Grundlagen ... interessant wird es dann bei der korrekten Implementation von beispielsweise des Barnes-Hut-Algorithmuses, aber bitte parallel.

Dann überzeuge mich.

Nein! Ich kann dir nur zeigen, wo du selbst nachlesen kannst. Ueberzeugen musst du dich selbst.