> Is there a specific reason that makes you prefer an impersonal compiler?

It complicates parsing

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.