Comment by boothead | Hacker News Reader

Comment by boothead | Hacker News Reader

Parent Full thread

I love libraries like this and fn.py, and I really miss the things I've got used to having available in Haskell when I write python. It's possible to use function patterns in python (Applicative and Functor are things you can implement in any language). However given who is in charge of python and the way he feels about FP, I don't think python will ever be a decent functional programming environment:

  As long as I'm "in charge" the chances of this (or anything like it) being accepted into
  Python are zero. I get a headache when I try to understand code that uses function
  composition,  and I end up having to laboriously rewrite it using more traditional
  call notation before I move on to understanding what it actually does. Python is not
  Haskell, and perhaps more importantly, Python users are not like Haskell users.
  Either way, what may work out beautifully in Haskell will be like a
  fish out of water in Python.

  I understand that it's fun to try to sole this puzzle, but evolving Python is more than
  solving puzzles. Enjoy debating the puzzle, but in the end Python will survive
  without the solution.

http://stackoverflow.com/questions/1017621/why-isnt-python-v...

Function call is somewhat expensive in Python compared to most languages, so I guess there are reasons other than personal taste for why functional composition is not blessed.

It seems to me function composition does similar thing as inheritance. I don't know about other (more higher?) functionnal patterns.

Side note: I already had to write or copy/paste most of the function of pytoolz already once at least.

Inheritance is quite heavy and static. FP idioms are full of tiny combinators to assemble pieces of logic to suit your needs, flip/reorder parameters, "cache" them through partial application. The historical reusable code that OOP claimed through the 90s seems much more real using FP. OOP is too verbose and too name-friendly, people create lots of classes not abstract enough to be used anywhere else, closer to concrete types than abstractions.

Not really - but it does let you chunk functionality together from smaller pieces.

So if you have function f1 that takes a and returns b (a -> b) and a function f2 that takes b and returns c (b -> c) you can compose them into a function (a -> c) all it does is call f2(f1(a))

I just hope he (and his successors) maintain the same uncompromisingly critical approach when it comes to adding features to the language..

I think the lack of some things like this, is a sort of reminder to the programmer that says, "hey you, you are writing Python. Not Haskell. Do not go that way because we don't have stuff to deal with what you may find further down that road".

Nothing ruins a language like adding a bunch of poorly thought out half baked features, that does not fit well with the rest of it...

And yet a language has to evolve or become obsolete...

Which is not the same as "a language must evolve into my preferred design or become obsolete".

Python has made it through years of criticism from people who misunderstand Guido's stance on FP in Python (and before that from people who disliked his stance on tail call optimization) without being obsoleted by pure FP languages.

I would argue that the really necessary evolution is often in implementation facilities, rather than core language constructs. C++ has evolved more than most, but people who don't choose C++ do it mostly because of other considerations. You could have the most functional C++ version ever, and still people would not use it for simple web apps.

Which, like apoptosis, is eventually a good thing.

Reply on news.ycombinator.com