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.
Conversation
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
1
2
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
“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
Any idea what a better prefix would be? Or would it be better to just remove it? Or do we dial down the severity of this stuff in development, so you get 'info' and 'note' messages instead, leaving the errors for CI and release builds?
2
(this doesn't solve the issues you raised in the previous tweet, just wondering as somebody who makes a diagnostic reporting library, hehe 😳)
1
1
If you can break with convention, removing `error: ` is an easy win
1
2
Yeah, thinking maybe it would be good to demonstrate that in the examples and documentation. Try to nudge downstream tool-makers in the right direction I guess… ‘this is what your tool could be like’ – hehe :)
1
1
Maybe "reason:" could work as a prefix? As in "the reason compilation stopped". Otherwise "info" is probably good
1
What about "fixme: "? Thinking about this:
Quote Tweet
This is most obvious with refactoring — experienced programmers will structure a refactoring so that the type checker tells them everywhere they need to fix (whenever possible…). Those “errors” are just a checklist from a very diligent partner.
Show this thread
2
3
Also thinking about hole driven development, and about that gives you a bunch of 'todo's for missing parts of the code you still need to fill in… sometimes those are displayed as warnings, or in an interactive side-panel in your IDE/editor. 🤔
Thinking about Lean's info panel, which is a bit like a todo list (you can even add custom widgets for your own datatypes): github.com/leanprover/vsc – they still use red squigglies and text for ‘errors’ though. Other theorem provers have similar ways of listing your ‘goals’…
1
1
3
Seems like Pyret just does away with a prefix in their browser based editor. Of course they have more freedom their with formatting, vs. the console. Was inspired to check them out again thanks to this tweet:
read image description
ALT
Quote Tweet
Replying to @yminsky
We have @Bootstrapworld teachers who use @PyretLang error messages as a pedagoical device. I think that's possible in part only because we don't have screaming red error messages, and in fact quite sophisticated output (partly thanks to @tenellous).
2
3
Show replies