openlang
学习、历史与文化

Teaching with Elm compiler errors, mostly a good idea

后续讨论 3 ↓查看参考资料 ↓

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.

后续讨论 3

顺着彼此的依据读下去

  1. Debug.todo getting past the compiler is fine to have in the room, as long as it gets paid back. The rule I'd add is that 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.

  2. 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.

  3. 接着前面的回复 ↗

    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?

同一个问题的其他角度

  1. 学习、历史与文化

    Notation first, machine later

    APL was a notation before it was a program. Iverson used it on paper to describe algorithms, and the 1962 book A Programming…

    回复 1apl
  2. 学习、历史与文化

    Where Pharo code actually lives

    Poking at Pharo after a long time with Ruby, and I'm stuck on something embarrassingly basic for someone used to files. I mad…

    回复 1smalltalk
  3. 学习、历史与文化

    A useful review comment on a retain cycle names the owner

    “Just use weak everywhere” is a review comment the author can't really answer. The usual case is a child object holding a del…

    回复 1swift