Zitat:
Dann müßte die Assemblerprogrammierung erst recht ohne Existenzberechtigung dastehen!
Viel wird ja heute wirklich nicht mehr in Assembler programmiert - Sinnvoll ist das wirklich nur mehr bei sehr wenig oft durchlaufenem extrem zeitkritischem Code. Ungeschickte Umsetzung des Algorithmus ist meistens eine wesentlich schlimmere Tempobremse als die im Vergleich zu Assembler geringere Effizienz des Compiler-generierten Codes. Und auch der Overhead, der durch Rekursionen entsteht, ist meistens vernachlässigbar - zugegebenermassen nicht immer, im Beispiel Fibonaccizahlen wäre eben eine "beinhart durchgezogene Rekursion" ein krasses Beispiel von ungeaschickter Umsetzung.
Wichtig ist in meinen Augen, dass Code möglichst leicht verständlich ist. Wenn eine Vorgangsweise sich rekursiv leichter beschreiben lässt als iterativ, dann wird auch das rekursive Perogramm leichter verständlich sein als eine Variante, in der die Rekusion manuell mit einer Reihe von zusätzlichen Schritten, wie einer manuellen Stackverwaltung, zu einem iterativen Verfahren aufgelöst wird. Aber die Erkärung "Multipliziere alle Zahlen von 1 bis n miteinander" ist leichter und unmittelbarer verständlich als "Für die Zahl x=1 ist das Ergebnis =1, Für x>1 nimm den Funktionswert f(x-1) und multipliziere den mit x", deshalb ist in dem Fall der iterative Ansatz vorzuziehen.
Ich sehe das ähnlich wie beim goto-Statement. Prinzipiell sollte man goto vermeiden, und zwar deshalb (und NUR deshalb), weil ein Label beim Studium eines Programms und bei der Fehlersuche zusätzliche Aufmerksamkeit erfordert (Woher wird der Label angesprungen, gibt es vielleicht noch andere Stellen im Programm, die zu diesem Label verzweigen, auf welche Invarianten kann ich mich verlassen, wenn der Code, der auf den Label folgt, durchlaufen wird, etc.). Andererseits, wenn ich eine mehrfach geschachtelte Schleife verlassen will, ist mir ein Label hinter der Schleife immer noch viel lieber als eine Krampflösung mit drei booleans und 4 zusätzlichen Abfragen - das kostet nämlich noch viel mehr Aufmerksamkeit als die Verwendung eines Labels, und darum geht es doch nach vor allem.
Natürlich gibt es Sonderfälle. Die eben angeführte Fibonaccizahl ist ein solcher, bei Problemen im wirklichen Leben ist so etwas eher selten. Es ist dieses Beispiel aber auch ähnlich einer Tail call Rekursion, wenn auch mit zwei rekursiven Aufrufen, weshalb sich hier der iterative Ansatz von vorneherein anbietet. Selbstverständlich wird man immer, wenn Teilergebnisse wiederholt benötigt werden, diese puffern, dann ist der rekursive Algorithmus wahrscheinlich nicht viel langsamer als der iterative (würde aber in diesem Sonderfall wirklich ordentlich mehr Speicher fressen, weil beim iterativen Ansatz immer nur die letzten beiden berechneten Werte gespeichert werden müssten.