Of course number of keywords is not everything. But it usually correlates well with number of syntax rules, which correlates in turn with usages per keyword. To get a more accurate picture one also needs to look at the size of the whole context-free grammar. I did not do that for F#, but for many other languages, and found that, again, Scala is at the lower end of the spectrum, smaller than Java, Kotlin and (I would guess) F#, a lot smaller than C++ and C#, about on par with OCaml, larger than Python.
But of course, number of syntax rules isn’t everything either. Maybe we should stop identifying “small” and “simple”, There is probably a correlation between the two, but it does not look very strong.
Also, if I look at @haoyi’s argument, it turns out that plus points of languages sometimes correlate with extra features. Scala improves on F# because it has higher-kinded types, whereas F# is better with computation expressions. Both of these are examples where a language spends syntax footprint in order to make something simpler which would otherwise have to be encoded (sometimes akwardly). So, that’s another argument why perceived simplicity and size do not seem to be strongly correlated. It’s a bit sad for me, since I was operating under the assumption that the language ideal is to be small, orthogonal and very expressive, so that features can be provided by libraries. It seems the world does not agree that this approach leads to simplicity, overall.
Which is not to say that Scala has not made mistakes. Like any other language it has warts and dark corners. We are trying to fix some of these in Scala 3, and that will hopefully be an ongoing effort.
One quick suggestion to make the language easier would be to have some more organization of the methods in the collections library.
E.g., Scala Seq looks to have about 150 methods. It would be nice if it was possible to filter them by what the methods are broadly doing: E.g. filtering the collection, partitioning the collection, applying a function to a subset of the collection etc. Sometimes I find that I have to look through the list of methods trying to find the right one (or maybe grep by what I expect the shape of the return type to be).
But perhaps something like this could be achieved by adding tags to the method descriptions, e.g., something along the lines of #filter, #maplike, #partition, #conversion, and then some tweaks on the webpages to group or filter the methods based on the tags?
I think it is more about the possible combinations per use-site, and the complexity of determining / remembering what combination goes at which use-site.
Few relatively simple equations rule the physics of the universe, is it? Few people think of the universe as simple, most of us regard it as a highly complex thing.
My private rule of thumb when dealing with Scala code is to expect unexpected :-). Though not everyone feels comfortable with this, especially when tasked with fixing or expanding someone’s else codebase on short notice.
Having the freedom to shape new features is a developer’s best friend and greatest foe at the same time. It needs time and trials to do it right. Unlike libraries, in my usual commercial projects with limited resources and timeframes, it tends to leave things half baked and messy at best. Senior devs spend precious time discussing the merits of using feature A vs feature B, whereas junior devs are scared of the code and use to copy-pasting existing formulas.
What is the conclusion? IMHO Scala language, giving so much freedom, should also aim to provide devs with high regularity and certainty at least at the very lowest levels: syntax, core library, core patterns. Every small irregularity and inconsistency in these small, orthogonal and very expressive features disturb much.
Personally I don’t think it should be a goal to ‘please the world’. Languages like JavaScript and PHP are generally seen as bad design, yet have become two of the most popular programming languages in the world. In a similar sense Go is incredibly limited with design decisions that make no sense to me, but still is often praised for its simplicity. Even if a lack of generics leads to incredible verbose boilerplate and complex solutions like code generation for simple problems.
I rather stay with something like Scala, even if that means less chance of a job. Because I believe it can lead to simpler code.
Another reason why I think Scala is perceived as complex is because it is really one of the only languages that tries to unify FP and OOP from the ground up. From the viewpoint of languages like Haskell, ML, etc. the OOP parts seem complex and unnecessary, whereas from the mainstream languages like Java, C#, etc. the FP and type-system seem complex and unnecessary. I don’t think there is much we can do about that except ‘showing the world’ how well this unification can work.
That said I think Scala could be (perceived) simpler. As I said in another thread, less ‘unnecessary’ choice would be great. For example, with the new anonymous givens I think context bounds are unnecessary. They are only slightly shorter, but provide IMO unnecessary choice. Context bounds also have more limitations, so you need to switch to other syntax anyway when your structure changes. Another example would be to unify functions and methods. Since they have gained some capabilities in Scala 3 I don’t see any reason why we would need both. I am not sure how feasible it is to actually do this, but my point is that the syntax now gives quite some freedom to express the exact same thing. See for example this old Stackoverflow question by @lihaoyiNine ways to define a method in Scala? - Stack Overflow which I think is still partly valid today.
I do not like python if I had choice I would prefer to use scala2 or groovy in many cases.
But when I need scripts in linux I use python because of ecosystem(there are many libraries like iostat)
When I need light web app I use python because it can be deployed in any cloud easily.
So I am not sure that python and scala can be compared against each other.
Scala native could take a bite from cgi web apps for example but when I think about it I don’t understand how I can easily link an application library(working with c is quite harder). So I will prefer python only because of ability to get many libraries which can be added to project very easily.
I don’t think so, at least when I needed to analyze /proc/pid/io I found a python library very quickly.
I am not sure that static language can be good at scripting at all in general. Ammonite is very good around scala. But it will never be a competitor to bash or python, so there always will be a lack of some libraries
Yeah, if the library you need isn’t available, you’re kind of stuck
I’ve used Ammonite a couple times, and for most scripting tasks it’s been quite an improvement. Unfortunately, the one place it lacks is a big use case for me (piping data to and from external processes), otherwise it’d probably replace the bulk of my bash scripts.
