[zelphirkalt]

About FP in Python I always feel like trying and I do make use of some of the ideas, like avoiding a lot of mutation, but the lack of TCO then makes me feel "Meh … it's not so nice actually.". No TCO is in my opinion a huge bummer when trying to do FP.

[fnord123]

I think TCO is a party trick. Recursion in FP is almost always about structure traversal. For this iterators are usually better:

1. You separate concerns of traversal and computation.

2. You can reuse a function that takes an iterator and use it on any container. In recursive functions you generally specify the next item in the structure explicitly.

3. You can edit code on functions that take an iterator without accidentally removing the TCO.

I used to believe that iterators and higher order functions were the dual of each other (each can become a 'poor man's' version of the other (cf famous scheme koan[1])). Stepanov's Elements of Programming convinced me (whether that was his goal) that iterators are superior.

[1] http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

[2] http://elementsofprogramming.com/

[smabie]

I'm not sure exactly what you mean by iterators, but I agree that TCO isn't that important. Like you said, most of FP is the traversal of collections. Map, scan, and foldr/foldl should be sufficient to solve the vast majority of problems.

If you find yourself reaching for TCO, it usually means that you're mission a collection combinator.

I actually find myself using TCO really only when grinding leet code problems in order to achieve n, log n, or n log n complexity. In the real world, it's rarely ever needed. And if it is, you could always use a free monad instead.

[smabie]

TCO isn't really important. It's pretty rare that you ever need to use recursion in FP. the vast vast majority of the time, folds, scans, and maps should be sufficient.