Funktion vs Iterativ

[kostonstyle]

hallo miteinander
Gestern habe ich mit ein programmierer, der gerade die Fachhochschule abgeschlossen hat, über Java diskutiert.
Er sagte Java verliert an Beliebheit, dagegen nimmt Python zu. Programmierersprache, die funktional sind, dass heisst
Funktion in Funktion aufrufen, werden in Zukunft mehr verwendet.
Er sagte auch, dass die For-Schleife eigentlich nicht logisch sei, anstatt dem sollte man rekursive Funktionen verwenden.
Warum kann man bei funktionelle Programmiersprache die Probleme mathematisch einfacher lösen?

Danke kostonstyle

[Defnull]

Es gibt Probleme, die sich eleganter mit Rekursionen lösen lassen (z.B. Fibonacci) aber dabei sollte man beachten das Funktionsaufrufe recht teuer sind (Stack wird aufgebaut, lokaler Namensraum ändert sich u.s.w.) und man jedes rekursive Problem auch iterativ (in einer Schleife) lösen kann, was häufig schneller ist.

Funktionale Programmierung ist deswegen so beliebt, weil sie für kleine Probleme so schön einfach ist. OOP dagegen zwingt einen, sich Gedanken über sinnvolle Objektstrukturen zu machen. Ich bevorzuge für kleinere Projekte die Mischung aus beiden: Objekte für Daten und funktionale Programmierung für die Logik der Anwendung.

Das genau ist die Schwäche von Java: Sie zwingt einen selbst für die einfachsten Probleme ins OOP Gerüst und ist in der Hinsicht sehr unflexibel. Das man zum Nachdenken gezwungen wird, muss aber nicht unbedingt schlecht sein. Für komplexe Probleme ist OOP ein Segen. Besonders, wenn man das Problem in kleinere Teilprobleme zerschneiden will oder mit mehr als einer Person daran arbeitet. OOP ermöglicht nämlich eine bessere Abstraktion von komplexen zusammenhängen.

[numerix]

1. Python ist keine funktionale Programmiersprache.
2. Gerade in Python ist die iterative Lösung der Fibonacci-Folge sehr elegant.

[Leonidas]

Er sagte Java verliert an Beliebheit, dagegen nimmt Python zu. Programmierersprache, die funktional sind, dass heisst
Funktion in Funktion aufrufen, werden in Zukunft mehr verwendet.

Das ist nicht die Definition von funktionalen Sprachen.

Er sagte auch, dass die For-Schleife eigentlich nicht logisch sei, anstatt dem sollte man rekursive Funktionen verwenden.

Die For-Schleife aus Sprachen wie C ist nicht logisch wenn man über Indizes iteriert, wäre doch viel eleganter über Items zu iterieren. So wie Python das tut.

[kostonstyle]

es ist alles so kompliziert. Was sind dann funktionalen Sprachen, heisst das, dass die Definition von Funktion ohne Klasse möglich ist? Programmiersprache C gehört auch dazu oder?

[Pekh]

Nein, funktionale Programmiersprachen funktionieren nach einem ganz anderen Paradigma als die objektorientierten oder imperativen Sprachen.

In fast schon unzulässiger Verkürzung:

Bei den objektorientierten und imperativen Sprachen beschreibst du, wie ein bestimmtes Problem gelöst werden soll.

Bei den funktionalen Sprachen beschreibst du das Problem und seine Abhängigkeiten, und überläßt das Lösen dem Computer. Du beschreibst also in etwa, was gelöst werden soll.

[numerix]

es ist alles so kompliziert. Was sind dann funktionalen Sprachen, heisst das, dass die Definition von Funktion ohne Klasse möglich ist? Programmiersprache C gehört auch dazu oder?

Nein, C gehört nicht dazu.
Kennst du Wikipedia? -> http://de.wikipedia.org/wiki/Funktionale_Programmierung

[Leonidas]

Was sind dann funktionalen Sprachen, heisst das, dass die Definition von Funktion ohne Klasse möglich ist?

Sprachen in denen Funktionsapplikation im Vordergrund steht, Funktionen möglichst keine Seiteneffekte haben und viele immutable Typen vorkommen.

[sma]

Funktionale Sprachen sind näher an dem mathematischen Modell dran. Jedem echten Mathematiker rollen sich die Fußnägel auf, wenn er "x = x + 1" liest, denn diese Gleichung ist nicht erfüllbar. Es gibt kein solches X welches gleich seinem Nachfolger ist (so man denn die Die Peano-Axiome als gegeben ansieht).

Rekursive, also selbstbezogene Algorithmen sind elegant, da sie nicht nur kurz ein einfach zu beschreiben sind sondern meist auch einfacher zu beweisen. Nehmen wir als Beispiel, die Multiplikation zweier natürlicher Zahlen a und b. Dann gilt: p = a * b ist a wenn ObdA b=1 ist. Ansonsten ist p = a + (a * b - 1). Dabei sei b-1 der Vorgänger von b, so wie x+1 der Nachfolger von x ist. In Python

Code: Alles auswählen

def mul(a, b):
    if b == 1:
        return a
    else:
        return a + mul(a, b - 1)

Ich würde es allerdings kürzer aufschreiben:

Code: Alles auswählen

def mul(a, b): return a if b == 1 else a + mul(a, b - 1)

Die wichtigste Eigenschaft (IMHO) funktionaler Programmierung ist, dass Funktionen wieder Werte sind, mit denen man "rechnen" kann. Eine der wichtigsten Funktionen ist "map", die eine Funktion auf eine Liste mit Werten anwendet und eine neue Liste als Ergebnis liefert. Es gibt eine kleine Menge weiterer derartigen Funktionen, aus denen man sich eine mächtige Sprache zusammenstellen kann, um alle Arten von Operationen auf Mengen zu beschreiben.

Eine derartige Abstraktion hat den Vorteil, dass sie nicht mehr zustandsbehaftet ist und keine zeitliche Komponente mehr enthält. Daher kann "map" auch parallel ausgeführt werden. Hierin sehen viele die Hoffnung für die aktuelle Prozessor-Krise (Prozessoren werden nicht mehr schneller wie von Moore's Law vorhergesagt), die aktuell einzige Chance ist, mehr parallel zu machen. Hier ist aber das Problem, dass man das mit traditionellen Mittel und vertretbarem Aufwand nicht fehlerfrei hinbekommt.

Funktionen höherer Ordnung wieder ein typisch mathematisches Konzept und entscheidend für die vielleicht wichtigste Theorie der Informatik, das Lambda-Kalkül, welches die mathematische Grundlage für all unsere Programme bietet und überhaupt erklärt, warum ein "for i in range(10): print i" eigentlich funktioniert wie es funktioniert.

Stefan

[Leonidas]

Daher kann "map" auch parallel ausgeführt werden. Hierin sehen viele die Hoffnung für die aktuelle Prozessor-Krise (Prozessoren werden nicht mehr schneller wie von Moore's Law vorhergesagt), die aktuell einzige Chance ist, mehr parallel zu machen.

Das stimmt so nicht ganz*. Moores Law spricht sich (wohlwissend?) nur über die Anzahl der Transistoren auf einem Chip aus und diese Anzahl steigt mit Dual, Quad und Multicores dennoch an (wie man auf diesem hübschen Bild sieht, ist Core 2 Duo etwas darunter, die Quad-Variante aber deutlich darüber). Da die Y-Achse logarithmisch ist, ist der Unterschied durchaus groß.

* ich nehme aber an dass sma das durchaus weiß und das nur so über-vereinfacht gesagt hat.