Haskell

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

[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

[Zeigen]

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.

[Irgendwer]

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.

[volkard]

knivil schrieb:

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.

Echt?
Das wäre supi. Dann könnte ich ja ungelöste mathematische Probleme nach Haskell übersetzen und dort beweisen. Genial! Ich liebe Haskell und den Fanclub.

[Irgendwer]

Nein, dieses Wissen kann nicht vorausgesetzt werden.

Man muss die Kategorientheorie nicht verstehen um Monaden schreiben und verwenden zu können. Siehe auch: You could have invented monads
Solche Aussagen wie deine sind es, die dazu führen, dass funktionale Sprachen von den meisten als rein akademische Forschungssprachen verstanden werden.

Das wäre supi. Dann könnte ich ja ungelöste mathematische Probleme nach Haskell übersetzen und dort beweisen. Genial! Ich liebe Haskell und den Fanclub.

[knivil]

@Irgendwer: Ich kenne die meisten Artikel. Um Monaden zu benutzten, braucht man sie vielleicht nicht verstehen. Aehnliches gilt auch fuer Templates. Ich kann die Container der STL benutzen. Will ich aber Templates darueber hinaus einsetzen, muss ich sie verstehen.

Solche Aussagen wie deine sind es, die dazu führen, dass funktionale Sprachen von den meisten als rein akademische Forschungssprachen verstanden werden.

Bullshit! Der Schritt von Monaden in Haskell auf alle funktionalen Sprachen ist sehr gross.

@volkard: Bullshit! Ich habe nicht von allen Programmen gesprochen.

[volkard]

knivil schrieb:

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

Lies das nochmal genau durch. So, wie es da steht, sprichst Du von allen Programmen. Und das ist Quatsch.

Manche Programme können auch in anderen Sprachen bewiesen werden. Das ist also nicht der Vorteil. Abgesehen davon, daß die Flieger abtürzen, weil die Spezifikation falsch war, nicht das Programm. Du könntest höchstens herausarbeiten, daß manche Programme in Haskell leichter automatisch bewiesen werden können.

Benutzt Du automatisierte Programmbeweiser?

[GPC]

Bashar schrieb:

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

Klar gibt's auch VB6 Gurus, warum auch nicht. Die werden halt immer weniger, weil es seitens MS keinen Suppport mehr für VB6 gibt und auf .NET die meisten C# anstatt VB.NET nutzen.
VB6 ist halt furchtbar verbose und es fehlen (inzwischen) im Mainstream angekommene Dinge wie Lambdas, Generics/Templates etc, aber es war ja auch als RAD-Tool für GUI bzw. COM ausgelegt und da hat es nicht ohne Grund massive Erfolge gefeiert.