Teaching with Elm compiler errors, mostly a good idea

The conversation continues 3 ↓Explore the sources ↓

I've been using Elm compiler error messages as teaching material in a small study group. Everyone brings code that's wrong on purpose, we read the error together, then fix it.

Record field typos went really well. Write fistName and the compiler compares the fields and points at firstName <-> fistName as a likely typo. People spotted it right away and could say in their own words what went wrong. The compiler will tell you, kindly. It really does.

MISSING PATTERNS was the problem. Add Failed to type Status = Idle | Loading | Failed String without touching the case, and the error names the missing case, with a hint to use Debug.todo as a placeholder if you want to write that branch later. A few people pasted the hint in and stopped there. It compiles, after all. Nobody decided what the screen should show for Failed, and the moment that branch runs, the app crashes.

The hint isn't wrong. It's there to help with a way of working. To someone learning, though, it seems to read as "fix it like this". I might run the same exercise in ReScript next, since adding a case to a variant gets you the same complaint about the unhandled branch. If anyone has taught like this, I'd love to hear how it went.

The conversation continues 3

Follow the reasoning

dryhingePermalink
Debug.todo getting past the compiler is fine to have in the room, as long as it gets paid back. One rule I'd add. Whoever writes it runs elm make --optimize once, which refuses code that still uses Debug, so the placeholder can't slip into a build anyone ships.

And if you do try ReScript next, it won't be the same complaint. A switch that misses a variant case is a warning there by default, not an error, so the code compiles and the warning scrolls past. I haven't decided whether that makes it a worse exercise or a more honest one.
Sources
- Minification · An Introduction to Elm ↗
rook77Permalink
How about hiding the hint at first and asking for a guess? Show only the error title and the missing possibility, and have everyone write down what that branch should do. Keep your guess. Then open the hint.

Read that way, Debug.todo stops looking like the answer and starts looking like a marker for "not decided yet". With OCaml pattern exercises it went similarly. The guess someone wrote down stayed with them longer than the compiler's wording did.
SeoyeonPermalink
Following an earlier reply ↗
rook77, I like hiding the hint, but I'm wary of where the guesses go. Show only the missing case, ask what Failed should show, and I'd bet most people write Failed _ -> text "Error". It compiles, never crashes, and throws away the message the type was carrying, so the placeholder problem just turns into a shrug problem. Would a real error message in the sample data be enough to make the wildcard visibly lose something?

Teaching with Elm compiler errors, mostly a good idea

The conversation continues 3

Other sides of the same question

round(2.5) gives 2, and learners don't believe it

3 + 4 * 2 is 14, and that is the easy part

Translating old CoffeeScript by hand is a decent JavaScript lesson