4 ms·

Scala shows a lot of promise for certain. The big challenge to Scala will be Java 8. The basic problem is that Scala is too complex. Having written productio

Scala shows a lot of promise for certain. The big challenge to Scala will be Java 8. The basic problem is that Scala is too complex. Having written production code in Scala before, I am unlikely to do so again due to code complexity reasons. And we avoided all the trendy Scala stuff (akka, sbt, DSLs, etc)

danieldk 13y ago
Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. That complexity (or different flavors if you will) has also been a reason for me to stop writing Scala. I don't want to leave behind maintenance hells for whoever has to modify my code in five years. Java may be verbose, but its simplicity (if you avoid the big frameworks) and standardisation (JAX-RS, etc.) does help to keep things understandable and predictable. That said, I do use Akka a lot and like the Typesafe Console. Other than that, I am keeping a distance for now, and put my bets on Java 8 or Kotlin.
- Dewie 13y ago
  > Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. I guess that's a predictable consequence of the design goal of "scalable language". Scalable to the point that people should be able to mold the language in ways that the language designers hadn't foreseen (though in this case the two styles are the two styles that the language was designed to accommodate from the get-go). Maybe people should treat it as a language with many dialects which has the benefit of having a unified ecosystem, instead of having one ecosystem for every dialect.
- eweise 13y ago
  I know what you mean since I develop in Scala for a living. I wonder though if the complexity isn't with Scala itself but rather the abstractions that are created to enable functional style programming. I recently bought the Oreilly functional javascript book and the code also looked complicated once the author introduced unfamiliar abstractions such as trampolines.
- memracom 13y ago
  Scala's complexity is an issue, but I would not characterize it as a big problem. In any organization that adopts Scala, you should have a coding style guide that explains what kinds of constructs are allowed. Start it out with nothing more than Java with less redundancy and then add one thing at a time, making sure that the whole team understands the construct, when to use it, and when it is overkill. The idea is to evolve your way to functional style code rather than dropping it on people's heads from day one. This requires some restraint from senior developers and it requires them to spend more time on educating internally than on coding a masterpiece. Same thing goes with Akka, start small with a simple Actor System with a supervisor tree no more than two levels. Then work your way step by step into more complex solutions where people will recognize the value of a supervisor tree. Expose the inner workings either by implementing message monitoring in Scala or by diverting the message flow externally to RabbitMQ brokers where you can more easily tap and monitor the message flow.
  - ebiester 13y ago
    What about libraries? What if you have to start trying to understand what's going on in Slick? I had two friends who were pairing and were trying to figure out how to get something done. They are both strong java developers and both had scala experience. However, they started diving in and got lost in even understanding what was going on. I believe it was Dijkstra that said (paraphrasing) source code is meant to communicate to humans first and only incidentally machines.
    - atto 13y ago
      I've seen this, too, but Scala's complexity does become more manageable with time. Slick seems to make a trade-off for a very nice API, at the cost of complex underlying code — which you sometimes need to understand when you want to use Type mappers and such. There's several Scala libraries that are on the border of "too clever". One is Play's Iteratees: it's a really nice concept, they take a few days to wrap your mind around. Trying to get a Java programmer to understand them borders on a lost cause.

danieldk 13y ago

Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. That complexity (or different flavors if you will) has also been a reason for me to stop writing Scala. I don't want to leave behind maintenance hells for whoever has to modify my code in five years. Java may be verbose, but its simplicity (if you avoid the big frameworks) and standardisation (JAX-RS, etc.) does help to keep things understandable and predictable. That said, I do use Akka a lot and like the Typesafe Console. Other than that, I am keeping a distance for now, and put my bets on Java 8 or Kotlin.

Dewie 13y ago
> Scala's complexity is a serious problem. I once overheard a conversation between two people (one of them family) who implemented a 'binding' for a distributed key-value store in Scala. One complained that he couldn't even understand the other person's code. The difference: one library treated Scala as a Java with classes, while the other was written in a very functional style using Scalaz. I guess that's a predictable consequence of the design goal of "scalable language". Scalable to the point that people should be able to mold the language in ways that the language designers hadn't foreseen (though in this case the two styles are the two styles that the language was designed to accommodate from the get-go). Maybe people should treat it as a language with many dialects which has the benefit of having a unified ecosystem, instead of having one ecosystem for every dialect.
eweise 13y ago
I know what you mean since I develop in Scala for a living. I wonder though if the complexity isn't with Scala itself but rather the abstractions that are created to enable functional style programming. I recently bought the Oreilly functional javascript book and the code also looked complicated once the author introduced unfamiliar abstractions such as trampolines.
memracom 13y ago
Scala's complexity is an issue, but I would not characterize it as a big problem. In any organization that adopts Scala, you should have a coding style guide that explains what kinds of constructs are allowed. Start it out with nothing more than Java with less redundancy and then add one thing at a time, making sure that the whole team understands the construct, when to use it, and when it is overkill. The idea is to evolve your way to functional style code rather than dropping it on people's heads from day one. This requires some restraint from senior developers and it requires them to spend more time on educating internally than on coding a masterpiece. Same thing goes with Akka, start small with a simple Actor System with a supervisor tree no more than two levels. Then work your way step by step into more complex solutions where people will recognize the value of a supervisor tree. Expose the inner workings either by implementing message monitoring in Scala or by diverting the message flow externally to RabbitMQ brokers where you can more easily tap and monitor the message flow.
- ebiester 13y ago
  What about libraries? What if you have to start trying to understand what's going on in Slick? I had two friends who were pairing and were trying to figure out how to get something done. They are both strong java developers and both had scala experience. However, they started diving in and got lost in even understanding what was going on. I believe it was Dijkstra that said (paraphrasing) source code is meant to communicate to humans first and only incidentally machines.
  - atto 13y ago
    I've seen this, too, but Scala's complexity does become more manageable with time. Slick seems to make a trade-off for a very nice API, at the cost of complex underlying code — which you sometimes need to understand when you want to use Type mappers and such. There's several Scala libraries that are on the border of "too clever". One is Play's Iteratees: it's a really nice concept, they take a few days to wrap your mind around. Trying to get a Java programmer to understand them borders on a lost cause.