Conversation

Jon Purdy
@evincarofautumn
Compile errors aren’t errors! Most of them are plain outputs with needlessly stern wording.
Quote Tweet
Bob Nystrom
@munificentbob
·
I like this article a lot. I can distinctly remember when I first started realizing that working through compile errors and designing the types for my program *was* programming and that fixing those errors was meaningful, important progress. twitter.com/healeycodes/st…
Show this thread
3
84
Jon Purdy
@evincarofautumn
I’ve said it before:
Quote Tweet
Jon Purdy
@evincarofautumn
·
Replying to @http406
Even if it’s a situation where the compiler can’t go on, is it really an error if that’s normal/expected? I’m a Haskell “expert” and still surprised when anything but the most trivial program compiles on the first go. Almost all of my compiles end in “errors”, on purpose.
1
4
Jon Purdy
@evincarofautumn
In multiple ways:
Quote Tweet
Jon Purdy
@evincarofautumn
·
Thinking of type “errors”—or even syntactic “errors”—comes pre-burdened for free with a really unfortunate set of assumptions and hostile framing. Your program is *wrong*! It’s got an *unexpected* mismatch between this and that. You need to *fix* it before I’ll *let* you proceed.
Show this thread
1
1
Jon Purdy
@evincarofautumn
With concrete advice:
Quote Tweet
Jon Purdy
@evincarofautumn
·
Adopting this attitude (ca. 2012 iirc) changed the whole way I do language design and tooling development. Compiler/interpreter error messages are the single best place to surface learning materials for a language, because trial *and error* is a huge aspect of how people learn! twitter.com/ManishEarth/st…
Show this thread
1
4
Jon Purdy
@evincarofautumn
I will continue to say this until we make the computer quit being mean. It’s an important realisation that the process of figuring out how to get your code to compile is programming too, and it shouldn’t be a realisation at all—it should be clear from the user interface design.
2
21
Esteban K�ber – 🦀⚙️
@ekuber
You know what? I make an effort to always use plain language and try to come accross as matter of fact (playfulness might be accepted but is frowned upon) in diagnostics, but just removing the leading "error:" might actually be a small change ti reframe the interaction.
2
2
Jon Purdy
@evincarofautumn
Exactly! Doing that has led me in a direction I like, at least. Including a “warning” or “error” prefix does serve some purposes, like helping IDEs/editors format messages that follow (or vaguely imitate) the standardish GNU format, although those tags aren’t very informative.
1
2
Jon Purdy
@evincarofautumn
“Error” might be “I can’t”, or “You’ve asked me not to”, or “I will, but only if you super-promise that these shenanigans are what you meant to do”; “warning” might be about anything: style, performance, possible issues, or even *likely* issues too noisy to make errors.
1
3
Esteban K�ber – 🦀⚙️
@ekuber
Replying to
@brendanzab
and
@evincarofautumn
1) we can't remove it outright because we want TTS users and tools that want to parse it to be able to do so (so I'd use some short prefix, maybe a single char?) 2) that would be ideal, to turn things into lints denyed when publishing instead of hard errors to aid in development.
1
1
Show replies
Show replies