FP welche Sprache?
-
Bashar schrieb:
Oder Scheme.
hat aber ein set!
:p
-
Na und? Ocaml auch. :p
-
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!
-
Ganz klar C++ :p
-
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.
-
.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

-
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 ?
-
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.
-
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.
-
Es gibt sogar einen in Haskell geschriebenen Window-Manager: Xmonad.

-
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("blablawn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.
-
.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("blablawn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.
Also zum Beispiel 'cat' ist in Haskell leicht zu implementieren:
main = getContents >>= putStrWo isn da das Problem?

-
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.
-
.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?
-
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("blablawn", ["bla"]) zur Ausgabe reicht und man mit getline einlesen kann.
Also zum Beispiel 'cat' ist in Haskell leicht zu implementieren:
main = getContents >>= putStrWo 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!
:pErlang 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 ;).