3 ms·
> Error messages are another PL design feature shaped by peoples’ standpoint, by their lived experiences and values. For many programming language designers, er
by tines 1y ago
> Error messages are another PL design feature shaped by
peoples’ standpoint, by their lived experiences and values.
For many programming language designers, error messages
are an afterthought. Other aspects of design will likely over-
power the careful crafting of error messages, such as an op-
timized compiler or an elegant syntax. Many language de-
signers, explicitly or implicitly, take the stance that ‘users
will just have to deal with error messages when they oc-
cur’. Error messages in many languages explicitly do not
include the user in their phrasing, saying things like ‘miss-
ing bracket’ or ‘unknown variable’, which leaves the user
out of the equation. For a person with the lived experience
of being told they don’t belong in programming and being
afraid of failure in the programming world (a common expe-
rience for women in computing), unclear or unhelpful error
messages are more likely to have negative impacts. More
readable error messages are not just helpful for those with
less prior knowledge, clear error messages are a better ex-
perience and will help all users—even professional develop-
ers. A recent study on error messages in Elm showed that
their well-phrased error messages were the most-named
positive experience of professionals working with the language [citation].
The author must consider the audience is either stupid or childish. An intelligent adult deserves respect and should not be talked about in this way, implying that they are emotionally unequipped to handle a straightforward computer error message.
- deleted 1y ago[deleted]
- James_K 1y agoTalked about in what way? The text you quote says that error messages "may have negative impacts" on people, which seems undeniably true.
- 1718627440 1y agoNice sounding "non-negative" error messages also have a negative impact on people, in that they can't fix the problem, because the message isn't precise enough.
- James_K 1y agoYes. This is what she pointed out in that quote you just gave.
- 1718627440 1y agoHuh, I was stating the opposite of the original claim, was about negative short messages while I was talking about the then introduced "user-inclusive" long messages.
- miav 1y agoThe author is not advocating for friendlier messages in the googlesque sense of dumbing them down or introducing more positive wording, but in the sense of making them more readable and useful. Of course it does not matter for "a straightforward computer error message", in cases where the error is a simple type mismatch or a missed semicolon, but if those were the majority of the problems we encounter as programmers, our work would be trivial. It's not difficult to imagine a situation where structuring a compiler in such a way that it keeps more state and perhaps has to perform more analysis is worthwhile, since a more useful error message saves the user time in understanding and fixing a problem. An example that comes to mind is when in Rust I tried to create a dynamically dispatched trait, where the trait in question contained a function an argument of which was generic over a different, statically dispatched trait. Since the compiler did not know at compile time the exact object which would be instantiated, it was incapable of inferring the exact type of the second, statically dispatched trait at compile time, thus failing to compile. The error was presented to me in a clear way that pointed out the problematic relationship between dispatch types of the two traits allowing me to understand and fix the problem quickly. If the error message was far simpler, such as "can't dynamically dispatch trait", I would have figured that out too, but it would have simply taken more valuable time. Most importantly, having to track down the issue from a minimal error message, would not have been an honorable test of my intelligence and emotional maturity, it simply would have been inefficient.