Haskell vs Lisp vs Scheme etc für KI usw
-
Danke für die ANtwort!
Somit ist Scheme schonmal aussortiert und es bleiben nur noch Lisp und Haskell.
(Hab leider nicht genug Zeit um erstmal das zu lernen und dann das andere. Lieber gleich voll rein mit der Zielsprache.)Das mit den Scriptsprachen habe ich auch schonmal gehört. Python zb soll einiges von Lisp und funktionaler Programmierung enthalten.
Aber heisst das jetzt, dass Lisp garnicht die KI-Sprache schlechthin ist? Sondern, dass Python genauso gut in dem Bereich ist?Dein letzter Absatz interessiert mich aber sehr: Ist das nur mit Lisp möglich, dass Programme sich selber "programmieren" können? Denn das ist ein großer Vorteil wenns um AI geht.
Oder ist dies auch mit Haskell und Python möglich?
Also ich möcht nochmal direkt frageN:
Wenn wir davon ausgehen dass jemand bereits Python und C beherrscht. Würdet ihr ihm dann empfehlen Lisp oder Haskell zu lernen? Und warum?Es ist für mich wirklich eine schwere Entscheidung da einige von Lisp schwärmen aber die anderen wiederum von Haskell weill es komplett funktional ist...
-
@ borg
Es währe super wenn du das nochmal ein bisschen begründen könntest.
Vor allem da du ja schon einige funktionale Sprachen durch hast. Wohl uach schon Lisp?
Und bei welchen Aufgaben denkst du eine funktionale Sprache währe toll?
Danke im voraus!
-
Gundalf schrieb:
(Hab leider nicht genug Zeit um erstmal das zu lernen und dann das andere. Lieber gleich voll rein mit der Zielsprache.)
Warum? Du solltest sogar auch Scheme lernen.
-
Haskell ist natuerlich auch nicht rein bzw. "komplett" funktional. Das ist aber nicht schlimm, dass das so ist (zum Glueck).
Um es kurz zu machen:
Wenn es dir nur um den Erwerb von Kenntnissen im KI-Bereich geht, wuerde ich zu Lisp raten. Falls du keine Emacs-Kenntnisse hast, rate ich dir im speziellen zu clisp, einer Implementierung von Common Lisp.Falls du "einfach nur" deinen Horizont erweitern willst, ist denke ich angesichts deiner Python-Vorkenntnisse Haskell die vorzuziehende Wahl, da es deutlich weiter von Python entfernt ist als Lisp.
Beim Lernen von Haskell wirst du (ziemlich coole) Sprachfeatures entdecken, die in anderen Sprachen nicht mal ansatzweise vorhanden ist.
-
@ Bashar:
Und warum sollte ich Scheme lernen? Wenn überhaupt, dann währe doch Lisp besser oder?
@ Dr. Prokt
Also ist Lisp doch die beste Sprache für KI? Und das nur wegen der reinen Sytax?
Dieses clisp und auch andere Lisps - sind die weit vom original Lisp (Common Lisp?) entfernt? Oder kann man die anderen auch wenn man das eine kann?Ja, eigentlich geht es mir hauptsächlich darum "meinen Horizont zu erwitern".
Deshalb ist das wieder ein Punkt für Haskell.Aber weiss noch jemand über die Verbreitung und die Einsatzgebiete von Lisp und Haskell bescheid? (KI ist klar)
Welches wird häufiger eingesetzt? Vllt kennt jemand sogar die ganz genauen Einsatzgebiete?Thx!
-
Nunja, Common Lisp ist eine standardisierte Sprace und hat einige bekannte Implementierungen, wie z.B. clisp, sbcl, cmucl, ecl, etc. Die implementieren fast alle den Standard zu 100%. Wenn du allerdings auf implementierungsspezifische Details (zB MOP) zugreifst oder auf Features, die nicht im Standard vorgesehen sind (zB Sockets), unterscheiden sie sich natuerlich schon. Allerdings gibt es fuer letzteren Fall implementierungsuebergreifende Libs, die diese Unterschiede wegabstrahieren. Die Wahl der Implementierung ist also nicht so dramatisch.
Es faellt schwer, Lisp und Haskell direkt miteinander zu vergleichen. Haskell ist im Vergleich zu Lisp eine sehr spezielle spezielle Sprache, geschaffen fuer bestimmte Probleme. Lisp wird hingegen eher nachgesagt, ein "Programmiermedium" zu sein, man kann die Sprache nach seinen Vorstellungen biegen und formen (entsprechende Kenntnisse vorausgesetzt
).Haskell ist eine funktionale Sprache, die zwar aus der Theorie kommt, aber enorm an praktischer Bedeutung gewonnen hat. Sie kann mittlerweile ueberall dort eingesetzt werden, wo Mainstream-Sprachen auch Anwendung finden (es gibt sogar schon ein Mini-Framewort zur Entwicklung dynamischer Webseiten), nur dass man eine neue Sicht auf viele schon bekannte Dinge erhaelt.
Wenn du die Zeit findest, schau dir am besten beides an.
-
ohne nun mit lisp oder haskell übermäßig viel gearbeitet zu haben, kann ich doch sagen, dass bei sprachen grundverschieden sind, auch wenn sie unter dem label "funktional" laufen.
ich glaube, der witz bei lisp ist vorallem, dass man mit lisp - code (sehr vereinfacht gesprochen) wie mit strings umgehen kann, soll heissen, man kann programmcode während der laufzeit automatisch generieren, ändern etc. - und eben auch ausführen lassen. aus dem bauch heraus würde ich sagen, dass das für KI sachen durchaus nützlich sein könnte..
-
lisp ist imho die reinere sprache, von der syntax her. lisp ist reine baumstruktur, reiner code. deswegen kann ein lisp programm auch lisp programme schreiben, die wiederum lisp programme schreiben koennten.
Was erzählst du da eigentlich? Was soll den "unreiner" Code sein? Ich kann dir auch ein Java Programm schreiben, das ein Java Programm schreibt usw....
Meinst du vielleicht das Lisp eine echte funktionale Sprache ist? Also ohne Gedächniss und Seiteneffekten?
-
DEvent schrieb:
Ich kann dir auch ein Java Programm schreiben, das ein Java Programm schreibt usw....
und ich kann mit einem stein eine schraube in die wand hämmern.
-
Doktor Prokt schrieb:
Haskell ist natuerlich auch nicht rein bzw. "komplett" funktional. Das ist aber nicht schlimm, dass das so ist (zum Glueck).
Abgesehen von den Funktionen mit "unsafe"-Prefix ist Haskell tatsächlich rein funktional, sprich völlig seiteneffektfrei; oder ich habe Haskell grundlegend falsch verstanden. Selbst Ein/Ausgabe wie getLine/putStrLn wird über Datenabhängigkeiten dargestellt, nicht über Seiteneffekte.
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt. Auf Haskell-Ebene ist der Code meines Wissens nach jedoch immer seiteneffektfrei (von den "bösen" unsafe-Funktionen abgesehen, die nur äußerst selten gebraucht werden, und AFAIK auch dann nur um bestimmte Komplexitätsklassen zu erreichen). Eine Funktion wie "getLine" liefert zum Beispiel bei jedem Aufruf dasselbe Objekt zurück; das ist der Grund warum getLine nicht einfach einen String liefern kann.
-
DEvent schrieb:
Meinst du vielleicht das Lisp eine echte funktionale Sprache ist? Also ohne Gedächniss und Seiteneffekten?
Das Lisp keine "echte funktionale" Sprache ist, hatten wir doch schon erwähnt? Nicht?
Ansonsten fällt es sicher schwer Lisp ohne Lisp Kenntnisse zu bewerten und wie groß sind bitte deine Lisp-Kenntnisse?
-
Christoph schrieb:
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt.
Jo, darauf wollte ich auch nicht abzielen, ganz so kleinlich bin ich dann doch nicht
Ich sehe ein Problem bei der IO Monad. Wenn zum Beispiel eine hypothetische Funktion getLine ein IO String zurueckgibt, so gibt es sehrwohl viele Werte, welche eben diesen Typ haben.
-
Doktor Prokt schrieb:
Christoph schrieb:
Dass der Compiler den Haskell-Code zwangsläufig in imperativen Maschinen-Code transformiert, ist ein anderer Punkt.
Jo, darauf wollte ich auch nicht abzielen, ganz so kleinlich bin ich dann doch nicht
Ich sehe ein Problem bei der IO Monad. Wenn zum Beispiel eine hypothetische Funktion getLine ein IO String zurueckgibt, so gibt es sehrwohl viele Werte, welche eben diesen Typ haben.
Nein, getLine liefert aus Haskell-Sicht immer dasselbe Objekt zurück. Das kann man z.B. daran sehen, dass du sowas schreiben kannst wie
myGetLine = getLineund dann im folgenden myGetLine anstelle getLine benutzt.
getLine liefert ein anderes "IO String"-Objekt als z.B. die Funktion hGetContents, was den ganzen verfügbaren Eingabe-Stream als IO String liefert.In Haskell sind Funktionen mit null Parametern automatisch konstante Werte.
Das IO String-Objekt von getLine kann man auch als Handle betrachten. Das stdin-Handle ist z.B. immer identisch, ebenso wie eben der Rückgabewert von getLine. Nur wenn man etwas damit anfängt, wird zusätzliche Status-Information gebraucht, die implizit im IO Monad steckt. Das State-Monad zeigt sehr schön, wie man diese Statusinformation verstecken und nutzen kann; das State Monad lässt sich mit wenigen (seiteneffektfreien!) Zeilen komplett in Haskell implementieren.
-
DEvent schrieb:
Was erzählst du da eigentlich? Was soll den "unreiner" Code sein?
hab ich doch geschrieben: die syntax, naemlich keine. nur baumstruktur. alles einheitlich.
wenns nur ein problem mit meiner aussprache oder deinen loeffeln waere, aber nein, es sind deine augen
-
@Christoph: Ich habe noch nicht so viel Ahnung von Monaden und bei der State-Monad sehe ich ein, dass diese rein funktional ist.
Auch bei der Eingabe faellt mir keine geeignete Argumentation ein, wohl aber bei der Ausgabe.
Zum Beispiel gibt ja auch die Funktion putStrLn immer den gleichen Wert zurueck, keine Frage, aber sie veraendert doch die "Welt" (es wird auf stdout geschrieben). Wie ist das mit dem "rein" funktionalen Gedanken vereinbar?
-
Doktor Prokt schrieb:
Zum Beispiel gibt ja auch die Funktion putStrLn immer den gleichen Wert zurueck, keine Frage, aber sie veraendert doch die "Welt" (es wird auf stdout geschrieben). Wie ist das mit dem "rein" funktionalen Gedanken vereinbar?
Die "Welt" ist in gewisser Weise ein Parameter und wird herumgereicht. putStrLn nimmt nicht nur einen String, sondern auch die aktuelle "Welt" und liefert die neue "Welt" zurück. getLine nimmt die aktuelle "Welt" und liefert einen String und eine neue "Welt" zurück.
-
Zur Frage, warum alle immer Lisp empfehlen:
Ist ja ganz logisch. Wir sind ja auch in Lisp geschrieben...
Beweis:
-
zum mitsingen: http://www.gnu.org/fun/jokes/eternal-flame.html