Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because you are making the mistake of only looking at languages that enforce a pfp style, but not at those that at least support it.


I am aware that most mainstream languages incorporated FP features. And they are the better for it.

But the topic of this discussion is PURE functional programming. See the following quote:

    "same reason why it took some time for pure functional programming to take off too."
So when did that happen? Almost every codebase I see is imperative, either procedural or OO. They use mutable state, they use functions with side effects.

The reason why my argument above is built around PFP Languages, is because they are the only ones where pure functional codebases seem to exist from my PoV. I am happy to change my mind if you can point me towards major projects written in a PFP style in non PFP PLs.


> But the topic of this discussion is PURE functional programming.

Yes, exactly. It is NOT about "pure functional programming languages" nor is it about (what's nowadays called "functional programming" features). But you seem to be talking about those two things.

> So when did that happen? Almost every codebase I see is imperative, either procedural or OO. They use mutable state, they use functions with side effects.

Then maybe you need to broaden your horizon. I've worked exclusively(!) in different code bases over the last 5+ years that followed a pure(!) functional style, maybe with very few exceptions for performance or sometimes to make things simpler since it was not Haskell.

For example, look at the adopters of ZIO: https://github.com/zio/zio#adopters

ZIO is a PFP library for Scala (even though they don't market it as that to be more beginner-friendly, but read the documentation and you'll see that it's essentially an IO-monad on steroids). And it is a rather new one but already got lots of traction. And even typescript has now fp-ts which is used much more than I expected myself.

Of course, being a ZIO adopter does not necessarily mean the whole codebase is using ZIO (and hence following a PFP approach) but the chance is high and I personally know two more companies that use ZIO and are not in the list, so there are very likely much more companies that use ZIO. Also, those companies were using a PFP style pretty much everywhere, in every team (backend only though). So it's not like there was just one project in that style or something like that.

When I compare that to 10 years ago, there was pretty much nothing besides Haskell and Haskell is, as you correctly said, not very prevalent in visible production projects. But checkout the list and to your surprise you might find some familiar names in there.


> Of course, being a ZIO adopter does not necessarily mean the whole codebase is using ZIO (and hence following a PFP approach) but the chance is high

How does "uses a library for async and concurrent programming" indicate a high chance that an entire codebase follows a PFP approach?


What was unclear about

> (even though they don't market it as that to be more beginner-friendly, but read the documentation and you'll see that it's essentially an IO-monad on steroids)

?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: