4 ms·

There's no substantiative argument in this comment. > Scala, as a programming language, tries to incorporate too many concepts Too many concepts? Says who? Ho

There's no substantiative argument in this comment. > Scala, as a programming language, tries to incorporate too many concepts Too many concepts? Says who? How many concepts is too many? You don't have to use them all, and you can pick them up fairly easily as you go along; that's exactly how I learned the language. > while still trying to be typesafe. Not sure why that's contentious. > This makes the language complex, and not an ideal candidate. Says who? Why? Should all complex things be abandoned? I find the Android framework itself complex, personally, so should we throw that out? This is the same Scala FUD that's always prevalent on Hacker News. "The language does too much." So what? You don't need to know all the concepts to be proficient. The language's beauty is that you can write simple code and pick up the concepts as you go along. Library modularity generally means that you don't need to get into the deep end of the language unless you want to. Scala is an expressive language. That's an intentional design decision that makes it flexible. It is not a drawback. It does not make it overcomplicated for a beginner.

apendleton 12y ago
> Says who? Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language. Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.
- smrtinsert 12y ago
  I'm a non expert in Scala and after a little learning it is extremely legible and provides many ways to clearify your syntax. If you're arguing that syntax should be obvious, I think that's a non starter in a technical argument. That's like believing that programming should be possible without programming.
- mgkimsal 12y ago
  "I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala." Gut feeling, Scala is the new Perl. At least with respect to 'idiomatic' Scala/Perl encouraging a terseness, as well as a fairly deep/loyal (if small) fan base. Also, many of the use cases where the language shines tend to be non-mainstream - usually other languages handle mundane 'every day' use cases differently, perhaps more verbosely, but also with a lot more developers on board. Just a thought that popped in to my head. I've no doubt I've offended the very core of many Scala and Perl devs out there just now. ;)
- saryant 12y ago
  > but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators This is not idiomatic Scala. http://docs.scala-lang.org/style/naming-conventions.html#symbolic_method_names http://docs.scala-lang.org/style/naming-conventions.html#sym... > Avoid! [...] As a general rule, symbolic method names should be well-understood and self documenting in nature. The rule of thumb is as follows: if you need to explain what the method does, then it should have a real, descriptive name rather than a symbols. There are some very rare cases where it is acceptable to invent new symbolic method names. Odds are, your API is not one of those cases!
  - benburton 12y ago
    I think this is actually the crux of the issue. The language gives you enough rope to hang yourself with, and when people do hang themselves with it, those who look in from the outside throw the baby out with the bathwater.
    - 12y ago
zak_mc_kracken 12y ago
> So what? You don't need to know all the concepts to be proficient Yes, you do. We heard this kind of argument with C++ twenty years ago. You can choose to ignore huge portions of the language for your personal use, but once you start working on a team, you will have to know the entire language.
- saryant 12y ago
  No, you don't. I've been working on Scala project with a team mostly comprised of people who never used Scala before and who came from different programming backgrounds. We can and do ignore huge portions of the Scala language and ecosystem (no Scalaz, no type system hackery). At the same time, we still reap huge benefits from the parts of Scala we do use. Immutability by default, high-level parallelism/concurrency constructs, monads, typeclasses, etc.

apendleton 12y ago

> Says who? Says at least me and the OP, and probably others... I haven't put a ton of time into learning Scala and only occasionally interact with it, but in that capacity I'd definitely say I find it a bit intimidating and someone hard to read. Certainly there are many ways to write Scala, and a Java-like style is doable, but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators that aren't immediately interpretable by people not familiar with the language. Whether legibility from non-experts is important is absolutely a matter of opinion and personal taste (it's a clear source of disagreement between the Python and Ruby communities as well), but if you're someone who thinks it's an important property for languages that get widespread adoption to have (and I am), looking at Scala code as it seems to typically be written would give you (or at least gives me) pause. I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala. I don't think they fill the same niche, as the poster seems to be advocating that they could.

smrtinsert 12y ago
I'm a non expert in Scala and after a little learning it is extremely legible and provides many ways to clearify your syntax. If you're arguing that syntax should be obvious, I think that's a non starter in a technical argument. That's like believing that programming should be possible without programming.
mgkimsal 12y ago
"I can look at Swift without having ever written any and know roughly what it's doing. I can't with Scala." Gut feeling, Scala is the new Perl. At least with respect to 'idiomatic' Scala/Perl encouraging a terseness, as well as a fairly deep/loyal (if small) fan base. Also, many of the use cases where the language shines tend to be non-mainstream - usually other languages handle mundane 'every day' use cases differently, perhaps more verbosely, but also with a lot more developers on board. Just a thought that popped in to my head. I've no doubt I've offended the very core of many Scala and Perl devs out there just now. ;)
saryant 12y ago
> but idiomatic Scala, as far as I've seen, encourages terseness and the use of opaque punctuation-laden operators This is not idiomatic Scala. http://docs.scala-lang.org/style/naming-conventions.html#symbolic_method_names http://docs.scala-lang.org/style/naming-conventions.html#sym... > Avoid! [...] As a general rule, symbolic method names should be well-understood and self documenting in nature. The rule of thumb is as follows: if you need to explain what the method does, then it should have a real, descriptive name rather than a symbols. There are some very rare cases where it is acceptable to invent new symbolic method names. Odds are, your API is not one of those cases!
- benburton 12y ago
  I think this is actually the crux of the issue. The language gives you enough rope to hang yourself with, and when people do hang themselves with it, those who look in from the outside throw the baby out with the bathwater.
  - 12y ago

zak_mc_kracken 12y ago

> So what? You don't need to know all the concepts to be proficient Yes, you do. We heard this kind of argument with C++ twenty years ago. You can choose to ignore huge portions of the language for your personal use, but once you start working on a team, you will have to know the entire language.

saryant 12y ago
No, you don't. I've been working on Scala project with a team mostly comprised of people who never used Scala before and who came from different programming backgrounds. We can and do ignore huge portions of the Scala language and ecosystem (no Scalaz, no type system hackery). At the same time, we still reap huge benefits from the parts of Scala we do use. Immutability by default, high-level parallelism/concurrency constructs, monads, typeclasses, etc.