The Four Flaws of Haskell

It's almost as if programs are useless if they don't perform some IO and therefore, trying to encode this kind of side effects in the type system is theoretically interesting but practically inconvenient.

You can build more granular effect systems on top of IO if you want, and many people have done.

It's a good practice to wrap your IO with newtype.

While I agree that wrapping IO in newtypes for various purposes would be useful, from a somewhat more 'pure' standpoint, it's impossible to guarantee. Writing to a file could be network, it could be outputting to a screen somewhere, it could be launching the nukes, as far as I'm aware, it's essentially impossible to tell in many cases, so I think there's an argument for being 'honest' about this and not making type guarantees for things that aren't necessarily true.

One way around this is to have typeclasses for all the different kinds of effects you'd like with instances for IO. Then for testing you can use a different instance that produces a value of a free monad.

At least half the value of "IO" is that it marks pure functions as being pure. If Haskell had a "Pure" typeclass instead of IO it would be much the same (except with the wrong default, and you'd have to type more!).

I like Purescript, and it might be worth making IO more granular as described. But my opinion is this would be focusing a lot of effort on the less valuable half of IO.

That's what we attempted to remedy with `capabilities`[1]

[1] https://hackage.haskell.org/package/Capabilities

I share this feeling , esp. when each third party lib wants to introduce some variant of <$../<>).

But I've found some of the more common symbols end up being how you think about your code when you become more versed.

The big one is <$> for fmap. If you have some functor/monad/thingy, you'll often be like "I have this pure function that I want to apply to the inner value of my functor", and <$> is the perfect analog to $.

The high abstraction level of Haskell makes reaching for these really tempting and easy. And the alternatives are verbose and harder to read in many situations.

compare "capitalise <$> readStrLn" to

    do val <- readStrLn
       return capitalise val

(though "fmap capitalize readStrLn" isn't too bad)

The article is about things that impact professionals (thought they also beginners). For better or worse, experienced Haskell users can read the one liners just fine.

The less decisions you make through you programming day, the more you achieve and the less stressful the job is.

Naming variables is a decision (I am looking at you, function arguments in most mainstream languages). Naming variables once and for all is a big and heavy decision (and now it is time for class members to be looked at).

For one operator in Haskell I often have to invent names for three-to-five variables in C#.

Interesting, readability is something I would put on a list of upsides of Haskell.

I agree that the abundant use of operators can make things difficult in some cases, but this is largely naivety on the part of the reader rather than complexity like Perl.

Perl's obfuscated one-liners are just vanilla things that every perl programmer will understand, while Haskell's weird lines are generally package specific operators that one needs to become familiar with.

Once familiar (unlike in Perl) a seasoned Haskeller will be able to grok a lot of what is going on very quickly.

As a further point, the strictness of it all makes understanding the entire system a much easier experience than many other languages.

I suspect that there's a grab bag of things that happen in those one liners, and whether they are a good idea or not depends on the details. For instance, <$> seems pretty helpful, but I shudder when I see flip. I'd go out on a limb and speculate that even for experienced readers, flip is going to be a bit difficult to parse. But I'll have to come back to that when I have more experience.

Is Haskell's default lazy evaluation really a flaw that needs to be fixed? I personally like it, I find that most of the time lazy evaluation is what I need instead of strict.

If you'd like strictness by default, there's a pragma for that https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

PureScript also compiles to readable C++. I haven't used it, but it is compelling.

https://github.com/andyarvanitis/purescript-native

Nix (and NixOS) are certainly nice to use with Haskell, but Stack is good. The post even says so:

> Stackage solved the consistent set of packages, and Stack made it even easier. I now consider Haskell package management a strength for large projects, not a risk.

FYI, it's possible to use Nix package manager outside of NixOS. I'm not quite convinced that some of the choices the NixOS distro has made are good (or to my liking) but the package manager seems much better thought out.

I was able to quickly install Nix on a not quite up-to-date Linux distro to get my hands on specific versions of some programs that are too big to conveniently build from source.

I'm not sure it solves the package management problem for Haskell completely, but it should help managing GHC versions and external dependencies (ie. native libs required by Haskell libs), which cabal/stack aren't great with.

Note: I was a bit disappointed that installing Nix required root access to create /nix store. I would have liked to put it in my home directory instead.

One point might be, that Haskell thinks big. Its strengths might not be too noticeable with smaller projects and be problematic because of a steeper learning curve. The inertia is huge. Imperative programming has a lot of momentum, because it reads more or less like text, not maths.

A steep learning curve means effectively more power. And that means responsibility. If modularization means separation of concerns, and thus less responsibility, lack of power is largely mitigated, but it puts the responsibility on the s/w-architects.

Just like LISP's strength supposedly is revealed when it's the whole OS. And as they say, any involved program will contain an ad-hoc implementation of LISP :)

C, eg., also resembled the hardware architecture more closely. With concurrent programming, though, we see more functional influences creep into the staple languages. It's the other way around with Haskell's do notation.

Anyway, as a research project, it is rather academic. Therefore it is often not backwards compatible, which is an immediate show stopper and also shows that it's far from finished, due to its bigger goals.

Probably the whole needing to learn an entire part of English that many didn't even know existed before.

A language really shouldn't require its language-specific glossary to be mandatory reading, just to understand anyone speaking about it. I could just learn any other language in half the time!

from the above comments

> "I have this pure function that I want to apply to the inner value of my functor"

pure function I know well enough, that is the same for any language, functors though... is that a function object that can be applied to something? then why does it already have a value?

I can take terminologies from C, to python, or C#, and feel a-okay, but haskell kinda feels like it went and shut it self away from the world, and its terminology developed differently due to that, I guess.

Golang is simple and most graduates would be familiar with the style (C with some extras)

Haskell is radically different for people

I think it's because the needs of industry and academia (or hobbyists?) or rather different. Onboarding and hiring are much more important in industry and both are much harder with Haskell because most people aren't nearly as familiar with functional programming as they are with imperative programming.

Most somewhat experienced developers could pick up Golang in a day or two, having come from C++/Java, but learning Haskell is much more daunting, at least in my personal experience. I don't feel like Golang really brings anything new to the table, it just takes away stuff, which isn't a bad thing.

However, learning Haskell was really eye opening to me, and yet, even a year later, I feel somewhat comfortable writing code but I am only beginning to try to learn performance analysis and think about laziness. I mean, imagine hiring someone who's only used imperative languages and telling them to start writing code that doesn't use for loops or if statements which don't have corresponding else statements.

You can just write something like

    foo x = case x of
              pattern1 -> ...

While I see how this at first appears to be a problem (when I started with Haskell I sure thought of it as one), it turns out that language-pragma filled code can be mixed with vanilla code too without problem. The pragmas usually just expose more of the inner representation of GHC (I'm thinking things like FlexibleInstances, TypeApplication, RankNTypes and not the pathologically broken and perhaps logically unsound ImpredicativeTypes). So it really is just GHC you are shipping (and not GHC + which extensions are enabled).

Eh, I think in practice it's more like there's one large language, but you have to enable some of the features with pragmas.