Use a shorter command instead of `scala-cli`, for example `scala` or `scl`

[bjornregnell]

There is a stated goal that the scala-cli runner becomes the offical scala, but perhaps that might take a while - in the mean time scala-cli might get popular... Also there is a real value of having both the simple standard binaries under scala and the versatile scala-cli under another command. HOWEVER when watching my beginner students I am convinced that a shorter command would be much more convenient and appreciated. What comes out of the box with batteries included is what is going to stick for most, and fiddling with your own alias is not so nice for a beginner. Instead I propose that we now early on, when scala-cli is not so spread yet, include in all installers a shorter version of the command either as an alias/symlink or preferably as the real binary name. Options:

• sc short and nice and mimics the .sc file suffix, but may clash with sudo apt install sc
• scl short and nice and does not seem to clash with any existing command and can be seen as an acronym for scala-cli and we can keep that name on home page and doc and just update the command in examples. This is in line with how sdkman does it with sdkman being the name of the thing and the short command sdk is what invokes the service...
• sca can be written with the left hand (with the other hand on the mouse) and same advantages as scl but perhaps more seen as an acronym for scala rather than scala-cli
• scli long and more awkward to write requiring both hands back and forth over the keyboard

My favorite is scl

[bjornregnell]

See also discussion thread https://github.com/VirtusLab/scala-cli/discussions/351 There goes opinions and here goes implementation details and facts.

[bjornregnell]

What would it take to implement this?

• Change all docs
• Change all example on the home page
• Change the name of the runners

What have I missed?

Note that if we keep scala-cli as the name of the app and just change/add the scl command there is no need to change logos and what not.

[kubukoz]

IMO shorter command names are less descriptive and make it more difficult to search e.g. the internet for the actual tool's documentation.

If scala-cli isn't convenient enough to type it all the time in direct manual use, users could create their own aliases. For use in scripts, I would definitely suggest using the longer name for the previous reason I mentioned (just like it's good practice to use long option names in scripts).

[bjornregnell]

I agree with the downsides you mention. But if we prioritize uptake and convenience then having also e.g. scl included with the batteries may have a large impact on perception, compare sdkman and the shorter sdk. And to be honest, the cli-acronym is rather obscure and means little to a beginner programmer anyway :) so it is what we get used to out.of.the.box that sticks..

[bjornregnell]

@kubukoz Regarding: alias; setting a permanent alias in Windows is not at all trivial for a beginner. You potentially have to deal with both cmd and powershell and neither is very easy compared to bash in setting a permanent alias. The vast majority (around 80%) of my students want their stuff working in native Windows... Also, the point of all having the same short command is that people can share their command line snippets.

[kubukoz]

Windows is a fair point I didn't consider! Now I'm on the fence :)

btw. now I remembered about coursier/cs, which was all the more confusing because cs had been used by conscript. Hopefully nobody is using https://linux.die.net/man/1/scl :D

[bjornregnell]

Lol. Never heard of that scl; when doing apt show scl nothing shows...

$ apt show scl
N: Unable to locate package scl
N: Unable to locate package scl
E: No packages found

[romanowski]

We will present the idea as an additional step (to add alias) or as an alternative solution to renaming. For any further discussion, I think we should use mentioned discussion thread #351.

[bjornregnell]

Ok great @romanowski - sorry for creating confusion by opening both an issue and a discussion. @kubukoz further discussion goes here #351 ...

[som-snytt]

scali

[Gedochao]

In the context of SIP-46 we'll proceed with scala. Closing this.