Strategic Scala Style: Principle of Least Power

lihaoyi.com

16 points·ignoramous··4 comments

Reading this post reminds of when I tried to learn Scala and ran away when I saw the heap of complexity it was.

It seems like they tried to put all features they could in there without thinking about the orthogonality of the result.

Languages that need all that restraint to be used right maybe are ok for some very clever people, problem is all the rest of us that can't juggle all that in out heads.

As a Scala fan, I can agree with the sentiment.

Scala tried to be (1) flexible and (2) very interoperable with Java.

This lead to (1) a lot of confusing intersections of paradigms and (2) a lot of compromise even within those ideals.

That said, I don't see any better statically typed functional language with even half the available libraries of Scala (because of Java), so I stick to it as my language of choice. Haskell is very close though, with the added benefit (IMO) of native compilation.

This is the main reason I settled on Clojure as my primary language. It encourages applying a small number of concepts to a wide range of problems. It has simple syntax and semantics, so I can focus on the problem I'm solving instead of constantly thinking about the language.

I really think simplicity is underappreciated in language design. Packing a bunch of features into a language can make it powerful, but it also makes it difficult to reason about. This in turn makes it harder to maintain code and collaborate with others.

> If you don't know what can go wrong, use exceptions

Disagree. Exceptions are broken in Scala. I think it's better to do what was suggested in an earlier point, and return an ADT. You should wrap them and return an ADT constructor taking in the exception.

Reply on news.ycombinator.com