33 ms·

[rant, for which I'd like to apologize] I've tried to like Scala and it's just hard to do so. Once you've been spoiled by Ruby, Haskell, Python, Coffeescript,

[rant, for which I'd like to apologize] I've tried to like Scala and it's just hard to do so. Once you've been spoiled by Ruby, Haskell, Python, Coffeescript, Clojure, etc, it's hard to see Scala as more than an obfuscated Java [and, yes, I've been coding for nearly 30 years, so this isn't new-language-cock-fight fanboism]. "case classes"? Really? I read Programming Scala and thought that we had learned better. I'll take 3 languages that try to make my life easier rather than one language that tries to encompass every possible paradigm... Or perhaps Scala could have stepped the fuck up, worn the hair shirt for a while and done something interesting. By which I mean: see Mirah (http://www.mirah.org/ http://www.mirah.org/) which is imperfect, beautiful and headed in an awesome, productive direction. And I realize that I'm not in the sweetspot for Java.next, but I am certainly involved in languages du jour and Scala, even if it is Java.next, is not one of them. Some may point at C and C++ as an analogous set of languages and transitions, but I'd point out that we currently live in a world in which new languages are popping up constantly, are being marketed well and are being tried by large groups of coders. Merely extending an existing language is no longer a recipe for success.

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.

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.