[bradrn]

I completely agree with you. As a Haskeller, I find it immensely irritating when people try to force ‘FP’ into programming languages where it doesn’t fit. It just ends up putting people off functional programming, which is a very nice paradigm in languages which properly support it. I feel that the best code is that which adheres to the general paradigm and style of the language it is written in, and these kinds of libraries go against that.

What’s worse, these versions of ‘FP’ often bear very little resemblance to actual functional programming and its advantages. Rather, people seem to fall into the trap of confusing functional programming with ‘those fancy words I hear from Haskell’. Now, I may like Haskell, but its concepts are only useful because of the rest of the language — you can’t just port ‘monads’ and ‘IO’ into some random language and expect them to be usable. It looks like this library partly avoids that fate, in that it does have more than just ‘monads’… but yes, the monads are still there, and they’re just as clunky as you’d expect from Python.

</rant>

[epgui]

> you can’t just

I mean, you can... But only with great discipline and experience. It just (probably) won't work if you're having to mentor more junior engineers with an OOP background.

[PaulHoule]

Do you think that style of error handling works in Scala? It certainly seems possible to get right but the quality of Scala code I've worked with in different roles has frequently been atrocious, I'd almost rather dig into some old ColdFusion or PHP.

(Funny, I was downright terrified 15 years ago about ever mentioning "ColdFusion" or "Sharepoint" in a forum because I'd get contacted by recruiters about the first and salespeople about the second. I'd always tell the salespeople that we had no budget at all for Sharepoint and just had one for our dev team because you could get the license for free with an MSDN subscription)

[epgui]

To be perfectly honest, I don't know Scala very well.

I'm more interested in "pure FP" languages than in multi-paradigm languages, because the former seem much more coherent in design to me. IMO, functional programming isn't about adding extra degrees of freedom (or "extra features"), it's about working within very well-defined and rigid constraints (what one might call safeguards).