Seems to be on par with the practice of other vendors:
Java SE releases are updated for the public with bug
fixes, security fixes, and minor updates for a period of
at least 3 years before the release reaches end-of-public-
updates (EoPU).
You can't possibly be comparing the binary and source compatibility of Java with Scala can you? I'm not an expert, but I haven't experienced a binary Java incompatibility in the wild and I've been using Java since before 1.0. As far as source compatibility you can count on 1 hand the incompatibilities between Java 1.4 released in 2002 with the current release and Java is not a paradigm for long term support!
Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. Namely, Scala is free from the problems brought on by Java's strict backwards compatibility requirements and can continue to dramatically improve from version to version.
> Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides.
I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet, but not discussing interesting things like how union types will change the way people will write code, how collections could be improved, or how the arity-limitation of tuples could be dropped–because that would actually involve thinking and doing some research–it's a hard thing to do.
Especially when it's likely that I'm going to be accused of "moving the goal posts" when doing that.
It's kind of sad that there is pretty much no insightful technical discussion happening on HN, but at least I can have some fun with "somebody is wrong on the internet" when people make wrong claims.
"I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet..."
"It's kind of sad that there is pretty much no insightful technical discussion happening on HN"
Just as an FYI, in this 1 thread you've dismissively commented on some of the people responsible for the largest user bases of Scala and some of the oldest users of it.
Maybe there would be more insightful technical discussions about Scala on HN if some of us who have actually written Scala in the wild didn't have to put up with derision every time we mention fairly obvious problems that we've encountered and instead could say things like "man useful automated refactorings would be really useful and who cares about tuple arity above 23 f'n parameters"
Another hard thing to do is to deliver relevant business functionality. If your language/community doesn't make that easier, the faster it can be discarded the better.
By all means say them, I think that would add something valuable to the debate.
I'm just bored by people who keep complaining that Scala is not Java (which won't change) or make ridiculous comparisons with C++ (because constructive criticism seems to be too much work these days). I think most people heard that stuff 5 years ago, and it's just a waste of time.
From my point of view, 80% of the comments are firmly focused on events in the past, not what can be learned from them for the future or what they would like to see in the next version.
----
So, given the announcement, which parts do you like, which parts do you consider unimportant and which parts are missing in your opinion?
Why do you think removing the arity limit is not interesting? What's your approach when interacting with databases, were tables with tons of columns seem to occur in practice?
What automatic refactorings would you like to see? Which impression do you have regarding ScalaIDE vs. the IntelliJ plugin?
If you had a few wishes about improving Scala in the future, what would they be and how would you implement them?
"So, given the announcement, which parts do you like, which parts do you consider unimportant and which parts are missing in your opinion?"
Things I love: Union/Intersection types. Any simplification of the type system with regards to type members. Any removal of special XML features. Any fixing of the travesty that is the collections library.
Things that are unimportant: "The type system will have theoretical foundations that are given by a minimal core calculus." A type system being theoretically sound doesn't interest me. What does this provide me in practice? Macros/Reflection (not that it isn't actually important, but unless Macros are central to your paradigm like in Lisp, they are a hack, who cares how hacky they are). Parallel collections.
Things that are missing: Structs. Structs. Real f'n Structs (granted this may be a JVM limitation but I'd trade nearly everything for them).
"Why do you think removing the arity limit is not interesting? What's your approach when interacting with databases, were tables with tons of columns seem to occur in practice?"
Because the only reason I can think of for having giant sized tuples is in a code generation scheme most likely for an ORM system. Code generation in an ORM system is generally a bad idea and it bothers me that an ORM system seems to have the ear of the language designers. When I encounter dbs with tons of columns, I fix the db using standard and proven SQL techniques like normalization, views, and stored procedures. I don't need or want a language crutch to get around those standards.
"What automatic refactorings would you like to see? Which impression do you have regarding ScalaIDE vs. the IntelliJ plugin?"
In an ideal world the Scala refactorings would achieve parity with the Java ones. As it stands currently, there are a fraction of the number of refactorings and they aren't actually safe, even on simple ones like rename or move. Using Eclipse is a non-starter for me. I prefer Vim or IntelliJ. That the Scala maintainers have a defacto standard that goes against my (and many other peoples) preference is a real problem. I would much prefer that the defacto standard was removed so that any solutions they came up with in the tooling space were of necessity workflow agnostic.
"If you had a few wishes about improving Scala in the future, what would they be and how would you implement them?"
The single most important next step for the Scala community is to come up with an idiomatic style. As it stands, if you open a library, go to a new company or even look at the standard libraries there is no single "right" way to write Scala code. For instance, lots of effort has been expended to enable type classes in the language but you can't use standard type classes to enable for syntax (to be honest I'd be fine with the removal of the for syntax entirely but understand that is a pretty out there proposition). A decision around what is and is not idiomatic code and a systematic rewrite of the standard libraries to follow that code is in order. Better yet, a program similar to Go format that just makes decisions about what is right or wrong is in order. The XLint/future features are a good start (not withstanding the neutering that happened with procedure syntax) but I would love to see something more aggressive.
Finally, Typesafe the company and Scala the community need clearer boundaries. It is troubling to me that the Akka/Play/Sbt/Slicks of the world get obvious preferential treatment when it comes to language prioritization. If you want to do something outside the norm in any of those functional spaces, Scala becomes hard to use (and in the case of Sbt they are actually internally inconsistent). I'd prefer a more hands off approach by the language that let the "market" decide the solution.
Refactoring in a dependently typed language is hard. There's room for improvement. Scala-refactoring is a great example of community contribution.
Scala style checking is on our roadmap for 2.12. I'm procrastinating reviewing the first PR for the tool (abide) right now.
Finally, I would like to clarify we are doing everything we can think of to encourage the community to help shape the design and implementation of Scala. We publish roadmaps, review (and even rework) community PRs, do most of our team comms publicly (we are a distributed team), solicit proposals for language changes (e.g., http://docs.scala-lang.org/sips/pending/42.type.html). We spun out library modules that are now being maintained by the community. I spent last year simplifying the core build, so that we can move to a standard sbt build this year, which should also make it easier to contribute. As a first step towards updating the [spec](http://scala-lang.org/files/archive/spec/2.11/), we converted it to [markdown](https://github.com/scala/scala/tree/2.11.x/spec).
That said, I think it's only natural that the Scala committers on Typesafe's payroll are more inclined to work on customer support issues / internal Typesafe support. We always try to strike a fair balance to give back to the community.
Please let me know how we can do better, here or via contact info in my about.
I'll probably focus a bit on the things you think are not as interesting. Not because I dislike your opinion, or disagree with it, but because I think it might be interesting to share my view how and why even uninteresting feature X might add value in the end.
> Union/Intersection types. Any simplification of the type system with regards to type members.
Agree. I think it will be very interesting to see how many ugly LUBs will go away due to that. Also, having first-class support for type lambdas will make some people's lives vastly easier.
> Any removal of special XML features.
I guess it's the right thing to do, but I'll probably miss that feature ... not sure if it is possible to achieve feature parity with string interpolation.
> Any fixing of the travesty that is the collections library.
Yes, I agree that a lot of work could be done there.
> "The type system will have theoretical foundations that are given by a minimal core calculus." A type system being theoretically sound doesn't interest me. What does this provide me in practice?
I think the benefit is that it might free the time of compiler developers, because they might be able to skip the step of figuring out whether code X should compile or not. And if we know the type-system is sound, the chance of having code that throws ClassCastExceptions in unexpected places gets smaller.
But I guess the main benefit is easier reasoning, both for language developers and language users, which leads to less edge cases and feature interactions down the road.
> Macros/Reflection (not that it isn't actually important, but unless Macros are central to your paradigm like in Lisp, they are a hack, who cares how hacky they are).
I'll come back to this in a minute.
> Things that are missing: Structs. Structs. Real f'n Structs (granted this may be a JVM limitation but I'd trade nearly everything for them).
Absolutely agree on that. But this really depends on the VM, there is not much Scala can do to work around the lack of value types (see the limitations of AnyVal). I really hope Oracle manages to ship those things with JDK 10.
> Because the only reason I can think of for having giant sized tuples is in a code generation scheme most likely for an ORM system. Code generation in an ORM system is generally a bad idea and it bothers me that an ORM system seems to have the ear of the language designers.
ORMs are the vietnam of computer science, but I think that the need to represent properties of a database in code is not restricted to just ORMs.
Especially when you have multiple consumers of databases, it's often hard to correct the database schema without having to touch multiple projects in different languages for different customers.
I don't see that having better tuples would be a crutch to get around bad database design.
I think that especially with first-class union and intersection types, better tuples will get vastly more useful and will reduce the current fragmentation in the library space (tuples vs. HLists, etc.).
> [...] I would much prefer that the defacto standard was removed so that any solutions they came up with in the tooling space were of necessity workflow agnostic.
I think this is the huge opportunity macros give us. Eugene Burmako gave a talk recently about scala.meta and one of his examples was showing how people can build IDE-independent rewriting, reformatting and refactoring functionality using Scala's macro features.
> The single most important next step for the Scala community is to come up with an idiomatic style.
Agree. While a lot still needs to happen here, I think there was quite some progress in the last years.
From my point of view it seems as if the style of Scala code out there is slowly converging.
While the adoption of the recommendations in the style guide was good in my opinion, I think the upcoming framework for configuring compiler warnings and the possibilities of scala.meta to build "go fix" like tools will certainly make an impact.
> Finally, Typesafe the company and Scala the community need clearer boundaries.
Agree. From what I have heard, I think the right people are aware of these concerns now.
> It is troubling to me that the Akka/Play/Sbt/Slicks of the world get obvious preferential treatment when it comes to language prioritization.
By picking tacit standards for the messaging, web, build, orm stacks etc Typesafe introduces a chilling effect on other projects in those functional spaces. This chilling effect causes there to be less choice and competition which causes quality degradation in the long term. For instance, I don't think sbt would have survived it's dreadful beginnings if it weren't for the tacit backing of the core Scala team and to be honest I think the Scala community would have been better off with sbt dying young.
Further, by assuming that those stacks are the tacit standards it decreases the diversity of opinions for the language designers to hear about how the community is using their language. For instance Play is very opinionated about how web projects should be created. But it isn't actually the only way people are using Scala for web deployments. Further, once the core team starts to assume that people are using those stacks they can fob off problems onto them instead of centrally fixing the root cause problems. Compile times and sbt's incremental compilation support is an obvious example of this.
Finally, just my own opinion is that they've drawn the lines about what will be Typesafe and what will be "the community" in weird places. Refactoring tools seem like a very central requirement of the language yet that is left to the community. An ORM on the other hand has been elevated.
What's the alternative, though? By offering a nicely integrated platform, I would hope the community benefits from the halo effect this has on Scala. Our goal is to make the whole Scala eco-system successful, but we have to pick carefully what we work on ourselves.
The Scala team is absolutely interested in hearing how Scala is used. We had 800 users from all over the world show us their projects in Berlin not long ago. On the more technical side, we build 1M lines of OSS code every night to make sure we don't break anything out there, and we'll be more than happy to include more projects (https://github.com/typesafehub/community-builds).
I see our role as providing the platform for others to build on (examples of extension points: compiler plugins/macros/sbt's client-server-split/abide as an extensible stylechecker). I'd love for us to work on scala-refactoring, for example, but it's not immediately a priority since the community is already doing it, and we have so many other things to do. A tool like "go fix", which is closely related to code formatting, refactoring and style checking, is on our planning horizon (as mentioned in the roadmap that sparked this discussion).
> Compile times and sbt's incremental compilation support is an obvious example of this.
I don't understand. You seem to be implying incremental compilation is restricted to sbt: it's not! We expose this as a service through the zinc project, which is used by the Intellij plugin (name hashing support added here: https://github.com/JetBrains/intellij-scala/commit/4831c0357...) and many other build tools (e.g., gradle, maven).
Also, regarding sbt: it survived because of the awesome sbt community. The core Scala team (which I lead) is shamefully still using ant, although we plan to move to sbt this year.
The easiest answer to this (and what most language teams do) is not have tacit default functional stacks. Typesafe have gone the odd route, not the standard one.
"I would hope the community benefits from the halo effect this has on Scala"
That may or may not happen, but my experience has been the opposite. An example is Play (which I quite like). It is a very opinionated web framework, that many developers have quite rightly decided didn't match their opinions. By tying the brand of Scala with the brand of Play you make it so that I as a Scala advocate have to fight for both together, even though there are many other Scala web frameworks, and I might not even be fighting for a web project, just that the negative connotations of Play leak into the discussion either explicitly or implicitly. Think of the Ruby case, which is currently more extreme than the Scala one. If someone says they do Ruby development, it is quite natural to think they do Rails even though I'm sure there are other Ruby web frameworks and Ruby the language could be used for any number of things.
This impact is even worse for something that has a really bad reputation like sbt. For many developers their first impression of Scala came from fighting sbt and that negative experience colors their whole opinion of Scala. For years I literally said some variation of "just skip sbt and use maven/gradle/ant etc." trying to get people to divorce Scala from sbt in their mind. Sbt has finally reached a point where instead of saying that I just say, "you'll get used to sbt" which is better, but I can't with a straight face say that sbt is not part and partial to the scala experience (for instance you mention some sbt work is part of the scala core teams responsibilities). If nothing else the other stacks you may encounter make use of it, so you need to have an understanding.
"You seem to be implying incremental compilation is restricted to sbt: it's not!"
I'm sorry if I implied that, you certainly can use zinc standalone or with other build tools besides sbt but the experience is not very polished outside of the sbt use case.
"Also, regarding sbt: it survived because of the awesome sbt community"
No it didn't. For years it was worse than the other alternatives and the only advantage it had was that it was the "Scala" build tool. It is now at a point where it needn't be actively avoided but when I think of all the sunk cost spent on building sbt and fighting to build with sbt it makes me irrationally angry.
"The core Scala team (which I lead) is shamefully still using ant, although we plan to move to sbt this year."
There is nothing shameful about this at all and I wish you'd stick with Ant for all the reasons I've mentioned above.
Thanks for pointing all this out. I honestly don't think of the Scala brand as being tied to the Play framework. Typesafe actually pushes Play on Java more than it does Play on Scala (even though we think Scala is better suited, obviously). We try to decouple Scala from Typesafe and our technologies in two ways: we provide Java programmers with an excellent experience on akka & play, and we welcome external maintainers for any part of Scala.
We happen to steward the Scala project and fund a lot of Scala core development (along with EPFL and research grants), but we're more than happy to share that responsibility with anyone who steps up, as has recently happened (baby steps) with the Scala modules that we spun out of the core for this reason.
PS: The only things that make me angrier than ant are jenkins and bash. (The build systems you're not angry with are probably the ones you haven't spent enough "quality" time with.) In any case, thanks for persevering with sbt and scala!
PPS: I don't think this is an odd route for a small company; how do you make money by developing just a programming language and nothing else?
> It is troubling to me that the Akka/Play/Sbt/Slicks of the world get obvious preferential treatment when it comes to language prioritization.
Being a member of the Play core team at Typesafe, it hasn't been my experience that Play gets preferential treatment when it comes to Scala. If you feel that this is the case then please cite concrete instances of where this has occurred.
> Compile times and sbt's incremental compilation support is an obvious example of this
I do not agree. This has been a general issue and not directly associated with Play. Play has provided some use-cases in this regard, but that is all.
Java is backwards compatible in the syntax, and future compilers have, so far, been able to compile old code as well.
Will that be the thing for Scala?
reply