Haskell

[ertes]

CStoll schrieb:

OK, wir haben eine Funktion sqrt(), die nur positive Zahlen als Parameter entgegennimmt, eine Funktion arcsin(), die nur Zahlen im Bereich [-1,1] akzeptiert und einige weitere die auch ihre jeweiligen Einschränkungen haben. Und aus diesen Funktionen wollen wir nun komplexere Funktionen zusammenbauen (z.B. die pq-Formel für quadratische Gleichungen). Allerdings kannst du bei den meisten Funktionen nicht garantieren, daß ihre Werte in einem bestimmten Bereich bleiben, d.h. du mußt die zusammengesetzte Funktion mit Fallunterscheidungen spicken, um die Wertebeschränkungen sicherzustellen.

Nein, die Funktionen kannst du zusammensetzen, wie du willst, solange die Typen passen. Es kommt auf die Werte an, die in das System geschickt werden. Aber ist auch egal, denn sowas zu bewerkstelligen ist in Haskell zu aufwendig, um praktikabel sein. Ich sage es jetzt zum letzten mal und werde dann auch nicht weiter auf das Thema eingehen: Haskell ist nicht dafür geeignet, numerische Korrektheit von Formeln zu beweisen. Es ist möglich, aber viel zu aufwendig. Schau dir Agda und Coq an, wenn dich das Thema interessiert. Thema ist meinerseits beendet.

Du hast einige Begriffe in den Raum geworfen.

Nun, ich traue den meisten hier zu, eine Suchmaschine richtig zu benutzen. Aber ich habe auch schon Links gepostet. Du wolltest z.B. praktischen, produktiven Code sehen. Ich habe dir welchen verlinkt. Plötzlich gings du überhaupt nicht mehr darauf ein. Du gehst nur auf die Themen ein, in denen du vermutest, dass du mir widersprechen und/oder Haskell in den Boden stampfen kannst. Hat es dich so erschreckt, dass richtige Real World-Bibliotheken in Haskell gibt, und dass man mit denen tatsächlich produktiv arbeiten kann?

Und eventuell solltest du meine Bemerkungen auch zu Ende lesen. Klar kannst du deine Typen und Funktionen so weit einschränken, daß sie nur auf eine bestimmte Art verwendet werden können, aber was für einen Sinn macht das? Und solange die beteiligten Ausdrücke mit den selben Typen zusammenpassen, wird dein Compiler keinen Unterschied bemerken.

So ist es. Und wenn du den Sinn darin nicht siehst, dann hat es keinen Wert, darüber zu diskutieren. Du kannst in Haskell viele statische Garantien erreichen, die in C++ undenkbar sind, aber es hat keinen Wert, dir das näherzubringen. Einerseits bist du versteift in deiner Überzeugung, andererseits bist du aber nicht bereit, Haskell erst mal wirklich auszuprobieren, bevor du urteilst.

Wie schon gesagt: Ich kenne C++ und Haskell, beide aus mehrjähriger Erfahrung. Du kennst nur C++ und zeigst keine Bereitschaft, das zu ändern. Somit ist die ganze Diskussion, die wir führen, Zeitverschwendung.

Bitte schön, hier der Haskell-Code dazu: […]

Und wie sieht der in der Anwendung aus?

Nicht anders als bei entsprechenden C/C++/Ruby/Smalltalk-Bibliotheken, außer dass diese Bibliothek effektfrei ist. Beispiel:

newHeaders = M.insert "Content-type" "text/plain" oldHeaders

Wenn man seinen Code richtig funktional schreibt, sieht man da aber meistens nur entweder auf der rechten oder auf der linken Seite einen Namen, etwa wenn man mit StateT arbeitet: modify (M.insert "Content-type" "text/plain") .

(PS: eine vorgefertigte Library zu verwenden ist keine Kunst - das geht in C++ genauso einfach)

Warum nicht? Machen die anderen doch auch. Außerdem ist Haskell sehr gut mit Datenstrukturen. C++ würde ziemlich alt gegenüber Haskell aussehen, wenn ich anfangen würde, die B-Tree-Struktur selber zu entwickeln. Aber ich denke, ich nehme mir auch so genug Zeit für das Forum hier.

[Bashar]

ertes schrieb:

Aber ich denke, ich nehme mir auch so genug Zeit für das Forum hier.

Sehr gut, kannst du noch etwaszum Thema Webentwicklung mit Haskell oder Racket sagen?

[ertes]

Bashar schrieb:

ertes schrieb:

Aber ich denke, ich nehme mir auch so genug Zeit für das Forum hier.

Sehr gut, kannst du noch etwaszum Thema Webentwicklung mit Haskell oder Racket sagen?

Nunja, ich habe bisher nur gesagt, dass es möglich ist. Ich hoffe, du fragst aus Interesse und nicht aus dem Druck heraus, den Flamewar fortzusetzen.

Für Haskell gibt es ein paar Web-Frameworks, darunter (alphabetisch) Happstack, Salvia und Yesod. Ich persönlich bevorzuge Yesod, da es mehr Integration bietet und speziell für zügige, sichere Webprogrammierung entwickelt wurde. Es basiert auf dem MVC-Pattern.

Racket kommt mit einem eigenen Web-Framework, das auf einem ganz eigenen Design-Pattern basiert. Es benutzt das in Scheme fest verdrahtete Konzept der Continuations. Auch eine sehr geniale Idee, die ebenfalls rapide Webentwicklung ermöglicht.

Was man aber bedenken muss: Die Wege, die Haskell und Racket im Webbereich gehen, unterscheiden sich grundlegend von dem, was man von den gängigen Sprachen gewohnt ist.

[Zeus]

Sieht aus wie Nischen-Frameworks aus, Schade

[!rr!rr_.]

@!rr!rr_.: Ich war schneller. Und wieder ist mein Code kürzer.

der Vergleich ist unfair - Smalltalk ist eine OO-Sprache und macht Funktionales wie den qsort-Einzeiler nur im Nebenjob und dabei trotzdem eine sehr gute Figur.

Für haskell dagegen ist Funktionales der Hauptjob. Kann haskell ebensogut OO wie smalltalk Funktional kann?

[Bashar]

ertes schrieb:

Nunja, ich habe bisher nur gesagt, dass es möglich ist. Ich hoffe, du fragst aus Interesse und nicht aus dem Druck heraus, den Flamewar fortzusetzen.

Der Flamewar interessiert mich nicht. Ich hab nur schonmal was von diesem Continuation-basierten Ansatz gehört (leider nicht vertieft) und mich gefragt, ob es in Haskell ähnlich gemacht wird oder ob es andere Haskell-spezifische Techniken, die einem dabei helfen können, gibt.

Für Haskell gibt es ein paar Web-Frameworks, darunter (alphabetisch) Happstack, Salvia und Yesod. Ich persönlich bevorzuge Yesod, da es mehr Integration bietet und speziell für zügige, sichere Webprogrammierung entwickelt wurde. Es basiert auf dem MVC-Pattern.

Schau ich mir mal an.

[volkard]

ertes schrieb:

Außerdem ist Haskell sehr gut mit Datenstrukturen. C++ würde ziemlich alt gegenüber Haskell aussehen, wenn ich anfangen würde, die B-Tree-Struktur selber zu entwickeln. Aber ich denke, ich nehme mir auch so genug Zeit für das Forum hier.

Vermutlich wieder ist Haskell deutlich "schneller" aber wenn man dann tatsächlich mal nachmißt, ist es hoffnungslos lahm, aber mit "schneller" war in Wirklichkeit schon die ganze Zeit gemeint, daß man den Code schneller eingetippt hat.

[ertes]

Zeus schrieb:

Sieht aus wie Nischen-Frameworks aus, Schade

Natürlich sind die Frameworks nicht weit verbreitet, aber deswegen sind sie nicht ungeeignet. Wenn du Interesse hast, einfach mal ausprobieren. Ich wüsste nicht, was etwa in Yesod schwerer/komplizierter zu realisieren sein könnte als in irgendeinem anderen Framework.

!rr!rr_. schrieb:

@!rr!rr_.: Ich war schneller. Und wieder ist mein Code kürzer.

der Vergleich ist unfair - […]

Ich wollte nur ein Bisschen darauf herumreiten. Allerdings muss ich ehrlich sagen, aus der Smalltalk-Syntax werde ich nicht schlau, ohne davor irgendein Tutorial gelesen zu haben.

Bashar schrieb:

Der Flamewar interessiert mich nicht. Ich hab nur schonmal was von diesem Continuation-basierten Ansatz gehört (leider nicht vertieft) und mich gefragt, ob es in Haskell ähnlich gemacht wird oder ob es andere Haskell-spezifische Techniken, die einem dabei helfen können, gibt.

Haskell macht es ganz anders und jedes Framework hat sein eigenes Konzept. Yesod etwa benutzt die guten alten Monaden (die Antwort wird nach bestimmten Regeln berechnet), während Happstack mit Monoiden arbeitet (es gibt den Null-Webserver, der immer 404 zurückgibt, und eine Webapplikation ist eine Summe von Webservern). Salvia habe ich mir noch nicht angesehen.

Das CPS-Konzept von Racket finde ich eigentlich echt genial. Es ist prinzipiell möglich, das auch in Haskell zu bekommen, aber bisher habe ich noch keine praktischen Ansätze gesehen.

volkard schrieb:

Vermutlich wieder ist Haskell deutlich "schneller" aber wenn man dann tatsächlich mal nachmißt, ist es hoffnungslos lahm, aber mit "schneller" war in Wirklichkeit schon die ganze Zeit gemeint, daß man den Code schneller eingetippt hat.

Dumme, zusammenhanglose Behauptung. Bleib sachlich oder halt dich einfach raus.

[volkard]

ertes schrieb:

volkard schrieb:

Vermutlich wieder ist Haskell deutlich "schneller" aber wenn man dann tatsächlich mal nachmißt, ist es hoffnungslos lahm, aber mit "schneller" war in Wirklichkeit schon die ganze Zeit gemeint, daß man den Code schneller eingetippt hat.

Dumme, zusammenhanglose Behauptung. Bleib sachlich oder halt dich einfach raus.

Verzichte doch einfach auf die unpassenden Seitenhiebe gegen C++.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all

[Zeus]

ertes schrieb:

Zeus schrieb:

Sieht aus wie Nischen-Frameworks aus, Schade

Natürlich sind die Frameworks nicht weit verbreitet, aber deswegen sind sie nicht ungeeignet. Wenn du Interesse hast, einfach mal ausprobieren. Ich wüsste nicht, was etwa in Yesod schwerer/komplizierter zu realisieren sein könnte als in irgendeinem anderen Framework.

Hauptsache verteidigen? Es geht mir nicht um den Punkt, dass die Frameworks verbreitet sind oder weniger Funktionalität bieten. Aber wenn man Infrastruktur- und Business-Anwendung in einem Guss entwickelen muss, dann wird das Framework eine Nische bleiben.

[ertes]

volkard schrieb:

ertes schrieb:

volkard schrieb:

Vermutlich wieder ist Haskell deutlich "schneller" aber wenn man dann tatsächlich mal nachmißt, ist es hoffnungslos lahm, aber mit "schneller" war in Wirklichkeit schon die ganze Zeit gemeint, daß man den Code schneller eingetippt hat.

Dumme, zusammenhanglose Behauptung. Bleib sachlich oder halt dich einfach raus.

Verzichte doch einfach auf die unpassenden Seitenhiebe gegen C++.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all

Wenn ich mir den entsprechenden Haskell-Code anschaue, wundert mich das Ergebnis nicht. Mich würde derselbe Benchmark mit Data.IntSet interessieren. Dass eine schlechte Haskell-Implementierung nicht schneller als eine optimierte C++-Implementierung ist, kann ich nachvollziehen. Um optimierte Datenstrukturen in Haskell zu implementieren, sollte man die Sprachsemantik erst mal verstanden haben. Die Art, auf die der Baum im Shootout in Haskell implementiert wurde, bedeutet, dass für jede verändernde Operation der gesamte Baum kopiert werden muss. Das verraten schon die Ausrufezeichen in dieser Zeile:

data Tree = Nil | Node !Int !Tree !Tree

Der Shootout ist eben kein Sprachvergleich, sondern ein Implementierungsvergleich. So. Was hat jetzt dein Link für einen Inhalt gehabt? Keinen.

Zeus schrieb:

Hauptsache verteidigen?

Ich denke, ich bin hier einer der Wenigen, die stets objektiv bleiben. Wenn du den Thread verfolgt hast, wirst du festgestellt haben, dass ich Haskell (oder Racket oder was auch immer) durchaus nicht in jeder Hinsicht verteidigt habe.

Es geht mir nicht um den Punkt, dass die Frameworks verbreitet sind oder weniger Funktionalität bieten. Aber wenn man Infrastruktur- und Business-Anwendung in einem Guss entwickelen muss, dann wird das Framework eine Nische bleiben.

Sie werden nicht viel genutzt werden, da es eben immer noch Haskell/Racket ist. Das sagt aber nichts über die Frameworks als Solche aus. Das war meine Aussage. Nicht mehr, nicht weniger.

[currywurst]

ertes schrieb:

Aber ich denke, ich nehme mir auch so genug Zeit für das Forum hier.

Ich habe mir die Zeit genommen, den Thread durchzulesen und mich hast du davon überzeugt, Haskell zu lernen. Vielen Dank dafür!

[otze]

ertes schrieb:

data Tree = Nil | Node !Int !Tree !Tree

Der Shootout ist eben kein Sprachvergleich, sondern ein Implementierungsvergleich. So. Was hat jetzt dein Link für einen Inhalt gehabt? Keinen.

Das ganze wird in dem Moment ein Sprachvergleich, sobald kein Programmeirer mehr in de rLage ist, in den jeweiligen Sprachen ein schnelleres Programm zu erzeugen. Also, wenn du dich darüber beschweren kannst, kannst du als Haskell Jünger doch sicher ein schnelleres Programm erzeugen.

[CStoll]

ertes schrieb:

CStoll schrieb:

OK, wir haben eine Funktion sqrt(), die nur positive Zahlen als Parameter entgegennimmt, eine Funktion arcsin(), die nur Zahlen im Bereich [-1,1] akzeptiert und einige weitere die auch ihre jeweiligen Einschränkungen haben. Und aus diesen Funktionen wollen wir nun komplexere Funktionen zusammenbauen (z.B. die pq-Formel für quadratische Gleichungen). Allerdings kannst du bei den meisten Funktionen nicht garantieren, daß ihre Werte in einem bestimmten Bereich bleiben, d.h. du mußt die zusammengesetzte Funktion mit Fallunterscheidungen spicken, um die Wertebeschränkungen sicherzustellen.

Nein, die Funktionen kannst du zusammensetzen, wie du willst, solange die Typen passen. Es kommt auf die Werte an, die in das System geschickt werden. Aber ist auch egal, denn sowas zu bewerkstelligen ist in Haskell zu aufwendig, um praktikabel sein. Ich sage es jetzt zum letzten mal und werde dann auch nicht weiter auf das Thema eingehen: Haskell ist nicht dafür geeignet, numerische Korrektheit von Formeln zu beweisen. Es ist möglich, aber viel zu aufwendig. Schau dir Agda und Coq an, wenn dich das Thema interessiert. Thema ist meinerseits beendet.

Du hast mir immer noch nicht verraten, welchen Typ und welche Definition eine Subtraktionsmethode haben muß, um vom Compiler sicherstellen zu lassen, daß der Ausdruck "sqrt(x-y)" immer gültige Werte erhält.

Du hast einige Begriffe in den Raum geworfen.

Nun, ich traue den meisten hier zu, eine Suchmaschine richtig zu benutzen. Aber ich habe auch schon Links gepostet. Du wolltest z.B. praktischen, produktiven Code sehen. Ich habe dir welchen verlinkt. Plötzlich gings du überhaupt nicht mehr darauf ein. Du gehst nur auf die Themen ein, in denen du vermutest, dass du mir widersprechen und/oder Haskell in den Boden stampfen kannst. Hat es dich so erschreckt, dass richtige Real World-Bibliotheken in Haskell gibt, und dass man mit denen tatsächlich produktiv arbeiten kann?

Wenn ich z.B. den Begriff GADT an Google verfüttere, bekomme ich einiges, wa aber entweder nichts mit Haskell zu tun hat oder für einen Außenstehenden völlig unverständlich ist. Das Konzept von Phantomtypen kann man damit eventuell verstehen, aber wie diese mit den reellen Typen interagieren ist nicht wirklich klar.
(du kannst ja gerne deinen Code posten, mit dem du Sortiertheit bewiesen hast)

Das letzte, was du verlinkt hast, war der Artikel über das "Blub-Paradoxon".

Und eventuell solltest du meine Bemerkungen auch zu Ende lesen. Klar kannst du deine Typen und Funktionen so weit einschränken, daß sie nur auf eine bestimmte Art verwendet werden können, aber was für einen Sinn macht das? Und solange die beteiligten Ausdrücke mit den selben Typen zusammenpassen, wird dein Compiler keinen Unterschied bemerken.

So ist es. Und wenn du den Sinn darin nicht siehst, dann hat es keinen Wert, darüber zu diskutieren. Du kannst in Haskell viele statische Garantien erreichen, die in C++ undenkbar sind, aber es hat keinen Wert, dir das näherzubringen. Einerseits bist du versteift in deiner Überzeugung, andererseits bist du aber nicht bereit, Haskell erst mal wirklich auszuprobieren, bevor du urteilst.

Wenn ich wirklich Wert darauf legen würde, könnte ich auch zwei Dutzend Hilfstypen definieren und passende Funktionen definieren, so daß es genau EINE legale Reihenfolge gibt, diese Typen zusammenzufassen. Das hindert mich aber in C++ genausowenig wie in Haskell daran, die verwendeten Werte ans Limit auszureizen.

Wie schon gesagt: Ich kenne C++ und Haskell, beide aus mehrjähriger Erfahrung. Du kennst nur C++ und zeigst keine Bereitschaft, das zu ändern. Somit ist die ganze Diskussion, die wir führen, Zeitverschwendung.

Ich hatte während des Studiums kurze Berührungspunkte mit Haskell, aber es danach nicht wieder gebraucht. Inzwischen muß ich mit dem auskommen, was mein Arbeitgeber nutzt (nein, das ist nicht C++, sondern schlimmer).
Und ich bin durchaus bereit zuzugeben, daß Haskell seine Vorteile hat, aber es hat auch Schwächen - und vor allem habe ich bislang immer noch gehofft, konstruktive Argumente von dir zu hören anstatt plumber Schlagworte.

Bitte schön, hier der Haskell-Code dazu: […]

Und wie sieht der in der Anwendung aus?

Nicht anders als bei entsprechenden C/C++/Ruby/Smalltalk-Bibliotheken, außer dass diese Bibliothek effektfrei ist. Beispiel:

newHeaders = M.insert "Content-type" "text/plain" oldHeaders

Wenn man seinen Code richtig funktional schreibt, sieht man da aber meistens nur entweder auf der rechten oder auf der linken Seite einen Namen, etwa wenn man mit StateT arbeitet: modify (M.insert "Content-type" "text/plain") .

(PS: eine vorgefertigte Library zu verwenden ist keine Kunst - das geht in C++ genauso einfach)

Wenn du deine import-Anweisung als vollwertiges Programm ansiehst, das geht im C++ übrigens genauso schnell:

#include <map>

Und übrigens ist dein Anwendungsbeispiel alles andere als typsicher.

[!rr!rr_.]

Wenn du deine import-Anweisung als vollwertiges Programm ansiehst, das geht im C++ übrigens genauso schnell:

#include <map>

so lang .. ? in smalltalk geht das kürzer:

kein Witz - Dictionaries sind für gewöhnlich schon out-of-the-box in der Klassenhierarchie im Image.

[ertes]

currywurst schrieb:

Ich habe mir die Zeit genommen, den Thread durchzulesen und mich hast du davon überzeugt, Haskell zu lernen. Vielen Dank dafür!

Gerne, aber nimm viel Zeit mit.

otze schrieb:

Das ganze wird in dem Moment ein Sprachvergleich, sobald kein Programmeirer mehr in de rLage ist, in den jeweiligen Sprachen ein schnelleres Programm zu erzeugen. Also, wenn du dich darüber beschweren kannst, kannst du als Haskell Jünger doch sicher ein schnelleres Programm erzeugen.

Natürlich. Es hat schließlich kein Haskell-Programmierer etwas Besseres zu tun als den ganzen Tag im Shootout irgendwelchen C++-Fanatikern irgendwas zu beweisen. Gute C++-Programmierer gibt es im Vergleich zu guten Haskell-Programmierern wie Sand am Meer. Die Handvoll der Letzteren, die es gibt, scheren sich einen Dreck um deine oder volkards Meinung.

CStoll schrieb:

Wenn ich z.B. den Begriff GADT an Google verfüttere, bekomme ich einiges, wa aber entweder nichts mit Haskell zu tun hat oder für einen Außenstehenden völlig unverständlich ist. Das Konzept von Phantomtypen kann man damit eventuell verstehen, aber wie diese mit den reellen Typen interagieren ist nicht wirklich klar.

Natürlich kannst du GADTs nicht verstehen, wenn du das Typensystem von Haskell nicht verstehst. Phantomtypen, oder eigentlich eher Phantomtypparameter, sind nichts Besonderes. Das sind einfach nur Parameter eines Typs, die keine Laufzeitfunktion haben. Das heißt, es existieren zur Laufzeit keine konkreten Werte dieses Typs. Mit GADTs haben Phantomtypen nicht viel zu tun, aber sie werden gerne kombiniert.

Das letzte, was du verlinkt hast, war der Artikel über das "Blub-Paradoxon".

Falsch. Den solltest du dir aber dennoch durchlesen. Du leidest nämlich im Moment an genau diesem Paradoxon, so wie viele andere hier.

Ich hatte während des Studiums kurze Berührungspunkte mit Haskell, aber es danach nicht wieder gebraucht. Inzwischen muß ich mit dem auskommen, was mein Arbeitgeber nutzt (nein, das ist nicht C++, sondern schlimmer).
Und ich bin durchaus bereit zuzugeben, daß Haskell seine Vorteile hat, aber es hat auch Schwächen - und vor allem habe ich bislang immer noch gehofft, konstruktive Argumente von dir zu hören anstatt plumber Schlagworte.

Ich habe konstruktive Argumente geliefert, aber es bringt nichts, wenn du mit ihnen nichts anfangen kannst. Vieles von dem, was ich schreibe, kannst du doch gar nicht nachvollziehen, ohne Haskell zu kennen. Wenn du bereit bist, Haskell richtig zu lernen, bin ich auch gerne wieder bereit, mit dir über statische Garantien zu diskutieren. Vorher musst du aber die Basics können, denn sonst ist die Diskussion für mich einfach nur ermüdend und macht keinen Spaß. Ich poste dir proof of concept-Code, du widersprichst trotzdem, weil das in deinen C++-Verstand einfach nicht reingeht. Deswegen gehe ich vorerst – wie angekündigt – auch konsequent auf nichts mehr ein, was mit diesem Thema zu tun hat.

Wenn du deine import-Anweisung als vollwertiges Programm ansiehst, das geht im C++ übrigens genauso schnell:

#include <map>

Und übrigens ist dein Anwendungsbeispiel alles andere als typsicher.

Ja? Vielleicht möchtest du diese Behauptung mit Argumenten oder Beispielen untermauern.

[CStoll]

ertes schrieb:

CStoll schrieb:

Wenn ich z.B. den Begriff GADT an Google verfüttere, bekomme ich einiges, wa aber entweder nichts mit Haskell zu tun hat oder für einen Außenstehenden völlig unverständlich ist. Das Konzept von Phantomtypen kann man damit eventuell verstehen, aber wie diese mit den reellen Typen interagieren ist nicht wirklich klar.

Natürlich kannst du GADTs nicht verstehen, wenn du das Typensystem von Haskell nicht verstehst. Phantomtypen, oder eigentlich eher Phantomtypparameter, sind nichts Besonderes. Das sind einfach nur Parameter eines Typs, die keine Laufzeitfunktion haben. Das heißt, es existieren zur Laufzeit keine konkreten Werte dieses Typs. Mit GADTs haben Phantomtypen nicht viel zu tun, aber sie werden gerne kombiniert.

Dann erklär's mir doch mal an einem praktischen Beispiel - bei den arithmetischen Funktionen hast du schließlich schon wieder einen Rückzieher gemacht.

Das letzte, was du verlinkt hast, war der Artikel über das "Blub-Paradoxon".

Falsch. Den solltest du dir aber dennoch durchlesen. Du leidest nämlich im Moment an genau diesem Paradoxon, so wie viele andere hier.

Was dann? Wenn du nicht ein Doppelgänger von knivil oder volkard bist (was ich mal nicht hoffe), war das hier der letzte Beitrag, wo du etwas verlinkt hast.

Ich habe konstruktive Argumente geliefert, aber es bringt nichts, wenn du mit ihnen nichts anfangen kannst. Vieles von dem, was ich schreibe, kannst du doch gar nicht nachvollziehen, ohne Haskell zu kennen. Wenn du bereit bist, Haskell richtig zu lernen, bin ich auch gerne wieder bereit, mit dir über statische Garantien zu diskutieren. Vorher musst du aber die Basics können, denn sonst ist die Diskussion für mich einfach nur ermüdend und macht keinen Spaß. Ich poste dir proof of concept-Code, du widersprichst trotzdem, weil das in deinen C++-Verstand einfach nicht reingeht. Deswegen gehe ich vorerst – wie angekündigt – auch konsequent auf nichts mehr ein, was mit diesem Thema zu tun hat.

Du postest Fragmente und wenn dich jemand um Details oder Ergänzungen bittet, tust du es mit einem "kann man machen" ab. Und mit deinen Ergüssen hast du bei mir (leider) das genaue Gegenteil erreicht wie bei currywurst. Ich hoffe, bei unserer nächsten Begegnung geht es um etwas, wo du eher gesprächsbereit bist.

PS: Und kein System der Welt kann dir Garantien bieten, die mathematisch nicht realisierbar sind.

[!rr!rr_.]

man fragt sich, ob Typsicherheit überhaupt diesen unglaublichen Aufwand wert ist.

Ich kann mich jedenfalls nicht erinnern, wann ich zuletzt einen Typfehler bei der Programmierung mit einer dynamisch typisierten Programmiersprache hatte - in den letzten 4 Jahren mit Sicherheit kein einziges Mal.

Und selbst wenn, dann kann man diese Gefahr (und viele andere mögliche Fehlerquellen) minimieren durch sprechende Bezeichner und vor allem durch feinkörnige Unit-Tests, die synchron mit dem Sourcecode aufgebaut werden.

[GPC]

!rr!rr_. schrieb:

man fragt sich, ob Typsicherheit überhaupt diesen unglaublichen Aufwand wert ist.

Ich kann mich jedenfalls nicht erinnern, wann ich zuletzt einen Typfehler bei der Programmierung mit einer dynamisch typisierten Programmiersprache hatte - in den letzten 4 Jahren mit Sicherheit kein einziges Mal.

Und selbst wenn, dann kann man diese Gefahr (und viele andere mögliche Fehlerquellen) minimieren durch sprechende Bezeichner und vor allem durch feinkörnige Unit-Tests, die synchron mit dem Sourcecode aufgebaut werden.

Ack. Statische Typisierung ist zwar ganz nett, um die gröbsten Fehler rauszuhalten und den Programmierer vor sich selbst zu schützen, aber ansonsten find ich's eher lächerlich, wie da manche drauf abgehen, als sei es das Allheilmittel der Programmierung

[hustbaer]

!rr!rr_. schrieb:

Wenn du deine import-Anweisung als vollwertiges Programm ansiehst, das geht im C++ übrigens genauso schnell:

#include <map>

so lang .. ? in smalltalk geht das kürzer:

kein Witz - Dictionaries sind für gewöhnlich schon out-of-the-box in der Klassenhierarchie im Image.

So lang ...? Einen gleichwertigen Beitrag zur Diskussion kann ich so machen:

Kein Witz - deine Beiträge sind für gewöhnlich ausser sinnlos nur noch sinnlos.