I am sick of error messages. I want possible solution messages. I have spent my life trying to understand error messages. Give me possible solutions/miss-understandings/how to resolve messages


#1

scala> List(1, 2, 3).size()
:12: error: Int does not take parameters
List(1, 2, 3).size()
^

At least tell me what is the most probable thing I am doing wrong and how to remedy it. I hate all compiler designers. They have slowed my development as a software engineer bigtime.

NO MORE ERROR MESSAGES! We need HOW TO FIX messages,

Compiler writers - No more error messages. We don’t need to be told we are stupid. We need to be told what we did wrong and how to fix it. Solution messages please!!!

Love.
Andre


#2

the method “size” does not take any parameters. What you are executing
resolves like this:
List(1, 2, 3).size resolves to the Int 3
The extra parentheses are applied on the number 3, like this: 3(). Since
Int does not take parameters (it is not a Function with an apply method),
the compiler throws the error.

If you take a look at the definition of size (below) you will note that
size receives no parameters. You want to execute “scala> List(1, 2, 3).size”

override def size = length


#3

In Seq (and List by inheritance) size (type Int) is defined without
parentesis, so you should call it in the same way.
See https://stackoverflow.com/questions/6939908/scala-
methods-with-no-arguments for an explanation why.


#4

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.


#5

I hope there is a web site store.scala-off-center.org where I can buy the t-shirt:

I am sick of error messages. I want solution messages.

scala-clippy was a step in this direction.

The way a linter says “you might be about to do something stupid,” a solution message says, “you did something stupid, here’s how to fix it.”

Maybe they’ll set up a scalafix web service to do all of linting, source repair, and solution messaging. The desired AI would sit behind the scenes.

Compiler error messages tend to lack the context required to be useful. That’s a symptom of 1970s-era constraints.

For example, there may be a path-dependent reason this error message is true. But it is not a solution message.


#6

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?

:o)

Andre


#7

“the method “size” does not take any parameters.” !

Size is not a method. It is an Int.

[Edit] I didn’t totally believe what I wrote, so I checked. “size” does appear to be a method. My heartfelt apologies.

Andre


#8

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.


#9

It might be a good idea to reread our CoC. PLEASE READ: Scala Code of Conduct


#10

You’ve got me re-reading the thread vs. the CoC and wondering what you’re concerned about?


#11

Oh, that’s a classic.

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)”?

Best, Oliver


#12

How to write a solution message. Example.

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…


#13

Jarrod,

I have just read the Code of Conduct. It looks reasonable to me.


#14

You? https://github.com/scala/scala/pulls is open for business. There are a number of tickets in https://github.com/scala/bug labeled “usability” and/or “errors and warnings”, awaiting volunteers to make improvements.

Also, there are efforts on better errors in Dotty (aka Scala 3), see http://scala-lang.org/blog/2016/10/14/dotty-errors.html . Not applying AI to the problem, just considering usability more. A backport to Scala 2 would be welcome.

The limiting factor for doing better on this in Scala is simply resources — people to do the work.

About applying AI to the problem, sounds like something someone could get a Ph.D for, or multiple people could get multiple Ph.Ds.


#15

We hate you too and take great personal joy in making your life as miserable as we can.

Love, Seth

:wink:


#16

Seth,

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.

All the best,
Andre


#17

Adding my two cents to this thread…

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.

Cheers, Eric


#18

Seth baby,

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.

Love,
Andre


#19

Thanks Eric,

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.


#20

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.

Love,
Andre