Ist das Typensystem von Haskell ein Hindernis für das Verständnis der funktionalen Programmierung? [geschlossen]

Ich studiere Haskell, um die funktionale Programmierung zu verstehen, mit der Erwartung, dass ich die Erkenntnisse, die ich in anderen Sprachen erhalte, anwenden werde (hauptsächlich Groovy, Python, JavaScript).

Ich habe mich für Haskell entschieden, weil ich den Eindruck hatte, dass es sehr rein funktional ist und kein Vertrauen in den Staat zulässt.

Ich habe mich nicht für Haskell entschieden, weil ich an der Navigation in einem extrem starren Typensystem interessiert war.

Meine Frage lautet: Ist ein starkes Typsystem ein notwendiges Nebenprodukt einer extrem reinen funktionalen Sprache, oder handelt es sich hierbei um eine Design-Wahl, die nichts mit Haskell zu tun hat?

Ich glaube, dass das Verständnis von Haskells Typsystem ein Verstärker für das Verständnis der funktionalen Programmierung ist.

Die Sache mit der rein funktionalen Programmierung ist, dass ohne Nebenwirkungen, mit denen Sie alle möglichen Dinge implizit ausführen können, die Struktur Ihrer Programme durch die rein funktionale Programmierung viel deutlicher wird.

Haskell hindert Sie daran, Dinge unter den Teppich zu schieben, zwingt Sie, sich explizit mit der Struktur Ihres Programms zu befassen, und bringt Ihnen eine Sprache bei, die diese Strukturen beschreibt: die Sprache der Typen. Das Verstehen von Typen, insbesondere von umfangreichen Typen wie Haskell, macht Sie zu einem besseren Programmierer in jeder Sprache.

Wenn Haskell nicht stark typisiert wäre, wären Konzepte wie Monaden, anwendbare Funktoren und dergleichen niemals auf die Programmierung angewendet worden.

Die am dynamischsten typisierte funktionale Sprache ist wohl Scheme. Das heißt, Haskells Typensystem ist ein Indikator für seine Reinheit. Es geht um die Frage "Wie misst man Reinheit?". Mit dem Typensystem von Haskell können Sie unreine Vorgänge auf einfache Weise absperren IO. Dazu benötigen Sie ein statisches Typsystem.

Nehmen wir an, das Typensystem von Haskell hat nichts mit funktionaler Programmierung zu tun. Es wäre immer noch ein Hochkonjunktur, zu behaupten, dass das Typensystem Ihnen bei diesem pädagogischen Unterfangen nicht helfen würde. Das Typensystem von Haskell ist umfangreich und komplex und umso interessanter im Vergleich zu den Typensystemen von C ++ und OCaml.

Ist es ein Hindernis? Nein, ich denke es ist eine Bereicherung. Versuchen Sie zu überlegen, wie Sie mit Haskells Faulheit umgehen sollen, ohne IOzum Beispiel.

Clojure ist dynamisch geschrieben und fast so rein wie Haskell. Es gibt also ein gutes Argument dafür, dass das Typensystem von Haskell eher eine Designentscheidung als eine absolute Anforderung war. Beide haben definitiv ihre Stärken, also sollten Sie Clojure in Betracht ziehen, wenn Sie Haskells Starrheit wirklich nicht mögen (siehe unten).

Als ich anfing, Haskell zu verwenden, empfand ich das Typensystem als störend und tolerierte es nur wegen der Typinferenz. Ich stellte bald fest, dass viele der vom Compiler beklagten Tippfehler ohnehin nicht funktionierten, selbst wenn der Compiler sie mir überlassen hätte (z. B. versehentlich map anstelle von concatMap verwenden). Dann stellte ich fest, dass Programme, die die Typprüfung bestanden hatten, normalerweise korrekt oder zumindest nahezu korrekt waren. Ich hatte sogar eine träge Phase, in der ich ein Refactoring durchgeführt habe, indem ich einen Funktionstyp geändert und den Compiler sagen ließ, was noch geändert werden musste. Schließlich wurde mir klar, dass Haskells Schriftsystem tatsächlich sehr aussagekräftig war, und ich begann, meine Programme mit Schriften zu gestalten. Das ist der Heilige Gral von Haskell.

Das Typensystem von Haskell ist der Schlüssel für die Fähigkeit, Effekte von reinem Code zu isolieren. Wenn Sie Effekte nicht auf andere Weise isolieren oder vollständig entfernen können, ist ein starkes statisches Typsystem eine Voraussetzung für reine Funktionsprogrammierung.

Haskell ist ein sehr gutes Beispiel für eine Sprache mit einem starken statischen Typensystem. Wenn Sie eine breite und umfassende Ausbildung in Informatik und insbesondere in der Gestaltung von Programmiersprachen wünschen, ist Haskell eine ausgezeichnete Wahl für eine der Sprachen, die Sie lernen sollten.

Das Typensystem sollte kein großes Hindernis sein. Menschen, die programmieren, befolgen selbst bei der Verwendung dynamischer Sprachen in der Regel Typisierungskonventionen, die mit dem Haskell-Typensystem codiert werden können. Haskell bietet auch eine Typinferenz, die die Ausführlichkeit im Vergleich zu Sprachen wie C ++ und Java verringert. Wenn Sie eine Fehlermeldung erhalten, teilt Ihnen der Compiler nur zur Kompilierungszeit mit, was eine Sprache mit dynamischen Typen Ihnen zur Laufzeit mitteilen würde.

Das Gegenteil eines dynamischen Typsystems ist ein statisches Typsystem, kein starkes Typsystem. Ein starkes Typensystem ist das Gegenteil eines schwachen Typensystems.

Es sagt Ihnen sofort, wenn Sie dumme Fehler machen. Das ist hilfreich. Ich habe in diesem letzten Semester in Racket (Schema) gearbeitet, und es gab einige Male, in denen ich einen nicht analysierten s-exp bestanden habe, bei dem ich einen analysierten ast für eine Funktion in meinem Interpreter erwartet habe, und er erschien nur in meinem mittelgroße Testsuite. Wenn ich statisch getippt hätte, wäre ich sofort darauf aufmerksam geworden.

Natürlich können logische Fehler nicht wirklich vom Typensystem erfasst werden, aber die Anzahl der Möglichkeiten, wie Sie Fehler machen können, ist erheblich verringert.

Wenn Sie möchten, können Sie das Typensystem auch über die Typinferenz ignorieren. Es ist immer noch da, aber es erfordert keinen aktiven Input von Ihrer Seite. Es ist immer noch hilfreich, die Arten Ihrer Funktionen zu verstehen, aber der richtige Code wird gut funktionieren.

Die Reinheit von Haskell ist in seinem Typensystem kodiert. Die E / A-Monade ist ein Konstrukt auf Typebene, das verhindert, dass unreiner Code in reine Funktionen gelangt, sodass die Reinheit durch das Typsystem garantiert wird.

Als "funktionale" Sprache bedeutet dies (neben anderen Dingen), dass Funktionen erstklassige Objekte in der Sprache sind.

Eine "reine" Sprache zu sein bedeutet, dass Funktionen mathematische Funktionen sind (im Gegensatz zu Prozeduren) - bei gleicher Eingabe erzeugen sie immer die gleiche Ausgabe.

Eine "reine Funktionssprache" ist eine Sprache, in der beide oben genannten Aussagen zutreffen. Ich bin mir nicht bewusst eine „rein- ly funktionalen Sprache“.

Ein starkes Typensystem ist eine saubere Möglichkeit, eine reine und dennoch praktische Sprache zu haben. Die Typen helfen dem Compiler, Optimierungen herauszufinden, abgesehen davon, um die Korrektheit weiter zu gewährleisten. (Aber das ist nicht der einzige Weg - Clojure ist rein, hat aber kein so starkes Typensystem wie Haskell.)

Wenn Sie das Typsystem stört, empfehle ich Ihnen, eine dynamischere Sprache wie Scheme zu verwenden oder Haskells Typinferenzsystem zu verwenden.

Ja, das Typensystem ist eine unglaubliche Bereicherung. Es wäre sehr schwierig zu beschreiben, wie Monaden funktionieren oder wie einige Kombinatoren ohne das Typsystem arbeiten. Überlegen Sie, wie viele Tutorials in Haskell Sie zuerst auffordern, den Typ der betreffenden Funktion mit einem: t an der REPL zu prüfen. Das steht Ihnen in einer dynamisch getippten Sprache einfach nicht zur Verfügung. Klar, die ganze Komplexität des Typensystems ist noch da. Eine Monade ist immer noch eine Monade. Aber die Sprache hat beschlossen, sich die Hände zu waschen und überhaupt keine Hilfe zu leisten. Du bist auf dich allein gestellt, Kumpel. Ich klopfe nicht an dynamisch getippte Sprachen. Ich liebe sie sehr. Schema ist ein Elektrowerkzeug schlechthin. Sie werden jedoch feststellen, dass wir häufig eine Notation erfinden , wenn wir über Dinge wie Monaden in dynamischen Sprachen sprechenzur Beschreibung der Verfahrensarten. Ein funktionaler Programmierer kämpft auf die eine oder andere Weise mit Typen. Haskells Typprüfung gibt Ihnen nur gute Werkzeuge, um zu lernen, wie man das macht.