I still disagree with the idea that this should be put in scalac.
sbt, for >80% of Scala users, is the UI to scalac. No one really uses scalac directly. Therefore, UI work should be done on the UI, and that UI is sbt. @Duhemm has assured that both new and old error reporting would continue to exist in sbt (configurable) so people can leave their tools/scripts/etc that may already be parsing sbt’s error messages as-is, to eliminate ecosystem/tooling breakage from potentially occurring due to an error reporting facelift.
Additional reasons include the following; sbt 1.0 is bringing huge changes to how sbt is used. It’s a good time to also improve the output of sbt. Changing the output of sbt in 1.1 or some later version would just be surprising. We’re making big changes now; let’s not surprise people with a different UI experience down the road. Since we’re changing lots of user-facing things about sbt now (the DSL, the structure of builds, etc) we should also touch something user-facing like sbt output now. It’s only consistent.
Another huge and completely discounted reason we should fasttrack this and get it into sbt is education. The people reading this mailing list/forum are typically grizzled, seasoned, and professional “back-end” people. Most people have been hacking on complicated “back-end stuff” for years. But if I want to teach my 16 year old sister how to program in Scala, her experience will be unmeasurably different with colored/better spaced/easier-to-read output from sbt. Right now, to her, the output of sbt looks like the matrix:
I see the following happening right now; “I see someone has invested time in something that a lot of people seem to care about (significantly improved and user-visible error reporting), so let’s crowdsource all of the things we would like to see in scalac and request that that’s done rather than optimizing the sbt experience.”
The short answer here is that we don’t have the budget to do this.
Meanwhile, I note that 89% of people we asked want this to go into sbt. This shouldn’t be discounted.
Martin has already invested time. This isn’t an unbounded investment from the Scala Center; Martin has loads of other responsibilities that relate directly to Scala Center initiatives. The goal here was to get this work he already did into peoples’ hands. Not to define an entirely new project to revamp error-reporting in scalac.
Further, the likelihood that a single person will be able to quell all of Adriaan’s, Lukas’s, Jason’s, Seth’s, …, (insert whoever else I neglected to mention here)‘s wishes for The Perfect Error Message ™ to a sufficient degree of “perfect” to have merged into 2.13 or whatever Scala version lands in 1-1.5 years, is simply too much of an investment for us, for a return too far down the line. We don’t have that kind of money or time. The Scala Center exists to improve things that have been languishing for years, and to get those improvements into peoples’ hands as soon as possible. Satisfying a wishlist added-to by a potentially unbounded number of people for The Perfect Error Message ™ in scalac means (1) lots of time, and (2) no one sees this benefit for a minimum of one year. On the one hand, we don’t have the time to invest in this (speaking of SC budget), and on the other, the SC is set up so that the community sees benefit sooner rather than later. This is low-hanging fruit that a lot of people would benefit from now rather than in 1-1.5 years. Think of all the teenage girls or university bachelor students, or ScalaBridge participants, or regular already-trained full-time working Scala developers, etc, that would have a much improved experience this year rather than next. This what the SC is designed to optimize for.