See a typo? Have a suggestion? Edit this page on Github
This blog post will focus on the situation for Haskell, though the ideas likely generalize well to other languages, or even to non-programming disciplines. I’m simply speaking to the topic I have the most experience with.
Many people will make claims that a certain decision needs to be made “for new users.” These recommendations can range anywhere from sensible, to confusing, to insulting. New users are thought of anywhere from smart people who need decent information provided, to individuals hungry for knowledge, to idiots who don’t know any better.
I’ve discussed this situation over time with people, and have spent significant time personally and professionally looking for ways to improve the situation for “new users.” And I believe that, by far, the most important trait we need to do this is empathy. To quote Wikipedia:
Empathy is the capacity to understand or feel what another person is experiencing from within their frame of reference
Let me start off with the most extreme example of where we, as Haskellers, have failed historically: monad tutorials.
Haskellers occassionally will glibly state “a monad is just a monoid in the category of endofunctors, what’s the problem.” I strongly believe the vast majority, if not all cases, of this statement are meant to self-mock. But let’s pretend for a moment that this information was stated in this tone to a new user, who has never seen monads, monoids, categories, or endofunctors before. This massively fails the empathy test:
Note that none of these statements require us to believe anything negative about a new user. I’ve not implied that they are unintelligent, lazy, weak-willed, or unsuitable to Haskell. My mental model of their frame of reference is fairly straightforward here: they have not been exposed to this material previously, they’re trying to get an answer to a specific question, and they don’t want to be made to feel inferior.
The monad tutorial fallacy in general (aka “monads are like burritos”) is a more subtle form of this. The author of such a tutorial, in their mind, has decided that monads are somehow like burritos. This is ignoring the frame of reference of the reader, who likely has no reason to believe monads actually are like burritos, and cannot understand the analogy. Sharing the analogy as if it will help, when in reality it doesn’t, can make a reader feel frustrated, confused, and inferior, and prevent them from wanting to go further. Again, this is not a failing in the new user!
I’ve built up a mental model for how I believe a new user to Haskell will typically be thinking. This is by no means universal; many people are exceptions. But I’ve found that the following traits generally apply to someone trying out Haskell for the first time. And making these assumptions about new users who don’t fit this description perfectly doesn’t usually cause any kind of major negative impact:
There are others attributes too, most of which I probably haven’t fully identified even to myself. But this is a decent starting point.
Regarding exceptions to this rule: some people are not
skeptical. Maybe they’ve been a Scala developer for years, have seen
Haskell at conferences for a long time, and are totally bought into
the language before they even start. Great! Treating them as skeptical
initially may involve giving them some cool motivating cases for
Haskell (my personal favorite being something like STM and the
Concurrently type). Providing this extra information can, at worst,
result in them telling me “hey, I get it, can we just skip to the part
where you teach me something?”
The same applies with impatient. I optimize my Haskell teaching to get something working quickly so that people know the investment has a good chance of paying off. But maybe someone has decided that, come hell or high water, they’re going to spend the next 2 weeks learning all the ins and outs of Haskell. They want to learn the Lambda calculus from the ground up, understand some type theory, and then write Hello World. Great! In those cases, they can easily skip my “concurrent HTTP downloads in 5 minutes” tutorial. The other way around—skipping the “the Lambda calculus for math majors”—happens less frequently.
As a side note, and just to prove the point: my wife has started learning Haskell (though our home renovations have recently gotten in the way of that). She fulfills neither of these criteria: she’s watched me using Haskell for 10 years, and isn’t at all skeptical of the language. And she’s learning the language without any specific impatience to get things working. To my knowledge, my standard mental modeling and new user onboarding wouldn’t have negatively impacted her acquisition of Haskell, despite this mismatch..
Alright, so given that I’ve built up this mental model, how does this affect how I try to onboard new users?
This is vital to keep in mind. When I started using Haskell, Hackage
had barely started,
cabal-install didn’t really exist at all, there
were barely any libraries worth using, and there was almost no
educational material. I was absolutely a “new user,” but I didn’t fit
the mental model described above at all. Making any assumption about
what other new users are willing to go through based on my own
experience would be wrong.
As I’ve recently stated, my goal is to “increase the adoption of Haskell.” For me, it’s vital to improve the new user experience significantly, and this drives a lot of what I work on in Haskell. Not everyone shares that goal, and that’s fine. But identifying these differences can help us within the Haskell community to have more constructive discussions about how to proceed.
One example of such a discussion (that I was not really involved in) was the Foldable Traversable Proposal (FTP) debate. There was a lot of discussion about “new users.” I strongly believe that different parties had wildly different ideas of who these new users were, and what their frame of reference was. If we had the language and perspective to openly discuss these differences, I think we could have had a more meaningful discussion.
The same applies to many discussions I am involved in, such as tooling. You can trace many of the more opinionated pieces of Stack to the mental model I’ve described above. For example, on the impatient side, Stack is optimized for a use case of impatience: you download a Stack executable, and it will automatically handle all of the other tooling installation you need. It may not do it in exactly the way every user wants (e.g. shared vs user-local GHC installations), but that’s not the goal.
Similarly, it’s optimized for skeptical users. From personal experience, running into dependency hell out of the gate is a major turnoff for skeptical users. Ensuring that the default of the tool is to use pretested Stackage snapshots knocks down this major obstacle to skeptical users. This also plays into the “smart, but distracted:” from experience, new users won’t spend time reading all of the detailed instructions you put on your site. They’re impatient to get started quickly, distracted by 15 other tabs, and will become frustrated when line 27 of your instructions would have fixed the problem they run into, but they just happened to miss it.