Erlang im Trend?
-
Das bisschen Kategorientheorie hat man in ein paar Jahren gelernt.
Ich garantiere dir, dass lernt man nicht in ein paar Jahren. Mathe ist noch immer für die meisten ein echtes Problem und die Kategorientheorie stellt gerade so das abgefahrenste der Mathematik dar... Der Vergleich mit den Eigenheiten einer Sprache hinkt hier sehr deutlich
Haskell "C++, Python und Co." gegenüberzustellen ist einfach keine gute Idee, weil C++ und Python zu verschieden sind.
Bei der Entwicklung von Python hat man oft auf die Konzepte aus Haskell zurückgegriffen, ich würde Python daher auch nicht klassisch als imp.Sprache betrachten. Aber Vergleichspunkte gibt es zwischen Haskell und Python in jedem Fall.
-
nman schrieb:
knivil schrieb:
Funktor, Monade als auch deren Verallgemeinerung Arrow sind Grundkonzept aus der Kategorientheorie, die explizit in Haskell eingesetzt werden. Um sie wirkungsvoll anzuwenden, muss man sie verstanden haben.
So what? Das bisschen Kategorientheorie hat man in ein paar Jahren gelernt. Genauso wie die vielen Eigenheiten von C++, die uns schon gar nicht mehr auffallen, weil wir sie gewöhnt sind.
Ich würde sogar sagen, dass man die Kategorientheorie dahinter gar nicht verstehen muss, um effektiv in Haskell programmieren zu können. Ähnlich wie man auch effektiv in C++ programmieren kann, ohne verstanden zu haben, was eine operationelle Semantik ist.
In einem gewissen Sinn wird zwar jeder brauchbare C++-Programmier eine operationelle Semantik von C++ verstanden haben, aber nicht auf dem Level der Mathematik. Ich denke, dass das mit Monaden, Funktoren etc. ähnlich ist. Die kann man auf Haskell-Level sehr gut verstanden haben, obwohl man auf Mathematik-Level damit weniger anfangen kann.
Wenn man z.B. mal den Wikipedia-Artikel zu Monad im Bereich Kategorientheorie anschaut, dann findet man dort kommutative Diagramme und Begriffe wie "natürliche Transformation" und "adjungierte Funktoren". Es kann sicher nicht schaden, das zu kennen. Aber um in Haskell effektiv programmieren zu können, muss man IMHO mit dem Begriff "adjungierter Funktor" nicht unbedingt etwas anfangen können. Es würde mich sehr wundern, wenn auch nur einer von zehn Haskell-Programmierern "adjungierte Funktoren" erklären kann.
Ich seh das ähnlich, wie man in C++ programmieren kann, ohne den Begriff "operationelle Semantik" in mathematischer Sprache erklären zu können.
-
Tja, man kann auch effektiv C++ programmieren, ohne Instanzen und Klassen zu kennen oder zu benutzen. Leider ist Haskell programmierte Mathematik und wenn du selbst Monaden entwerfen willst, dann musst du die noetige Mathematik dahinter kennen. Fuer die alleinige Nutzung brauchst du das weniger. In C++ kann ich auch ohne weiteres std::vector und so verwenden, hilft aber wenig, wenn ich selbst Templates (nicht nur fuer Container) entwerfen moechte. Aber es sind nicht nur Monads, sondern auch type classes, phantom types, existential types, general algebraic data types, ... . Der Kram mit map, filter, zip, fold oder Rekursion ist da vergleichsweise schnell gelernt. Wenn man in Haskell nur imperativ programmieren moechte, dann kann man das auch. Leider laesst man sich dann nicht wirklich auf die Sprache ein und sollte eine andere waehlen.
Sofern trifft das Skifahrerargument natuerlich zu. Mit Haskell werden einfach sehr viele neue und ungewohnte Idiome eingefuehrt. Bei den anderen Sprachen (z.B. C++, Python, Scheme, ml, ...) kann man auf mehr bekanntes aufbauen. Deswegen ist es schwieriger, man hat weniger auf das man aufbauen kann.
-
frosch03 schrieb:
Das bisschen Kategorientheorie hat man in ein paar Jahren gelernt.
Ich garantiere dir, dass lernt man nicht in ein paar Jahren.
Das bisschen, das zum produktiven Arbeiten mit Haskell nötig ist sehr wohl, doch.
Haskell "C++, Python und Co." gegenüberzustellen ist einfach keine gute Idee, weil C++ und Python zu verschieden sind.
Bei der Entwicklung von Python hat man oft auf die Konzepte aus Haskell zurückgegriffen, ich würde Python daher auch nicht klassisch als imp.Sprache betrachten. Aber Vergleichspunkte gibt es zwischen Haskell und Python in jedem Fall.
Ich habe mich nicht gegen den Vergleich zweier Sprachen gewehrt, sondern gegen ein in meinen Augen absolut nicht sinnvolles Zusammenclustern von "C++, Python und Co.", lies doch die vorhergehenden Posts nochmal.
Btw, gibt es irgendeinen bestimmten Grund, warum Du den Thread nach einem Monat wieder ausgräbst?
-
Monaden im Haskell Kontext zu verstehen Fällt vielen meiner Meinung nach deshalb schwer, weil sie einfach schelcht erklärt werden. Entweder werden sie von der mathematischen Seiten erläutert, was Leuten ohne Hintergrundwissen aus der Kategorientheorie gar nicht hilft oder es werden alberne Vergleiche angestellt, wie "Monads Are Like Burritos", die man zwar nachvollziehen kann, wenn man Monaden einmal verstanden hat, einem beim Lernen an sich aber kein Stück weiterbringen.
Entsprechend der mathematischen Erklärungen: jemand will eine x belibige Sprache lernen, kommt nun zum Thema Funktionen und bekommt als Erklärung "Funktionen ordnen jedem Element einer Definitionsmenge genau ein Element einer Zielmenge zu." Das hilft im Kontext der Sprache vermutlich wenig weiter.
Oder entsprechend der Vergleiche: "Funktionen sind wie Backöfen. Man tut die Zutaten rein, z.B. Teig, Tomatensauce und Käse und raus kommt ein fertigs Gericht, z.B. eine Pizza." Hilft demjenigen, der die Sprache lernen will wohl auch nicht weiter.
-
liegt wohl auch daran, daß eine Programmausführung nach wie vor ein zeitsequentieller Vorgang ist (bei Parallelisierung eben mehrere in sich zeitsequentielle Vorgänge). (ohne science-fiction jetzt mal :D)
Die funktionale Denkweise ist aber vom Ansatz her zeitlos, eher wie eine mathematische Formel "sin(a+b)".
-
Bringt es eigentlich was für "normale" Programmierung (C++, Java...), wenn man Sprachen wie Erlang oder Haskell kann? Also lassen sich irgendwelche Konzepte übertragen? Wenn ja, welche?
-
einige funktionale Elemente sind in vielen anderen Prog.Sprachen zu finden (Iteratoren, Generatoren, lambda, list comprehension, reduction, ...) und schon in den mainstream gesickert, bei einigen Sprachen mehr (python, C++/STL, ...), bei anderen weniger.
-
Helium schrieb:
Monaden im Haskell Kontext zu verstehen Fällt vielen meiner Meinung nach deshalb schwer, weil sie einfach schelcht erklärt werden. Entweder werden sie von der mathematischen Seiten erläutert, was Leuten ohne Hintergrundwissen aus der Kategorientheorie gar nicht hilft oder es werden alberne Vergleiche angestellt, wie "Monads Are Like Burritos", die man zwar nachvollziehen kann, wenn man Monaden einmal verstanden hat, einem beim Lernen an sich aber kein Stück weiterbringen.
Das stimmt total. Ich habe noch keine halbwegs brauchbare Einführung in Haskell gefunden. In scheme sagen sie dir „Scheib lambda hin. Dann hast du eine neue Funktion. Die hat außerdem noch zugriff auf die dort verfügbaren variablen wo du die hingeschrieben hast.” ohne mit Lambda-kalkül oder so einen scheiß zu kommen. Bei Haskell erzählen dir dir alle so einen Quatsch von Y-Combinator oder anderer Theoretischer Scheiße, was einfach nur den Sinn hat cool zu sein und sich selbst als Scene bewusst zu werden. (Damit meine ich jetzt weniger die Theoretischen Konzepte als mehr das die Haskell-Szene sie als Lebensnotwenig darstellt.
Ein anderes Problem von Haskell ist, das man es nicht wirklich sinnvoll von oben nach unten lesen kann. Bei jeder sprache kann ich wenn ich eine Variable sehe einfach nach oben Scrollen und sehe wo sie definiert ist. Bei Haskell kann man aber mit let die Variablen vor einen Ausdruck und mit Where nach einem Ausdruck definieren. Das ist wieder so ein Fall wo zu viel Freiheit alles viel zu kompliziert und inkonsistent macht.
-
IPH schrieb:
Ein anderes Problem von Haskell ist, das man es nicht wirklich sinnvoll von oben nach unten lesen kann. Bei jeder sprache kann ich wenn ich eine Variable sehe einfach nach oben Scrollen und sehe wo sie definiert ist. Bei Haskell kann man aber mit let die Variablen vor einen Ausdruck und mit Where nach einem Ausdruck definieren. Das ist wieder so ein Fall wo zu viel Freiheit alles viel zu kompliziert und inkonsistent macht.
das Feature macht es gerade einfach ein Programm von oben nach unten zu lesen. Du schreibst selbst, du scrollst sonst wieder nach oben - also liest du ja rückwärts.
-
nman schrieb:
Das bisschen, das zum produktiven Arbeiten mit Haskell nötig ist sehr wohl, doch.
Jetzt würde mich doch brennend Interessieren, was das deiner Meinung nach ist.
Welche Kathegorientheoretischen Konstrukte benötigt man um produktiv mit Haskell
arbeiten zu können?nman schrieb:
Btw, gibt es irgendeinen bestimmten Grund, warum Du den Thread nach einem Monat wieder ausgräbst?
Bin über die Suchfunktion auf diesen Thread aufmerksam geworden. Ist das echt so ungewöhnlich?