My biggest frustration with Scala is the exact opposite of their frustration with Typesafe's Scala: it moves too fast. Scala's backwards compatibility problems are obnoxious for the people who don't feel the need to reinvent everything. I can find a version of Foo that works with 2.11 but the only version of Bar I can use only has artifacts for <=2.10.
The play framework exemplifies these problems. Documentation doesn't keep up with releases, blog posts and tutorials don't either. Sometimes I'm looking for example code for some plugin or library, and the code only works with some other version of another dependency that I can't use. I totally understand that people prefer Agile development, but you can't combine Agile development with non-Agile documentation, unless you want to create a framework that only experts can use.
You are misunderstanding. The issue you have observed is caused by binary incompatibility between Scala versions. Java has an almost one-to-one mapping to JVM bytecode. Scala, having many features that Java does not, does not have such a direct mapping. Sometimes the way Scala is compiled to JVM bytecode changes, to fix bugs or to improve performance (e.g. compilation of lambdas will change now that Java 8 supports them). This leads to binary incompatibility between Scala versions, though the problem is decreasing with time.
This effort is aiming to keep binary compatibility, so it will have no effect of users of Typesafe's compiler. To quote: "programs which are valid when compiled with the Typesafe Scala compiler would have the same meaning and binary representation when compiled with the fixes in place."
The documentation for JSON parsing in Play is hilarious.
You read the "The Play JSON library Basics" document, it looks like a lot of code for something that should be simple, but you go ahead and implement as explained. After a while, the verbosity starts bugging you, so you read the "JSON Reads/Writes/Format Combinators", followed by "JSON transformers" and finally the "JSON Macro Inception" pages.
The punchline in the last section can be summarized as "forget all that other stuff, just do "implicit val personFmt = Json.format[Person]". I was happy to be able to delete hundreds of lines of code from my project after learning this, but couldn't you just have told me this upfront since it probably covers 99% of all cases? The documentation also has an aura of "Isn't this all very clever?" feeling to it. It's also quite hard to search for anything, as outdated versions of the docs keep popping up in Google as the first results.
I think if anything that example shows the cleverness is a good thing. It's from almost 5 years ago, since when Scala has gone from strength to strength, so the collections rewrite turned out quite well, and fears that it would stop new people coming to Scala, or that companies would stay on 2.7 and the community would schism, were definitely unfounded. The "use case" simplification of the documentation has been implemented and has shown itself to work well, suggesting that this kind of complexity can be managed. And a few years later I've seen Chris use equally complex techniques in his own code (check out his "practical scalaz" talk).
I had this exact same thing experience, thinking, "wow, they want me to write marshal/unmarshal code for every type... is it 1999?" and then, finally, stumbling across the horrifically written "JSON Macro Inception" articles--as if no one had ever used reflection before for serialization--and feeling very, very stabby.
And lets not talk about all the wrong/missing import statements in code examples...
The documentation also has an aura of "Isn't this all very clever?"
This attitude needs to die. Forever. Why the fuck should I need know about contravariance and parser combinators to write a basic web app? I hope this Scala forking will kill it in Typesafe. It has no place in actually building products.
Yes. The implementation uses a macro, which some people have (sometimes legitimate) concerns about, but you can tell it to make a format for a case class and it will Just Work.
We've been bitten by this as well. We started several projects within a few months of each that also used what we believed to be similar enough versions of Play but there are just enough inconsistencies between versions of play (and Scala language versions as well) to make it exceedingly frustrating to work with.
Comments
My biggest frustration with Scala is the exact opposite of their frustration with Typesafe's Scala: it moves too fast. Scala's backwards compatibility problems are obnoxious for the people who don't feel the need to reinvent everything. I can find a version of Foo that works with 2.11 but the only version of Bar I can use only has artifacts for <=2.10.
The play framework exemplifies these problems. Documentation doesn't keep up with releases, blog posts and tutorials don't either. Sometimes I'm looking for example code for some plugin or library, and the code only works with some other version of another dependency that I can't use. I totally understand that people prefer Agile development, but you can't combine Agile development with non-Agile documentation, unless you want to create a framework that only experts can use.
You are misunderstanding. The issue you have observed is caused by binary incompatibility between Scala versions. Java has an almost one-to-one mapping to JVM bytecode. Scala, having many features that Java does not, does not have such a direct mapping. Sometimes the way Scala is compiled to JVM bytecode changes, to fix bugs or to improve performance (e.g. compilation of lambdas will change now that Java 8 supports them). This leads to binary incompatibility between Scala versions, though the problem is decreasing with time.
This effort is aiming to keep binary compatibility, so it will have no effect of users of Typesafe's compiler. To quote: "programs which are valid when compiled with the Typesafe Scala compiler would have the same meaning and binary representation when compiled with the fixes in place."
Yeah I've wasted so much time dealing with code for the wrong version of Play. It's horrendously organised: case in point, the JSON parsing (WTF?)
The documentation for JSON parsing in Play is hilarious.
You read the "The Play JSON library Basics" document, it looks like a lot of code for something that should be simple, but you go ahead and implement as explained. After a while, the verbosity starts bugging you, so you read the "JSON Reads/Writes/Format Combinators", followed by "JSON transformers" and finally the "JSON Macro Inception" pages.
The punchline in the last section can be summarized as "forget all that other stuff, just do "implicit val personFmt = Json.format[Person]". I was happy to be able to delete hundreds of lines of code from my project after learning this, but couldn't you just have told me this upfront since it probably covers 99% of all cases? The documentation also has an aura of "Isn't this all very clever?" feeling to it. It's also quite hard to search for anything, as outdated versions of the docs keep popping up in Google as the first results.
Look at this one: http://stackoverflow.com/questions/1722726/is-the-scala-2-8-...
Scala has a lot of really clever stuff and the "isn't this all really clever" attitude is definitely there.
EDIT: Come on. I meant clever in a good way as well. I'm just a bit ambivalent, is all.
I think if anything that example shows the cleverness is a good thing. It's from almost 5 years ago, since when Scala has gone from strength to strength, so the collections rewrite turned out quite well, and fears that it would stop new people coming to Scala, or that companies would stay on 2.7 and the community would schism, were definitely unfounded. The "use case" simplification of the documentation has been implemented and has shown itself to work well, suggesting that this kind of complexity can be managed. And a few years later I've seen Chris use equally complex techniques in his own code (check out his "practical scalaz" talk).
Yeah, I think there's a strong possibility that the Play JSON docs constitute a much more worrisome suicide letter.
I had this exact same thing experience, thinking, "wow, they want me to write marshal/unmarshal code for every type... is it 1999?" and then, finally, stumbling across the horrifically written "JSON Macro Inception" articles--as if no one had ever used reflection before for serialization--and feeling very, very stabby.
And lets not talk about all the wrong/missing import statements in code examples...
The documentation also has an aura of "Isn't this all very clever?"
This attitude needs to die. Forever. Why the fuck should I need know about contravariance and parser combinators to write a basic web app? I hope this Scala forking will kill it in Typesafe. It has no place in actually building products.
I notice a lot of difference in quality between libraries released by enterprises and those by users. It's the difference between https://www.paypal-engineering.com/2014/02/13/hello-newman-a... and Dispatch. We need way more of the former.
Wait, so it can figure out case classes on it's own?
Yes. The implementation uses a macro, which some people have (sometimes legitimate) concerns about, but you can tell it to make a format for a case class and it will Just Work.
We've been bitten by this as well. We started several projects within a few months of each that also used what we believed to be similar enough versions of Play but there are just enough inconsistencies between versions of play (and Scala language versions as well) to make it exceedingly frustrating to work with.