Erlang im Trend?
-
knivil schrieb:
LiGERWooD schrieb:
Microsoft Visual Studio. Ob Visual C# oder Visual C++. Obwohl bei Visual Basic hatte ich noch freude bis ich da an die Grenzen gestossen bin und die schlechte Performance mir auf den nerv ging.
Du laberst allgemeinen Kram. Wahrscheinlich kennst du dich einfach nicht aus und weisst nicht, was du tust.
Oh ja bitte! Dämliche vorurteile!
Ich meine z.B. dass das man Arrays anders inialiserein bzs. deklarieren musste. Und das mit dass 0 in Warheit 1 ist nicht mehr eindeutig war. Mal war es so und mal so und das brachte einem zum Wahnsinn bei der Fehlersuche.
-
Ist dann aber ein Problem der Sprache selbst und nicht der IDE. Mit der hat das nichts zu tun. VB würde ich für Datenaufwendige Sachen sowieso nicht benutzen. Wo alle WinAPI Funktionen zum 50000 mal gekapselt sind
.
-
knivil schrieb:
LiGERWooD schrieb:
Microsoft Visual Studio. Ob Visual C# oder Visual C++. Obwohl bei Visual Basic hatte ich noch freude bis ich da an die Grenzen gestossen bin und die schlechte Performance mir auf den nerv ging.
Du laberst allgemeinen Kram. Wahrscheinlich kennst du dich einfach nicht aus und weisst nicht, was du tust.
Wenn ich davon keine Ahnung hätte, dann frage ich mich wie ich es geschaft habe mit Visual C++ ein kleines Programm zu schreiben wo mit einem MySQL .Net Connecter mit einer MySQL Datenbank connectet wird, und querys ausgeführt, also Daten gelesen und geschrieben werden. Und darüberhinaus, durch diese Daten sich das Programm individuell verhalten hatt.
-
Und, das macht dich zum Experten? Nein, du hast nicht gesagt, dass du ein Experte bist. Genauso wenig habe ich gesagt, dass du keine Ahnung hast.
-
knivil schrieb:
Und, das macht dich zum Experten? Nein, du hast nicht gesagt, dass du ein Experte bist. Genauso wenig habe ich gesagt, dass du keine Ahnung hast.
Ändert das irgendwas?
Ich habe mir das geschrieben, was das erbringt, was ich mir von der funktion her vorgestellt habe und damit bin ich zufrieden.
Echt peinlich, das hier Experte als Status angesehen wird! Bist der King he?! Ja ej mann du hast es voll drauf du Experte!!!
-
LiGERWooD schrieb:
Ändert das irgendwas?
Ich hatte gehofft, zum Thema zurueckkehren zu koennen. Tja, Pech gehabt. Das hat auch nichts mit Vorurteilen zu tun, allein deine Posts reichen mir. Bestes Beispiel soweit:
Und was war da ausser schlechter Perfomance? .. wie dämlich die HDD angefangen hat zu rattern.
Da fragt jemand, was dich stoert, ausser die Performance. Und du antwortest, die Performance sei scheisse. Deine Aufmerksamkeit reichte nur fuer die ersten vier kleinen Woerter.
-
Hast du brav gemacht. Am besten du nimmst einen Strick!
-
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.
Haskell "C++, Python und Co." gegenüberzustellen ist einfach keine gute Idee, weil C++ und Python zu verschieden sind. Wenn Du sagen wolltest, dass imperative Sprachen einfacher sind, als funktionale Sprachen, muss ich Dir widersprechen. Für Menschen, die imperative Sprachen gewöhnt sind, natürlich. Ist aber uninteressant. ("Für Autofahrer, die nicht Schifahren können, ist Schifahren schwer." Oh Überraschung.)
-
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?