5 ms·

Pattern matching is the brainchild of ML. Python, being a multi-paradigm language with the strong functional side, missed this simple in concept and powerful in

Pattern matching is the brainchild of ML. Python, being a multi-paradigm language with the strong functional side, missed this simple in concept and powerful in practice language concept.

jnxx 6y ago
> Python, being a multi-paradigm language with the strong functional side I would doubt that. Surely, things like Numpy are written in a functional fashion, but Python relies very much on statements, iteration, things not being an expression, almost every named symbol except string and number literals being mutable, and there are no block-scoped name bindings which are essential to functional languages. And the attempt to add the latter to Python might end in a far bigger train wreck than C++ is already. Mixing OOP and functional style works, more or less, for Scala, but everyone agrees that Scala is a hugely complex language. And in difference to Python, it has immutable values. What could turn out better would be to create a new language which runs interoperable in the same VM (much like Clojure runs alongside Java and can call into it). And that new language, perhaps with the file extension ".pfpy", would be almost purely functional, perhaps like a Scheme or Hy, without these dreaded parentheses. That would at least leverage Python's existing libraries.
jnxx 6y ago
> Python, being a multi-paradigm language with the strong functional side Coming back to that, just a reminder that lambdas in Python are still gimped, closures do not work as expected because of -- scoping, and core developers in Python 3 tried to remove with "map" and "filter" tools that are considered quite essential for functional programming.
- mumblemumble 6y ago
  I actually wish they had done so. As someone who switches between Python and functional languages, I find Python's "map" and "filter" to be a trap, and have taken to scrupulously avoiding them. The problem is that I expect those functions to be pure, and, in Python, they aren't. They actually can't be, not even in principle, because their domain and range include a core datatype that cannot be interacted with in a pure manner: generators. A generator will change its own state every time you touch it. For example: >>> seq = (x for x in range(1, 11)) >>> list(filter(lambda x: x % 2 == 0, seq)) [2, 4, 6, 8, 10] >>> list(filter(lambda x: x % 2 == 1, seq)) [] In a language that is a good fit for functional programming, the last statement would return [1, 3, 5, 7, 9], not an empty list. But Python is imperative to the core, so much so that I would argue that trying to use it as a functional language is like trying to drive screws with. . . not even a hammer. A staple gun, maybe? (Which isn't to say that you can't successfully use some functional techniques in Python. But it's best done in a measured, pragmatic way.)
  - Tarean 6y ago
    To be fair, that's a foot gun in haskell as well. Using lists non-linearly like this in haskell gives you the correct results but at a 10x performance tax or worse because it can't optimize into a loop anymore.
    - mumblemumble 6y ago
      At least to me, a footgun goes beyond a mere performance gotcha. There's a whole category difference between, "If you do this, the compiler may not be able to optimize your code as well," and, "If you do this, your code may produce incorrect results."
  - jnxx 6y ago
    A good example why immutability by default seems to be the right thing - in Clojure, "seq" would not have been modified by the first filter expression: user=> (def seq_ (range 1 11)) user=> (filter (fn [x] (== (mod x 2) 0)) seq_) (2 4 6 8 10) user=> (filter (fn [x] (== (mod x 1) 0)) seq_) (1 2 3 4 5 6 7 8 9 10) or more concisely: user=> (filter even? seq_) (2 4 6 8 10) user=> (filter odd? seq_) (1 3 5 7 9) And also an example why it does not work to go and grab one or another desirable feature from a functional language, they need to work together. > (Which isn't to say that you can't successfully use some functional techniques in Python. But it's best done in a measured, pragmatic way.) A great example how it is done right is Python's numpy package. The people who created that knew about functional languages and APL (which fits nicely in since Python's predecessor ABC had some APL smell). The obviously knew what they were doing, and created a highly usable combination of a general data type and powerful operations on it.
  - gerikson 6y ago
    I found this very surprising so asked a Python-knowledgeable acquaintance who mentioned that this works as expected >>> seq = [x for x in range(1,11)] >>> list(filter(lambda x: x % 2 == 0, seq)) [2, 4, 6, 8, 10] >>> list(filter(lambda x: x % 2 == 1, seq)) [1, 3, 5, 7, 9]
    - 6y ago

Pattern matching is the brainchild of ML. Python, being a multi-paradigm language with the strong functional side, missed this simple in concept and powerful in practice language concept.

jnxx 6y ago

> Python, being a multi-paradigm language with the strong functional side I would doubt that. Surely, things like Numpy are written in a functional fashion, but Python relies very much on statements, iteration, things not being an expression, almost every named symbol except string and number literals being mutable, and there are no block-scoped name bindings which are essential to functional languages. And the attempt to add the latter to Python might end in a far bigger train wreck than C++ is already. Mixing OOP and functional style works, more or less, for Scala, but everyone agrees that Scala is a hugely complex language. And in difference to Python, it has immutable values. What could turn out better would be to create a new language which runs interoperable in the same VM (much like Clojure runs alongside Java and can call into it). And that new language, perhaps with the file extension ".pfpy", would be almost purely functional, perhaps like a Scheme or Hy, without these dreaded parentheses. That would at least leverage Python's existing libraries.

jnxx 6y ago

> Python, being a multi-paradigm language with the strong functional side Coming back to that, just a reminder that lambdas in Python are still gimped, closures do not work as expected because of -- scoping, and core developers in Python 3 tried to remove with "map" and "filter" tools that are considered quite essential for functional programming.

mumblemumble 6y ago
I actually wish they had done so. As someone who switches between Python and functional languages, I find Python's "map" and "filter" to be a trap, and have taken to scrupulously avoiding them. The problem is that I expect those functions to be pure, and, in Python, they aren't. They actually can't be, not even in principle, because their domain and range include a core datatype that cannot be interacted with in a pure manner: generators. A generator will change its own state every time you touch it. For example: >>> seq = (x for x in range(1, 11)) >>> list(filter(lambda x: x % 2 == 0, seq)) [2, 4, 6, 8, 10] >>> list(filter(lambda x: x % 2 == 1, seq)) [] In a language that is a good fit for functional programming, the last statement would return [1, 3, 5, 7, 9], not an empty list. But Python is imperative to the core, so much so that I would argue that trying to use it as a functional language is like trying to drive screws with. . . not even a hammer. A staple gun, maybe? (Which isn't to say that you can't successfully use some functional techniques in Python. But it's best done in a measured, pragmatic way.)
- Tarean 6y ago
  To be fair, that's a foot gun in haskell as well. Using lists non-linearly like this in haskell gives you the correct results but at a 10x performance tax or worse because it can't optimize into a loop anymore.
  - mumblemumble 6y ago
    At least to me, a footgun goes beyond a mere performance gotcha. There's a whole category difference between, "If you do this, the compiler may not be able to optimize your code as well," and, "If you do this, your code may produce incorrect results."
- jnxx 6y ago
  A good example why immutability by default seems to be the right thing - in Clojure, "seq" would not have been modified by the first filter expression: user=> (def seq_ (range 1 11)) user=> (filter (fn [x] (== (mod x 2) 0)) seq_) (2 4 6 8 10) user=> (filter (fn [x] (== (mod x 1) 0)) seq_) (1 2 3 4 5 6 7 8 9 10) or more concisely: user=> (filter even? seq_) (2 4 6 8 10) user=> (filter odd? seq_) (1 3 5 7 9) And also an example why it does not work to go and grab one or another desirable feature from a functional language, they need to work together. > (Which isn't to say that you can't successfully use some functional techniques in Python. But it's best done in a measured, pragmatic way.) A great example how it is done right is Python's numpy package. The people who created that knew about functional languages and APL (which fits nicely in since Python's predecessor ABC had some APL smell). The obviously knew what they were doing, and created a highly usable combination of a general data type and powerful operations on it.
- gerikson 6y ago
  I found this very surprising so asked a Python-knowledgeable acquaintance who mentioned that this works as expected >>> seq = [x for x in range(1,11)] >>> list(filter(lambda x: x % 2 == 0, seq)) [2, 4, 6, 8, 10] >>> list(filter(lambda x: x % 2 == 1, seq)) [1, 3, 5, 7, 9]
  - 6y ago