Nice, but it feels quite unnatural that compiler tries to speak to you like a human being ("As I infer types of values flowing through your program…"). I cannot say why I'm against it, or even if I'm against it, but I remember some postgresql error message guidelines where it was explicitly said not to do so, cannot remember why though. That's peculiar.
I'm a big fan of the coming anthropomorphisation of computers. It seems so clear (to me) that the future is heading that way.
Apple have already hired writers for Siri; how many more years before its personality starts to change to match the tone and manner that you ask questions? Young children have already started to mis-identify Siri as a real person! There was also the film Her the other year which seems quite prescient. Regardless of if we ever get to real AI, it seems quite clear we're going to face intelligent-seeming computers in the near future, and we're going to start to interact with them almost as if they were intelligent. It's going to be an interesting future.
This is a huge tangent, I know. It just seems like compilers speaking to you like a human being is just one more facet of this change.
> Software isn't "cautious" or "ambitious", those are qualities of alive beings. But maybe it serves us to think so.
Also this:
> Our minds respond to speech as if it were human, no matter what device it comes out of. Evolutionary theorists point out that, during the 200,000 years or so in which homo sapiens have been chatting with an “other,” the only other beings who could chat were also human; we didn’t need to differentiate the speech of humans and not-quite humans, and we still can’t do so without mental effort.
The future may be heading that way, but I'm personally not a fan of it.
As I understand it, we use different regions of our brain for interacting with tools, people, animals, etc. I enjoy using the tool part of my brain when computing. It feels "quieter" and contemplative. It feels like I am doing something, not like I am asking an assistant to do the work on my behalf.
I like social interaction a lot too, but as an introvert, it's kind of draining. I would have to leave computing if using a computer felt like being in an intense conversation with a computer-person all day. Even if the conversation is pleasant and fulfilling, it would be too much social interaction.
> I enjoy using the tool part of my brain when computing. It feels "quieter" and contemplative.
I totally get that. Personally though, I see conversational UI as an additional parallel mode of interaction, that you can use simultaneously. I can imagine e.g. coding, and interacting and thinking analytically about that, while still verbally being able to have a conversation with my computer for e.g. responding to email or calendar appointments. Not for everybody, of course.
Edit: I suppose, what I really mean, is that I'd like to interact with human things (email, meetings, messages, etc.) in a human way (conversationally, as I would a person), and I'd like to interact with machine things (coding, simulations, etc.) in a machine way. Trying to interact with human things in a mechanical way seems unintuitive, really, except it's all current technology affords, so we all have to learn these machine interfaces instead. And maybe that's why so many (non-techy) people find computers needlessly complicated.
I have tried to talk Evan (Elm's creator) out of the first person, but as you can see he likes it. But I think you bring up an important point: for some people, being able to use the social parts of our brain is like offloading to the GPU, and for others it's like firing up a generator when the power goes out.
Part of it might be that it obfuscates the structure of the error message. Error messages, even without error cascading, and especially when taking a top-down approach to writing code, are long and meant to be skimmed. Human languages are great for reading top to bottom, but not so great for skimming. Terse (but not cryptic) formatted text, as found in programming languages, is much better for skimming.
You'll only ever actually read "As I infer types of values flowing through your program…" a few times while getting used to the compiler, after that you'll recognize it by shape and never read it again, and at that point all the anthropomorphized text is doing is taking up screen real estate that could have been used to display more errors.
If you mean parsing by machine, the solution is to have a separate machine-readable output (JSON perhaps). If you mean comprehension, that's a valid point that is being discussed elsewhere on the page.
As I said I don't have strong opinion on that matter. It just struck me as something I remembered as not recommended by some guidelines, considered to be good example of error message standard and violated here, in another post about "good error messages". But let me play devil's advocate, anyway.
Compiler is relatively simple piece of machinery, it isn't really smart. So maybe it shouldn't pretend it is? It doesn't have personality, it doesn't think anything, it doesn't actually even do anything: it is just a set of transformations from one set of bytes to another. In the worst case it has some heuristically-statistical optimizations, but it still is some process that can be accurately described in a relatively short amount of time. I don't want it to have an opinion and actually I know it doesn't have one. I know all has happened is that I made a mistake and I just want to know exactly what went wrong. I don't want to read compiler's essay about how it spent its holidays, because I know it cannot write essays and didn't have holidays anyway.
At the moment I don't use Elm, but if I did, I would be getting such messages tens, hundreds times a day. Every time I have to search for something one could call "the real problem" in the bigger text — I do work. I spend energy. Sometimes I can do so while being mentally exhausted or in a hurry. Or both. The more short, exact and concise message will be, the easier to understand the problem it will be and the greater my gratitude towards the author of this message will be. And it's not only about length of the message, human-like natural language constructs are inherently more complicated and diverse than short messages and labels — that's the reason why we invent labels and such after all.
All the good answers must be the direct answers to the question one might ask. When I'm about to read the error message of the compiler, I'm not thinking "Dear friend Compiler, what have you been doing in the meanwhile and what do you think about life?". No, I'm asking "What the hell did happen?". What did happen, and not what "did compiler do" or "how things work" or whatever.
One more problem is that Elm compiler might work just nice, but it won't always be right. I don't believe it and you probably shouldn't rely on it. The less creative it will be in its search for "what might have happened", the more likely it is I won't be distracted by its opinion. Even as skeptical and suspicious as I am, I am prone to get used to how some tool behaves. If it usually is right and tries to deceive me by behaving smarter and more human like than it is — one day I will believe it and spend way more time to figure out the problem than I would have if I treated is as a compiler and not my mate.
So, finally, what is the real purpose of the error message? I love artistic people, but unfortunately it isn't to show how thoughtful and creative the author of this piece of technology is. The real purpose is to help me find my mistake. There are 2 general types of mistake I can make: a simple one, like a typo, syntax error, forgotten type, variable definition, you know what I mean — and a complicated one, like unexpectedly finding a bug in the compiler itself, some weird Rust-lifetime problem, — It's hard, to make up an example, but the point is it requires some thinking and research. Help I need in the case of simple mistake is generally just as precise place of the mistake in the code as possible. Maybe some function signature with good description of parameters. Something I can easily grep (ack) or google (DuckDuckGo) in the case of more "internally-oriented" errors. I don't usually find "typo suggestions" useful, but ok, why not. The thing is 3 times out of 5 I will fix my mistake quicker than I do the reading (even in the languages with less verbose error messages), literally. I would thank my compiler for being as concise and straight-forward as possible to shorten the gap even more. I don't want to read what I don't need to.
In the case of "the complicated mistake" it is not likely compiler will actually guess what's the matter. I'll need stacktraces (if any), precise and unique exception names (error codes), maybe some additional info, but nothing that compiler can actually handle to discover itself.
So the best compromise I can imagine, which, I think, would help in both cases, would be short, concise, "machine-like" messages, concrete things like function signatures, "expected/found" diffs and links to the related section of documentation (web-based or local one — the latter would be even better) where everything would be described in the detail. And no playing a human.
