Why should Scala be dead for now? I agree its a Flying Spaghetti Monster, but so is C++.
Why should Scala be dead for now? I agree its a Flying Spaghetti Monster, but so is C++.
I would urge typesa^H^Hlightbend to bring forward the introduction of vital syntactic features from dotty (e.g. existentials as HKTs, if they really think that's the best way to express type lambdas). Even if that involves making large changes to scalac that will have to be thrown away, the Scala community cannot survive with the syntax the way it is for much longer.
My two biggest day-to-day peeves are:
1) The poor quality of the entire tool chain
2) Immature libraries and ecosystem
Tool chain: from the slow-as-molasses compiler, to the fact that every so often IDEA gives up and refuses to parse parts of our project, to the horror that is SBT, working with Scala just feels* painful. Heck! - my Macbook Pro sounds like it's taking off whenever I start a Scala compile, and if I'm building from scratch? https://xkcd.com/303/Libraries and ecosystem: many opensource Scala libraries feel more like experiments in language wrangling or narrow (exposing only a tiny subset of the underlying features) wrappers for existing Java libraries than well-tested code. Documentation? Almost always spotty. Library community? Spotty. Source? Good luck reading it. Depending on the author's bent it can range from vaguely understandable to downright inscrutable. (On this last point: I've often poked around various Java/Python/Go/C libraries and been able to figure out fairly quickly what's going on. Much less so with Scala.)
Besides those two points - Scala is complex. To a newcomer the language is unfriendly and has a lot of rough edges. You have to build a lot of context to interpret existing Scala code - and much of this context is incidental to the problem at hand. This makes it very tough to incrementally learn about Scala features/syntax and slowly explore an existing Scala code base (especially an opensource one, where authors are more likely flexing their advanced Scala knowledge). And all that syntactic sugar? Terse. Elegant. Unintelligible to a newcomer.
Sorry. /rant over.
Code complexity though, yeah, it's hard (for me, at least) to grasp ordinary for Scala abstraction-heavy, typeclass-heavy code. I would love to see better code exploration tools for Scala.
Over time, I learned slowly to use vals or var, that I don't need to initialize a return value and ship it at the end, and how to build up mapping.
The syntax; I agree with you totally. I just got hired by a company doing Scala and OMG that codebase. I'm seeing all kinds of constructs I haven't used yet.
I still prefer Scala over Java, but there is a high cost to entry.
The library ecosystem is growing every day, and the community is starting to recognize the importance of good documentation. See e.g. the Cats project, with a big emphasis on that.
Code readability in general, rough edges, and things that are difficult for newcomers to read incrementally are precisely why I'm so worried about the syntax being frozen.
So has the situation been reversed now?
(Look, I'm not on a crusade against Typesafe/Lightbend, but they've been hugely disingenous on a lot of things like this. I could have accepted it if they'd just said "yes, it's operator overloading, but better". Instead they chose this ridiculous disingenuous "nono, it's just method names!" approach. In my book, the only people who can get away get arbitrary method/function naming are the LISP/Scheme people. Because in LISP/Scheme there is no precedence to worry about.)
Most of the time, there is := (set something), += (add something) and ++= (add multiple things). I think that's pretty straight-forward.
I know exactly what they do; the underlying reasoning is very consistent, maybe even elegant. But if you don't know and need to understand/modify a build.sbt file, it's very tricky to find out.
Like this?
libraryDependencies ++= Seq(...) libraryDependencies :++= Seq(...)
? Because I've definitely seen that in some build.sbt files. error: value :++= is not a member of sbt.TaskKey[Seq[sbt.ModuleID]]For me, the language still hits a sweet spot miles ahead of the dynamic languages in its soundness, the old school typed OOP languages in its "functionalness", and the typed functional languages in its approachability and modernity (compared to, say, Haskell). Scala's killer innovation was to find a way to apply sound typing to Ruby-like syntax, and in that, it succeeded quite nicely.
That's not to say the stagnation isn't frustrating or that there aren't great improvements to be made. I think Scala would be greatly improved if Shapeless were expressible with much less hackery. It's a testament to Scala that Shapeless is even possible, but it's still pretty unsatisfactory when it comes to regular people being able to understand such code, let alone debug it when it goes wrong.
But look at Scala through the lens of other languages. It took monumental effort to get to Java 8, Python 3, and ES6. It's unfair to paint the current Scala plateau as some kind of albatross. Especially given that just a few years back, people were complaining about language churn.
Python 3 was very much at the front of my mind as I wrote that - I think their "plateau" has killed the language (I hope I'm wrong). People were complaining about language churn, but I wasn't one of them. With Dotty an unknown number of years away and no committed schedule, I simply don't think Scala can afford to freeze for that long.
Because Scala doesn't have enough syntax already?
Also there are cases where it's not more syntax that's needed, but different syntax. E.g. the way irrefutable unpacks in for/yields desugar to a (with)filter call is just dumb.