Unterschiede zwischen funktionaler- und prozeduraler Programmiersprachen
-
Hallo,
ich habe jetzt schon eine ganze Weile im Internet geschaut, aber das einzige was man da herausbekommt, dass funktional nicht prozedural ist, und dennoch scheinen sich die Konzepte fast identisch zu sein. oO
Wo ist der Unterschied? Kann man das an einem Programmierbeispiel klarmachen? Wäre echt nett.
Danke,
Squall
-
Huch, der deutsche Wikipedia-Artikel dazu ist wirklich schlecht. Der größte Unterschied ist der, dass funktionale Programmierung sich eher an der Mathematik orientiert und einerseits keine Seiteneffekte erlaubt und andererseits Funktionen (daher) immer (mindestens) einen Rückgabewert haben.
In der englischen WP ist es besser erklärt:
http://en.wikipedia.org/wiki/Functional_programming#Comparison_of_functional_and_imperative_programming
-
Stichwort function
--------------------------In prozeduralen Sprachen kann die Funktion seitenEffekte haben
( wenn die funktion von globalen Variablen abhängig ist ).In funktionalen Sprachen hat die Funktion keine seitenEffekte
( die berechnung ist nur von den Parammetern abhängig )Ein Link:
-----------------
In D werden seitenEffekt freie Funktionen als pure Funktionen bezeichnet.
pure function---
-
Abgesehen davon gestaltet sich die Programmierung in einer funktionalen Sprache vollkommen anders, da man nicht über die imperativen Merkmale von prozeduralen Sprachen verfügt.
-
Das ist meiner Meinung nach einer dieser Sachen worüber man viele Worte verlieren kann, aber es mal gemacht haben sollte. Schau mal in Haskell rein (sehr schöne Syntax) ich denke dann erübrigt sich diese Frage
-
ich denke der hauptunterschied ist in der denkweise (wie meistens bei sprachen).
man geht davon aus: alles ist eine funktion.
zB gibt es keine variablen, sondern einfach nur eine funktion die keinen param nimmt und einen wert liefert. das bedeutet zB, dass "variablen" automatisch immutable sind. und das fuehrt eben zu keinem shared state und hat massig andere implikationen wie zB keine for-Schleifen moeglich, etc.
-
Shade Of Mine schrieb:
ich denke der hauptunterschied ist in der denkweise (wie meistens bei sprachen).
man geht davon aus: alles ist eine funktion.
zB gibt es keine variablen, sondern einfach nur eine funktion die keinen param nimmt und einen wert liefert. das bedeutet zB, dass "variablen" automatisch immutable sind. und das fuehrt eben zu keinem shared state und hat massig andere implikationen wie zB keine for-Schleifen moeglich, etc.
Sag mal Shade Haskell hat ja ein System um Shared State bei I/O zu vermeiden, wie ist das bei Erlang?
-
Erlang ist da etwas anders.
Man umgeht Shared State indem man ihn in nur einem Prozess/Funktion "shared". In Erlang koennen ja Funktionen als Prozess agieren und sich Messages schicken. Indem Moment indem du state also in eine Funktion kapselst, hast du ihn nicht mehr geshared, kannst aber dennoch messages senden und empfangen (sprich den state manipulieren).
-
Shade Of Mine schrieb:
Erlang ist da etwas anders.
Man umgeht Shared State indem man ihn in nur einem Prozess/Funktion "shared". In Erlang koennen ja Funktionen als Prozess agieren und sich Messages schicken. Indem Moment indem du state also in eine Funktion kapselst, hast du ihn nicht mehr geshared, kannst aber dennoch messages senden und empfangen (sprich den state manipulieren).
Das heißt, wenn ich in Erlang von mehreren Threads aus das selbe I/O Objekt manipuliere brauche ich eine zentrale Stelle welcher in Messages schicken kann und welche dann die entsprechenden Aktionen ausführt?
Hört sich für mich so an, als ob das das gleiche wäre wie bei Haskell, nur hier muss ich das Wrappen selber übernehmen.
-
Erlang-Anfänger schrieb:
Das heißt, wenn ich in Erlang von mehreren Threads aus das selbe I/O Objekt manipuliere brauche ich eine zentrale Stelle welcher in Messages schicken kann und welche dann die entsprechenden Aktionen ausführt?
Hört sich für mich so an, als ob das das gleiche wäre wie bei Haskell, nur hier muss ich das Wrappen selber übernehmen.Nein, du hast keine Threads, du hast Funktionen. Eine Funktion ist uU ein Thread, aber das braucht dich nicht zu kümmern.
Du machst zB
io:format("Hallo")
und damit sendest du eine Nachricht und io:format übernimmt die Ausgabe - uU liegt io:format in deinem aktuellen Thread, uU nicht. Die Synchronisierung erfolgt automatisch über das Message passing. Dadurch dass du State in eine Funktion kapselst (der du unterschiedliche Nachrichten schicken kannst) hast du automatisch eine Synchronisierung dabei und da Messages immer kopiert werden, gibt es zwischen einzelnen funktionen keinen shared state.
Wie es Haskell löst, weiss ich nicht.
-
Ok, danke. Heißt das, dass alle Funktionsaufrufe nur Nachrichtenübermittlungen sind, oder nur in speziellen Fällen?
Und was ist wenn ich von io:format einen Rückgabewert erwarten würde, würde dann mein Thread blocken bis io:format fertig ist mit meiner Aufgabe?
-
Du kannst dir natuerlich auch wiederum eine message schicken lassen mit dem rueckgabewert.