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.
another 2 cents
Andre
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?
Love,
Andre
I’ve responded at Strange warning - #5 by SethTisue . (In general, we ask that you not post the same content in multiple places so that the same discussion doesn’t end up split across multiple locations.)
I think you’re quite mistaken about how difficult such a thing would be to build.
Thank-you for pointing it out.
I sincerely apologise for “same content” posting. I am quite new to forums and do my utmost to adhere to the etiquette.
I arrived at the conclusion there was similarity, yet found no super-class post.
Love,
Andre
Tell your compiler writers that software engineers are never going to think that an integer (or any other constant for that matter) requires parameters, meaning a message such as “Int does not take parameters” is of use to no-one. How many software engineers think constants take parameters? None. So why the message? There is no good reason other than it was easy to produce. Unprofessional, Lazy, probably with PhDs, I think their bosses have a lot to answer for.
Love
Andre
Who is in charge of compiler messages? I really would like to know. Is there a quality “Solution Message” person? I guess not, but there should be.
Love,
Andre
Well, the good news is, in open source, whoever cares deeply enough about it, and contributes to make it happen, is in charge of it! Perhaps it could be you?
1 Like
As a newish scala developer(2 years - 1 purely functional) yet a long time
in software engineer, i think that @yawaramin is correct, as i think
@SethTisue has stated, this is an open source project that we all use and
if you don’t like something about it, you can do something about it. Being
a compiler engineer may not be where you are (I’m not), but once you learn
the errors that come out of the compiler this becomes a non-issue in my
mind. Wait until you use shapeless and other powerful libraries, there are
some very esoteric compiler errors there that took me a while to decipher,
I figured out what works for me, if you don’t like it, you contribute.
Also try splain https://github.com/tek/splain, a little less helpful for
vanilla scala (good for implicits), when you get deep into the language;
its features and libraries that use them heavily, i’ve found it useful.
IMO, we have a great language attached to a great community, its on the
individual engineers to get used to a language they chose, or was chosen
for them. If the latter, i’d suggest talking with your teammates and
contributing if you can. As i stated, i very likely could not to this use
case. Think of Java’s NPE, and the complete lack of information that you
get out of them related to your code, again IMO, especially when using
threads. I’ll take scala compiler errors any day.
Best,
Jeff
1 Like
Here is an example of a constructive query about error messaging. It received a response and a contribution. Even the ticket was pretty good. At the cost of no skin off anyone’s nose.
(The first response to the question about “omitting necessary parentheses” includes the caveat: “granted there is probably no 5() function.”)
Some messages are terse but precise. That an Int value does not take parameters does not mean it cannot.
scala> implicit class IntOps(val i: Int) { def apply() = 42 }
defined class IntOps
scala> 3()
res0: Int = 42
Error messages work best when they are specific and also expressive of regularity in the language.
Attempts to capture edge cases as errors or warnings is more challenging. In particular, what’s wanted is to capture known deficits or implementation details and expose them through a linting facility. That’s where instead of losing ten minutes posting a question, you lose hours for head scratching and hair pulling. For example, someone mentioned that a change in bit shift semantics should have been in the release notes, but that would be more effective as a lint rule (and easy to detect, in that case; it wound up as a deprecation).
1 Like
Like anyone could replace a hip joint because the procedure is “open source”? I would do it - but I have neither the time nor the inclination - as I do not use Scala that much. But I do love the language. It’s great. Not as good as Haskell, obviously.
OK - how difficult is it? Playing “Go” was difficult. Define difficult? More difficult than the game “Go”? It is a simple map from what is now an error message, to solution messages.
A program that could play Go has been an elusive challenge, involving hundreds of researchers over decades. When it was finally cracked (twice), it made international news. Surely this level of effort is a bit more than one can expect for the error messages in one language?
Also, you seem to be under the impression that an error message can only occur under one scenario. Solutions that don’t solve the problem are far more confusing than simply reporting an error without an idea for how to fix it. Figuring out what scenario the user expected to be in is a nontrivial problem.
However, in those cases where there is only one reasonably common failure mode, improving the error message is not dreadfully hard–you can grep for the text in the compiler source, and submit a patch with better wording! If you need help including more information in the message, you can ask, for instance, on the scala/contributors gitter channel, these forums, or other places.
Great error messages are a sizable benefit to users of a language, but they aren’t exceedingly easy. Though improvements have been and continue to be made, if you want things to go faster, it’s probably more effective to help than to complain. All hands are already on deck; there’s just a lot to do.
2 Likes
Who is talking about error messages now? It’s all about Solution Messages. I told everyone I am sick of them, yet you still mention them as though they are OK.
I guess the old error message would be the fall back to a lack of a solution message.
I did like implicits, then I didn’t.
Are you aware of the complexity involved creating “functionality follows mind”-programs?
The reason, I guess, that nobody has implemented “solution-messages” is that it largely depends on what the programmer actually wanted to do. That is seldom obvious… Even companies like Microsoft and Apple, with “infinite resources”, still write compilers without solution-messages, at least to my knowledge.
Error-messages, despite you dislike them, is what most compiler-writers give us for now, and, as has been pointed out to you, that isn’t likely to change any time soon.
Being a squeaky wheel doesn’t help…
2 Likes
People who ignore the squeaky wheel, should not complain when the wheel falls off, and the car is in the ditch.
Perhaps the most significant development in automotive technology was Ralph Nader. This particular squeaky wheel transformed the automotive industry, and saved the lives of millions of people world wide. Sadly, the computing industry has not seen its Ralph Nader yet.
To accept or promote “Error-messages, despite you dislike them, is what most compiler-writers give us for now, and, as has been pointed out to you, that isn’t likely to change any time soon.” is to advocate for a dystopian future of software development.
You didn’t address any of my points, and instead pedantically said:
I can’t tell whether you honestly didn’t see how what I said had any bearing on error vs. solution messages, or whether you just couldn’t come up with any contentful reply but still felt annoyed. But this isn’t a helpful way to get anything accomplished (aside from showing people that you’re still irritated, and making them wish they hadn’t already spent time unproductively interacting with you).
Perhaps this method of dealing with errors would work better:
If you are not interested in helping solve the problem at any level, but merely want compilers to know far more about what you were trying to do–well, people know this would be great, it’s hard (deeply hard to do it well), and it’s not the only work to do. Things will go more and more in that direction whether or not you personally complain or are sick of things, because people recognize it’s nice to have. But there is no quick fix, so you’ll have to be patient (especially if it’s not important enough to you for you to want to do any work to help the effort).
In the meantime, maybe you should find something less stressful to do.
3 Likes
So you’re comparing https://en.wikipedia.org/wiki/Unsafe_at_Any_Speed to
compiler errors. If the OP is so put off at compiler errors, then perhaps
scala is not the language that the OP should choose (it may have been
chosen for him). It took me a while, coming from a largely duck typed
language to a typed language , to strongly typed functional and yes I had
frustrations especially using advanced libraries with even more arcane
errors, but you learn how to deal with them b/c you’re an engineer, or you
learn who to contribute and contribute.
Is there a similar thread, as i mentioned before about NPE’s and Java
threads…useless. I really enjoy this community and am staying within
the bounds of being nice, but this is getting a bit old without action.
Implicits btw, can easily be mitigated by turning on compiler flags. Not
every error message is what you want, but in python WTF does None has not attribute foo mean unless you go back and find out why you received a
None. No compiler there purely runtime, if people have found a compiler
that gives you solution messages, and i think we’ve already found that is
not true, change to it.
Everyone has shown the utmost trait that this community asks, which is to
be open, kind and mindful of others. I think we’re starting to go off the
rails with the Hip Surgery comment.
Best,
Jeff