A lot of the worst tendencies that developers complain about in complex programming languages (i.e. all of them, they're all complex) could be addressed by this advice.
I mean in a future release of Scala, they will add generics - that, combined with higher-order functions, will allow for functional programming constructs like Option and operations like map, filter, etc - those are already possible, but the function they operate on has to be declared for every type.
But while that has really taken off in some languages and environments, it's heavily discouraged in Go - the runtime is not designed for it, it can't cleverly unroll and optimize it, and the function call overhead will make its performance terrible compared to a regular loop.
TL;DR while it is or will be possible, it conflicts with the principle of least power described here, and a number of e.g. Go proverbs and other wisdoms.
This is a typo, the great old one meant to say Go, not Scala.
Unfortunately, at the same time it also takes away the power in situations where it should be used and where the benefits of abstraction overweigh the drawbacks. This then leads to repetitive and bloated code, runtime errors and all the problems that come from it.
Pick your poison...
With Scala, and I've worked with the language and some Scala oriented developers, I get the feeling that each individual developer styles themselves an artisan, and their code is not for the likes of mortals to comprehend.
I mean I kinda get it, it makes them feel smart and empowered and above the common Java developers and will probably earn them more money. Hell, I've been at one and heard of at least one other place where they decided for Scala not so much because it was the best language for the job, but because if they went with Java they would have to weed out 95% of applicants because they're mediocre - if you nab a Scala developer you know you've got someone from the top 10% at least.
I mean the one project failed and they went back to C# / .NET after a few years because they couldn't find developers and the other one probably muddles on because of sunk cost, but still.
Perhaps Scala adoption would be higher today. Assuming no competitors (Kotlin) had gained momentum.
(2017) https://www.lihaoyi.com/post/SowhatswrongwithSBT.html
(2018) https://www.lihaoyi.com/post/MillBetterScalaBuilds.html
For example, it assumes that refactoring is easy, making it easy to switch your initially simple solution to something more complex if / when the need arises. That is true in Scala thanks to a rich and safe type system, but in other languages it may not be as easy, and it's certainly not easy to replace a python app with a Scala app.
Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11467339 - April 2016 (64 comments)
Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11265424 - March 2016 (4 comments)
