[bad_user]

Python will never be FP friendly, even if there have been certain attempts in the past. The reason is that at its core Python is very statement and mutation oriented, instead of being expression oriented and to prefer immutability by default, like all FP languages are.

People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby.

I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.

[Areading314]

As a corollary I think the lack of adoption of 'pure' languages, even after decades of trying, is evidence that they are just less productive than 'dirty' languages like python. Libraries and community are just much more important than the language itself.

[setr]

The problem with the lack of adoption argument is that the only paradigms that saw widescale adoption was imperative and oop; its difficult to imagine that we as an industry picked so well on the first try (imperative) that only oop could compete, and even then is treated as an extension of imperative than full-on oop. Especially when its easy to imagine viable reasons for the paradigm's success not based on merit: inertia, market economics, network effects, luck, piggybacking off unix's merit, ease of learning (compared to previous major languages), etc.

Hell, even as you claim, libraries/communities is a chicken and egg problem, and its certainly easier to build a community on a familiar language/paradigm, than a different one.

Its a big ask to assume that it boils down to productivity, especially when most alternatives are completely unknown to most: imperative, oop, and recently functional are the only options non-academics would usually imagine. Concatenative, stack-based, logical, etc are gone from the conversation long before productivity ever comes into play.

At best, the productivity question is likely just a short term one: it costs little up-front to jump from C to Python, compared to C to Haskell. The long-term productivity question is more likely than not, not actually in play. And presumably even haskellers don't think of a proper comparison against C, in the long-term benefits (they'll usually note C's weaknesses against haskell's strengths, but not vice-versa; the C programmers will do the same in C's favor)

[lmm]

The pure-functional features have gradually been adopted. It's hard to imagine a new general-purpose language coming out without map/reduce/filter, or without some form of typing with generics and inference, or without pattern-matching. It's hard to remember that these things were all seen as pure-functional nonsense a decade or two ago.

[nepeckman]

I'd argue that the more pure FP languages have a higher learning curve, but that doesn't equate lower productivity. Plenty of people are productive in FP languages, and there are a good number of FP languages with decent adoption throughout the industry. They might not be as widely adopted as Python, but that's because it's really easy to learn Python.

[stevesimmons]

There's productivity at the level of an individual developer, and productivity at the level of an enterprise.

Just because an individual or a small team can be highly productive in say, Haskell, doesn't mean it makes sense for the whole company.

In Finance, the area I work in, the only FP success stories that come immediately to mind are a couple of teams at Standard Chartered for Haskell, and Jane Street Capital for OCaml. And they are notable for their rarity, not because there are plenty of other comparable examples.

[throwaway5752]

My experience is that pure FP languages have enormous individual productivity but that comes at the expense of lower team productivity/collaboration (my experience, even if not universal or even correct, is that in practice they are fairly idiomatic from developer to developer) and maintenance over time can be an issue for similar reasons. For simple systems and system management scripting, I will take the simpler language.

That said, I'd want a very high concurrence system written in a function language over Python any day (gil notwithstanding). But I'm fine with Python not being that language.

[crdoconnor]

...is precisely the attitude that killed perl.

I don't want the extreme strictness of haskell or F# but I'd rather be edging in that direction rather than edging in perl's direction. 572 was definitely the latter.

[jrs95]

Some FP constructs can be productive even in a “dirty, mutable language”. It works well for JavaScript, at least.