So I’m writing this post as some constructive criticism of the Haskell User Experience. While the language has been worthwhile to learn the actual experience of working with Haskell has been quite poor.

Learning Haskell has been a very interesting experience – it’s helped me in rethinking a lot of things including how web applications can be structured. I’ve even found an opportunity to use Haskell at work. One of my colleagues was having trouble with an importer and while we waited on a fix from the vendor I spent about an hour writing a Haskell script that modified the import file so that he could continue working. When deciding what language to do the script in, I just couldn’t imagine using anything else.

I’m just a Haskell hobbyist not a professional user. I’m currently working as a UX Architect for a student management system implementation at Deakin University. As an atypical Haskeller, I thought my UX background could contribute to the Haskell ecosystem.

Getting Haskell

Haskell Platform and Cabal

The Haskell Platform is designed to be a simple, easy to set up method of getting Haskell. This comes with a major problem – it obscures the existence of Cabal. Pretty quickly after finishing the Learn You a Haskell book people will want to go off and build something that needs a package from Hackage. This leads to a lot of confusion about how to actually use Hackage. People who want to learn Haskell are going to need to use a command line and they are going to need to get additional packages. We shouldn’t hide this from them right at the start.

And in order to find out how to use Cabal and set up a Haskell project the best resource is actually the Haskell post on How I Start. Because this is an external resource there’s no guarantee that it will be kept up to date (as of writing this, it’s out of date with the latest version of GHC).

Meanwhile I took some time out a little while ago to pick up Rust. As well as providing a set of guides and tutorials for learning Rust right on the website (more on that later), the guides include a good introduction to their Cabal equivalent Cargo. Meanwhile, buried in a list of links on the documentation page of the Haskell site, there’s a link to a Cabal user guide. Considering that Haskell Platform obscures the existence of Cabal one might wonder how a new user could find this page (let alone its inferiority to the How I Start article).

GHC

I think it’s safe to claim that most people who use Haskell just use GHC. There’s no big desire to use any other compiler. If people are unhappy with something in GHC generally they express interest in improving GHC to meet their needs, rather than wondering if there’s another compiler out there for them. The idea that there are multiple compilers out there makes Haskell seem like a fractured space. I think it’s time to admit that GHC has won and put our effort into making it better – and drop the illusion that modern Haskell is anything but GHC.

Stack, Stackage and FP Complete

Stack and Stackage are built on top of Cabal and aim to solve many issues that new users won’t be aware of. These are part of initiatives from the commercial Haskell group. This suggests that commercial users of Haskell need something that’s not available with vanilla Haskell. While both Stack and Stackage are great initiatives they add to the feeling that the Haskell ecosystem is fractured.

Especially for new users, some information about what these things are, how they work and why you’d use them wouldn’t go astray.

GHC version

There isn’t any clear indication about which version of GHC you should be using. It’s not necessarily a big deal, but sometimes presenting choice to users is considered a bad thing. The way we do it with Haskell Platform is actually good – users only get the latest version. It’s just a shame that Haskell Platform isn’t something I’d recommend to a new person starting with Haskell.

Additionally I think Haskell could use a portable binary. Installing Haskell outside of its default location is incredibly difficult. This is a reasonably minor issue however, and perhaps doesn’t have any demand.

Using Haskell

IDE

The most senior people in the Haskell community seem to hate the idea of an IDE. After all, what’s wrong with Emacs or Vim? As if the weekly post on /r/haskell asking about an IDE wasn’t enough of a hint, there are people who want this.

So many of us settle for SublimeHaskell or ide-haskell for Atom. For any useful IDE functionality these both rely on ghc-mod which didn’t compile under the latest version of GHC (7.10) until 7.10.2 was released. Yet even with ghc-mod these aren’t full-fledged IDEs.

Anyone who has used IntelliJ or Eclipse for Java will tell you the amazing refactoring powers of those IDEs. Especially with Java 8’s functional features it is pretty amazing seeing a loop automatically refactored into a chain of pure stream functions.

A quick shout out to Leksah. The author is the only one putting in a serious effort to build a Haskell IDE. From what I hear it’s getting over a lot of the initial teething problems that it had.

It would be great to see efforts from the teams of ghc-mod, SublimeHaskell, ide-haskell and Leksah considered in the Haskell release cycles. For example, as of writing this Leksah is on GHC 7.10.1.

Packages on Hackage

One great feature about Haskell is that if there’s a package that’s worth using, it’s on Hackage. You rarely have to build random github repos in order to access some open source library. Unfortunately there aren’t too many more good things to say about this.

Package version, compatibility and SEO

There needs to be some SEO considerations taken in to Hackage. That way if I google a package I should end up at the latest version. If I’m in an old version of a package it should have some way of letting me know I’m not in the current version and a quick jump to get there.

In a package I also have no idea of which GHC version I need. Frankly I never keep track of which version of base is for which version of GHC.

Links

This is a pretty minor issue, but sometimes I want to provide someone a link to a specific function in a package. For example I can link them to the listArray function in the array package. It would be really nice if there was an anchor link next to it whose hyperlink I could copy – instead of having to inspect the source to get the name of the anchor. (I’m aware you can also get these links from “Index” in the nav).

Navigation and information scent

Information scent refers to the extent to which users can predict what they will find if they pursue a certain path through a website. The term is part of information foraging theory, which explains how users interact with systems using the analogy of animals hunting for food. Deceivingly Strong Information Scent Costs Sales

While browsing Hackage I have absolutely no clue where I am. There are no breadcrumbs, highlighted nav options or any contextual clues. It is incredibly easy to get lost. The information architecture seems to have emerged rather than been designed.

Additionally, it’s difficult to know where to go to navigate around. The navigation style suddenly changes when the user is inside a package and the navigation you do have isn’t very clear. For example there is a table of contents for the package labelled “contents”. So if I click the “contents” link in the nav, where might I expect it to take me? Why would I expect that to take me back to the package home page (which is more than just the contents of the package)? What does “Index” mean?

Mobile

Hackage is so simple there is really no reason why it shouldn’t be more mobile friendly. For example, we could start by adding this to the <head> tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

Finding packages

Hackage has the rare distinction of having both too much and too little content. There often aren’t libraries for certain specific things (though this is getting massively better over time). But worse – when there are libraries there are often too many to choose from. It’s always interesting seeing a Reddit or StackOverflow post where someone asks about using some random package that hasn’t been edited in years when there is a mainstream package that everyone uses (probably maintained by Edward Kmett).

There are many ways this could be improved – including community/social curation, better categorisation, sorting, filters, faceted searching, etc.

The wiki, other documentation and IRC

I refer back to the Rust documentation – which covers everything from how to install and setup Rust all the way through to how to use its many features. Some Rust features such as its borrow checker are on a complexity level close to Monads. Yet it’s all there, on the official Rust site, in a structured easy to learn way.

The Haskell wiki on the other hand is a beast. There isn’t a structured way to read through it and it’s often found through Google searches or linked to via StackOverflow or Reddit. The content falls out of date with the version of GHC that we are up to, and many of the articles provide hints that try to resolve some of the other issues discussed here (such as which package to use).

Meanwhile the incredibly detailed GHC documentation describing every feature it has is comprehensive but daunting. It’s method of structuring content seems more based on architecture than on usage. And it’s method of describing things like language extensions is insufficient enough that countless blog posts exists about each feature (each explaining it in a different way).

All of this documentation is either so hard to find or so poor that often the easiest way to get any help is to go on the IRC channel. That we have such an amazing community willing to help others with issues is actually a sign of how bad the self-help is.

Learning Haskell

Learning Haskell was hard. I’m fairly certain I’m in the majority with that sentiment. There are people out there who will insist that Haskell is easy to learn. For most people I’ve spoken to that have tried to learn Haskell, that false impression is problematic. It makes people feel dumb for not being able to understand something that’s sold as simple. Hard doesn’t mean bad – hard just means hard. People don’t scale mountains, launch rockets into space and explore the bottom of the ocean because those things are easy. We do it because hard things can be worthwhile.

Like many people I learned Haskell from the Learn You a Haskell book. Afterwards it felt like making my way through the wild west. The lack of intermediate level resources is a well known issue that I don’t think is worth getting into (this post is long enough as it is).

The main issue is that there seem to be two types of Haskellers. for lack of better phrasing, I’ll call them the “Developer” and the “Academic”.

The Developer is interested in examples, tutorials, use-cases, etc. Here’s what the Developer might want – n tutorial on how to connect to an API and parse a deeply nested JSON response. Here’s an excellent tutorial that answers just that – a wreq tutorial.

The Academic is interested in other things – what problem does the library solve? Is it a problem worth solving? If there are type classes do they have laws? This type of Haskeller will go straight for type signatures and function definitions to understand how it works. They will read that 50 page paper linked in the Hackage package and understand not just how to use the library but the theoretical underpinnings of its implementation.

Learning Haskell has really prompted me to pick up the academic side. I can now read a papers like Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire and come out understanding what a hylomorphism is. I can now read confusing type signatures full of complex constraints and RankNTypes and understand what they mean. I get how lenses compose. I now understand the Yoneda Lemma.

But at the end of the day I’m still a Developer in an Academic world. And more and more Haskell is attracting the kinds of developers who don’t know Lambda Calculus or Type Theory. We find things like the Turtle tutorial and Pipes tutorial to be welcome documentation in complex libraries.