Summer of Usability


The logic for computing the conditions goes into the build. See for an example.


Are there any limits for count of scalacOptions?

If Preprocessor is used for cross-building against libraries the amount of options will be unpredictable.


Are there any limits for count of scalacOptions?

There shouldn’t be but it’s unlikely that anyone has tested it with a million options before.

If Preprocessor is used for cross-building against libraries the amount of options will be unpredictable.

Any individual preprocessor option would currently require at least one source folder, possibly more if you need different sources for combinations of various config options. I’m sure scalac can deal with more config options than you can deal with source folders.


Please add another round-table, to continue @jvican’s thread


This is an improtant topic that we’d love to see moving forward, but it just didn’t make it to our list this time.

And yes, of course error and warning messages are related to configurable and suppressable warnings. The proposal for configurable warnings is already non-trivial, so I decided to keep improvements to the actual messages separate.

However, maybe that’s not so simple. Implementing configurable warnings will require some refactorings in the compiler’s reporting facilities. If we’re doing this work, it might make sense to first think of a better internal representation for errors. We’ll see and keep that in mind.


Thanks, I have understood logic. And it can be undeniable for
libraries which are distributed by binary code.

But Mono-repositories and sharing by source code can be more useful for end applications or ERP decisions.
For example we have about 1000 function points in our old applications(not scala).
we currently use reflection for that purpose.
Such amount of combinations(point*module_version) is quite difficult to manage. And even if the compiler can support such amount of options. It is a leaky abstraction for that purpose.
Of course they always can say just don’t use it such way.
If it is so I will sorry. I think string comparison and primitive logical operations is not so hard to implement. At least it is supported by most languages which I know, for example gcc,plsql, etc


I believe this will also require changes in implementors of Zinc’s Reporter in build tools because pretty much every build tool implements its own, so this change might also need to move in tandem with build tools.


The idea is brilliant. It will help getting a foothold into corporate environments. Particularly in those with multinational development teams.The installers are often different than the users. More importantly it will simplify the auditing processes. The fewer moving parts, the less hostile people will be to new software.

A few suggestions on the installer.

  1. Provide a bootstrapping SBT. One that includes all the language libraries (xml,parser) by default.
  2. Two bootstrappers. One that includes the developer environment (compiler, testing tools, repl) and one for installing scala application (no compiler, testing tools).
  3. If possible, just download a single complete runtime sbt bootstrap in a single jar. If a bat/bash/brew script is involved, all three should be in the single environment. File. Ideally, java -jar would be the only thing in the files. A fourth PDF or simple .html README file would be all that the bundle would include.
  4. The sbt should be self updating (or skip more gracefully). Hopefully the single file installer should remain stable 1.3.1, 1.3.2, … allowing the bootstrapper to to update these minor version.
  5. Ideally, the bootstrapper wouldn’t’ be a complete sbt. That’s just a want.
  6. The sbt bootstrap should install with no user input by default. Perhaps a -interactive-install for people that want to be asked question like “where to install.”
  7. The bootstrap installer should not be the runtime sbt. E.g. in can be run from download/tmp and deleted after the install. Or squirreled away to be rerun later (update,uninstall).

A question. If the parse & xml libraries are optional, how will persistence be handled?

Desire. sbt should be able to correctly update a pom, even a large complex existing pom. And pull dependencies from a pom.


I agree, I believe “better compilation error messages” should be on the list.

I would like to also add: “better implicit not found explanation” (like, for instance, splain does).

1 Like

Love this direction. Regardless of the outcome of these proposals, I appreciate that there is focus and attention to improve user experience for the “middle class” of Scala programmers.


I’ll chip in my 2c and say that improved compile errors should definitely be on the list, and probably affect more people in a more substantial way.

Things like a preprocessor are definitely advanced features, while a builtin unit test framework or tweaked distribution is “nice” but I don’t think a huge deal. In comparison, compile errors are front-and-centet in everyone’s experience trying to use Scala. Even simple things like colorizing the different parts of an error message using ANSI colors would be a huge boost in usability


Any chance Scastie could be enhanced to display the compiled types?

It’s the first place I send those who are interested in playing with Scala without having to go through a PhD in understanding the Scala ecosystem before getting to play with a Scala REPL. However, being unable to see the resulting types with “Save” degrades the experience the instant they hit a weird type edge case…which is very quickly in Scala 2.


How do these proposals affect the timeline of Scala 2.14?


We intend to stick to our standard release cycle (2 ±0.5 years between RCs, as we’ve done since 2.11).


May be a dumb idea.

If Scala 3 would be released in 2020, will Scala REPL use Dotty REPL codebase at that time?

If it is true, how about delaying REPL usability improvements and using this human power for Scala 2.14.

If user want a better Scala REPL, they can choose Ammonite now. And Scala team can begin a overhual for REPL when Scala 3 releases?


What I mean is, wouldn’t it be better to first do the things that have been planned for 2.14, many of which are critical for the Dotty transition, and then see how much extra time there is? Or do these proposals not affect that somehow? Or are they just higher priority?


The idea is to first let the dotty features bake a little longer before back porting them. We also still need to (collectively) decide which ones to back port in the first place. The other big work package is to iron out, implement and test the compatibility story – my preference is to start with that.

1 Like

Hear, hear – IMO, this is by far the highest priority…


It’s a reasonable suggestion to wait for Scala 3, but my concern is with the Scala 2 users. They’re not all going to be able to immediately switch to Scala 3. So, investment in the Scala 2 REPL (or some other thing we decide to do for 2.14) will be enjoyed for at least another 5 years (conservative estimate :-)).

Ideally, the REPL code would be shared between the Scala 2 and 3 compilers anyway.


The frontend could be shared through the use of a REPL Server Protocol, more info and code:

1 Like