On Tue, Jul 14, 2015 at 3:15 PM, Paul Rubin <no.email@nospam.invalid> wrote: > Chris Angelico <ros...@gmail.com> writes: >> I'm not sure why the transition to another state has to be recursive. > > It's not recursive: it's more like a goto with arguments, and a tail > call expresses it nicely.
Hmm, maybe, but I'm not sure that the transition to another state is a goto with arguments. What triggers the transition? Is it a linear protocol? Is it a nested protocol that completes some operation and returns to a base state? How are these transitions recognized, and why is that needing a "goto with arguments" to express it? >> Maybe this is something where previous experience makes you more >> comfortable with a particular style, which will mean that functional >> idioms will never feel more comfortable to me than iterative ones do, >> and vice versa for you. If that's the case, then I'll stick with >> Python and Pike, and you can happily use Lisp and Haskell, and neither >> of us need be a problem to the other. > > Do you also use explicit loops instead of list comprehensions? They are > another nice functional idiom adapted into Python. I use list comprehensions, but that's not the same thing as using functional programming. What that means is that there's nothing that we can't learn from. I'm glad functional languages exist, where people try to make everything have no side effects and be deterministic; it's a good discipline, and worth being aware of even when your language doesn't enforce it. But just because functional languages like to say "take this array and multiply every element by 4" and I like using that same feature, that doesn't mean that I want to do everything in a functional style. Here's an alternative way of expressing that thought. Do you write code such that each line does one simple thing? That's a nice assembly language practice that's been adapted into Python. Assembly languages tend to enforce a "one line, one operation" rule. Python programmers often adhere to that (you don't generally see a bunch of stuff separated by semicolons, and even "for line in lines: print(line)" is frowned upon - add a newline!), but that doesn't mean we want all the other trappings of assembly languages. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
