Welche Sprache empfiehlt sich zum Einstieg in die Funktionale Programmierung?
Sollte aktuell und verbreitet sein, und, wenn es geht, mit aktiver Community.

Oder Scheme.

hat aber ein set! :p

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!

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

Das andere Zeug ist halt nur halb funktional.

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 ?

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.

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.

.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.

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?

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 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.

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

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).

.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.

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 ;).

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?

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

Du siehst das schon richtig. Funktionale Sprachen, bei denen man jederzeit ein set! und damit mutable state verwenden kann, sind nicht das, was man unter "rein funktional" versteht. Lisp wird allgemein als funktionale Sprache angesehen, die Funktionen koennen aber beliebige Seiteneffekte haben. Daher kann Lisp nicht das Feature "referentielle Transparenz" bieten, das du in deinem Posting umschrieben hast.
Andere Sprachen wie Haskell oder Clean bieten dieses Feature, allerdings auf Kosten der Seiteneffekte an beliebigen Stellen. In beiden Sprachen muessen Funktionen gekennzeichnet werden, die Seiteneffekte haben. Dieses Kennzeichnen laeuft in Haskell ueber den Rueckgabewert und damit ueber das Typsystem. In Clean ist es AFAIK auch der Rueckgabewert, aber Clean benutzt dafuer eine etwas andere Theorie als Haskell.

In Haskell steht im Rueckgabewert z.B. IO, wenn die Funktion I/O-Operationen macht. Eine Funktion wie das Sieb des Eratosthenes benoetigt (wenn sie effizient sein soll) auch mutable state, allerdings nicht IO im Rueckgabetyp. Hier koennte man sinngemaess "State BoolArray" waehlen. Damit wird zum einen festgelegt, dass diese Funktion mutable state hat, zum anderen wird aber garantiert, dass diese Funktion keine I/O-Operationen macht. Der mutable state, den diese Funktion verwendet, bricht sogar nicht einmal die referentielle Transparenz. Das funktioniert dank der Monaden.

In Lisp ist es mit der Optimierung soweit ich weiss wie in C++: Der Compiler kann Funktionsaufrufe deren Rueckgabewert nicht benoetigt wird nur dann weglassen, wenn er den Code der aufgerufenen Funktion kennt und feststellt, dass dieser seiteneffektfrei ist.

EDIT: oder geht's hier nur um "lokalen" State (das was bei anderen Sprachen halt "Stack Variablen" sind)? Der ist ja unproblematisch, d.h. der kann eine Funktion auch nich nicht-deterministisch machen, da er ja nicht von Aufruf zu Aufruf erhalten bleibt, und auch nie Seiteneffekte verursachen, da er ja lokal ist. -- "Problematisch" sind halt Funktionen die globalen State verwenden... /EDIT

----

Weil du C++ erwähnt hast: ich wünsche mir das schon länger für C++ als Erweiterung, also dass man dem Compiler durch irgendein Keyword sagen kann dass eine Funktion "deterministisch" ist (also das Ergebnis nur vom Input abhängt), und dass sie keine (wichtigen) Seiteneffekte hat.
Weiters wäre es natürlich nett wenn man solche "deterministischen" Funktionen dann auch in Template-Metaprogrammierung verwenden könnte, bzw. der Compiler sie an den passenden Stellen einfach beim Compilieren "ausrechnen" und durch Konstanten ersetzen könnte.