Reflecting on Haskell in 2015

I haven't found the same to be true for other languages, but in my experience the Average Haskeller is so caught up in academic exercises, technical one-upmanship, and code golf shenanigans that I'm surprised they find any time to contribute any business value at all. Having a discussion about acceptable levels of technical debt with a Haskeller is like having a discussion about acceptable levels of meat products in your diet with a vegan in a world where there are no plant foods..."everything is technical debt, and none of it is acceptable, and we absolutely can't move on until we change all relevant functors to applicatives and all nested record accesses to lenses!"

And it is squarely a cultural issue, not a technical one...it is quite obvious that Haskell is a fantastically powerful language and capable of mowing over most enterprise-y languages with ease for a very wide variety of domains. Its just that Haskellers are so nitpicky about elegance and style that they don't know how to let shit be shit and get something done when it is needed.

This obviously isn't the only case for Haskellers. Looking at JGM's github feels like looking at Dumbledore's magic through the eyes of a Muggle. It just feels that way with the average Haskeller that I work with.

The nice thing about monads with respect to the haskell programming thing is that you don't have to know why they work to get their benefit. However, if you wanted to build your own you probably do need to grok them.

However, I'm not convinced that monads are the best way to proceed on the most part in programming advancements. The immutable/mutable tracking, affine types, and borrow checker in Rust seems like it would help prevent a lot of the same types of bugs that pure FP does, but without the cost of needing to have a monadic effect system (and Rust is a more familiar style of programming than the State monad with a host of monad transformers). I'm hoping for optional affine types and more immutable data structures to become the norm more than I am monad usage.

You mention LINQ and the List abstraction. Yes IEnumerable is a monad (LINQ isn't in itself - it [the grammar] is the equivalent of 'do' notation in Haskell). Monads are simply 'wrapper types' that follow a couple of rules:

1. You must be able to construct one from the un-wrapped value (return in Haskell, new List(...) in C#)

2. It must implement the bind function.

If you understand 'map' (or Select in LINQ) then bind is very similar, except instead of returning a mapped version of the wrapped value, it returns a mapped version of the wrapped value, re-wrapped.

So in C# parlance (because I assume from your comment you use this daily):

    IEnumerable Map(this IEnumerable self, Func mapper)
    {
        foreach(var x in self)
        {
            yield return mapper(x);
        }
    }


    IEnumerable Bind(this IEnumerable self, Func> binder)
    {
        foreach(var x in self)
        {
            foreach(var y in binder(x))
            {
                yield return y;
            }
        }
    }

    var res = from x in list
              select x + 1;

    var res = list.Select( x => x + 1);

    var res = from x in list1
              from y in list2
              select x + y;

    var res = list1.SelectMany(x => list2.Select(y => x + y));

It's been a while since I've done any Haskell, so forgive me if I get some of the syntax wrong here. But the LINQ statement above translates very similarly:

    do x