Haskell, Lisp und Ausführlichkeit [geschlossen]

Ich bin gespannt, wie "angenehm" (um einen schrecklichen Begriff zu verwenden) es ist, Code in Haskell vs. Lisp zu schreiben.

Einige Hintergrundinformationen: Ich lerne jetzt Haskell, nachdem ich zuvor mit Scheme und CL gearbeitet habe (und einen kleinen Ausflug in Clojure). Traditionell könnte man mich wegen der Prägnanz und Schnelligkeit, die sie bieten, als Fan dynamischer Sprachen betrachten. Ich habe mich schnell in Lisp-Makros verliebt, da es mir eine weitere Möglichkeit gab, Ausführlichkeit und Boilerplate zu vermeiden.

Ich finde Haskell unglaublich interessant, da es mich in Codierungsmethoden einführt, von denen ich nicht wusste, dass sie existieren. Es hat definitiv einige Aspekte, die dazu beitragen, Agilität zu erreichen, wie das einfache Schreiben von Teilfunktionen. Ich bin jedoch ein bisschen besorgt über den Verlust von Lisp-Makros (ich nehme an, ich verliere sie; um ehrlich zu sein, ich habe vielleicht noch nichts davon erfahren?) Und das statische Typisierungssystem.

Würde es jemandem, der in beiden Welten eine anständige Menge an Codierung durchgeführt hat, etwas ausmachen, zu kommentieren, wie sich die Erfahrungen unterscheiden, was Sie bevorzugen und ob diese Präferenz situativ ist?

Kurze Antwort:

• Fast alles, was Sie mit Makros tun können, können Sie mit einer Funktion höherer Ordnung tun (und ich schließe Monaden, Pfeile usw. ein), aber es erfordert möglicherweise mehr Nachdenken (aber nur beim ersten Mal, und es macht Spaß und Sie werden ein besserer Programmierer dafür) und
• Das statische System ist so allgemein gehalten, dass es Ihnen nie im Weg steht, und es ist überraschenderweise tatsächlich "hilfreich, um Agilität zu erreichen" (wie Sie sagten), denn wenn Ihr Programm kompiliert wird, können Sie fast sicher sein, dass es korrekt ist, sodass Sie es mit dieser Gewissheit versuchen können Dinge heraus, vor denen Sie sonst Angst haben könnten - es gibt ein "dynamisches" Gefühl beim Programmieren, obwohl es nicht dasselbe ist wie bei Lisp.

[Hinweis: Es gibt eine " Vorlagen-Haskell ", mit der Sie Makros wie in Lisp schreiben können, aber genau genommen sollten Sie sie niemals benötigen .]

Machen Sie sich zunächst keine Sorgen, dass Sie bestimmte Funktionen wie die dynamische Eingabe verlieren. Da Sie mit Common Lisp, einer bemerkenswert gut gestalteten Sprache, vertraut sind, ist Ihnen vermutlich bewusst, dass eine Sprache nicht auf ihre Funktionen reduziert werden kann. Es geht um ein zusammenhängendes Ganzes, nicht wahr?

In dieser Hinsicht leuchtet Haskell genauso hell wie Common Lisp. Die Funktionen bieten Ihnen eine Programmiermöglichkeit, die den Code extrem kurz und elegant macht. Das Fehlen von Makros wird durch ausgefeiltere (aber ebenfalls schwerer zu verstehende und zu verwendende) Konzepte wie Monaden und Pfeile etwas gemildert. Das statische Typsystem erhöht Ihre Leistung, anstatt sich wie in den meisten objektorientierten Sprachen in den Weg zu stellen.

Andererseits ist das Programmieren in Haskell viel weniger interaktiv als in Lisp, und die enorme Menge an Reflexion in Sprachen wie Lisp passt einfach nicht zu der statischen Sicht der Welt, die Haskell voraussetzt. Die Ihnen zur Verfügung stehenden Werkzeugsätze unterscheiden sich daher erheblich zwischen den beiden Sprachen, sind jedoch schwer miteinander zu vergleichen.

Ich persönlich bevorzuge die Lisp-Programmierweise im Allgemeinen, da sie meiner Meinung nach besser zu meiner Arbeitsweise passt. Dies bedeutet jedoch nicht, dass Sie dazu verpflichtet sind.

In Haskell ist weniger Metaprogrammierung erforderlich als in Common Lisp, da vieles um Monaden herum strukturiert werden kann und die hinzugefügte Syntax eingebettete DSLs weniger baumartig aussehen lässt, aber es gibt immer Template Haskell, wie von ShreevatsaR erwähnt , und sogar Liskell (Haskell-Semantik + Lisp) Syntax), wenn Sie die Klammern mögen.

In Bezug auf Makros ist hier eine Seite, die darüber spricht: Hallo Haskell, Goodbye Lisp . Es erklärt eine Sichtweise, in der Makros in Haskell einfach nicht benötigt werden. Es kommt mit einem kurzen Beispiel zum Vergleich.

Beispielfall, in dem ein LISP-Makro erforderlich ist, um die Bewertung beider Argumente zu vermeiden:

(defmacro doif (x y) `(if ,x ,y))

Beispielfall, in dem Haskell beide Argumente nicht systematisch bewertet, ohne dass eine Makrodefinition erforderlich ist:

doif x y = if x then (Just y) else Nothing

Und voilà

Ich bin ein Common Lisp-Programmierer.

Nachdem ich vor einiger Zeit Haskell ausprobiert hatte, war es mein persönliches Fazit, bei CL zu bleiben.

Gründe dafür:

• Dynamische Typisierung (siehe Dynamische und statische Typisierung - Eine musterbasierte Analyse von Pascal Costanza )
• optionale und Schlüsselwortargumente
• einheitliche homoikonische Listensyntax mit Makros
• Präfixsyntax (Sie müssen sich keine Vorrangregeln merken)
• unrein und damit eher für schnelles Prototyping geeignet
• Leistungsstarkes Objektsystem mit Metaobjektprotokoll
• reifer Standard
• große Auswahl an Compilern

Haskell hat natürlich seine eigenen Vorzüge und macht einige Dinge auf eine grundlegend andere Art und Weise, aber es schneidet es auf lange Sicht für mich einfach nicht ab.

In Haskell können Sie eine if-Funktion definieren, die in LISP nicht möglich ist. Dies ist aufgrund der Faulheit möglich, die eine größere Modularität der Programme ermöglicht. Dieses klassische Papier: Warum FP wichtig ist von John Hughes, erklärt, wie Faulheit die Kompositionsfähigkeit verbessert.

Es gibt wirklich coole Dinge, die Sie in Lisp mit Makros erreichen können, die in Haskell (wenn möglich) umständlich sind. Nehmen Sie zum Beispiel das "Memoize" -Makro (siehe Kapitel 9 von Peter Norvigs PAIP). Damit können Sie eine Funktion definieren, z. B. foo, und dann einfach auswerten ('foo auswendig lernen'), wodurch die globale Definition von foo durch eine gespeicherte Version ersetzt wird. Können Sie den gleichen Effekt in Haskell mit Funktionen höherer Ordnung erzielen?

Während ich meine Haskell-Lernreise fortsetze, scheint es eine Sache zu sein, die hilft, Makros zu "ersetzen", die Fähigkeit, eigene Infix-Operatoren zu definieren und deren Priorität und Assoziativität anzupassen. Etwas kompliziert, aber ein interessantes System!