작은 스터디에서 Elm 컴파일러 에러 메시지를 교재처럼 쓰고 있어요. 각자 일부러 틀린 코드를 가져오고, 다 같이 에러를 읽은 다음에 고치는 식이에요.
레코드 필드 오타는 정말 잘 먹혔어요. fistName이라고 쓰면 컴파일러가 필드를 비교해 보고 firstName <-> fistName을 오타 후보로 짚어 줘요. 다들 바로 알아봤고, 뭐가 틀렸는지 자기 말로 설명도 하더라고요. 컴파일러가 친절하게 알려 줘요. 진짜로요.
문제는 MISSING PATTERNS였어요. type Status = Idle | Loading | Failed String에 Failed를 넣고 case를 안 고치면 빠진 경우를 보여 주면서, 그 분기는 나중에 쓸 거면 Debug.todo를 자리표시자로 쓰라는 힌트를 붙여 줘요. 그런데 몇 명이 그 힌트를 그대로 붙여 넣고 끝냈어요. 컴파일은 되니까요. Failed일 때 화면에 뭘 보여 줄지는 아무도 안 정했고, 그 분기가 실행되는 순간 앱이 죽어요.
힌트가 틀린 건 아니에요. 작업 순서를 도와주려는 말이니까요. 그런데 배우는 입장에서는 "이렇게 고쳐라"로 읽히나 봐요. 다음엔 ReScript로도 같은 걸 해 볼까 해요. variant에 case를 추가하면 처리 안 한 분기를 짚어 주는 건 거기도 똑같으니까요. 혹시 이런 식으로 가르쳐 보신 분 있으면 어땠는지 듣고 싶어요.
