if you have this main.scala
println("hello")
and you use:
scala main.scala
it works. why do we need more?
1 Like
The hypothesis is not that brevity of hello world is strongly correlated with language popularity, i.e., that it is the most important, or only important, variable that affects the popularity of the language.
The hypothesis is that for any given language, the ease of starting is an important variable that affects its popularity. That is, whatever its popularity is as influenced by other factors, having a better getting started experience will increase its popularity relative to itself, and having a worse getting started experience will decrease its popularity relative to itself.
That’s not something you can falsify with a popularity ranking of languages. (Without getting into the flaws that have been pointed out in the TIOBE method.)
1 Like
Great question. I think the answer is that there’s too big of a gap between that and a compiled program. You can’t use them together.
1 Like
It is undeniably.
Nobody have said that it is not so.
I can give a good example of good getting started for everyday:
I have searched for java and scala and I have found
Python’s strength in making writing simple scripts quickly doesn’t translate to big popularity among big projects. Big projects are still written in Java, C#, C++, etc and it doesn’t seem that will change. It doesn’t seem Python is a good choice for projects of every scale.
Scala scripting should only be good enough to convince newcomers that Scala language is convenient and productive. After that they be willing to put a little effort to create proper Scala projects based on a build tool (probably SBT) and regular Scala code with objects with main method. It’s really not a long task to create new (nearly) empty SBT project with proper structure and some library dependencies. If Scala scripting will support dynamic importing of any library dependencies (like Ammonite does with import $ivy) then even some minor hurdles with SBT setup won’t prevent a Scala newcomer from using external libraries (i.e. he’ll be using Scala scripting until someone else helps him resolve problems with SBT).
Java and C# aren’t oriented towards beginners. You can’t write loose code in Java or C#, neither you can loosely import external libraries straight from within the source code (skipping any build tools, IDEs support, etc). Does that mean that advertising Java and C# to beginners is a “bad publicity stunt”?
1 Like
From what I see in the industry, python is the “quick and dirty” testing ground before seriously implementing the final product.
1 Like
Thare are interesting questions, but I am sorry. I leave that topic. It seems like offtopic, so I do not want to show disrespect
This is only true if your industry is “professional software engineers working on large services”, and even limited to that tiny subset, the amount of “final product” implemented in Python already dwarfs Scala usage.
Python’s “industry” is much larger than that. For data scientists, analysis, sys admins, devops, mathematicians, mechanical engineers, and many others who use Python on a daily basis. Unlike Scala, which is very much just people working on backend services, Python has a very broad base of usage across all fields. If we think Scala is a good “general purpose” language, this broad appeal is something we should very much be striving to emulate, not turning up our noses at as “unserious”.
18 Likes
Python is used not only because of its conciseness. It’s also used because many people don’t want to deal with types and complicated software engineering in general, so they will have more time to spend on the business domain. That doesn’t scale to big programs, because for big programs you need proper software architecture and strong typing helps with that.
Is there a precedent of statically typed language displacing duck-typed one? I don’t think so. Golang was supposed to be one such attempt, but it doesn’t seem it comes even remotely close to Python’s popularity. That’s despite Google backing, fast compiler, super-low GC pauses and simplicity of the language. If Google can’t do it, why should we risk wasting time on it?
As for Python being “quick and dirty testing ground”, I was speaking with HFT (high frequency trading) developers and the situation there is that mathematicians are developing their algorithms in Python (which results in slow programs), which are then rewritten into C++/ Java/ etc by proper programmers.
Typescript is gaining more and more momentum as a way of doing things that were previously done in pure JS, for one of the most obvious examples. I’m sure there are others. One could say “Java + generics” is another good example of strong static types successfully replacing previous weakly-typed conventions (Java pre-generics ).
Coincidentally both TypeScript is a superset of JavaScript and Java 5 is a superset of Java 1.4. Similarly, both static typing in TypeScript and generics in Java 5+ are optional. You can use duck-typing wherever you want in TypeScript and you can use erased types in Java 5+. Such smooth and gradual adoption is not possible when the underlying programming platform changes.
1 Like
I just want to point out that there is sbt scripting as well that allows dependencies. I did a bit of modification to make it support .bat and .cmd files on Windows and .sh or extension-less on UNIX/Linux. I assume it still works but have not used it myself or played with it recently. Whether this could be made easier I am not sure but it could be a starting point for simplification.
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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)
I’d like to see:
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.
6 Likes
Incidentally, while I like ammonite, I do not find it clearly a win over the Scala REPL because
- No
:javapand 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.
Work on a better documentation which can at least hold a candle to the documentation for Rust or Kotlin.