Python is honestly a terrible example, I have had so many issues getting a “simple” python experience working. This is a bit of a relic of the past, especially with the now Python2/Python3 split (plus the fact that OS’s like MacOS come with python preinstalled which complicates things).
It has actually been much quicker/faster to install amm/sbt on a fresh machine compared to Python. sbt has an issue where it takes ages to load on the first time, but it pretty much works 100% of the time on any machine.
I concur. I’m constantly surprised how easy it is to build an sbt project defined years ago. Just run sbt compile and you’re done. The right version of sbt, Scala and your dependencies is automatically downloaded.
With Python or C projects, I’ve had a terrible experience at trying to compile them from source.
Getting started experience is more about writing new simple code from scratch than reviving old projects. If you have your own old project in Scala then that means you know some Scala and perhaps SBT.
The two aren’t mutually exclusive, and it also seems this argument is being presented in a way that static langauges will always “lose” because they always need some sought of build tool to compile the code so it can be run.
Unless you are using a REPL, in which case the Scala REPL is just as good as the python REPL (amm is even better)
Single file programmes, where basic build information, such as dependencies, for sbt or mill, could be included in special comments, that the build tool could parse.
Single Folder programmes, which might or might not contain a separate sbt or build.sc file.
Single module programmes. We already have this in Sbt, but not in mill. Perhaps the existence of a src folder in the projects root folder could designate to mill that it is a single module project.
@lihaoyi We have just merged Ammonite support in bloop https://github.com/scalacenter/bloop/pull/886 Ammonite is now the default console implementation and will be available in the upcoming release 1.3.0. Running bloop console $PROJECT on any build exported by bloop (from sbt, mill, maven and gradle) will start up an Ammonite console in the terminal with the project’s classpath, so that experimenting with APIs is straightforward. If the current project does not compile, one can pass --exclude-root so that only the classpath of the project dependencies is used.
I hope this brings us closer to “officializing” Ammonite as the default Scala console. I think Ammonite contributors have done a great job and I’m happy to recognize that by making it the default. The experience is indeed much better than the scala console.
Incidentally, while I like ammonite, I do not find it clearly a win over the Scala REPL because
No :javap and other commands (not easily discoverable anyway) render it considerably less powerful
Default of not displaying warnings is bad for learning and debugging, which is a main reason to use a REPL anyway
It’s (in my experience) more fragile on different platforms and with different configurations
I haven’t bothered writing bug reports for any of these things because I just use the traditional Scala console instead when there’s an issue. But it’s not clear to me that, despite its mostly-nicer user interface, it is a better choice for the default as it currently stands.