Right, good and informative answer, but I think it is partially missing
Andre’s point though. With some better contextual looking the compiler
could have given a more helpful message, like "size does not take
parentheses after it." which would be much less obtuse than what it did
actually render as an error message.
This isn’t an isolated incident, the Scala compiler gives error messages
that confuse certainly beginners in the language, but also all the way
though advanced-intermediate users as well. I think the quality of error
messages does indeed slow down Scala developers and thus impedes the
Scala’s use more broadly.
It is also true that poor compiler errors certainly don’t only come from
the Scala compiler. Java’s can often be quite unhelpful and even misleading
and certainly verbose to the point of obfuscation. And before that C,
Pascal, FORTRAN, ADA, COBOL, they all put the burden on the software
engineer to figure out the true error and solution.
Scala wants to be a better language to code in, right? This is one area
where there are no limitations of outside compatibility, backwards
compatibility or such, it’s a doable thing that can make using Scala better.
The two previous answer just goes to show. “Partially missing the point”? Bentito, you are too nice. Writing a compiler is easy. Lexing, parsing, code generation, all studied till we’re blue in the face. But useful solution messages? Zero.
Ok. Now I have got that off my chest, who is going to do something about it?
I agree with most of your points. In Scala it‘s even worse due to implicits where you‘re confronted with error messages that don‘t even touch the root cause, but give hint to a plan within a plan within a plan.
Welcome to Scala 2.12.4 (OpenJDK 64-Bit Server VM, Java 1.8.0_151).Type in
expressions for evaluation. Or try :help.scala> List(1, 2,
3).size():12: error: Int does not take parameters List(1, 2,
3).size() ^scala> List(1, 2, 3).sizeres1: Int =
3scala> 3():12: error: Int(3) does not take parameters
3() ^
The problem is that there is no size() method with an empty arguments
list, only a size method with no argument list. And that method returns Int. So the compiler thinks you are trying to apply () to the Int
returned by size.
Yeah, the error message is confusing. Can it be better? Maybe replace the
message “does not take parameters” with “does not take parameters (maybe
you used parentheses on a method that does not have an argument list)”?
scala> List(1,2,3).size()
:12: error: Int does not take parameters
List(1,2,3).size()
Wouldn’t life be so much easier if it were this instead.
“size” makes use of the uniform access principle. It is a method with no arguments, and the brackets are not required. In short, replace size() with size…
Nice of you to throw down the gauntlet. I really do love all compiler
writers by the way. A great job, and a privilege in my opinion, having
worked on one myself. Thanks for the links.
Seems like Dotty people are working on usability issues relating to error
messages. I can see its already in good hands.
I really love term “Solution Messages” and will have to try to use that
in the future.
I have found in my career, that when I go to my superiors with
"problems" they tend to give me the stink-eye if I don’t also offer some
solutions as well.
In particular, the psychology of “Solution Messages” is way better than
"Error Messages." I hope in the future that messaging will evolve from
simply reporting symptoms, to actual diagnosis, treatment options, and
prognosis.
If the Dotty people need help, please tell them I have expressed a passionate (almost code of conduct violating) interest in turning error messages into solution messages.
Thanks for pointing out the term “Solution Message”. I hope it changes the way every compiler writer approaches reporting the mismatches between the BNF (or whatever) language definition and the stuff that coders like me write. That would be a new day in software engineering in my view.
I really am sick of error messages. A couple of days ago I had a linker message (from a Visual Studio 2017 C/C++ project which drove me to the brink of madness) which was a 1000 times more maddening than the one I moaned about in this post. If I hate compiler writers, then what I have to say about linker writers breaks with the code of conduct.
One of things I like about Maven is often when there is an error, it prints some terse diagnostics, but offers a hyper-link to a better explanation,with more context. I like this pattern because if you understand the terse diagnostics, there is not too much verbiage to deal with, but if you don’t understand, a better explanation is a click away. I have seen a few other apps/tools that do this, but Maven is the one which came to my mind first.
Indeed. In an HTML setting the terse message could be the link.
What was needed “back in the day” was feedback of the kind, “How did you fix this error?”. With today’s all-singing data mining techniques or whatever, a simple mapping from errors to solutions would be available today.
I wrote this on another thread, but I think you might be interested in this view
On the balance of probabilities, I would imagine that most software engineers would prefer the identifier of a so-called “first-class” function object to be just the function’s name (like it is in Haskell), rather than “function space underscore”.
I think a functions first-class object name should be just it’s name.
Somebody, somewhere, thought that Uniform Access Principle was so cool, that it should trump the obvious, That is sad.
As one of the compiler gurus, how do you feel that, in scala, a 1st-class function object is not simply it’s name?
