Sunday, February 21, 2016

State of the Haskell Ecosystem - February 2016 Edition

Six months ago I released the first "State of the Haskell Ecosystem", a collaborative wiki documenting the maturity of the Haskell language for various application domains:

The primary goals of this wiki are to:

  • Advertise what areas the Haskell language and ecosystem excel at
  • Warn newcomers about common pitfalls so they avoid unpleasant surprises
  • Give new contributors ideas for where they can improve things

Every six months I plan to post about what changed since the last update in order to highlight any major changes or trends.

Education

The biggest improvement in the Haskell ecosystem was the Early Access release of the Haskell Programming from first principles book. The book is not yet released but I consider this book the best resource for people new to the language. The material is very beginner-friendly and written for somebody without any functional programming experience whatsoever.

The book is not free, but if you're really serious about learning Haskell the price is well worth it and this book will save you a lot of headaches.

The rating of the "Educational" section still remains "Immature" until this book is out of Early Access and finally released, but once the book is out I will finally mark Haskell as having "Mature" educational resources.

IDE support

For a long time vim and emacs were the Haskell editors of choice. Now more traditional IDEs like Atom and IntelliJ are starting to get Haskell support, but their respective Haskell plugins still need a bit more polish.

Also, the Haskell for Mac is supposed to work really well for learning the language if you have an OS X development environment.

However, my rating hasn't changed for IDE support, and I believe this is still the biggest gap in the Haskell ecosystem so I want to draw attention to this area for people interested in contributing to Haskell. Improving IDE support is the single easiest way to lower the entry barrier to newcomers.

If you're not sure what editor to contribute to I recommend the ide-haskell plugin for Atom. This editor and plugin are freely available and cross-platform and many users have reported an excellent experience with this plugin, although some setup issues still remain.

Another important area where newcomers can contribute is the Leksah IDE, which is a true integrated development environment for Haskell which is also written in Haskell.

Front-end web programming

stack recently added support for ghcjs, meaning that it's now very easy to start a new ghcjs project. Previously, setting up ghcjs correctly was very difficult, but those days are over now.

The ghcjs ecosystem still has a long way to go before I would rate it as "Mature", but stack support is a big and necessary step in that direction.

Standalone GUI applications

Right now I'm looking for just one really polished widget toolkit before I rate this area of the Haskell ecosystem "Mature".

Deech has made great strides in improving the ease of setup and use for the FLTK Haskell bindings and integration with visual interface builders. The setup process still needs a bit more polish but I think his work probably holds the most promise for a mature widget toolkit binding.

Types

The Liquid Haskell extension has made some great strides in adding refinement types to the language. This is not yet an official language extension, but you can still use it today and it works really well. You can learn more about refinement types by reading the awesome Liquid Haskell tutorial:

I already gave Haskell a "Best in class" rating for the type system, but advances like Liquid Haskell just further cement its lead.

Parsing

I upgraded the parsing rating from "Mature" to "Best in class". Haskell has always been a leader among languages when it comes to parsing, but I held off on a "Best in class" rating for a while because all the Haskell parsing libraries required you to sacrifice one of the following features:

  • Good error messages
  • Full backtracking (i.e. no need to left-factor the grammar)
  • First-class parsers (i.e. not a parser generator like happy)

The Earley library changed that and provides a well-rounded choice. That doesn't mean that I recommend Earley for all parsing use cases, though, and there are still great reasons to use other parsing libraries:

  • attoparsec remains the king of speed, generating parsers competitive in speed with C
  • trifecta remains the king of error messages, generating gorgeous clang-style errors

However, if Earley gets a little more polish then I'd probably switch to Earley as my default parsing library recommendation for new users.

Distributed systems

The newly added glue-core / glue-* libraries give Haskell a new service toolkit useful. Haskell still gets an "Immature" rating in this area until I see people consolidate on a common stack for service-oriented architectures and report success stories in industry.

New sections

Two generous contributors added two new sections to the wiki which I would like to highlight:

I would like to thank both of them for their contributions!

Conclusions

As always, visit the Github collaborative wiki for the most up-to-date information since this post will eventually go stale. Pull requests are always welcome, both for corrections and new additions.

8 comments:

  1. What sort of polishing do you think Earley needs?

    Every time I look at trifecta I give up immediately. The Haddocks don't give me the foggiest clue of how I'm supposed to use it.

    Why no mention of uu-parsinglib? It has some papers that explain it quite thoroughly. The API has some nasty gotchas though. Last time I looked, the Applicative and Monad instances did not match up--and that's just one gotcha.

    ReplyDelete
    Replies
    1. Yeah, `trifecta`'s documentation is downright hostile because Edward doesn't seem to document his own libraries. The trick is to realize that trifecta's parser implements the shared interface provided by the `parsers` library.

      For Earley the two main rough edges are:

      * the API for running parsers (there should probably be some helper utilities for certain common cases)
      * It doesn't come with a lot of parsers out of the box. It should probably implement the `parsers` library's API, for example

      I think the main thing I'm interested in for uu-parsinglib is what are the main features that distinguish it from other parsing libraries. It looks pretty actively used and I just need to understand the use case it's best suited for

      Delete
  2. IMO if using a library requires reading a paper, this is not good enough.

    ReplyDelete
  3. I'm curious, why is there no mention of Leksah in the IDE section?

    ReplyDelete
    Replies
    1. So Leksah is already mentioned in the original wiki under both the IDE and Debugging sections, but I also just added a mention of it to this post as well.

      Delete
  4. What's wrong with reading a paper to use a library? Just because the intro comes as a pdf file?

    (The only problem is that people usually don't keep their papers updated when the library changes over time.)

    ReplyDelete
  5. > parsec is still a "free" dependency since it comes with ghc by default

    I guess that means "part of Haskell Platform": I don't think parsec has ever been included in ghc.

    Thanks for doing this - it is a really great resource and source of Haskell info.

    ReplyDelete
    Replies
    1. Whoops! You're right. I fixed it

      Also, you're welcome!

      Delete