4 ms·

Seems like an awful lot of rules to hold in one's head. Scala just looks like a giant tumor of complexity to me.

sumnulu 12y ago
To be fair these are not rules, just best practices, like naming conventions. i.e. > 2.1. MUST NOT use "return" > 1.1. SHOULD enforce a reasonable line length > 1.5. Names MUST be meaningful *(x, xs, xss, ns, are meaningful names by the way)* > 3.3. SHOULD NOT apply optimizations without profiling ...
bad_user 12y ago
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.
ionforce 12y ago
As you get more experienced with Scala, you begin to develop better habits and notice more patterns and you will throw away a lot of the unneeded complexity. Scala can be complex (on paper), but in practice it doesn't have to be.
the_af 12y ago
When you think about them, a lot of those rules aren't Scala-specific (though some are). So you could just as well say "most programming languages are giant tumors of complexity". For example, if you write Java, most (or similar, or even more complex) rules apply.
- bkeroack 12y ago
  "Java is just is bad" is not a ringing endorsement.
  - the_af 12y ago
    Heh. I'm not one of them, but a lot of people think Java would be mostly fine with just minor updates. In any case, I chose Java as an example because (sadly) it's what I'm forced to use in my day job, with some Scala side-projects (thankfully!). But I didn't mean to single Java out: a lot of the advice applies in general to software design, regardless of language. You know, "choose the right abstraction", "beware concurrency", "name things wisely", etc.

To be fair these are not rules, just best practices, like naming conventions. i.e. > 2.1. MUST NOT use "return" > 1.1. SHOULD enforce a reasonable line length > 1.5. Names MUST be meaningful *(x, xs, xss, ns, are meaningful names by the way)* > 3.3. SHOULD NOT apply optimizations without profiling ...

bad_user 12y ago

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.

ionforce 12y ago

As you get more experienced with Scala, you begin to develop better habits and notice more patterns and you will throw away a lot of the unneeded complexity. Scala can be complex (on paper), but in practice it doesn't have to be.

the_af 12y ago

When you think about them, a lot of those rules aren't Scala-specific (though some are). So you could just as well say "most programming languages are giant tumors of complexity". For example, if you write Java, most (or similar, or even more complex) rules apply.

bkeroack 12y ago
"Java is just is bad" is not a ringing endorsement.
- the_af 12y ago
  Heh. I'm not one of them, but a lot of people think Java would be mostly fine with just minor updates. In any case, I chose Java as an example because (sadly) it's what I'm forced to use in my day job, with some Scala side-projects (thankfully!). But I didn't mean to single Java out: a lot of the advice applies in general to software design, regardless of language. You know, "choose the right abstraction", "beware concurrency", "name things wisely", etc.