> Mylisz się.
> Pewne strategie implementacji rekurencji działają wolniej
> (i zużywają więcej zasobów) od typowych strategii implementacji
> iteracji, i tyle.
> Istnieją strategie, pozwalające implementować rekurencję
> ogonową (czyli taką, która realizuje iterację) bez narzutu.

Tak, jak kompilator zamieni rekurencję na iterację, to działa tak szybko, jak
iteracja. Nie jest jednak prawdą, że bez narzutu, bo tym narzutem może być też
większy koszt kompilacji i optymalizacji kodu. Bo co przepłacać?
Natomiast iteracja zawsze działa tak szybko, jak iteracja. I zawsze jest tak tania,
jak iteracja.

> > Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej.
>
> W jaki sposób chciałbyś uzasadnić, że była prostsza?

Już pisałem: mniej liter, krótsza gramatycznie, nie odwołuje się do definiowanego
pojęcia.

> > Moja iteracyjna metoda wyboru elementów z listy też była prostsza.
>
> W jaki sposób chciałbyś uzasadnić, że była prostsza?

Ma mniej liter? Mniej razy się pomylę? Mniej bugów będę tam poprawiał?

> > Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty element?
>
> Pewnie musiałbym zmienić więcej.

To zmień i pokaż. Bo szczerze mówiąc nie za bardzo mi się chce szarpać w
nieskończoność o filozofię natury, istoty, prostoty, czy czego tam.
Na razie niczego użytecznego w tej dyskusji nie ustaliliśmy.

> Co nie oznacza, że Twoje rozwiązanie
> jest prostsze, tylko to, że Twoje rozwiązanie można łatwiej dostosować
> do pewnej klasy zmian wymagań (z czym się zasadniczo zgadzam)

To też jest użyteczna miara prostoty. Jeśli coś można łatwiej do czegoś dostosować,
to chyba dobrze, co? Po co przepłacać?

Jeszcze raz, co dziesiąty z szeregu wystąp: x[[1;; ;;10]].

Pokaż wersję rekurencyjną i uzasadnij, że zawsze będzie to rekurencja ogonowa, bo
przecież nie chcemy, żeby tak prosta rzecz działała wolniej, niż potrzeba.

--
Maciej Sobczak * http://www.inspirel.com