4 ms·

I've been waiting for this for a very, very long time. I've not learned Haskell yet but generally speaking I'm very fond of FP in all languages, including Pytho

I've been waiting for this for a very, very long time. I've not learned Haskell yet but generally speaking I'm very fond of FP in all languages, including Python. However, the BDFL has arbitrarily decided that Python shouldn't even have remotely easy-to-use FP semantics (even though Python being so multi-paradigm is often touted as a major advantage), so (as an example) while he gave up on trying to remove `lambda`, he didn't make it simpler and more useful, which makes it so that whenever someone runs into it as a beginner they say, "Oh, what a stupid little thing that I can replace easily, FP is stupid." [1] I've been very upset generally speaking at how much control the BDFL is taking - not necessarily directly, but indirectly through people who seem to think that Pythonic™ programming is literally God and anyone who doesn't do Pythonic is Bad. [1] https://stackoverflow.com/questions/890128/why-are-python-lambdas-useful https://stackoverflow.com/questions/890128/why-are-python-la...

FridgeSeal 9y ago
I agree completely. Other choice decisions include: "No tail-call-optimisation because I don't like recursion and I reckon the stack traces would probably be ugly" And "python doesn't need to be any faster" even though it should be possibly to do so without compromising development speed. If you want more functional style stuff in Python, check out Coconut: http://coconut-lang.org http://coconut-lang.org I think an ideal candidate would look like Coconut with its python X haskell feel. Maybe target LLVM for nice compile time checks and performance benefits.
- naiveai 9y ago
  People often attribute this to careful language design - and to be completely honest, I can't say anything about that since I'm just some kid, but I feel like that doesn't make the BDFL immune to criticism. TCO, for example, would change almost nothing that already exists in the language, and would make it faster in at least some cases. As evidenced by Coconut, and in fact the number of libraries that smack TCO onto Python, albeit in a very inelegant way. And sometimes it seems he intentionally cripples certain features so he can "prove" that certain ways of programming are bad. > filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, for example, x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension) (Quoted from https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196) If he had made lambdas even a little bit easier to write, then this criticism is completely blown out the window. I'm not saying that FP is the holy grail and all must bow down to the ivory tower. But it disturbs me that the BDFL seems to be waaayyyyyyy to cautious about adding useful features to the language because Python Is Not A Functional Language.

FridgeSeal 9y ago

I agree completely. Other choice decisions include: "No tail-call-optimisation because I don't like recursion and I reckon the stack traces would probably be ugly" And "python doesn't need to be any faster" even though it should be possibly to do so without compromising development speed. If you want more functional style stuff in Python, check out Coconut: http://coconut-lang.org http://coconut-lang.org I think an ideal candidate would look like Coconut with its python X haskell feel. Maybe target LLVM for nice compile time checks and performance benefits.

naiveai 9y ago
People often attribute this to careful language design - and to be completely honest, I can't say anything about that since I'm just some kid, but I feel like that doesn't make the BDFL immune to criticism. TCO, for example, would change almost nothing that already exists in the language, and would make it faster in at least some cases. As evidenced by Coconut, and in fact the number of libraries that smack TCO onto Python, albeit in a very inelegant way. And sometimes it seems he intentionally cripples certain features so he can "prove" that certain ways of programming are bad. > filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, for example, x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension) (Quoted from https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196) If he had made lambdas even a little bit easier to write, then this criticism is completely blown out the window. I'm not saying that FP is the holy grail and all must bow down to the ivory tower. But it disturbs me that the BDFL seems to be waaayyyyyyy to cautious about adding useful features to the language because Python Is Not A Functional Language.