4 ms·

Writing something in scala feels like a waste to me. If they were to narrow the grammar of the language down, compiler time would decrease and the code rot situ

by anon3_ 11y ago

Writing something in scala feels like a waste to me. If they were to narrow the grammar of the language down, compiler time would decrease and the code rot situation would be much better. Instead, teams that want to grow big in scala have to come up with their own agreements on which features not to use. The deeper concern I see is the lack of introspection and defensiveness in the community when the critique is brought up. I've never seen programmers before take such offense and have to resort to banning programmers criticizing feature bloat. It's not a personal attack or trying to kill Scala. There's a legitimate feeling the language tacked on way too much, too soon. When it comes to a programming language, negative comments won't kill it. All languages grow their warts over time. Look at all the critique C absorbed.

tormeh 11y ago
The grammar isn't a problem (at lest not for the compiler). Scalac is pretty fast at giving you error messages. It's when your code is legal that you really have to wait. I'd speculate that it's the code generator that's the problem.
- anon3_ 11y ago
  Grammar ends up becoming a problem on a few fronts. I highly recommend Principles of Compiler Design [1]. One safe rule of thumb is, as grammar and rules expand, the performance and simplicity of the compiler begin to deteriorate, particularly if features aren't added carefully. The second is in practice, the additional grammar gives you far more ways to tackle the same problem. The is the conundrum that metaprogramming gives in languages like Ruby. Teams begin the phase of coding to the domain before letting other things fall into place. Thinking ahead is good, but I think the issue is Scala's grammatical flexibility makes it too tempting to dig ourselves into a DSL before we're really ready. This is why we'd get so grumpy when PM's came to us asking for new features that'd require a refactor. We bought in to our own idioms, if we programmed things without the DSL, we'd be more nimble. And we're not dumbasses. We're experienced programmers with experience programming in that domain before, but the target always ends up moving for reason's outside of engineering's control. From experience we know, DSL has no place until you're very secure in what the needs of the business is. That said, no codebase is future proof to the rest of the team needing last minute changes - but I feel scala forces you into design decisions too early, and we thought that was an advantage. Actually, I liked scala for not having Java's boilerplate. Then I began to miss those old things java forced you into. It was painful, because the ego investment the team had in scala was huge. A lot was on the line. Crow had to be eaten. [1] http://en.wikipedia.org/wiki/Principles_of_Compiler_Design http://en.wikipedia.org/wiki/Principles_of_Compiler_Design
  - thescrewdriver 11y ago
    It's worth pointing out that it's a case of YMMV. There are clearly those who haven't had success adopting Scala. I've seen Scala used successfully by multiple teams, but I suspect a strong culture of code reviews may have been a significant factor in our successful adoption of Scala. I would be disappointed if they tried to remove features from Scala, the extra features really do come in useful when used selectively.
    - anon3_ 11y ago
      If a good team nails the guidelines down before hand on which idioms they plan to use and stick to them, yeah. That is a rare qualifier to meet in my experience, many teams will be ecstatic about scala. Many times we'd be hiring java programmers who felt that scala would make them more relevant in the startup world. Next is the situation where it would be, "Just hold keep holding on..." until a. the language finally clicks b. the whole system is in scala. c. Both. Scala did just click. And there never was a best solution to solve a problem. Python programmers were canned, we had the floor - those "distractions" were eliminated. We just got in this vicious cycle while we burned away our runway. Now we look back, bitter, and make excuses. What hurts my pride to say is, Why didn't we just pick the safe bet - the Python or the Java. I upvoted you. If you got a smart team and can make scala work somehow, all the power to you. I think you should make a story about how you scaled your code so the rest of us can learn
      - tormeh 11y ago
        I think this confirms the importance of a language restricting your choices, not only for type safety, but also for architectural soundness. Actually, it sounds like your team needed Go.
      - zak_mc_kracken 11y ago
        > If a good team nails the guidelines down before hand on which idioms they plan to use and stick to them, yeah. So, like we used to do with C++? Anyone old enough to remember "C++ is fine as long as you define a well specified subset and stay away from certain features"? Even today, this is still what Google does about C++. Hopefully we learned that this is never a good sign about a language.
- justthistime_ 11y ago
  Most of the time is spent in the typechecker.
lmm 11y ago
The grammar is fine, probably simpler than Java's (e.g. try/catch is a much less specialized construct, type inference is applied much more consistently). What specifically would you look to cut? Scala does seem to attract a disproportionate amount of criticism. And a lot of it is vague, nonconstructive, or simply wrong (and "writing something in scala feels like a waste to me" is nonconstructive in my book). Some defensiveness is warranted.
justthistime_ 11y ago
So what _is_ your criticism? The grammar of the language has no relationship with compilation speed. What did they "tack on way too much, too soon"?
zak_mc_kracken 11y ago
> There's a legitimate feeling the language tacked on way too much, too soon. A lot of people certainly feel this way, and this feeling has given rise to the first crop of post-Scala languages: Ceylon and Kotlin. I'm sure there will be more.
- justthistime_ 11y ago
  People are still asking for examples, not for some popularity vote on feelings. (Also, the designer of one of the languages mentioned was completely unaware of Scala when he created his own.)
  - zak_mc_kracken 11y ago
    No, you are confusing people. The person is James Strachan, he created Groovy. Since then, he abandoned Scala and he's now a committer on Kotlin (or was, not sure if he still is, he tends to bounce around projects a lot).
    - justthistime_ 11y ago
      No, I'm right. I didn't think of James Strachan. (He by the way stopped contributing to Kotlin around October 2012. You're welcome.)
      - zak_mc_kracken 11y ago
        Ok, so who is this person you are referring to?
  - vorg 11y ago
    Don't think that's the case with Ceylon or Kotlin, perhaps with some other "post-Scala" JVM language such as Gosu or Fantom, but definitely with Groovy. It's creator James Strachan wrote in http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl... "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy".

by anon3_ 11y ago

tormeh 11y ago

The grammar isn't a problem (at lest not for the compiler). Scalac is pretty fast at giving you error messages. It's when your code is legal that you really have to wait. I'd speculate that it's the code generator that's the problem.

anon3_ 11y ago
Grammar ends up becoming a problem on a few fronts. I highly recommend Principles of Compiler Design [1]. One safe rule of thumb is, as grammar and rules expand, the performance and simplicity of the compiler begin to deteriorate, particularly if features aren't added carefully. The second is in practice, the additional grammar gives you far more ways to tackle the same problem. The is the conundrum that metaprogramming gives in languages like Ruby. Teams begin the phase of coding to the domain before letting other things fall into place. Thinking ahead is good, but I think the issue is Scala's grammatical flexibility makes it too tempting to dig ourselves into a DSL before we're really ready. This is why we'd get so grumpy when PM's came to us asking for new features that'd require a refactor. We bought in to our own idioms, if we programmed things without the DSL, we'd be more nimble. And we're not dumbasses. We're experienced programmers with experience programming in that domain before, but the target always ends up moving for reason's outside of engineering's control. From experience we know, DSL has no place until you're very secure in what the needs of the business is. That said, no codebase is future proof to the rest of the team needing last minute changes - but I feel scala forces you into design decisions too early, and we thought that was an advantage. Actually, I liked scala for not having Java's boilerplate. Then I began to miss those old things java forced you into. It was painful, because the ego investment the team had in scala was huge. A lot was on the line. Crow had to be eaten. [1] http://en.wikipedia.org/wiki/Principles_of_Compiler_Design http://en.wikipedia.org/wiki/Principles_of_Compiler_Design
- thescrewdriver 11y ago
  It's worth pointing out that it's a case of YMMV. There are clearly those who haven't had success adopting Scala. I've seen Scala used successfully by multiple teams, but I suspect a strong culture of code reviews may have been a significant factor in our successful adoption of Scala. I would be disappointed if they tried to remove features from Scala, the extra features really do come in useful when used selectively.
  - anon3_ 11y ago
    If a good team nails the guidelines down before hand on which idioms they plan to use and stick to them, yeah. That is a rare qualifier to meet in my experience, many teams will be ecstatic about scala. Many times we'd be hiring java programmers who felt that scala would make them more relevant in the startup world. Next is the situation where it would be, "Just hold keep holding on..." until a. the language finally clicks b. the whole system is in scala. c. Both. Scala did just click. And there never was a best solution to solve a problem. Python programmers were canned, we had the floor - those "distractions" were eliminated. We just got in this vicious cycle while we burned away our runway. Now we look back, bitter, and make excuses. What hurts my pride to say is, Why didn't we just pick the safe bet - the Python or the Java. I upvoted you. If you got a smart team and can make scala work somehow, all the power to you. I think you should make a story about how you scaled your code so the rest of us can learn
    - tormeh 11y ago
      I think this confirms the importance of a language restricting your choices, not only for type safety, but also for architectural soundness. Actually, it sounds like your team needed Go.
    - zak_mc_kracken 11y ago
      > If a good team nails the guidelines down before hand on which idioms they plan to use and stick to them, yeah. So, like we used to do with C++? Anyone old enough to remember "C++ is fine as long as you define a well specified subset and stay away from certain features"? Even today, this is still what Google does about C++. Hopefully we learned that this is never a good sign about a language.
justthistime_ 11y ago
Most of the time is spent in the typechecker.

lmm 11y ago

The grammar is fine, probably simpler than Java's (e.g. try/catch is a much less specialized construct, type inference is applied much more consistently). What specifically would you look to cut? Scala does seem to attract a disproportionate amount of criticism. And a lot of it is vague, nonconstructive, or simply wrong (and "writing something in scala feels like a waste to me" is nonconstructive in my book). Some defensiveness is warranted.

justthistime_ 11y ago

So what _is_ your criticism? The grammar of the language has no relationship with compilation speed. What did they "tack on way too much, too soon"?

zak_mc_kracken 11y ago

> There's a legitimate feeling the language tacked on way too much, too soon. A lot of people certainly feel this way, and this feeling has given rise to the first crop of post-Scala languages: Ceylon and Kotlin. I'm sure there will be more.

justthistime_ 11y ago
People are still asking for examples, not for some popularity vote on feelings. (Also, the designer of one of the languages mentioned was completely unaware of Scala when he created his own.)
- zak_mc_kracken 11y ago
  No, you are confusing people. The person is James Strachan, he created Groovy. Since then, he abandoned Scala and he's now a committer on Kotlin (or was, not sure if he still is, he tends to bounce around projects a lot).
  - justthistime_ 11y ago
    No, I'm right. I didn't think of James Strachan. (He by the way stopped contributing to Kotlin around October 2012. You're welcome.)
    - zak_mc_kracken 11y ago
      Ok, so who is this person you are referring to?
- vorg 11y ago
  Don't think that's the case with Ceylon or Kotlin, perhaps with some other "post-Scala" JVM language such as Gosu or Fantom, but definitely with Groovy. It's creator James Strachan wrote in http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl... "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy".