3 ms·

I’m not sure what you mean, what about python is notoriously unfunctional?

darkpuma 8y ago
It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, python still doesn't have multi-line lambdas, and the justifications for why always boil down to it being "unpythonic". Furthermore over the years Guido has made it pretty clear that he doesn't particularly like or care about functional programming: https://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html https://python-history.blogspot.com/2009/04/origins-of-pytho...
- pseudalopex 8y ago
  Requiring complex functions to have names isn't hostile to functional programming.
  - darkpuma 8y ago
    It really is though. It doesn't prevent it, but it sure as shit doesn't encourage it.
    - fulafel 8y ago
      Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not? I've actually started wishing for the opposite change in my use of Clojure. There, it is currently optional to supply a name for the fn form. Always supplying the name, like in "(fn add-42 [x] (+ x 42))", would make stack traces more readable and the named function object would be easy to identify when it appeared in the REPL / pretty-printed data structures.
      - darkpuma 8y ago
        > "Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not?" Not being able to define a two-line function in the place where it's used because you have to give it a name discourages FP in a way many other modern languages do not.
        stormking 8y ago
        Not really, since Python can nest functions: def something(x): def myfunc(y, z): ... return result reduce(myfunc, x) So the difference is like having to write x = some_very_complex_expression_that_can_get_quite_long some_function(x) instead of some_function(some_very_complex_expression_that_can_get_quite_long) In many cases this may make code even more readable. I'm not saying that Python's lambdas are perfect as they are or that multi-line lambdas would be a bad thing. I'm just saying it's not as bad as you paint it.
    - pseudalopex 8y ago
      It subtly discourages functional programming when a for loop would be faster and more readable.
      - darkpuma 8y ago
        > more readable 'More readable' is subjective. It's clear that Guido and much of the Python community believe that FP is less readable, less pythonic, and that viewpoint is exactly the sort of hostility towards FP that I'm talking about. And in no small part this is a self-fulfilling attitude, e.g. "python lambdas are ugly because pythonistas believe FP is ugly." They're way uglier in python than in other languages. The ugliness of python's lambda is a trait of python, not a trait of FP, yet it's ugliness cited to justify itself. > when a for loop would be faster Hey, that's fine. But I think much of the time for the sort of things I'm working on, that's deep into "premature optimization" territory. I'd rather a slight linear slowdown with more readable code than a slight linear speedup with less readable code. I'd prefer that python not "subtly discourage" me to nudge me towards less readable code because a list comprehension is marginally more performant.
      - fulafel 8y ago
        Python really took the direction of preferring list/generator comprehensions for this kind of thing, encouraging their use over both imperative loops and basic HOFs like map/filter. List comprehensions are declarative and hence functional constructs. Generators also get you another FP checkbox because you now have laziness in a very accessible form. You get building blocks like infinite sequences and so on. And you have access to all the normal primitives like reduce, take, partial, groupby etc in the itertools/functools std modules.
AlexCoventry 8y ago
The built-in data structures often force in-place mutation on code which wants to be in any way efficient.

It's capable of functional programming in the sense that functions are first class values that you can pass around, but it is infamously hostile to functional programming. For example, python still doesn't have multi-line lambdas, and the justifications for why always boil down to it being "unpythonic". Furthermore over the years Guido has made it pretty clear that he doesn't particularly like or care about functional programming: https://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html https://python-history.blogspot.com/2009/04/origins-of-pytho...

pseudalopex 8y ago
Requiring complex functions to have names isn't hostile to functional programming.
- darkpuma 8y ago
  It really is though. It doesn't prevent it, but it sure as shit doesn't encourage it.
  - fulafel 8y ago
    Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not? I've actually started wishing for the opposite change in my use of Clojure. There, it is currently optional to supply a name for the fn form. Always supplying the name, like in "(fn add-42 [x] (+ x 42))", would make stack traces more readable and the named function object would be easy to identify when it appeared in the REPL / pretty-printed data structures.
    - darkpuma 8y ago
      > "Allowing to elide the add42 from "def add42(x): x+42" makes the difference between encouraging FP or not?" Not being able to define a two-line function in the place where it's used because you have to give it a name discourages FP in a way many other modern languages do not.
      - stormking 8y ago
        Not really, since Python can nest functions: def something(x): def myfunc(y, z): ... return result reduce(myfunc, x) So the difference is like having to write x = some_very_complex_expression_that_can_get_quite_long some_function(x) instead of some_function(some_very_complex_expression_that_can_get_quite_long) In many cases this may make code even more readable. I'm not saying that Python's lambdas are perfect as they are or that multi-line lambdas would be a bad thing. I'm just saying it's not as bad as you paint it.
  - pseudalopex 8y ago
    It subtly discourages functional programming when a for loop would be faster and more readable.
    - darkpuma 8y ago
      > more readable 'More readable' is subjective. It's clear that Guido and much of the Python community believe that FP is less readable, less pythonic, and that viewpoint is exactly the sort of hostility towards FP that I'm talking about. And in no small part this is a self-fulfilling attitude, e.g. "python lambdas are ugly because pythonistas believe FP is ugly." They're way uglier in python than in other languages. The ugliness of python's lambda is a trait of python, not a trait of FP, yet it's ugliness cited to justify itself. > when a for loop would be faster Hey, that's fine. But I think much of the time for the sort of things I'm working on, that's deep into "premature optimization" territory. I'd rather a slight linear slowdown with more readable code than a slight linear speedup with less readable code. I'd prefer that python not "subtly discourage" me to nudge me towards less readable code because a list comprehension is marginally more performant.
    - fulafel 8y ago
      Python really took the direction of preferring list/generator comprehensions for this kind of thing, encouraging their use over both imperative loops and basic HOFs like map/filter. List comprehensions are declarative and hence functional constructs. Generators also get you another FP checkbox because you now have laziness in a very accessible form. You get building blocks like infinite sequences and so on. And you have access to all the normal primitives like reduce, take, partial, groupby etc in the itertools/functools std modules.

AlexCoventry 8y ago

The built-in data structures often force in-place mutation on code which wants to be in any way efficient.