ubuntuusers.de

Funktionale Programmierung - wozu?

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |

Superuser

Anmeldungsdatum:
13. Juli 2008

Beiträge: 6

Richtig, die Frage stelle ich mir.
Ich weiß es nicht. Nein. Wirklich nicht. Also:

Es ist ja so, dass man diese noch immer auf einigen Universitäten lernt, so man Informatik studiert (was ich nicht tue und auch nicht tun werde).
Und für die meisten Menschen, die "programmieren lernen" besteht dieses ja nur aus den imperativen Sprachen wie C, c++, c#, java - gelegentlich zählt dann manch einer noch python und ruby dazu.
Die funktionalen Sprachen wie Haskell, Lips erhalten in dieser Gruppe deutlich weniger Zuwendung.
Und wenn ich mich mit ihnen beschäftige, merke ich eigentlich, dass es in einigen Bereichen andere Ansätze gibt (Iteration statt while, etc), frage mich aber, wer sie ernsthaft benutzt.

Also: Welche Gruppe benutzt die funktionalen Sprachen wozu, was sind Vor - und Nachteile zu imperativen Sprachen und warum sind sie nicht so "verbreitet", werden aber trotzdem unterrichtet?

Gruß,
Superuser

Lunar

Anmeldungsdatum:
17. März 2006

Beiträge: 5792

Bei paralleler Programmierung spielen funktionale Sprachen eine große Rolle, weil sie von Natur aus kaum Seiteneffekte haben. Und die Verbreitung funktionaler Konzepte geht weit über rein funktionale Sprachen hinaus, Closures, Co-Routinen, Iteratoren, etc finden sich auch in Python, Ruby & Co.

Abgesehen davon, dass die Verbreitung funktionaler Sprachen allein schon ausreicht, um deren Lehre zu rechtfertigen, vertieft die Beschäftigung mit funktionalen Sprachen auch das Verständnis grundlegender Paradigmen der Programmierung. Zudem sind funktionale Sprachen nun mal ein Bestandteil der Informatik, folglich muss sich ein Informatiker auch damit beschäftigt haben. Die Universität sind ja primär noch im Lehranstalten und keine Kaderschmieden für die Bedürfnisse der Industrie. Außerdem ist funktionaler Code meistens eleganter als entsprechender imperativer Code, so dass man funktionale Sprache schon allein um der Ästhetik willen kennen sollte.

Im Übrigen ist es ziemlich vermessen, sich als Einzelperson ein Urteil über die Verbreitung einer Sprachgattung zu erlauben, und daraus dann auch noch Konsequenzen für die Lehre ziehen zu wollen. Mit Verlaub, in so einem Fall ist es legitim zu sagen, dass du über Dinge sprichst, von denen du keine Ahnung hast, keine Ahnung haben kannst.

schlonz

Avatar von schlonz

Anmeldungsdatum:
30. November 2005

Beiträge: 294

Wohnort: berlin

Funktionale Programmierung ist eben bisher (mit Ausnahmen) noch hauptsächlich eine rein akademische Tätigkeit, findet aber mittlerweile seinen Weg in den Mainstream dank F# und .NET.
Die zwei grossen Ausnahmen, die mir einfallen sind Ericsson (Erlang) und Emacs (Lisp).

FP entspringt dem Wunsch, mit geringem Aufwand fehlerfreie Programme schreiben zu können.
Zum einen soll das Fehlen von Zustand und Seiteneffekten die Programmierung weniger fehleranfällig machen und das Debuggen wesentlich einfacher und schneller gestalten.
Zum anderen versucht man, so nah wie möglich an die Sprache und Notation der Mathematik herankommen zu können, um die Korrektheit von Programmen einfacher beweisen zu können, aber auch einfach aus Gründen der Eleganz.
Vergleichst Du funktionalen mit Iterativem Code, fällt auf, dass Algorithmen in funktionalen Programen oft sehr viel kürzer und prägnanter dargestellt werden können.

Das Kernmerkmal von FP ist also das Fehlen von Zustand und Seiteneffekten; Alle Funktionen sind "pur", d. h. sie bekommen etwas übergeben und liefern etwas zurück, und das ist alles was sie tun. Also keine Seiteneffekte, wie zB etwas zu verändern, dass sich ausserhalb der Funktion befindet.
Funktionen sind zeitlos; egal wann und unter welchen Umständen eine Funktion aufgerufen wird, sie liefert bei gleichem Eingabewert immer das selbe Ergebnis. Das verhindert viele eklige und schwer zu findende Bugs mit denen man sich in der Iterativen Programmierung rumschlagen muss.

Als Folge der Zustandslosigkeit gibt es - wie in der Mathematik - auch keine Reihenfolge von Befehlen. Jede Funktion besteht aus genau einem Ausdruck. Da der Compiler nun weiß, dass Funktionen a) keine Seiteneffekte haben und b) es keine Reihenfolge der Abarbeitung gibt sind weitreichende Optimierungen möglich. Code kann automatisch vom Compiler parallelisiert werden, ohne das der Programmierer etwas dazu tun muss. Daher wir FP von einigen als ein möglicher Ausweg aus der derzeitigen Softwarekrise betrachtet.

Die grosse Schwachstelle von FP ist Ein- und Ausgabe, da dies nicht ohne Seiteneffekte machbar ist. Haskell's Monaden waren da wohl ein grosser Durchbruch, sind aber immer noch weit von einer optimalen Lösung entfert.
Zum anderen sind funktionale Programme eben noch ein Stück weiter vom Eisen entfernt und man kann kaum beeinflussen, wie Datenstrukturen intern im Coputer abgearbeitet werden. Man muß sich darauf verlassen, dass der Compiler vernünftig optimiert. Du kannst zum Beispiel meines (beschränkten) Wissens nach keinen Quicksort schreiben, der insitu arbeitet.
Das, und die Tatsache dass FP einfach abstrakter ist, dürfte die geringe Nutzung erklären. Gelehert wird es trotzdem, das viele Informatiker glauben, das FP in Zukunft wichtig werden wird. Außerdem ist es für den eigenen Horizont einfach wichtig, dass mehr als nur ein Paradigma gekannt wird.

**Edit** Lunar hat mich beim schreiben überholt, aus Trotz lasse ich diesen Beitrag aber trotzdem stehen. 😮

Lunar

Anmeldungsdatum:
17. März 2006

Beiträge: 5792

schlonz hat geschrieben:

Funktionale Programmierung ist eben bisher (mit Ausnahmen) noch hauptsächlich eine rein akademische Tätigkeit

Funktionale Programmierung mit rein funktionalen Sprachen trifft's wohl eher. Funktionale Paradigmen und Konzepte kommen auch in einigen nicht rein-funktionalen Sprachen wie Python häufig vor.

schlonz hat geschrieben:

Vergleichst Du funktionalen mit Iterativem Code, fällt auf, dass Algorithmen in funktionalen Programen oft sehr viel kürzer und prägnanter dargestellt werden können.

Imperativ, nicht iterativ 😉

schlonz hat geschrieben:

Zum anderen sind funktionale Programme eben noch ein Stück weiter vom Eisen entfernt und man kann kaum beeinflussen, wie Datenstrukturen intern im Coputer abgearbeitet werden. Man muß sich darauf verlassen, dass der Compiler vernünftig optimiert.

Mir war gar nicht bewusst, dass ich mich bei der Python-Programmierung noch manuell optimiere 😉 Will sagen, heute kümmert sich eh niemand mehr um manuelle Optimierung. Es ist längst bekannt, dass das Wechseln das Algorithmus mehr bringt, als Mikrotuning an Datenstrukturen. Heute verlässt sich jeder Programmier, der mit hohen imperativen Sprachen wie Java oder C# programmiert, darauf, dass der Compiler gut optimiert. Die Behauptung, bei funktionalen Sprachen müsse man sich darauf verlassen, dass der COmpiler gut optimiert, ist folglich nur eine Schutzbehauptung von Leuten, die an imperative Sprachen "glauben".

Superuser

(Themenstarter)

Anmeldungsdatum:
13. Juli 2008

Beiträge: 6

Im Übrigen ist es ziemlich vermessen, sich als Einzelperson ein Urteil über die Verbreitung einer Sprachgattung zu erlauben, und daraus dann auch noch Konsequenzen für die Lehre ziehen zu wollen. Mit Verlaub, in so einem Fall ist es legitim zu sagen, dass du über Dinge sprichst, von denen du keine Ahnung hast, keine Ahnung haben kannst.

Da stimme ich dir ohne weiteres zu. Meine "Ableitungen" basierten ja auch auf meiner beschränkten Sichtweise, aus der die Frage resultierte 😉

Wenn ich das so lese, dann habe ich den Eindruck, dass die (rein)funktionalen Sprachen eigentlich nur gelehrt werden, weil es sie eben gibt und einige Konzepte in den imperativen Sprachen übernommen wurden. Verbreitung in der Industrie finden sie dabei aber (bislang?) kaum.

Trifft es das in etwa?

\––\––\––-

In den funktionalen Sprachen, als Beispiel diene Haskell, gibt es so weit ich weiß auch keine "Variable im imperativen Sinne"; auch Schleifen entfallen und werden durch Rekursionen ersetzt. Das akzeptiere ich natürlich, ist eben ein anderer Ansatz - doch könnte jemand so nett sein und mir auch die Vorteile dessens nennen?

Bis hierher erstmal Danke und einen schönen Sonntag noch

Lunar

Anmeldungsdatum:
17. März 2006

Beiträge: 5792

Superuser hat geschrieben:

Wenn ich das so lese, dann habe ich den Eindruck, dass die (rein)funktionalen Sprachen eigentlich nur gelehrt werden, weil es sie eben gibt und einige Konzepte in den imperativen Sprachen übernommen wurden. Verbreitung in der Industrie finden sie dabei aber (bislang?) kaum.

Nicht unbedingt. Funktionale Sprachen sind bei paralleler Programmierung beliebt, eine der wichtigsten Sprachen in diesem Bereich (Erlang) ist sogar rein industriellen Ursprungs. Allerdings passiert das außerhalb dessen, was man Standardsoftware nennt, extensive Parallelprogrammierung ist vor allem im Wissenschaftlichen vorzufinden-

Superuser hat geschrieben:

In den funktionalen Sprachen, als Beispiel diene Haskell, gibt es so weit ich weiß auch keine "Variable im imperativen Sinne"; auch Schleifen entfallen und werden durch Rekursionen ersetzt. Das akzeptiere ich natürlich, ist eben ein anderer Ansatz - doch könnte jemand so nett sein und mir auch die Vorteile dessens nennen?

Da hat doch schlonz schon viel zu gesagt. In der Theorie sind funktionale Sprache komplett nebeneffektsfrei, eine Funktion in der funktionalen Programmierung ist auch tatsächlich eine "Black Box". In der Praxis stimmt das auch größtenteils, bis auf Gebiete, bei denen Interaktion gefragt ist. Der Vorteil liegt auf der Hand. Funktionale Programme können theoretisch ohne Probleme parallelisiert werden und so Hardwareresourcen optimal ausnutzen. Außerdem ermöglicht die vollständige Isolierung von Programmteilen, jeden Teil auch isoliert zu betrachten. So kommt man dem Ideal, die Korrektheit eines Programmes beweisen zu können, näher, als das bei imperativen Programmen aufgrund deren vielfältigen Nebeneffekten möglich ist. Außerdem ermöglicht die höhere Abstraktion, komplexen Code einfacher zu implementieren.

In der Praxis kranken funktionale Sprachen vor allem daran, dass klassische Programme auf Nebeneffekte abzielen. Eine Nutzereingabe ist ein gewollter Seiteneffekt. Bis jetzt hat noch niemand eine Lösung gefunden, solche Seiteneffekte auf elegante Weise funktional zu verpacken, weswegen sich nebeneffektsbasierte Programme (also eigentlich jedes GUI-Programm) nicht einwandfrei funktional modellieren lassen.

schlonz

Avatar von schlonz

Anmeldungsdatum:
30. November 2005

Beiträge: 294

Wohnort: berlin

Lunar hat geschrieben:

schlonz hat geschrieben:

Zum anderen sind funktionale Programme eben noch ein Stück weiter vom Eisen entfernt und man kann kaum beeinflussen, wie Datenstrukturen intern im Coputer abgearbeitet werden. Man muß sich darauf verlassen, dass der Compiler vernünftig optimiert.

Mir war gar nicht bewusst, dass ich mich bei der Python-Programmierung noch manuell optimiere 😉 Will sagen, heute kümmert sich eh niemand mehr um manuelle Optimierung. Es ist längst bekannt, dass das Wechseln das Algorithmus mehr bringt, als Mikrotuning an Datenstrukturen. Heute verlässt sich jeder Programmier, der mit hohen imperativen Sprachen wie Java oder C# programmiert, darauf, dass der Compiler gut optimiert. Die Behauptung, bei funktionalen Sprachen müsse man sich darauf verlassen, dass der COmpiler gut optimiert, ist folglich nur eine Schutzbehauptung von Leuten, die an imperative Sprachen "glauben".

Ok, Feintuning is Sache des Compilers ☺ Ich meinte eigentlich, dass man schon auf dem Algorithmenlevel weniger Möglichkeiten hat, Entscheidungen bzgl Effizient zu treffen. Daher das qsort Beispiel: Du kannst beim Programmieren nicht direkt bestimmen, ob der Algorithmus in-place oder out-of-place arbeitet. Sofern Du den Compiler nicht gut kennst, weißt Du nicht, wieviel Platz der Algorithmus benötigt.
Auch in Python überlegst Du dir bestimmt des öfteren, ob es Sinn macht, das Ergebnis einer Funktion zwischenzuspeichern, um diese Funktion (vielleicht mit expotientiellem Aufwand) nicht mehrmals aufrufen zu müssen. Bei FP musst Du dich drauf verlassen, dass es der Compiler selber schnallt. Oder alle zwischenergebnisse als Funktionsargumente mitschleppen, das wird schnell sehr hässlich.

Marc_BlackJack_Rintsch Team-Icon

Ehemalige
Avatar von Marc_BlackJack_Rintsch

Anmeldungsdatum:
16. Juni 2006

Beiträge: 4694

Wohnort: Berlin

@superuser: Es gibt einen Text, dessen Titel die Beantwortung Deiner Frage verspricht: Why Functional Programming Matters.

Du sagst sie werden "noch immer" an Universitäten gelehrt, als wenn es irgend wie etwas veraltetes wäre. Haskell und F# sind aber relativ jung. Auf der anderen Seite gibt es durchaus alte Sprachen wie Lisp oder "mittelalte" wie Erlang, die in der Praxis eingesetzt werden. Man darf sich bei der Betrachtung der Verbreitung von Programmiersprachen nicht immer nur auf die aktuellen "Hype"-Sprachen stützen. In der Praxis gibt es durchaus eine Menge Projekte, die in angeblich "exotischen" oder alten Sprachen geschrieben sind. Es gibt Unmengen von Systemen in Fortran, Cobol, Lisp, … da draussen, die funktionieren, und die nicht mal eben in Java oder C# neu geschrieben werden, nur weil die Sprachen gerade "in" sind. Ansonsten hat Verbreitung von Techniken auch eine Menge mit Geld und Marketing zu tun. Das Sun und Microsoft viel Geld in die Vermarktung ihrer Sprachen stecken, hat sicher auch etwas mit der Popularität von Java und C# zu tun. In Lisp wurde früher viel Geld gesteckt. Das Google hinter Python steht, Microsoft und Sun Geld dafür ausgeben, dass es Implementierungen für .NET und die JVM gibt, ist sicher auch der Verbreitung der Sprache förderlich.

Ein Grund für zum Beispiel Haskell als rein funktionale Sprache in der Lehre ist sicherlich, den Leuten, die denken sie könnten schon programmieren, einen kleinen Dämpfer zu versetzen. Es ist eben eine ganz andere "Denke" erforderlich als in imperativen Sprachen. Dabei erweitert man seinen Horizont und das Verständnis was Programmieren eigentlich ist. Ausserdem lernt man dabei auch mehr über imperative Sprachen, weil man jetzt etwas zum Vergleichen hat, und Sachen an anderen Ansätzen bemerkt, die man ohne Vergleichsobjekt so vielleicht nie bewusst wahrgenommen hätte.

Ein Vorteil von den meisten neueren funktionalen Sprachen ist zum Beispiel "type inferencing", dass heisst statische Typisierung, bei der man die Typen aber nur in Ausnahmefällen explizit angeben muss. Durch die Einschränkung, das ein Funktionsaufruf keine Seiteneffekte hat, und bei gleicher Eingabe immer die gleiche Ausgabe liefert, weiss der Compiler wesentlich mehr über das Programm und kann Optimierungen vornehmen, die zum Beispiel ein C- oder C++-Compiler nicht durchführen kann. Unter anderem kann er den Code selbständig oder mit ein wenig Unterstützung vom Programmierer besser Parallelisieren. Da immer mehr Mehrkernprozessoren verbaut werden und wohl auch die Zahl der Kerne in Zukunft steigen wird, ist das eine interessante Eigenschaft.

Das ist ein Grund warum funktionale Sprachen und Optimierungsmöglichkeiten in Unis verstärkt erforscht werden, und damit auch noch ein Grund, warum man Studenten damit quält. 😉 Letztlich möchte man gerne von dem uralten Fortran für numerische Berechnungen weg kommen und dafür lieber etwas funktionales einsetzen, was genau so optimierten Code erlaubt, aber näher an der Mathematik liegt, die man damit umsetzen möchte.

Das es keine "Variablen im imperativen Sinn" gibt, entspricht eher dem mathematischen Variablenbegriff, der älter ist, als das was imperative Sprachen unter "Variable" verstehen. Das würden Mathematiker jetzt wahrscheinlich als Vorteil sehen. ☺ Das man einem Namen nur einmal einen Wert zuweisen kann, ermöglicht es dem Compiler den Code sehr grosszügig umzustellen, weil man einen Namen ja überall durch seinen Wert ersetzen kann, oder umgekehrt beliebigen Funktionen oder Teilfunktionen einen temporären Namen verpassen kann. Wobei "Wert" hier auch Funktion oder Teilfunktion heissen kann, bzw. eigentlich immer heisst, denn ``x = 42`` ist nichts anderes als eine Funktion mit dem Namen x, die keine Argumente entgegennimmt und immer den Wert 42 als Ergebnis liefert.

Bei Rekursion kann man oft einfacher die Korrektheit beweisen als bei einer iterativen Lösung, weil Induktionsbeweise klassisches mathematisches Handwerkszeug sind.

Ich persönlich finde rein funktionale Sprachen unbenutzbar sowie es um Interaktionen mit der Aussenwelt geht, die nicht seriell abgewickelt werden können. Das kann auch an meinem Unvermögen liegen, mich da hinein zu denken, nachdem ich solange veränderbare Zustände in anderen Programmiersprachen verwendet habe. Aber ich mag Sprachen, die auch funktionale Programmierung unterstützen, weil "serielle" Datenverarbeitung damit sehr elegant und flexibel ausgedrückt werden kann.

Apollon

Avatar von Apollon

Anmeldungsdatum:
27. Oktober 2004

Beiträge: 724

Wohnort: Darmstadt

Marc 'BlackJack' Rintsch hat geschrieben:

denn ``x = 42`` ist nichts anderes als eine Funktion mit dem Namen x, die keine Argumente entgegennimmt und immer den Wert 42 als Ergebnis liefert.

Naja. Sie nimmt schon Argumente entgegen, nur bildet sie sie alle auf die 42 ab. Es gibt durchaus konstante Funktionen, denen man auf den ersten Blick diese Eigenschaft nicht ansieht. 😉

Sigma7

Avatar von Sigma7

Anmeldungsdatum:
25. Oktober 2007

Beiträge: 438

Klassisches Genetisches Programmieren macht man mit funktionalen Programmiersprachen, weil man Crossover und Mutationen sehr gut auf die Baumstruktur anwenden kann.

Utzinator

Anmeldungsdatum:
6. August 2006

Beiträge: 415

Moin,

klingt alles ganz interessant, danke soweit.
Werde mich mal mit Haskell beschäftigen, dabei merke ich eventuell ja vorteile.
Besonders gut komme ich damit noch nicht vorran, zumal ich alles immer versuche imperativ zu lösen. Besonders stört
dabei natürlich das andere Verständnis von Variablen und, dass es keine tollen IDEs gibt (bin da zu sehr verwöhnt worden)

Naja, mal sehen, eventuell verstehe ich ja doch irgendwann was und werde dann auch funktionale Sprache kenne, beherrschen und
ihre Existenz sinnvoll finden

audax

Avatar von audax

Anmeldungsdatum:
15. September 2006

Beiträge: Zähle...

für Eclipse gibts nen PlugIn für Haskell

Utzinator

Anmeldungsdatum:
6. August 2006

Beiträge: 415

Das scheint abe rnicht wirklich zu funktionieren ☹

Dateien hereinkopiert, dann Haskellprojekt geöffnet, ganz simples mainmodul erstellt, man klickt auf "run as" nimmt ghci und nix passiert, bis man wieder raufklickt und
gesagt bekommt, dass eclipse den Ort der Dateien nicht findet (vorher gespeichert).

doof

Utzinator

Anmeldungsdatum:
6. August 2006

Beiträge: 415

Da edit und so ja verboten sind:

Funktioniert doch, er hat das vorher installierte ghc unter einen falschen Pfad vermutet

PrairieDog

Anmeldungsdatum:
16. Februar 2006

Beiträge: 870

Sigma7 hat geschrieben:

weil man Crossover und Mutationen sehr gut auf die Baumstruktur anwenden kann.

Also sind Rekombinations- und Mutationsoperatoren Besonderheiten funktionaler Programmiersprachen? 😉

Antworten |