I Learned Haskell In 15 Years

TL;DR

Tutorial-style learning didn’t stick; doing exercises and building toward a goal mattered more than passive reading.

Briefing Cornell Notes

Briefing

A long, winding path ended with a concrete milestone: after roughly 15 years of intermittent study, a useful Haskell program finally got written—along with a clearer sense of what “learning Haskell” actually means. The payoff wasn’t just language fluency. It was a workflow built around declarative domain models, pure functions, and tight boundaries between business logic and the messy real world—an approach the narrator says made later programming tasks easier to reason about and safer to change.

The journey starts with early exposure to functional programming through blogs and projects, then a more deliberate attempt at Haskell via an independent study in 2007 with a dorm neighbor who used Common Lisp and Emacs. The narrator leaned on Graham Hutton’s “Programming in Haskell” but struggled with the classic tutorial trap: flipping pages without doing exercises didn’t stick. A turning point came when a real environment appeared—an Asus netbook running Arch Linux with xmonad configured via Haskell. Customizing xmonad wasn’t just tinkering; it provided a goal, fast feedback, and a reason to write Haskell repeatedly until the configuration “worked” and could be used daily.

Even so, Haskell mastery didn’t arrive as a straight line. The narrator describes years of partial use—sometimes using Haskell-written tools without realizing it, sometimes bouncing off the language when it felt too abstract. The breakthrough accelerates after learning Elm, which the narrator credits with making Haskell-like ideas feel approachable. Elm’s architecture—state, update, render, and message-driven interaction—served as a conceptual bridge. From there, Haskell became less like an academic puzzle and more like a language for modeling data and transformations with explicit handling of failure cases.

That conceptual shift shows up in later work. At Netflix and elsewhere, the narrator describes rewriting complex systems to reduce errors and improve reliability—citing a “fate of Destiny” test where turning off video prefetch reduced memory pressure, crashes, and ultimately improved revenue. The same theme appears in code: when software drifts from its original design, rewriting can be the only way to regain clarity and correctness.

The final milestone arrives after a layoff in October 2023 and freelancing. A first client need led to a time-tracking program built in Haskell: parsing command-line options, storing and querying SQLite data, converting UTC timestamps to the local timezone, and generating reports grouped by day or month. The program avoided heavy monadic abstractions at first, but the narrator eventually gained a mental model for monads—likened to a “burrito”—and used the compiler as a guide while iterating.

By the end, the narrator’s definition of success is practical and philosophical: Haskell is learned when it becomes natural to represent a domain declaratively, write pure functions over that data, and treat side effects as boundary work. The result isn’t just a working program; it’s a repeatable way of thinking the narrator expects to use again—whether for another Haskell project or for building software in general.

Cornell Notes

After about 15 years of intermittent study, the narrator finally wrote a genuinely useful Haskell program—after earlier attempts stalled on abstraction and tutorial fatigue. The key accelerant was a conceptual bridge from Elm: Elm’s state/update/render architecture made Haskell-like ideas feel practical, especially for modeling domain data and handling failures explicitly. Real progress also depended on writing for a purpose (e.g., configuring xmonad in Haskell) and on using the compiler and tests to tighten correctness. The final breakthrough came during freelancing, when a time-tracking tool required real command-line parsing and SQLite queries, turning Haskell from “something learned” into a workflow for building reliable software.

Why did the narrator’s early Haskell learning stall even after finding good resources?

They describe a common failure mode: reading or flipping through a book without doing the exercises doesn’t translate into real skill. They also admit difficulty following step-by-step tutorials once they get past the basics—eventually the urge to “just do it myself” takes over, so the learning path has to be driven by a concrete goal rather than a linear tutorial.

What role did xmonad play in making Haskell feel learnable?

xmonad became a practical sandbox. By running a netbook on Arch Linux and using xmonad, the narrator could treat the window manager configuration as a Haskell program. Customizing it—cutting down the config, setting keybinds, and adding status bar content—provided immediate feedback and a reason to keep writing Haskell until the setup stabilized.

How did Elm change the narrator’s relationship with Haskell?

Elm served as a friendly on-ramp because its architecture mirrors the core mental model behind functional UI: state is rendered from a model, user interactions send messages, and an update function produces a new state. The narrator argues Elm’s constraints make these ideas easier to grasp, and that understanding then transferred back to Haskell, especially for thinking in pure functions over domain data.

What does the narrator say about learning correctness—especially around decoding and invariants?

They emphasize explicit modeling and failure handling. Elm’s approach to decoding JSON into domain types forces mapping responses into expected structures and handling decode failures rather than passing around arbitrary dictionaries. Later, in game-state thinking, they highlight invariants: encode expectations (e.g., players’ move counts) directly in the state/update logic so mistakes surface quickly via asserts or compiler help.

What was the “real program” that finally made Haskell feel useful?

A time-tracking application built during freelancing. It parses command-line options, interacts with a SQLite database, converts UTC timestamps to the user’s timezone, and prints reports grouped by day or month. The narrator also notes it passes functions into functions and uses data types for client accounts and time entries, while avoiding overly fancy monadic machinery at first.

How does the narrator connect software rewrites to learning and reliability?

They describe rewriting as a response to drift: systems originally designed for one set of needs become messy when requirements change. They cite a Netflix example where turning off video prefetch reduced memory errors and crashes, improving user experience and revenue. The broader lesson: sometimes “burn it down and rewrite” is the path to clarity and correctness.

Review Questions

What concrete learning mechanism did the narrator rely on to move from reading Haskell to writing it (and why did tutorials alone fail)?
How does Elm’s state/update/render architecture function as a conceptual bridge to Haskell in the narrator’s account?
In the time-tracking program, what kinds of responsibilities (parsing, persistence, time conversion, reporting) made Haskell feel practically “real”?

Key Points

1
Tutorial-style learning didn’t stick; doing exercises and building toward a goal mattered more than passive reading.
2
A practical Haskell environment (xmonad configuration) provided feedback loops that turned theory into repeatable skill.
3
Elm’s architecture helped translate Haskell-like thinking into something approachable: messages drive updates that produce new state for rendering.
4
Correctness improves when domain logic is modeled declaratively and side effects are isolated at boundaries.
5
Explicit decoding into domain types (rather than loose dictionaries) forces handling of missing or invalid data early.
6
Rewrites can be justified when software requirements drift from the assumptions baked into the original design.
7
The final Haskell milestone came from freelancing needs that demanded a real command-line tool with SQLite persistence and reporting.

Highlights

The narrator’s first durable Haskell progress came from configuring xmonad in Haskell—turning a daily tool into a learning engine.

Elm acted as a bridge: state, update, render, and message-driven interaction made Haskell-like modeling feel practical.

A Netflix “fate of Destiny” test showed that removing an optimization (video prefetch) reduced memory errors, crashes, and improved revenue.

After freelancing began, a real Haskell time-tracking program finally delivered the “useful program” milestone after years of partial attempts.

Topics

Learning Haskell
Elm Architecture
Functional UI
xmonad
Software Rewrites