I find it much easier to reason about loops than to reason about recursion. Likewise I find it much easier to write loops than to write recursive functions.
It probably comes down to experience mainly. I spent some time with functional languages, but I have spent far far far more time writing imperative procedural code.
The language would have to change for you to be able to code a loop. And that would have all sorts of consequences: in Erlang, preemption happens at function calls and no loops means a bounded time until you make a function call or terminate, with loops, that changes and preemption gets more difficult.
I didn't think this was true. The secret sauce was that Erlang preempted on reduction counts, so as a result nothing has any responsibility to yield itself.
edit: ah, literally no difference between the two in the implementation.
If you take out enough simplifying implementation details, you no longer have a powerful system built from simple parts.
There are two camps of programmers:
1) Ones who are used to writing such algorithms (e.g. in Lisp) who cry bloody murder because they can't use them in Python. It's painful to lose that type of expressiveness.
2) Ones who have never used them, and don't realize what they're missing. These will usually complain about surface issues (like nicer stack traces for debugging).
Camps like camp #2 comes up a lot in history.
- In the eighties and nineties, most BASIC programmers had never used pointers, references, or real data structures, and saw them as abstract theoretical constructs without any real-world use.
- C / C++ programmers would call Java programmers lazy for wanting garbage collection (ignorant of the broad set of algorithms enabled if you don't need to keep track of when memory is no longer needed manually).
- Java / C / C++ programmers saw closures and a lot of other functional tools as pointless, complex, theoretical abstractions, until Python / JavaScript / etc. ate their lunch.
- Many people who have never used relational databases before see them as pointless complexity for most systems, aside from very specific use-cases.
... and so on. The other argument always made hinges on the Turing Completeness of languages ("I'd like to do X!" "Well, here's how you do it without Y. If you were just more clever, you'd see why Y is useless complexity.") You can ALWAYS implement any use case in any Turing-complete language. BASIC programmers stuck things into arrays. Java/C++ programmers could use objects instead of a closure. And tail-recursive code can always be translated into iteration.