7 Comments
User's avatar
Anès Foufa's avatar

Thank you for the article. There are in fact discussions and proposals to model exceptions in the type annotations. It did not go far AFAIK but it's a recurring discussion.

Funny typo: Ocalm instead of Ocaml, specially for a French speaker.

Expand full comment
Bite Code!'s avatar

Tranquille cousin, Ocalm.

Expand full comment
George V. Reilly's avatar

One of the influential sources of the "parse, don't validate" mantra is https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

Expand full comment
Bite Code!'s avatar

I really should have linked that in the article.

Expand full comment
Bite Code!'s avatar

Ended up adding a whole section with not only the original article, but also why it's so hard to match it with Python programming style.

Expand full comment
bjkeefe's avatar

I, like @wyrdsmythe, had not heard of "parse don't validate" before just now.

Just fyi, if you're curious.

That aside, this was another great article from you. Definitely a keeper. Thanks!

Expand full comment
Wyrd Smythe's avatar

Interesting post. I've been coding since 1977, but this is the first time I've heard "Parse don't validate". Until now, if asked, I would have said "parsing IS validation" (and vice versa). That said, my natural instincts are for high-level abstractions. I'll create a new class (or a subclass of a built-in) at the drop of a hat. I may sometimes start with tuples, but if the app has any complexity at all, that quickly gets old. "What element was which, now?" I usually skip over named tuples and go right to a user-defined class.

Expand full comment