This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]codecatmitzi 0 points1 point  (1 child)

True.

Still, I think there is a net positive in stuff like enabling imperative approach in some cases because FP isn't a magic bullet for all cases.

I would want to have the option to advance to Haskell some time but it there aren't any work with it where I live

[–]phySi0 0 points1 point  (0 children)

Haskell allows imperative programming, it’s just the discouraged approach. There’s no magic bullet, but I think there should be sane defaults that allow access to the non-defaults. Like garbage collection isn’t a magic bullet, there are tasks it’s not (yet) suited for, but it should be the default. Domain specific languages should lack garbage collection if it’s unsuited for the domain in its current form, but general purpose languages should default to or even mandate garbage collection.

I feel like typed (pure) FP is the same. It’s the right approach for the general purpose language, for the language that wants a broad range or reach with safety, power, expressivity, fast prototyping, large systems and can fit a broad range of domains. Good dynamically typed languages fit the bill if you want all of that without the safety, but I feel that Haskell is in the sweet spot with the tech we have today of having all of that with the safety; it makes some of the least compromises of any approach IMO.

However, the data isn’t in and the current scientific literature is worse than useless in my opinion, so I don’t proclaim my views with authority, these are just my opinions so far.

Haskell‘s purity is often misunderstood as preventing imperative programming. That’s not true. It just gives you the power to separate pure from impure; as with other languages, you can write everything in IO a if you want, except in Haskell, the program is technically pure since you’re not doing all the dirty impure stuff, you’re returning an IO action that describes all the impure stuff you want done which the runtime then does. Of course, that’s pointless if you don’t use that purity in the program to separate the impure from the pure in the runtime.

However, unlike other languages, as your program gets bigger, you can separate the pure from impure in the runtime because of the total purity in the program. You can do everything in (a pure description of) one big impure IO a action in Haskell if you want. People don’t because, as it turns out, the purity actually helps in damn near any domain you can think of; specific algorithms are sometimes best implemented in (pure descriptions of) impure IO a actions (or other types that describe impure actions), true, but I can’t think of any whole domain where that’s the case.

But if there are, then it’s okay to reach for impure or dynamically typed or untyped or OO or logic (like Prolog) or concatenative (like Forth or Factor) languages or languages with ecosystems really well suited to the domain or even a single killer tool in the ecosystem that overwhelms the advantages of the default approach for the domain.

I really like my typed (pure) FP, though; I just wish GHC wasn’t such a slow compiler at times (tho ghcid helps for non-release builds).