Thinking in Types

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

I understand the critique being made, but this seems like a slightly outdated view of Haskell. There is quite a bit of software being written in Haskell these days. One project that got some press recently is a long existing project that recently went open source, Cryptol [0].

While lots of projects in Hasekll continue to be libraries written for Haskell, there are also lots of languages using Haskell for their implementation language. Browse the GitHub trending repositories listing for Haskell [1] for an idea of what is being done with it.

[0] http://cryptol.net/

[1] https://github.com/trending?l=haskell

Frequently there will be many different ways to solve or architect a problem in Haskell, for better or worse depending on your viewpoint. Personally I think it it is better.

But anyways, another option would be to make a type for your list which wraps each possible element, then you can just pattern match on the ADT.

Also slightly concerned that this has language targeting beginners with almost 0 Haskell knowledge: I am not sure quick anecdotes like this will do more to help than confuse complete beginners.

I still think those interested should start with LYAH which does a good job giving enough context with the flurry of new things to learn.

I suppose it's inevitable if haskell gets more popular there will be more posts like this (which i like) but I'm not sure if its the right way to onboard newcomers.

Well, JS is used because it's the only way to run code on a client system.

If there were a byte-code available you can bet people would be using other languages. ASM.js exists, and many languages compile to js at the moment.

As for PHP, lots of people still eat at McDonalds. I can't explain why.

Heterogenous lists are always coming up when people try to translate OO ideas into Haskell. It's great that this example used the barrier of heterogeneity as a reason to think harder about their design instead of barreling forward.

In particular, heterogeneity causes a form of information loss via type erasure (existential typing). The problem is that this is pretty heavy machinery and is not always well-suited to such a simple problem as a heterogenous list. Additionally, once you've produced a type like

    [forall a . Renderable a => a] -- not a valid Hs type, but close

frequently you've reduced your options for what to do down to really just a single choice. In this case, `render`. This is what's sometimes called the Existential Antipattern—if you have an existential type where only one way forward remains... you may as well just take that way forward. This is especially easy in a lazy language like Haskell.

    renderEm :: Ball -> Player -> Player -> [IO ()] -- homogenous!
    renderEm b p1 p2 = [render b, render p1, render p2]

Note that this is functionally very similar to the implementation of `render` for Game as given in the article. In particular, the only difference is that the article's `render` method destroys the barriers between these `IO` actions by sequencing:

    instance Render Game where
      render (Game b p1 p2) = sequence (renderEm b p1 p2)

where `sequence` sequences a list of monadic actions

    -- try thinking about this as "distributing" a monad over a list
    -- much like you distribute multiplication over addition
    --
    -- x (a + b) --> x a + x b
    --
    -- and then go look up Data.Traversable
 
    sequence :: Monad m => [m a] -> m [a]
    sequence [] = return []
    sequence (ma:mas) = ma >> sequence mas

This tension between a "reified list of actions" and a composite action is pretty much the heart of the expression problem—the reified list is an initial encoding and the final action the final encoding. This kind of thing shows up all the time when dealing with heterogenous lists. The reason being that OO basically favors final encodings to the extinction of initial ones... but initial encodings are what generate type information.