Comment by SiVal | Hacker News Reader

Comment by SiVal | Hacker News Reader

Parent Full thread

I was at a Python user group meeting with Guido a few years back, and I asked him about his plans for functional programming support in Python. He responded that he thought functional programming was a lot less useful than all the hype would suggest, and that, far from planning more support for functional programming, he regretted having put in as much support as he already had. Ideally, he said, he would remove things like lambda instead of making them stronger.

Even things like tail call elimination, he said, would just encourage people to use more recursion, when iteration was easier to read, and in places where TCE would work, the programmer could obviously convert it to iteration himself and should do so for code clarity.

I like Python, and I like a lot of things about functional programming, so it wasn't the answer I was hoping for. Unless Guido has had a change of heart since then, I wouldn't pin my hopes on Python ever becoming a first-rate functional programming language. It's first rate at the things Guido values.

Python has added list and set comprehension syntax, which are just as functional as eg. map and filter. So I don't think it is functional constructs in general he is against, but rather specifically the lispy idioms with map, filter etc. with functions/lambdas as arguments.

Decorators are another example of functional programming added to Python, but with a pythonic syntax.

Python supports both imperative, OO and functional idioms, but generally only prefers one of them for a specific task. For example loops are preferred to recursive functions when appropriate. Objects are preferred to closures for mutable state, so mutation of captures variables has not been supported (support have been added recently with nonlocal, but it has clearly not been a priority).

Python is interesting because it is multiparadigm while trying to avoid fragmentation where you can solve the same problem in totally different styles.

I wish he would add TCE for the sole fact that parsing tree like structures feels much more natural using recursion than it does with a for loop. I am always paranoid that a really deep structure will cause an stack depth exceeded exception.

There's a quote from Guido about private attribute access where he said, "We're all adults", and that leaving the open is beneficial.

Recursion is another tool that he should let us adults use if it solves a problem better and TCE is lovely feature to have. Frankly, if you're using recursion, you either just learned it in a CompSci class or you know what you're doing. Either way, daddy Guido shouldn't tell us no :).

You can use an explicit trampoline to make sure you don't block the stack. It's not as clean, but still better than loops.

I don't know. It seems to me, from reading SICP, that functional programming doesn't mean lambdas or map reduce, it means pure functions as the main programming unit, instead of object or instruction or declaration. Then it is possible to write functional code in python without lambdas, map, using streams (iterators) as the state keeping data structure.

The problem, as always in these discussions, is that no-one wants to define the term "functional programming". Many people will be quite willing, though, to jump on each other for saying things that they believe flow from an incorrect definition of the term.

Anyway, at the very least there's two camps. On the one side, you have the hardcore Scheme folks whose conception of functional programming is "if I can't figure out how to write it with tail recursion it must not be computable". On the other side you have the Haskell folks whose conception of functional programming is "a monad is just a monoid in the category of endofunctors, what's the problem?"

Somewhere in between are people who actually get things done.

Maybe there is a difference between functional programming and functional programming languages.

Same thing happened with OO, where people have been discussing whether C++ or JavaScript or Python or Smalltalk are "real OO", rather than discussing if the patterns they support are useful or not.

Reply on news.ycombinator.com