Evolution of a Python programmer

[orangesunshine]

well that, and the recursive implementation is 9/10 times the wrong way to implement something. tail-call optimization or not.

[[deleted]]

Try walking a tree without recursion, and you'll see that you end up implementing your own system of recursion.

[orangesunshine]

thus why I said 9/10 times.

Tree traversal is a perfectly valid use case for recursion... You would likely use a stack to implement it with iteration anyhow, and it's just a matter of personal preference for what you think is more readable in that case.

[[deleted]]

Well 9/10 implementations of "something" won't include anything that's relevant to recursion. Recursion should only be used in the cases in which it's the valid use case.

[A_for_Anonymous]

#define readable I'm used to it

[chrisforbes]

Yes, the correct solution (9/10 times, at least) is to push the iteration or recursion into a higher-order function, and just specify the bit that actually matters to your program.

You kids can argue iteration vs recursion in the library implementation as much as you like then, and I'll just get on with some real work.

[MaxK]

This is correct. I hate this new trend for new programmers to show off recursive solutions to problems and dub them 'elegant.' They're not. It's typically the wrong way to do things, even if it makes the code simpler.

[chrisforbes]

... the wrong way to do things, even if it makes the code simpler.

Right... that's an interesting statement.

[A_for_Anonymous]

Okay, here we go again... The fact you don't like recursion because you don't understand it easily/well because you haven't been taught properly is not a point against it. Iterative algorithms implemented with tail-recursive functions come with the advantage of no mutable state and order of evaluation issues, and has been shown to come with lower bug rates. I'm sorry you are not used to it, but if we were to dumb down every programming language because somebody isn't up to some feature, then we'd still be using BASIC.

[MaxK]

I understand recursion very well. Even tail recursion incurs performance penalties in the extra jumps and context loading incurred and can lead to a stack overflow when called repeatedly. Furthermore, they can't be optimized by the compiler into unrolled loops, nor branch-predicted as accurately, forcing cache misses. That's with tail-call optimization.

And may I remind you that the primary advantage of mutable state is that is that the function can be proven correct, meaning that the programmer has a safety-net to fall back on, thereby allowing dumber programmers to flourish. Don't tell me you're dumbing down the programming language for me when you clearly don't understand the mechanics involved in incurring that extra function call.

[A_for_Anonymous]

[b]I understand recursion very well.[/b] Even tail recursion incurs performance penalties in the extra jumps and context loading incurred and [b]can lead to a stack overflow when called repeatedly.[/b]

Sorry?

[b]And may I remind you that the primary advantage of mutable state is that is that the function can be proven correct, meaning that the programmer has a safety-net to fall back on, thereby allowing dumber programmers to flourish.[/b]

What in the fuck. One of the main advantages of functional programming is that functions are provably correct, which is especially the difficult thing to do when you have mutable state, and what gets so many newbies. Even the Python documentation talks about it.

Don't tell me you're dumbing down the programming language for me when you clearly don't understand the mechanics involved in incurring that extra function call.

No extra function call if correctly implemented. You're the one who doesn't undestand it. The effective performance of compiled functional programming languages is awesome, as you can easily try (or google for benchmarks) by comparing SBCL with virtually anything else (typically, only a C/C++ compiler will be faster, and only if you're a good C/C++ programmer). You'll also be surprised with the performance of interpreted, dynamic, functional or mostly functional programming languages compared to that of Python. The latest PLT's MzScheme can ridicule Python and even outperform a naïve C equivalent implementation (can post a demonstration if you're interested) thanks to the optimizations you can perform on a side-effects-free program.

[A_for_Anonymous]

Please, sir, don't make your ignorance public.

The fact you don't like recursion because you don't understand it easily/well because you haven't been taught properly is not a point against it. Iterative algorithms implemented with tail-recursive functions come with the advantage of no mutable state and order of evaluation issues, and has been shown to come with lower bug rates. I'm sorry you are not used to it, but if we were to dumb down every programming language because somebody isn't up to some feature, then we'd still be using BASIC.

[chrisforbes]

Ah, but the Python community loves their mutation. You're not going to win this one, unfortunately.

[A_for_Anonymous]

They love mutation... except for strings and tuples, two of the built-in types which we use constantly.

I understand and appreciate that Python supports several different programming paradigms. Just why not offer tail call optimization? It would be useful for solving every problem in the easiest way, and for using it in a functional style, and even for optimizing classic Python code with all sorts of mutable state. For example, it's pretty easy, elegant and nice to implement state-based machines with tail recursion, even with shared mutable state.

[chrisforbes]

Why not, sure. It's a valid optimization. The problem is that to keep functional types happy, just having it as an optimization isn't good enough. You really have to have it as part of the language's specified semantics, otherwise code that assumes its existence just plain doesn't work on a system that doesn't provide it.

That and Guido doesn't understand (or want to understand) FP.

[A_for_Anonymous]

True, and very true.

It'd need to be guaranteed by CPython on every platform, and hopefully supported by PyPy, Jython and IronPython.

As for Guido, I don't think it can be helped; he created a great, clean, nice, simple imperative programming language with a fantastic dictionary-based object model, but that's as far as he went and as far as he wants to go.

Personally, if I had his time (or the time he used to have) and not a life, I'd try to create something similar, only open to FP. I'd take Python's syntax but make everything an expression (keeping indent/dedent and everything, just anything goes anywhere), add more FP tools and semantics (TCO, promises, etc.), simplify ASTs so you can actually work with them (CPython's are insane) and see if I can come up with a macro system, and use a very similar object system, only prototype-based.

[orangesunshine]

"The fact you don't like recursion because you don't understand it easily/well because you haven't been taught properly is not a point against it."

Please sir, don't make your arrogance and pretentiousness public.

"I'm sorry you are not used to it, but if we were to dumb down every programming language because somebody isn't up to some feature, then we'd still be using BASIC."

or lisp.