Hacker News Reader

Comment by damon | Hacker News Reader

According to Guido, he wants to drop functional programming constructs in Python.

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

What's interesting is the reasons he gives:

"Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't -- I still recall Laura Creighton's Aha!-erlebnis after I showed her there was no difference! Even with a better name, I think having the two choices side-by-side just requires programmers to think about making a choice that's irrelevant for their program; not having the choice streamlines the thought process."

Basically he wants to dumb down the language to make it more appealing to the mainstream programmer crowd. He wants another java. In the end, I think that mentality is a death sentence for the language.

View on HN

People continue to bring this post up. It is 2 years old, and Guido has said he will not be dropping functional constructs in Python.

And the reason he wanted to remove them is not because he wants to 'dumb down' the language, but rather because list comprehensions do what filter/map/reduce can do 9 times out of 10 but end up a lot more legible. He says as much in that post. But again, if you really want those functions, they still exist in Python and will exist in the future.

I was under the impression (from documentation, not from experience) that map/filter were the more "optimal" way to do things when you had a choice. I certainly find them more intuitive then the alternatives.

Another feature is the nested defines - that is quite nice (considering that you can put very little into a lambda).

Higher-order functions do entail a sacrifice to readability compared with plain loops. The reason should be fairly obvious: loops use indentation and syntax to show visually the structure of what they do, but that goes away when you pack the logic into a higher-order function. A function call is a function call; they all look the same.

Fortunately, there exist solutions to this problem. The Haskell solution is to make your code so damn concise that you don't need to add any structure to it. The Lisp approach is to allow you to program the representation of your code in arbitrary ways.

Both are, I think, superior to the Python solution, which is simply to revert back to the imperative style.

>Higher-order functions do entail a sacrifice to readability compared with plain loops.

I disagree with you there. If you understand that Map, Reduce and Filter (for example) are essentially loops, using them greatly increases code readability. Instead of having to read loop code, you're just reading code that describes what you're doing to the data.

EDIT: I know this is going to sound weird, but I recently implemented Map, Reduce and Filter in VB.NET. Aside from the fact that using .NET delegates is clumsy, the code portions that use those methods are much more concise (and readable).

It is easy to add features to a language. It takes courage to take features away. If you just add every feature than anyone might want, then you end up with something like Perl. Which incidentally seem to be much more popular than Python, so maybe Larry Wall have a point.

By "dumbing down" I assume you mean "looks less like lisp". You can do the same as map and filter in a more elegant and pythonic way using generator expressions.

Btw. he was just thinking aloud. In the end he just moved map and filter out of the core language and into a library, and lambda stayed.

From what I can tell, Python has always had this mentality. I think lambdas are a rather minor issue anyway. If you're going to slam Python for 'dumbing things down' to appeal to a 'mainstream programmer crowd' you can probably find better ammunition.

Reply on news.ycombinator.com