Hacker News new | past | comments | ask | show | jobs | submit login

> [recurrence] is not very intuitive and frankly is a programming anti-pattern in my view. [...] Reusing the previous step ... should only be done when absolutely necessary

Thanks, that's my main concern (fp was just an example). Would you agree the reason it is bad is becase there is more to track mentally in the execution model? (i.e. the intermediate results).

I think a complex execution model is problematic in general (it sounds obvious when I say it that way).

> which mathematicians love to use so much,

hmm... I was thinking "induction", and believed that fp is the same. .. > But I disagree with you that recursion is the essence of fp

This is BTW now, but that statement surprises me. Can you elaborate? What is the essencd of fp (has it one)?

Is your py version "more functional"? I'm so wedded to the idea that fp=recursion that that's the reason it doesn't seem functional to me. What makes it functional? Just that it's a nested expression (i.e. fn calls)?




Well I guess you could say the essence of FP is working recursively without (mostly) thinking of it, and not having to deal with the sort of control flow necessary for either loops or the kind of self-administered recursion you seem to think of.

The .join() taking the iterator in their example is, if you look closer, very much a fold/reduce repeatedly invoking a join of the thus far assembled string, the next part, and \n. Recursion!

Also rather than mutable i/j variables being incremented (albeit implicitly so in your example), generating a list of all numbers on which to run.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: