Haskell

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?

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?

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.

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.

GPC

ertes schrieb:

Programmiersprachen sind eben auch Religionen, wie dieser Flamewar hier beweist (und nein, ich schließe mich da nicht aus).

Man muss ja schon ein ziemlich armer Hund sein, wenn man sich ein Werkzeug zur Religion hochjubelt *renn und duck*

Na ja, Haskell ist ja zur Zeit der Mocca Latte unter den Programmiersprachen und man kommt kaum dran vorbei, weil sich so viele dran aufgeilen Auch ich fand Haskell von vielen Konzepten her echt interessant und es hat auch meine tägliche Arbeit mit C# positiv beeinflusst Ich denke es wird am Ende aber darauf hinauslaufen, dass imperative Sprachen die guten Teile von Haskell (speziell denke ich an Typklassen) abkupfern.

maximAL schrieb:

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.

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Kann das mal einer möglichst elegant in Haskel schreiben?

#include <string>
#include <iostream>
#include <ctime>

int main()
{
	int maxNr = 12;
    srand(time(0));
	int geld = 100;
	bool ende = false;
	while ( !ende ) {
		int setzen = 0;
		do {
			std::cout << "\nSie haben " << geld << " Geld. Wieviel wollen Sie setzen? ";
			std::cin >> setzen;
		} while (setzen <= 0 || setzen > geld );

		int zahl = 0;
		std::cout << "Auf welche Zahl wollen Sie setzen (1-" << maxNr << ")? ";
		std::cin >> zahl;

		int wurf = 1 + rand() % maxNr;
		std::cout << wurf << " wurde geworfen.\n";
		if ( wurf == zahl ) {
			geld += setzen * 10;
		}
		else {
			geld -= setzen;
		}

		if ( geld > 0 )	{
			std::string weiter;
			std::cout << "Sie haben " << geld << " Geld. Wollen Sie weiterspielen (j/n)? ";
			std::cin >> weiter;
			ende = weiter == "n";
		}
		else {
			ende = true;
		}
	}
	std::cout << "\nSie haben " << geld << " Geld. Gratulation! ;-)\n";
    return 0;
}

Bashar

GPC schrieb:

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Das tut ja nicht jeder, der sich C++-Programmierer nennt. Die wenigsten, schätze ich.

GPC

Bashar schrieb:

GPC schrieb:

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Das tut ja nicht jeder, der sich C++-Programmierer nennt. Die wenigsten, schätze ich.

Ja, aber es gilt für jede wichtigere Sprache, dass es einen großen "Mittleklasse"-pool gibt und dann eine kleinere Gruppe von Leuten, die richtig gut damit umgehen können

Bashar

Ob es Visual Basic Gurus gibt? Das ist doch Perlen vor die Säue.

audacia

Und wenn jetzt alle Haskell anfangen? Säue vor die Perlen?

otze

Irgendwer schrieb:

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.

Das Buch mit dem Ich Haskell programmieren lernen wollte "Introduction to functional progrmaming using Haskell" war das einzige Programmierbuch jemals, in dem sich der Autor genötigt fühlte zu beweisen, dass zwei Ausdrücke das identische Ergebnis bildeten. Nur war der eine Ausdruck 10x schneller, war aber nicht mehr wirklich gut von der Semantik her verständlich. Und der Beweis war auch meiner Erinnerung nach nichttrivial.

Ich weiß nicht, ob eine Sprache so toll ist, in der man bei bestimmten Codeschnipseln den Beweis als Kommentar drüber packen muss.

Nur war der eine Ausdruck 10x schneller, war aber nicht mehr wirklich gut von der Semantik her verständlich.

Selbst in C++ ist es häufig der Fall, dass die naive Implementierung nicht die schnellste ist. Schnellere Implementierungen werden dann häufig etwas komplizierter und sollten dann kommentiert werden.

Und der Beweis war auch meiner Erinnerung nach nichttrivial.

Sonst hätte er ihn wohl nicht erklärt, oder?

knivil

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

Kategorientheorie wird an den seltensten Universitaeten im Fach Informatik gelehrt. Nein, dieses Wissen kann nicht vorausgesetzt werden.

Autor genötigt fühlte zu beweisen, dass zwei Ausdrücke das identische Ergebnis bildeten

Nein, es drueckt ein wesentliches Feature von Haskell aus. Korrektheit von Programmen kann bewiesen werden.