Haskell Katas to keep syntax fluency sharp

I find my blank-page fluency in Haskell often gets degraded by various different things. What I mean by “blank-page fluency” is opening up an editor and writing out a program without looking anything up, without an LSP, without any help at all, from start to finish.

It’s debatable how useful this skill is anymore. It’s nearly always worth double-checking, looking up the latest practices, or checking patterns elsewhere in a codebase. I think with recent trends in AI, assistants, and LSPs, total syntax fluency isn’t as important as it used to be.

However, it’s still valuable in my opinion and a massive speed boost to be able to just create code from the editor without needing to check or look anything up. I think it’s especially useful for writing tests.

Anyway, this is my long-winded way of asking how people keep this skill sharp. I find I often have to jump into languages like C++, Python, Dart, etc., for extended periods. When I get back to writing raw Haskell (as opposed to working on existing Haskell code), I can be hit with the tyranny of the blank page and have to double-check even simple syntax for a few days.

Perhaps my question is disingenuous based on the title of this article. I’m curious about katas. I used to use Advent of Code and other coding challenges, but I think this is overkill for regaining syntax muscle memory (or is it just confidence?).

I’m curious about people’s experiences with katas and if there are any up-to-date and comprehensive ones out there. I like doing the 99 Haskell Problems with GHCi sometimes. But I think I would prefer something that has the most common patterns, so everything from basic list manipulation to creating data structures, to type classes, monads, concurrency, etc., maybe even stuff like working with Aeson. Or am I just overcomplicating it? Maybe the coding problems are just the best way to keep skills sharp.

6 Likes

I think it’s a great topic. From a blank page I can write simple Haskell scripts - using the parts of base that I’m familiar with, and maybe a few small parts of other libraries. Anything more has always required reviewing examples and multiple learning resources (online) - hoogle, hackage package pages, haddock pages, ghc user guide etc. I think Haskell was not designed for blank-page productivity particularly - or perhaps it was, but the current experience with GHC haskell has diverged from that.

Could that be improved by tweaking the language/libraries/tools ? Probably.

How much can a haskeller improve their blank-page coding fluency through deliberate practice ? Probably quite a bit.

What would be the most useful things to practise and hold in limited human memory ? Language constructs, a known set of extensions, the most useful APIs in base and core libraries for a particular LTS snapshot and GHC version ? A design and rough implementation of a few common program types (batch script, web app, database app, game..) and subsystems (command line processing, terminal interaction, tui, graphics, configuration, templates..) ? Some essential tools (cabal/stack, ghc, ..) and file formats (cabal files, stack.yaml, ..) ? Seems quite a lot.. specialisation needed..

Blank-page programming could be a great theme for a games jam or coding contest, maybe. “What can you build with GHC 9.10 [and base [and lts snapshot]] without consulting any docs ?” Self-policed.

2 Likes

Thanks, @simonmic . I’m glad the topic resonates. I have a similar experience; depending on how fresh I am with a library, I find myself on existing projects often just copying patterns from elsewhere in the codebase.

To me, it’s a question of cognitive load. I know this from learning spoken languages: you want the common patterns to be automatic and internalised to free up your mind for the actual conversation. I’d hypothesise it’s the same for a coding language. Removing the cognitive load of syntax frees up thinking power to focus on larger concepts and edge cases. Of course, in day-to-day development, just looking up a pattern achieves a similar result, as it’s much easier to recognise a solution than to create one on a blank screen.

The other benefit of this fluency is the ability to “code in your head”—to craft solutions and play around with ideas before typing. Most of us can probably design FizzBuzz just by thinking, and I find being able to quickly play with different approaches in my head, without the friction of typing, is a huge advantage.


On Practice and Memory

You mentioned holding things in limited human memory, and this is where I see the value of katas. I have no background in neuroscience, but my intuition is that our subconscious has a much larger storage capacity. For me, katas are a way to use conscious, deliberate practice to store patterns in that deeper part of the brain.

This storage I think has a relatively large cost when compared to simple note taking, the cost being in preparing the materials and then practicing them, This cost leads to the question: what’s actually worth the time and effort to store this informatin? What’s truly needed in the daily work of a Haskell developer?

I’ve started an experiment to create katas by feeding my own notes and code into an LLM. My hope is to refine this into something genuinely useful. It’s very much a work-in-progress; as I said, it’s LLM-generated (slop) at the moment, but my plan is to refine it through iteration. I expect to throw large parts of it out and craft new Katas by hand as I use them and assess the benefit with habitual use over the coming weeks and months. So part of me is very reluctant to share, but if you’re curious, this is the current state of it:

my early haskell katas


Lessons from a Language App

I love the game jam idea! And your point about it being “self-policed” is interesting because it brings up a lot of ideas from my experience building a free Irish language learning app.

We have a decent sample size of a few thousand users( I recognise its debateable how much cross over the domains are). We learned that having strict rules for sentence pairs made it fun and hard to game, while a “stuck button” provided a necessary release valve. We also added an EXP points system where seeing the score go up provides a bit of dopamin for motivation; we just deduct points for using hints. The point being the gamification really added a lot of motivation to a dry topic.

The biggest lesson was distinguishing between lesson types: for getting specifics right, strict typing exercises were best (simple string matching), but for encouraging people to actually speak, a simple self-assessment was far more effective than trying to technically analyze their voice. This was because of the implementation and maintence costs, building and maintaining an voice analyzer was infinetely more complex that just matching strings and it didnt provide much extra value to the user to justify it.

So, to bring all that back to Haskell, it seems there’s immense value in distinguishing between different kinds of practice:

  1. Strict Katas with Tests: For core syntax and patterns.
  2. Looser, Self-Assessed Exercises: For more complex topics where the goal is just to practice thinking about the problem.
  3. Simple Notes: For everything else that’s best left to documentation.

As you can probably tell, these ideas have really captured me recently! I’m really keen to explore this more, perhaps as a community effort. It would be interesting to see if there’s something tangible for the community in all this.

1 Like

Very interesting! I’ll have to check out that app and keep an eye on those katas.

Some related thoughts from #haskell-game chat this morning:

we need to consult docs at some point. Where should that point lie ? Does it come too soon and too often ? How does that compare for different languages/ecosystems/domains ?

for me with haskell, solving the problem, figuring out the mechanics of how to express what I want to say, and consulting docs about apis, packages, language, are all heavily interleaved. With say php, less so. It’s a smaller language conceptually, with more batteries built in, so less importing and researching noise⁦

⁦my ideal haskellscript language would be a bit more like that - more/better batteries and better built in docs, encouraging flow⁦

⁦i think for a given domain - say “sdl games”, or “tui games” - one could choose and document some flavour of simple haskell/packages/apis, to improve the “free coding” experience in that area⁦

(I like “free coding” - remiscent of free climbing or free diving.)

1 Like