Notably I use the New Scala Project feature of Metals, based on giter8.
This lead me to discover the build.sbt is structured radically differently in scala/hello-world.g8 and in scala/scala3.
hello-world.g8 is flat like so:
scalaVersion := "2.13.12"
name := "hello-world"
organization := "ch.epfl.scala"
version := "1.0"
libraryDependencies += "org.scala-lang.modules" %% "scala-parser-combinators" % "2.3.0"
(With a lot of very nice explanatory comments in-between.)
scala3.g8 on the other hand is âlayeredâ:
val scala3Version = "3.4.1"
lazy val root = project
.in(file("."))
.settings(
name := "$name$",
version := "0.1.0-SNAPSHOT",
scalaVersion := scala3Version,
libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test
)
To make it simpler for beginners, we should strive to have those two as similar as possible.
This implies the following question: Which one should we copy to the other one ?
(If we choose scala3.g8, weâll of course port the comments from the other one)
I agree that itâs easier to have one basic template, even if that is not the simplest possible build supported by sbt 0.13. That facilitates both understanding and cut/paste. It may also avoid refactoring the build for some trivial reason.
(An easy on-ramp is nice, but you turn the corner and hit a huge learning curve, itâs no longer nice.)
Eugene (and some others) take the position that people are going to need the multiproject style eventually so we might as well start them there. I (and some others) totally disagree.
I wrote:
You can learn a lot of Scala, and get a lot of value out of sbt along the way, before ever wanting or needing to know anything about multi-project builds at all. (I used Scala and sbt myself for years without ever learning that.)
In the context of teaching Scala to newcomers, I think the move to a multi-project build is in the learnerâs distant future, so to prepare them for that move so early is simply a pedagogical mistake that 1) distracts the learner from more important issues at their stage of learning, and not incidentally 2) gives them an unnecessarily negative impression of sbt.
Not sure if the advent of scala-cli changes anything here. It does mean that Iâm no longer using sbt except for multiproject builds.
The flat one is the better one for beginners, imho. Less is more, the layered one looks scary, and raises to many questions that cannot be answered at first (to val or not to val, why or not with lazy, use = or := etc etc ?? Just to name a few of this DSL nightmare). If they are still around after some time and need the layered version later on, they will switch.
And to be honest, i often still donât get it after many years of using Scala with SBT. It is just that i have collected enough examples for a decent copy-paste, and most build.sbt files are some mixture of both styles.
I think we should steer people towards Scala-cli regardless. I (admittedly non-beginner) converted all my projects to Scala-cli and found it so much easier to teach it (along with the awesome Scastie). I said goodbye to SBT for now and donât plan on using it in teaching. (I wish Coursera courses would switch to Scala-cli, but that may not be possible due to grading infrastructure and plugins needed.)
if youâll need SBT then youâll need to learn very non-beginner-friendly stuff anyway⌠(I think Eugene is right)
I can see Sethâs point that delaying the learning is a bit of a pedagogical mistake; but at the point when someone needs SBT theyâll be advanced enough to learn it. (Even then, they could probably get very far with Scala-cli.)
Having said all that, I think the âlayeredâ one is better for beginners and non-beginners alike. I struggled a lot with going from the âflatâ one to the âlayeredâ one. Having the layered one in front of me, so that I can edit the basic template / structure, was really helpful. We shouldnât delay showing the layered structure
For mac users this is not a no-brainer. Installing Scala-CLI requires âbrewâ on your system. This has its own issues:
If you do not have it, it must be installed which is an extra hurdle
Nowadays you should install nothing without a thorough safety assessment: a curl-bash pipe, really??
Installer requires bash but default shell is now zsh.
If you have âportsâ you may not want to install âbrewâ alongside (bin there, done that, not a good idea, although this experience is somewhat older)
It would be a lot nicer if the Scala CLI installation would be possible on a clean mac.
If no build tool is detected Metals will use Scala CLI as default. We do try to integrate it as much as possible to provide a better out of the box experience for Scala. No build tool is necessary to have all IDE features available.
Agree that it makes sense to give beginners a simple as possible starting point. But are there other templates for more advanced users that do want to create a fresh ânon-trivialâ sbt project?
The âmy first programâ thread on the other forum suggests that the beginner tool should be a desktop client for scastie. (Upload and run my file without making me click anything.) Then if I want a âprojectâ, download the project from scastie in whichever form I ask for.
Actually, that sounds like the tool they had several years ago for putting the IDE and build behind a web interface. I would require archaeological research to recall the name, which was not âAbideâ but possibly also started with âA for Abandonâ.
