往往有這樣的觀點：能不用遞歸就不用遞歸，遞歸都可以用叠代來代替。
誠然，在理論上，遞歸和叠代在時間復雜度方面是等價的（在不考慮函數調用開銷和函數調用產生的堆棧開銷），但實際上遞歸確實效率比叠代低，既然這樣，遞歸沒有任何優勢，那麽是不是就，沒有使用遞歸的必要了，那遞歸的存在有何意義呢？ 萬物的存在是需要時間的檢驗的，遞歸沒有被歷史所埋沒，即有存在的理由。
從理論上說，所有的遞歸函數都可以轉換為叠代函數，反之亦然，然而代價通常都是比較高的。但從算法結構來說，遞歸聲明的結構並不總能夠轉換為叠代結構，原因在於結構的引申本身屬於遞歸的概念，用叠代的方法在設計初期根本無法實現，這就像動多態的東西並不總是可以用靜多態的方法實現壹樣。
這也是為什麽在結構設計時，通常采用遞歸的方式而不是采用叠代的方式的原因，壹個極典型的例子類似於鏈表，使用遞歸定義及其簡單，但對於內存定義(數組方式)其定義及調用處理說明就變得很晦澀，尤其是在遇到環鏈、圖、網格等問題時，使用叠代方式從描述到實現上都變得不現實。 因而可以從實際上說，所有的叠代可以轉換為遞歸，但遞歸不壹定可以轉換為叠代。
采用遞歸算法需要的前提條件是，當且僅當壹個存在預期的收斂時，才可采用遞歸算法，否則，就不能使用遞歸算法。
遞歸其實是方便了程序員難為了機器，遞歸可以通過數學公式很方便的轉換為程序。其優點就是易理解，容易編程。但遞歸是用棧機制實現的，每深入壹層，都要占去壹塊棧數據區域，對嵌套層數深的壹些算法，遞歸會力不從心，空間上會以內存崩潰而告終，而且遞歸也帶來了大量的函數調用，這也有許多額外的時間開銷。所以在深度大時，它的時空性就不好了。
而叠代雖然效率高，運行時間只因循環次數增加而增加，沒什麽額外開銷，空間上也沒有什麽增加，但缺點就是不容易理解，編寫復雜問題時困難。
因而，“能不用遞歸就不用遞歸，遞歸都可以用叠代來代替”這樣的理解，還是辯證的來看待，不可壹棍子打死。