Summer of Usability

Language Design
1

Dear Community

We from the Scala team at Lightbend have decided to take some time this summer to work on usability improvements that are always falling through the cracks while we’re busy working on the hard features of the next Scala release. Here is a summary of our project proposals.

REPL usability improvements

@som-snytt already implemented the JLine 3 upgrade (https://github.com/scala/scala/pull/8036) which gives multi-line history and editing. We are planning to add further improvements (many of them pioneered by Ammonite and/or the Dotty REPL) on top of this, for example syntax highlighting and importing library dependencies.

Ticket: https://github.com/scala/scala-dev/issues/325
Lead: @adriaanm

Simplified Distribution and Launcher

Most people obtain and use Scala through the build tool, but we still build a distribution archive. Using the distribution has a few shortcomings:

  • need to install every new version
  • sbt is not included
  • no simple method to add library dependencies

We propose to stop building the distribution and instead provide version-agnostic scripts to run the various tools that make up Scala (REPL, sbt).

Ticket: https://github.com/scala/scala-dev/issues/326
Lead: @dwijnand

Roundtable: Unit Testing Library

We would like to work together with the community and maintainers of testing libraries to provide a zero-dependency unit testing library that ships with Scala releases, i.e., not as an external dependency. This library will be used in core projects (Scala, Scala.js) that currently have to fall back on JUnit. We also hope to find a common path forward to overcome some of the fragmentation in testing styles and libraries that is currently present in the Scala community.

Ticket: https://github.com/scala/scala-dev/issues/641
Lead: @eed3si9n

Preprocessor

There are situations where conditional compilation would be quite handy, for example when cross-building a project against multiple Scala versions. This proposal introduces a preprocessor into the Scala compiler so that no changes to the build toolchain is required.

Ticket: https://github.com/scala/scala-dev/issues/640
Lead: @szeiger

Configurable and Suppressible Warnings

The Scala compiler issues helpful warnings, for example when comparing unrelated types. Additional checks and warnings can be enabled with -Xlint, the -Werror flag turns all warnings into errors. In reality, not all warnings can always be eliminated: for example, cross-building may require using a deprecated API. This proposal introduces compiler flags to selectively promote or silence compiler warnings. It also adds support for suppressing warnings locally.

Ticket: https://github.com/scala/scala-dev/issues/333
Lead: @lrytz

Discussions

The projects listed above are being discussed on their respective scala-dev ticket. As always, we welcome and encourage contributions and feedback.

If you have a usability project in mind that is not being discussed currently, feel free to mention it here. And of course, we’d be thrilled if you’re motivated to join the usability summer with your own project!

14 Likes
2

Will it be possible to use it for cross-building a project against multiple application server?

It would be very valuable for us.

The documentation suggests:

  • Keep the predicates in the Scala sources simple (e.g. only key==value checks)

It is not enough for us.
We need at least string comparison.
It seems that the version comparison would be very useful.

3

The logic for computing the conditions goes into the build. See https://github.com/szeiger/scala-collection-compat/blob/f3302157b039e66b67b0320cb51d01bacc5934ec/build.sbt#L82-L85 for an example.

4

Are there any limits for count of scalacOptions?

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

5

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.

6

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

2 Likes
7

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.

2 Likes
8

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

9

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.

10

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.

11

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
12

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.

5 Likes
14

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

6 Likes
16

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.

17

How do these proposals affect the timeline of Scala 2.14?

2 Likes
18

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

19

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?

2 Likes
20

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?

21

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
22

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