3 ms·
I really disliked Scala at first as well. It is a very complex language, partly due to the fancy type system, implicits, and syntactic sugar. Still, after a yea
by arete 15y ago
I really disliked Scala at first as well. It is a very complex language, partly due to the fancy type system, implicits, and syntactic sugar. Still, after a year of writing Scala code I've really come to like it. The complexity certainly comes with benefits, and I wouldn't call it "obfuscated" in the least.
That fancy type system goes a long way towards helping to verify, at compile time, that your program is correct. Plus, with dynamically-typed languages you often have to build your own halfassed adhoc type system to check function parameters, map objects to db tables, (de)serialize JSON data, etc. Much better to use a well-thought out one built into the language, that also finds errors before the code is running!
Here's a little real-world example of using Scala types to define the response from a Foursquare JSON API call:
case class Response[T](meta: Meta, response: T)
case class Meta(code: Int)
case class MayorshipsResponse(mayorships: Mayorships)
case class Mayorships(count: Int, items: List[Mayorship])
case class Mayorship(venue: Venue)
Isn't the verification and documentation value of that so much better than using the typical dynamic language's map-of-maps and hoping you didn't mistype a string key name somewhere?
Implicits provide a really nice way to extend the functionality of existing types. Instead of monkey patching, which pollutes your entire program, you can simply write a wrapper class that provides new functionality and an implicit conversion. This is how Scala can give raw Java Arrays the same rich set of methods that any native Scala collection has, and how the standard "map" method can be defined generically but still build & return the expected result collection type.
Syntactic sugar is arguably a problem, there are definitely a lot of special cases to learn and remember: when can parenthesis be omitted, when can curly braces replace parenthesis, special methods with symbol names like "::", ":+", "@", etc. But in the long run I think the sugar does make code easier to read.
Compare a single "map" function in Erlang (a language that really eschews syntactic sugar):
lists:map(fun(N) -> N + 1 end, [1, 2, 3]).
vs Scala:
List(1, 2, 3).map(_ + 1)
which is really just syntactic sugar for:
List(1, 2, 3).map({(n: Int) => n + 1})
I think that in the long run I'd rather memorize some rules (as long as they're reasonable and logical) rather than have to read/write through a ton of boilerplate every time I declare a closure.