4 ms·

Pythons functional programming support is quite good. Better than JavaScript imo. JavaScript doesn't support list comprehensions. Additionally python with a ty

Pythons functional programming support is quite good. Better than JavaScript imo. JavaScript doesn't support list comprehensions. Additionally python with a type checker supports sum types AND exhaustive pattern matching similar to haskell and rust. Typescript does not support this as far as I know. Outside of types the differences between the two languages are just sugar. Lisp on the other hand is something truly different.

globular-toast 3y ago
List comprehensions aren't very functional. A functional language would use higher-level functions like map and filter which JS absolutely has. One thing I always miss in languages like Python and JS is the identity function. I don't how people are writing all this functional code without it.
- rebeccaskinner 3y ago
  I don't really see how list comprehensions aren't functional- it's just a different notation for dealing with maps, filters, and cartesian products. Python borrowed list comprehensions from Haskell in the first place.
  - pama 3y ago
    (not GP and I agree with you, and wanted to add some additional thoughts that may help others.) The comprehensions are great and have a functional flavor, sure. But when you hit the corner cases in Python you feel that the addition they provide to Python are not taking the language close to Haskell. Lambda functions within the Python comprehensions have limited power, reductions don’t work as nicely with comprehensions as map or filter; more generally, when you compose comprehensions things feel messy without the ability to pipe previous results to a next function, so you are using lots of intermediates and have to think of useful names which is hard. The end result can be good and closer to pseudo code, which is fantastic. However Python does not satisfy the need of many people used to lisp and often takes much longer to get right in those complex corner cases where Haskell or lisp would make validation and testing much easier.
    - corethree 3y ago
      > Lambda functions within the Python comprehensions have limited power, lambda functions in python have as much expressive power as any function. >comprehensions things feel messy without the ability to pipe previous results to a next function compose :: (a -> b) -> (b -> c) -> (a -> c) is definable in python Along with type checking. This is basically your pipe operator. Python has very much the capability to come rather close, closer than javascript to the flavor of functional programming found in ML languages like haskell. The benefit of using python is that you can cheat a lot too which is more challenging to do in language as strict as haskell. Here: from typing import Callable, TypeVar, List, Any from numbers import Number A = TypeVar("A") B = TypeVar("C") C = TypeVar("C") def compose(f: Callable[[A], B], g: Callable[[B], C]) -> Callable[[A], C]: return lambda x: g(f(x)) def curry(f: Callable[[Any, ...], Any], x: Any) -> Callable[[Any, ...], Any]: return lambda *args: f(x, *args) def compose_many(fs: tuple[Callable[[Any], Any], ...]) -> Callable[[Any], Any]: return (lambda x: x) if len(fs) == 0 else fs[0] if len(fs) == 1 else compose(compose(fs[0], fs[1]), compose_many(*fs[2:])) MultAllType = Callable[[List[Number], Number], List[Number]] multAll: MultAllType = lambda x, y: [i * y for i in x] SubTractAllType = Callable[[List[Number], Number], List[Number]] subtractAll: SubTractAllType = lambda x, y: [i - y for i in x] quadrupleAndSubtractTwoFromAll = compose_many( curry(multAll, 2), curry(multAll, 2), curry(subtractAll, 2)) as literals: quadrupleAndSubtractTwoFromAll = compose_many( lambda x: [i * 2 for i in x], lambda x: [i * 2 for i in x], lambda x: [i - 2 for i in x]) Python gets a bad rep for being noob language but it's capable of functional programming with very very good type checking. You can cheat too and go no types like lisp as I've shown in the example above. Overall I would say it's superior to typescript in terms of functional programming due to exhaustive pattern matching (which I did not demonstrate above.) In terms of FP in python versus FP in lisp it's mostly just opinionated differences. Python and lisp sort of even out because python has optional type checking and lisp has macros. I would say though that python leans more towards the ML flavor of FP which makes it less comparable to lisp. Apples and Oranges.
      - pama 3y ago
        Lambda functions in Python cannot contain statements (you couldn’t do a try/except block, or a while loop); they cannot have assignments, or multiple expressions. They don’t feel syntactically as expressive as other functions in Python. Your composition and curry are OK, and related tools exist in standard libraries. The lack of a first class support is a minor annoyance but not a showstopper, and the solutions are not as natural as genuine pipe notation (you can’t simply write left to right and generate text autoregressively). The lambda limit was more real in my mind and I hope Python eventually corrects it.
- corethree 3y ago
  No. A functional language is a language that primarily uses functions as defined in mathematics for it's programming language. Functions defined in mathematics are single lined expressions where no mutation takes place. In traditional languages programs are a list of procedures that change and mutate state. A list comprehension is functional in every way as it is a single expression. It does not change state. It is functionally equivalent to map and filter and even flatmap. If you need an official source you just need to know that list comprehensions are borrowed from haskell. That's where the term came from and that's where the feature was borrowed from.
- esafak 3y ago
  Guido van Rossum dislikes map and filter: > I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter... Also, comprehensions are inspired by set-builder notation. https://en.wikipedia.org/wiki/Set-builder_notation https://en.wikipedia.org/wiki/Set-builder_notation
  - corethree 3y ago
    Guido isn't a functional programmer. He doesn't know the trade off. The benefits of functional programming are less technical debt and greater modularity and less bugs. The cost is less readability and less efficiency. Reduce is ultimately the most readable way to iterate and accumulate with FP. The only other way would be recursion which is less readable.
  - odyssey7 3y ago
    This is fascinating context.

globular-toast 3y ago

List comprehensions aren't very functional. A functional language would use higher-level functions like map and filter which JS absolutely has. One thing I always miss in languages like Python and JS is the identity function. I don't how people are writing all this functional code without it.

rebeccaskinner 3y ago
I don't really see how list comprehensions aren't functional- it's just a different notation for dealing with maps, filters, and cartesian products. Python borrowed list comprehensions from Haskell in the first place.
- pama 3y ago
  (not GP and I agree with you, and wanted to add some additional thoughts that may help others.) The comprehensions are great and have a functional flavor, sure. But when you hit the corner cases in Python you feel that the addition they provide to Python are not taking the language close to Haskell. Lambda functions within the Python comprehensions have limited power, reductions don’t work as nicely with comprehensions as map or filter; more generally, when you compose comprehensions things feel messy without the ability to pipe previous results to a next function, so you are using lots of intermediates and have to think of useful names which is hard. The end result can be good and closer to pseudo code, which is fantastic. However Python does not satisfy the need of many people used to lisp and often takes much longer to get right in those complex corner cases where Haskell or lisp would make validation and testing much easier.
  - corethree 3y ago
    > Lambda functions within the Python comprehensions have limited power, lambda functions in python have as much expressive power as any function. >comprehensions things feel messy without the ability to pipe previous results to a next function compose :: (a -> b) -> (b -> c) -> (a -> c) is definable in python Along with type checking. This is basically your pipe operator. Python has very much the capability to come rather close, closer than javascript to the flavor of functional programming found in ML languages like haskell. The benefit of using python is that you can cheat a lot too which is more challenging to do in language as strict as haskell. Here: from typing import Callable, TypeVar, List, Any from numbers import Number A = TypeVar("A") B = TypeVar("C") C = TypeVar("C") def compose(f: Callable[[A], B], g: Callable[[B], C]) -> Callable[[A], C]: return lambda x: g(f(x)) def curry(f: Callable[[Any, ...], Any], x: Any) -> Callable[[Any, ...], Any]: return lambda *args: f(x, *args) def compose_many(fs: tuple[Callable[[Any], Any], ...]) -> Callable[[Any], Any]: return (lambda x: x) if len(fs) == 0 else fs[0] if len(fs) == 1 else compose(compose(fs[0], fs[1]), compose_many(*fs[2:])) MultAllType = Callable[[List[Number], Number], List[Number]] multAll: MultAllType = lambda x, y: [i * y for i in x] SubTractAllType = Callable[[List[Number], Number], List[Number]] subtractAll: SubTractAllType = lambda x, y: [i - y for i in x] quadrupleAndSubtractTwoFromAll = compose_many( curry(multAll, 2), curry(multAll, 2), curry(subtractAll, 2)) as literals: quadrupleAndSubtractTwoFromAll = compose_many( lambda x: [i * 2 for i in x], lambda x: [i * 2 for i in x], lambda x: [i - 2 for i in x]) Python gets a bad rep for being noob language but it's capable of functional programming with very very good type checking. You can cheat too and go no types like lisp as I've shown in the example above. Overall I would say it's superior to typescript in terms of functional programming due to exhaustive pattern matching (which I did not demonstrate above.) In terms of FP in python versus FP in lisp it's mostly just opinionated differences. Python and lisp sort of even out because python has optional type checking and lisp has macros. I would say though that python leans more towards the ML flavor of FP which makes it less comparable to lisp. Apples and Oranges.
    - pama 3y ago
      Lambda functions in Python cannot contain statements (you couldn’t do a try/except block, or a while loop); they cannot have assignments, or multiple expressions. They don’t feel syntactically as expressive as other functions in Python. Your composition and curry are OK, and related tools exist in standard libraries. The lack of a first class support is a minor annoyance but not a showstopper, and the solutions are not as natural as genuine pipe notation (you can’t simply write left to right and generate text autoregressively). The lambda limit was more real in my mind and I hope Python eventually corrects it.
corethree 3y ago
No. A functional language is a language that primarily uses functions as defined in mathematics for it's programming language. Functions defined in mathematics are single lined expressions where no mutation takes place. In traditional languages programs are a list of procedures that change and mutate state. A list comprehension is functional in every way as it is a single expression. It does not change state. It is functionally equivalent to map and filter and even flatmap. If you need an official source you just need to know that list comprehensions are borrowed from haskell. That's where the term came from and that's where the feature was borrowed from.
esafak 3y ago
Guido van Rossum dislikes map and filter: > I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter... Also, comprehensions are inspired by set-builder notation. https://en.wikipedia.org/wiki/Set-builder_notation https://en.wikipedia.org/wiki/Set-builder_notation
- corethree 3y ago
  Guido isn't a functional programmer. He doesn't know the trade off. The benefits of functional programming are less technical debt and greater modularity and less bugs. The cost is less readability and less efficiency. Reduce is ultimately the most readable way to iterate and accumulate with FP. The only other way would be recursion which is less readable.
- odyssey7 3y ago
  This is fascinating context.