FP welche Sprache?

Bashar

Na und? Ocaml auch. :p

rüdiger

Bashar schrieb:

Na und? Ocaml auch. :p

oh verdammt. Hab das ganz naiv in meine Liste aufgenommen. Vielleicht sollte ich es durch XSLT ersetzen *duck*

Aber okay, Scheme hat das hervorragende SICP!

Mr. N

Ganz klar C++ :p

.filmor

Haskell würd ich nicht nehmen. Das macht ganz ganz komische Sachen, nur weil man etwas Ein- oder Ausgeben will.
Erlang ist da toller und man kann damit auch noch feine parallele Programme schreiben.

rüdiger

.filmor schrieb:

Haskell würd ich nicht nehmen. Das macht ganz ganz komische Sachen, nur weil man etwas Ein- oder Ausgeben will.

Die "komische Sache" nennt sich halt funktionale Programmierung

Mr. N

Im Ernst, wenn das Ziel wirklich ist, funktionale Programmierung zu lernen, ist Haskell denke ich optimal.

Das andere Zeug ist halt nur halb funktional.

Danke für eure Antworten!

Also bleibt, von C++ mit boost oder C++ mit Prepro-Tricks abgesehen, LISP und Scheme, Haskell, OCaml und Erlang.

Welche von diesen ist denn die am wenigsten exotische, soll heißen: die, mit der man praktisch am meisten anfangen kann (mehr als "fac n = n == 0 : 1; n != 0 : fac n-1" und Quicksort wäre gut) und die am ehesten von einer community ge-maintained werden wird ?

Bashar

Was erwartest du denn von einer funktionalen Sprache? Die genannten lassen sich alle praktisch einsetzen. (BTW LISP hat niemand erwähnt)

naja, mit praxisnah und nicht exotisch meine ich: Welche von denen bringt am ehesten Vorteile im beruflichen Einsatz ?

Wenn das andere Zeug nur halb funktional ist, wie Mr.N sagt, tendiere ich dann doch zu Haskell, obwohl mir das Aussehen der Syntx nicht besonders zusagt.
OCaml sagt mir vom Aussehen der Programme her mehr zu, aber na gut.

Blue-Tiger

beginn92 schrieb:

naja, mit praxisnah und nicht exotisch meine ich: Welche von denen bringt am ehesten Vorteile im beruflichen Einsatz ?

Wenn das andere Zeug nur halb funktional ist, wie Mr.N sagt, tendiere ich dann doch zu Haskell, obwohl mir das Aussehen der Syntx nicht besonders zusagt.
OCaml sagt mir vom Aussehen der Programme her mehr zu, aber na gut.

Keine funktionale Sprache wird wirklich "Mainstream" eingesetzt. Es gibt zwar einige Nischen, wo sie Verwendung finden, aber sie sind bei weitem nicht so verbreitet wie C, C++ oder Java.
Vorteile im beruflichen Einsatz ergeben sich vor allem dadurch, dass dich funktionale Programmierung "weiter bringt", was deine Art zu Programmieren weiterbringt.

Die einzigen mir bekannten Programme, die in einer funktionalen Sprache geschrieben sind und auch "grossflaechig" eingesetzt werden, sind uebrigens ins LISP geschrieben.

Mr. N

Es gibt sogar einen in Haskell geschriebenen Window-Manager: Xmonad.

.filmor

rüdiger schrieb:

.filmor schrieb:

Haskell würd ich nicht nehmen. Das macht ganz ganz komische Sachen, nur weil man etwas Ein- oder Ausgeben will.

Die "komische Sache" nennt sich halt funktionale Programmierung

Nein, sie nennt sich Monade. Und ist einfach unglaublich blöd zu programmieren, wenn in anderen auch recht funktionalen Sprachen ein io:format("blabla_wn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.

Mr. N

.filmor schrieb:

rüdiger schrieb:

.filmor schrieb:

Haskell würd ich nicht nehmen. Das macht ganz ganz komische Sachen, nur weil man etwas Ein- oder Ausgeben will.

Die "komische Sache" nennt sich halt funktionale Programmierung

Nein, sie nennt sich Monade. Und ist einfach unglaublich blöd zu programmieren, wenn in anderen auch recht funktionalen Sprachen ein io:format("blabla_wn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.

Also zum Beispiel 'cat' ist in Haskell leicht zu implementieren:

main = getContents >>= putStr

Wo isn da das Problem?

.filmor

Mr. N schrieb:

Wo isn da das Problem?

Mein Problem ist, dass sich die Syntax für I/O unverhältnismäßig stark vom Rest des Programmes unterscheidet.

Mr. N

.filmor schrieb:

Mr. N schrieb:

Wo isn da das Problem?

Mein Problem ist, dass sich die Syntax für I/O unverhältnismäßig stark vom Rest des Programmes unterscheidet.

Wenn du immer nur >>=, >> und \ verwendest, dann ist die Syntax so ziemlich die gleiche wie normal auch.

also gut, probier ich es mit Haskell. Obwohl die Syntax etwas "eckig" aussieht, hoffentlich eine Frage der gewohnheit.
Wenn es mir nicht gefällt, weiß ich ja, bei wem ich mich beschweren kann

Obwohl, wenn ich im Tut "do ..." und "{ .. ; .. }" sehe, ist das nicht auch wieder imperative/sequenzielle Programmierung, durch die Hintertür eben?

Christoph

beginn92 schrieb:

Obwohl, wenn ich im Tut "do ..." und "{ .. ; .. }" sehe, ist das nicht auch wieder imperative/sequenzielle Programmierung, durch die Hintertür eben?

Wenn du es darauf anlegst, kannst du damit in einem imperativen Stil schreiben. Aber der Trick ist, dass man do {} fuer viele Funktionen ueberhaupt nicht braucht. Die do-Notation ist auch nur syntactic sugar fuer die Operatoren, die MrN bereits genannt hat.
Die do-Notation kann sogar verwendet werden um damit Assembler-Code zu schreiben. Fuer Spruenge vorwaerts, also an Labels die erst spaeter definiert werden, muss jedoch die Syntax ein kleines Stueck erweitert werden (ghc hat diese Erweiterung). ("The Monad Reader", Issue 6).

Mr. N schrieb:

.filmor schrieb:

rüdiger schrieb:

.filmor schrieb:

Haskell würd ich nicht nehmen. Das macht ganz ganz komische Sachen, nur weil man etwas Ein- oder Ausgeben will.

Die "komische Sache" nennt sich halt funktionale Programmierung

Nein, sie nennt sich Monade. Und ist einfach unglaublich blöd zu programmieren, wenn in anderen auch recht funktionalen Sprachen ein io:format("blabla_wn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.

Also zum Beispiel 'cat' ist in Haskell leicht zu implementieren:
main = getContents >>= putStr
Wo isn da das Problem?

Monaden koennen schon stoerend sein, wenn man z.B. mit Zufall hantiert und seine Werte immer in eine IO-Monade packen muss.

rüdiger schrieb:

Bashar schrieb:

Oder Scheme.

hat aber ein set! :p

Erlang unterhaelt zu jedem Prozess eine Hashmap. In dieser lassen sich nach Belieben Werte setzen und veraendern, wodurch wir bei der Existenz von set! bei Erlang waeren ;).

hustbaer

Mal eine GANZ doofe Frage bezüglich Funktionaler Programmierung und "Set" (Mutable State): wie verträgt sich das?
Bzw. wie handhaben das die Sprachen bzw. die Compiler/Interpreter?

Der grosse Vorteil von funktionalen Sprachen ist ja, wenn ich das richtig verstehe, dass Funktionen eben keine Seifenblasen machen, äh, Seiteneffekte haben. Das Programm wird dadurch von etwas Dynamischem zu etwas Statischem was nurmehr (mit einem bestimmten Input) "ausgewertet" wird um das Ergebnis zu bestimmen. Grob gesagt.

Ein grosser Vorteil für den Compiler/Interpreter ist doch hier dass er Funktionen beliebig "wegoptimieren" kann, oder die Auswertung "aufschieben" (lazy evaluation) bis der Wert wirklich gebraucht wird (falls er das jemals wird).
Bloss wenn man nun Mutable State einführt "bricht" doch das alles, d.h. wenn der Compiler Funktionen "wegoptimieren" würde die Mutable State angreifen könnte sich ja das Verhalten des Programmes verändern. Genauso wenn die Ausführung "aufgeschoben" wird.

Flaggt der Compiler/Interpreter einfach alle Funktionen die "Mutable State" ändern, bzw. Funktionen aufrufen die "Mutable State" ändern, und stellt dann sicher dass diese an den passenden Stellen noch "ausgeführt" werden, so dass man immer den erwarteten Output bekommt?

Und ist das nicht auch ein Nachteil für den Programmierer, dass Funktionen nun doch Seiteneffekte haben können? Schliesslich ist es für den Programmierer auch nett wenn er sich keine Gedanken über sowas (Seiteneffekte) machen muss. Oder muss man Funktionen die Seiteneffekte haben speziell als solche auszeichnen? Das würde zumindest verhindern dass man denkt man schreibt eine Funktion ohne Seiteneffekte, aber in wirklichkeine eine MIT Seiteneffekten schreibt, indem man andere Funktionen mit Seiteneffekten aufruft.

Oder mache ich hier einen Denkfehler und das alles ist viel einfacher? Oder viel komplizierter?