Diskussion:Iterative Programmierung

englischer Link passt nicht

Hallo zusammen, der englische Link passt nicht zu diesem Artikel. Da würde schon eher der kleinere Absatz aus der Iteration passen. --Erkan Yilmaz 19:27, 17. Dez. 2006 (CET)

Rekursionen

Ich bin mir nicht ganz sicher, aber ich glaube ALLE Rekursionen lassen sich auch iterativ implementieren. --Melkom 11:23, 21. Aug 2003 (CEST)

Ich bin auch der Meinung. Da ich mir nicht 100%ig sicher war, habe ich es vorsichtig formuliert. Allerdings ist es faktisch alsch, dass die iterative Lösung langsamer wäre, sie ist nur umständlicher zu implementieren, und die Rekursion ist intuitiv leichter zu verstehen. Ich hoffe das kommt jetzt so rüber, ansonsten noch mal umformulieren. -- Dishayloo 13:44, 21. Aug 2003 (CEST)

Ja stimmt, so ist das richtig. Ich hab da wohl was verwechselt. --Melkom 14:25, 21. Aug 2003 (CEST)

Ja, WHILE-Sprachen und mü-rekursive Funktionen sind äquivalent. -- JensMueller 02:00, 2. Jan 2004 (CET)

Ich halte es nicht für sehr sinnvoll, den Begriff sofort im ersten Satz (noch vor der Definition) durch Abgrenzung von Rekursion zu erklären.

Mir erschließt sich auch nicht ganz, was an iterativer Programmierung einfacher sein soll. NPOV ist das IMO nicht mehr. --JensMueller 02:01, 2. Jan 2004 (CET)

Unzulässige Begriffsverkürzung

"Iterative Programmierung" ist nicht gleichbedeutend mit "Schleifen statt Rekursion".
Der "Hauptkonkurrent" mag rekursive Programmierung sein, daher kann das als Hauptaspekt für die Abgrenzung der iterativen Programmierung herhalten - er ist aber nicht das einzige andere Konzept.

Die Gegenstücke zu iterativer Programmierung sind vor allem

• funktionale/listenbasierte Programmierung (z.B. Sprachen wie Lisp, Scheme, Haskell);
• logikbasierte Sprachen (da fällt mir nur Prolog ein) ~ und diese müssen anders abgegrenzt werden als über Rekursion.

--arilou (Diskussion) 08:55, 5. Sep. 2019 (CEST)

Ist gut! --Nomen4Omen (Diskussion) 11:35, 5. Sep. 2019 (CEST)

In der rein funktionalen Programmierung findet ja Wiederholung durch Rekursion statt, daher wäre die Abgrenzung begründbar. Bei der rein logikbasierten Programmierung handelt es sich ja lediglich um eine deklarative Datenbank für Aussagen, die mit Backtracking ausgewertet wird. Ich weiß nicht, inwieweit das ein Gegenstück sein soll, da die logische Auswertung ja nicht von Iteration oder Rekursion losgelöst ist... --Diaspomod (Diskussion) 02:42, 12. Okt. 2019 (CEST)

Ich glaube, Diaspomod hat Recht. Die Unterscheidung rekursiv vs iterativ ist auf wesentlich niedrigerer Ebene (viel näher an der Maschineninstruktion, an der Realisierung auf heutigen Computern) als funktional vs deklarativ. Ich halte für möglich, dass sich letztere sowohl rekursiv wie iterativ implementieren lassen. Ganz vergessen wurde in diesem Kontext die »AI«, whatever that is. --Nomen4Omen (Diskussion) 09:29, 12. Okt. 2019 (CEST)

Soweit ich das sehe, ist die Unterscheidung "funktional vs. iterativ" voll auf Hochsprachen-Ebene;

Diaspomod zeige mir in einem Prolog-Programm, wo genau da der Programmierer entweder eine Rekursion oder eine Schleife programmiert.

--arilou (Diskussion) 12:18, 23. Okt. 2019 (CEST)

in Prolog:

recursion(Counter, End) :-
    Counter =< End,
    write('Hello, world!'),
    Next is Counter + 1,
    recursion(Next, End).

die gleiche Semantik in C:

#include <stdio.h>

void recursion(int counter, int end) {
    if (counter <= end)
        puts("Hello, world!");

    recursion(counter + 1, end);
}

Wie möchtest du die logische von der funktionalen Programmierung abgrenzen? Ich habe ja nirgendwo ausgeschlossen, dass man das könnte...--Diaspomod (Diskussion) 17:12, 3. Nov. 2019 (CET)

Dann musst du nur noch den Unterschied zwischen funktionaler vs deskriptiver vs maschinennaher Programmiersprache und funktionalem vs rekursivem vs prozeduralem vs iterativem Programmierstil herausarbeiten. --Nomen4Omen (Diskussion) 12:49, 23. Okt. 2019 (CEST)

Nun, wie Diaspomod gerade gezeigt hat, kann man in der logikbasierten Sprache Prolog durchaus in rekursivem Stil programmieren. Common Lisp hat das loop-Makro, das iterative Problemlösungen erlaubt; und in z.B. C kann man sich im Wesentlichen frei aussuchen, ob man ein Problem lieber rekursiv oder iterativ lösen will.

Iterative Programmierung kann also durchaus stattfinden in einer (weitgehend) funktionalen Sprache.

Ich finde, es muss unterschieden werden zwischen "welches Konzept wird von einer Sprache (stark) begünstigt?" vs. "welches Konzept hat der Programmierer angewendet?" - das muss nämlich nicht deckungsgleich sein.

--arilou (Diskussion) 14:32, 7. Nov. 2019 (CET)

In Prolog ist die Rekursion keine funktionale Erweiterung, sondern inhärenter Bestandteil. Ohne rekursive Defintionen könnte man keine symmetrischen Relationen definieren wie:

f(X, Y) := f(Y, X).

Ohne die Möglichkeit der Wiederholung durch rekursive Regeln wäre Prolog nicht turingvollständig und wäre wie HTML überhaupt keine Programmiersprache.

Das abstrakte Konzept der Rekursion ist die der funktionalen oder logischen Programmierung (Sprache/Stil) übergeordnet.

Außderdem unterstützen die populären Sprachen meistens sowohl das iterative, als auch rekursive Konzept. Das heißt nicht, dass die Konzepte voneinander nicht zu unterscheiden wären.

Common Lisp ist auch nicht rein funktional, da es Seiteneffekte zulässt. --Diaspomod (Diskussion) 19:02, 8. Nov. 2019 (CET)

Endrekursion

Die Klammer "(bei Endrekursion)" muss mE weg, da der Selbstaufruf eine Abbruchbedingung auch dann braucht, wenn in der Prozedur nach ihm noch irgendwas gemacht wird. –Nomen4Omen (Diskussion) 14:48, 20. Apr. 2021 (CEST)

Weg sowieso, denn so etwas sollte in rekursive Programmierung stehen. Es steht dort aber garnichts davon
--Idohl (Diskussion) 18:07, 20. Apr. 2021 (CEST).

Im Artikel steht: "[Rekursion,] die dadurch (bei Endrekursion) unendlich oft ausgeführt werden könnte."

@Nomen4Omen: Die Klammern könnte man weglassen, richtig, womit im Artikel dann stehen würde "die dadurch bei Endrekursion unendlich oft ausgeführt werden könnte". Ich nehme an, dass du das so gemeint hast.

@Idohl: Zuvor stand im Artikel "[Rekursion,] die dadurch unendlich oft ausgeführt werden könnte". Eine Endlos-Rekursion ist ein Sonderfall der Rekursion, der nur extrem selten Anwendung findet, und nur bei Endrekursion funktioniert. Wenn die Aussage "unendlich oft" bleiben soll, dann muss dabei die Einschränkung 'Endrekursion' genannt werden; alternativ kann von mir aus auch der ganze Halbsatz "unendlich" weg.

Dieser extrem seltene Sonderfall der Rekursion ist eigentlich auch nur deswegen hier im Artikel nennenswert, weil Endlos-Schleifen gegelentlich vorkommen - sie sind zwar auch ein Sonderfall, aber deutlich weniger selten als eine echte, gewollte Endlosrekursion.

Ich persönlich finde die aktuelle Variante mit Klammern am besten - als Verfasser aber evtl. aus befangener Situation ;-)

--arilou (Diskussion) 09:35, 21. Apr. 2021 (CEST)

PS: @Idohl: Der Artikel Rekursive Programmierung ist nicht perfekt, richtig. Auf Endrekursion wird nur bei "Siehe auch" verlinkt.

@Arilou: Eine Endlos-Rekursion ist ein Sonderfall der Rekursion.
Dieser Satz von Dir drückt Deine Befangenheit aus: Du gehst nicht davon aus, dass Rekursion ein prinzipiell endloser Vorgang ist, sondern dass ein nicht zu Ende kommendes Computer-Programm des Teufels ist.
--Idohl (Diskussion) 12:40, 21. Apr. 2021 (CEST)

Befangenheit ~hm~ nuja. In 35 Jahren Programmierarbeit ist mir bisher noch nie eine echte gewollte Endlosrekursion untergekommen.

Echt gewollte Endlosschleifen zwar selten, aber so an zwei Händen abzählbar, meist bei Microkontrollern, die auf Interrups warten sollten.

Ein gewollt nicht zu Ende kommendes Computerprogramm? Hm, da fallen mir vor allem Spiele im Konsolenbereich ein, oder wieder Microkontroller-Steuerungen. Auf Anwender-PCs, Servern o.ä. fällt mir keine Programmgattung ein, bei der es nicht sinnvoll wäre, ihr eine vernünftige Möglichkeit eines geordneten Beendens zu gewähren.

Ansonsten bin ich doch eher ein Mensch der Praxis. "Prinzipiell endlos" ist ungleich "tatsächlich in der Praxis endlos".

--arilou (Diskussion) 13:16, 21. Apr. 2021 (CEST)

Genau: 35 Jahre sind zu viel, um nicht befangen zu werden. Danach dauert es umso länger, um wieder davon los zu kommen.
--Idohl (Diskussion) 00:29, 22. Apr. 2021 (CEST)

In meinen Augen kommen da jetzt mehrere Missverständnisse zu Tage.

1. Das einfachste: Ich habe nicht gemeint, dass die Klammern wegsollen, sondern dass die ganze Endrekursion in diesem Artikel nichts zu suchen hat. Es genügt, wenn sie im Artikel Rekursive Programmierung vorkommt.
2. Endrekursion hat mit Endlos-Rekursion rein gar nichts zu tun. Im Artikel Rekursive Programmierung steht, dass eine Rekursion (ein Selbstaufruf) dann als Endrekursion bezeichnet wird, wenn sie die letzte Anweisung der Prozedur ist, dann kann man sich nämlich einmal das Abspeichern des Kontextes sparen (diese Def stimmt m.E. mit der in enwiki überein) und sonst noch ein bisschen rumoptimieren, wie in Endrekursion#Beispiele​ gezeigt. Wenn es aber in der Prozedur Anweisungen gibt, die der aufrufenden Instanz (bspw. per Parameterrückgabe) signalisieren, dass die Sache erledigt ist, dann hat man die Abbruchbedingung. Und diese können vor oder nach dem Selbstaufruf stehen, bedürfen also keiner Endrekursion.
3. Die Formulierung einer Bedingung für einen Abbruch garantiert nicht, dass diese in irgendeiner Instanz greift. Anders gesagt: auch eine Prozedur mit einem if Bedingung then Abbruch, kann endlos laufen, wenn die Bedingung nicht erreicht wird.

–Nomen4Omen (Diskussion) 17:00, 21. Apr. 2021 (CEST)

Ok, mal eine Gegendarstellung aus der Praxis: Eine rekursive Prozedur, die (gewollt oder ungewollt) endlos rekursiv aufgerufen wird, und keine Endrekursion ist, verbraucht bei jedem Rekursionsaufruf Ram. Sofern sie keine allzu umfangreichen Aktionen durchführt, ist selbst eine Computer-Ausstattung mit z.B. 64GB Arbeitsspeicher in Sekunden voll, was ja wohl weit abseits von "endlos" ist.

Wenn dann auf die SSD geswappt werden muss, kann mit ca. 1GB/s geschrieben werden, womit eine 512GB-SSD in weniger als 10 Minuten ebenfalls voll ist. Und dann Ende von "endlos".

Eine Endrekursion verbraucht nur beim Erst-Aufruf Ram, danach kein weiteres Ram mehr, wenn der Compiler ausreichend schlau optimiert. Sie kann monatelang auf einem Rechner ausgeführt werden und tatsächlich eine iterative Endlosschleife ersetzen. Es gibt Rechner und Programme, die jahrelang ununterbrochen laufen sollen/müssen.

Da es in diesem Artikel um Iteration, also Schleifen, geht, und die Endlosschleife einen nicht vernachlässigbaren Spezialfall darstellt, sehe ich eine gewisse Sinnhaftigkeit, die rekursive Variante zu erwähnen, die eine Endlosschleife tatsächlich ersetzen kann.

--arilou (Diskussion) 09:32, 22. Apr. 2021 (CEST)