4 ms·

What other people find complex, I personally find refreshing. Could you please describe why it looks like a giant tumor of complexity? There's a difference bet

What other people find complex, I personally find refreshing. Could you please describe why it looks like a giant tumor of complexity? There's a difference between true complexity (i.e. complecting or that lead to accidental bugs) and things just being unfamiliar. I try to stay away from the former, while not shying away from the later - since I've picked up Scala about 3 years ago, my knowledge expanded with a lot of useful abstractions that help me do my job better, abstractions that weren't natural or popular or properly implemented in the other languages I worked with. This isn't to say that Scala doesn't have true complexity in it, but then again, what language doesn't?

bkeroack 12y ago
a) Martin Odersky has admitted as much[1]. b) The compiler internals are reportedly a mess[2]--likely due at least in part to the extreme number of different syntax variants. c) I find rule 4.1 in OP interesting ("SHOULD avoid concurrency like the plague it is"). According to Odersky's Coursera course[3], one of the main advantages of functional programming as enabled by Scala is easy, safer concurrency (reduced/absent mutable shared state). Yet here we see a presumably seasoned Scala veteran basically saying that this is a failure and we should avoid concurrency whenever possible because it results in too many bugs. 1. http://www.infoworld.com/article/2609013/java/scala-founder--language-due-for--fundamental-rethink-.html http://www.infoworld.com/article/2609013/java/scala-founder-... 2. https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg 3. https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
- frowaway001 12y ago
  It's always funny to see how these things get interpreted. :-) a) There is a lot of work going on at the foundations of the language – most of the stuff is unlikely to be felt by users. b) Compilers are hard, there is very likely no "nice" compiler out there (except for toy languages). This has almost nothing to do with syntax variants. Nevertheless, there are multiple groups which are working on improving the codebase. c) Concurrency is hard to get right, especially "traditional" approaches like synchronizing, locks, etc. If it's not necessary, don't use it. Otherwise use the right abstractions for your problem, as mentioned in the next paragraphs.
- bad_user 12y ago
  I really can't reply to that, sorry.

bkeroack 12y ago

a) Martin Odersky has admitted as much[1]. b) The compiler internals are reportedly a mess[2]--likely due at least in part to the extreme number of different syntax variants. c) I find rule 4.1 in OP interesting ("SHOULD avoid concurrency like the plague it is"). According to Odersky's Coursera course[3], one of the main advantages of functional programming as enabled by Scala is easy, safer concurrency (reduced/absent mutable shared state). Yet here we see a presumably seasoned Scala veteran basically saying that this is a failure and we should avoid concurrency whenever possible because it results in too many bugs. 1. http://www.infoworld.com/article/2609013/java/scala-founder--language-due-for--fundamental-rethink-.html http://www.infoworld.com/article/2609013/java/scala-founder-... 2. https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg 3. https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun

frowaway001 12y ago
It's always funny to see how these things get interpreted. :-) a) There is a lot of work going on at the foundations of the language – most of the stuff is unlikely to be felt by users. b) Compilers are hard, there is very likely no "nice" compiler out there (except for toy languages). This has almost nothing to do with syntax variants. Nevertheless, there are multiple groups which are working on improving the codebase. c) Concurrency is hard to get right, especially "traditional" approaches like synchronizing, locks, etc. If it's not necessary, don't use it. Otherwise use the right abstractions for your problem, as mentioned in the next paragraphs.
bad_user 12y ago
I really can't reply to that, sorry.