8 ms·

Scala: Next Steps

95 points by jfb 12y ago

tormeh 12y ago
I love how they don't take backwards compatibility so seriously. A lax attitude to backwards compatibility means they can actually have the syntax get less bad over time, instead of becoming C++. Scala does have some less-than-obvious things that need to be fixed.
- frowaway001 12y ago
  I like how most of the sentences in this comment try to present some questionable claims as facts, with the usual comparison with C++ casually thrown in.
  - nmrm 12y ago
    The #1 item on Aida specifically mentions breaking backward compatibility is an option. The #1 item on Don Giovanni is "clean up syntax".
    - deleted 12y ago
      [deleted]
  - tormeh 12y ago
    I'm not a fan of rigor; I prefer to communicate in a short, simple way and let people fill in the blanks. But here's some better argumentation: There are non-obviousnesses in the Scala syntax: Watch this talk from Scala Days: http://www.parleys.com/play/53a7d2c7e4b0543940d9e551/chapter0/about http://www.parleys.com/play/53a7d2c7e4b0543940d9e551/chapter... A language with backwards syntax compatibility will have either constant or deteriorating syntax over time: This requires a cost function for language and library syntax. I define this as being a combination of syntax size, syntax consistency and syntax readability (as measured by learning curve for new developers). Syntax here includes the syntax and interface to features in libraries, not just the core language. Obviously, already existing syntax cannot be improved upon without breaking compatibility. This is bad as long as the existing syntax is not perfect, which is (almost) always. One can add better, additional syntax to mitigate but size and inconsistency will grow and new developers will have to understand the old syntax anyway, so you cannot fix existing bad syntax by adding new replacements. Any new syntax will either adhere to old, bad rules or break consistency with the old, neither of which are optimal. Conclusion: Backwards compatibility means you're fucked. C++'s syntax is bad: This is straddling the line between subjective and objective. I can't imagine any measure by which this is not true. If you want to claim otherwise please remember that extraordinary claims require extraordinary evidence.
    - frowaway001 12y ago
      I object to you claim of Scala developers "not taking backward compatibility so seriously" and the "lax attitude". Just compare Oracle's approach–of letting an employee announce on Twitter that they are changing Generics in Swing, and that people should download a JDK9 build, compile their code and see whether things break–with Scala's approach of automatically and continuously building ~1.000.000 lines of publicly available code against Scala to detect breakages before they happen. Or compare the tools Java/Scala gives you for managing deprecations, both in the library (@deprecated) and external tooling (migration manager). Scala developers go the great lengths to improve and evolve the language while they try to minimize the work needed to move between language versions. See the recent improvements in Eclipse for an example. I also find the comparison with C++ pointless, boring and–to be honest–ridiculous, as well as the remark about "less bad" syntax.
      - tormeh 12y ago
        Oh, yeah, I exaggerate sometimes. Not really planning to stop, honestly. I think Java never breaks compatibility in the core language or standard library, right?
        frowaway001 12y ago
        They started to do that recently.
        ryanobjc 12y ago
        How exactly? You can still -target 1.4 and there hasn't been any removed APIs.
        frowaway001 12y ago
        Incompatible changes: - Ongoing changes to method selection within major and minor releases - Various breakages when generics where introduced - Various breakages when Swing was generified in Java 5, 7 and 9 - Change of visibility or removal of methods caused by security issues - Deprecation and upcoming removal of various methods due to modularization plans
- adamors 12y ago
  That also means that people will never pick it for anything that needs long term development/maintenance.
  - tormeh 12y ago
    They will if they know what's good for them. If not (and I have no doubt that often this is the case) then that's their problem.
  - frowaway001 12y ago
    This assumes that past releases are not maintained, updated and stop existing as soon as a new version is released. None of this is true. Java people do the same thing: They pick a version and stay with it, and migrate if/when it makes sense for their project.
    - ryanobjc 12y ago
      Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. 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?
      - adriaanm 12y ago
        There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.
        kasey_junk 12y ago
        Scala 2.9 is 3 years old. That is a trivially short amount of time.
        frowaway001 12y ago
        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). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
- bad_user 12y ago
  Very relevant is the timing. The first stable version of Scala 2.12 won't be released until Jan 2016. Also, no source compatibility breakage is considered without a migration tool available, also mentioned in the timeline.
  - benjaminjackman 12y ago
    Migration tools aren't panacea they don't fix stackoverflow answers, pdfs, blog posts, existing tutorials, talks, slides, examples, mailing list posts, or irc logs. They also require locking a codebase and making massive changes all at once. It should be preferred to just add them as -Xlint:XXX warning / -Xlanguage:XXX features that can be opted into, along with a tool that will automatically update the code to best practices. This way no legacy codebase has to undergo the massive cross-cutting refactor required when running a migration tool, instead they can opt into the features they want, and new users copy pasting in code will see that code work.
    - modersky 12y ago
      I completely agree. We'll try to make the boundary between old and new versions as flexible as possible and both lint tools and language imports will be an important part of that. Note also that the rewritings we consider are in their majority rather trivial. E.g. insert a ": Unit = " every time you used procedure syntax, or wrap every XML literal in xml"""...""". The one thing that scares me a bit is experimental features. These will not port cleanly, and my advice right now would be: If you want your code to survive transitions without major rewrites, don't use experimental features. They might be tempting, but they can well be a trap down the line.
- DCKing 12y ago
  Although I agree they have a good attitude towards deprecation and backwards compatibility, I do not believe their progressive attitude works necessarily implies a lax attitute to backwards compatibility. Investigation is underway for more sweeping changes where backwards compatibility can be broken on the fundamental level. This is the Dotty project [1], which will influence development of Scala 3. [1]: https://github.com/lampepfl/dotty https://github.com/lampepfl/dotty
  - virtualwhys 12y ago
    Umm, Scala 3 = Scala "Don Giovani" = Scala 2.14 (backed by Dotty); that's the gist I got from the linked post (thus the DOT calculus reference in this section of the document) A ways away, but they're spelling it out now: der Dotty cometh ;-) Sounds like 2018 if the roadmap plays out as planned. Looks tasty, wish it were more like 2016.
- hackerboos 12y ago
  Scala wasn't adopted by a company I worked for because they didn't take backwards compatibility seriously. I believe they were breaking on point releases at one stage.
  - kev009 12y ago
    I feel like this might be a prophetic litmus test of where to work. Example: Is the company able to handle moving targets, or is the culture so fucked they marry things like JDK 1.4 because they can't handle basic evolution.
    - mrkrwtsn 12y ago
      I disagree. It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. Different organizations have different priorities. Many times new versions give you features that are worth the effort taken to update. In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. It's flawed to say that this means the culture is "fucked up".
      - frowaway001 12y ago
        > It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. How is this different from e. g. Java? Developers pick a version which works for them and stick with it until it makes business sense to upgrade. > In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. How is this the case for Scala?
        kasey_junk 12y ago
        I've been developing Scala full time since 2.7. I have not had a release yet that didn't involve changing code to recompile to each new version. I also have Java projects that were written in pre 1.0 releases that have updated to 1.7 without a single code change. This is due to a different set of priorities. Each of those priorities has different costs and benefits but to act like Scala's lack of backwards compatibility doesn't have a cost is unfair.
- taeric 12y ago
  On the flip side, if all you were used to were systems such as Scala, it would be bloody amazing how documents that were typeset with tex still typeset. Or, any C program I wrote 20+ years ago can still compile and work.
  - kasey_junk 12y ago
    I've definitely written C code that took advantage of specialized compilers and OS calls that would most certainly not work on modern commodity hardware. C portability is all about limiting the features you use after all. If you limit yourself to a small subset of Scala features it has all been backwards compatible as well. (That's not to say, I think that Scala does a good job with backwards compatibility)
    - taeric 12y ago
      How small of a subset are we talking about here? And yeah, I realize it is a bit unfair, as much of the "c language" is not about fancy containers and collections. This is something I still admire in Knuth's tex, though. Having a typesetting language that is effectively "archival" is impressive. I love that I can load up any of the .tex files from his site and they still work, today. Even his cweb language snippets benefit from this. It may seem somewhat odd and cryptic by some modern aesthetics, but it also hasn't been touched in years and still works.
      - kasey_junk 12y ago
        To be honest, it would need to be an extremely small set of Scala code. But, more to the point is that you are glossing over decades worth of discussions, fights & costs associated with C code being compatible from machine to machine, compiler to compiler, and year to year. C got to backwards compatibility via longevity. Scala de-emphasizes backwards compatibility on purpose so it isn't surprising that it isn't good. Tex is built for a very small, constrained, and well known problem space. It isn't surprising that you can get it right faster than a general purpose language. Yet, even Tex has been supplanted even it it's own wheel house.
- Locke1689 12y ago
  I kind of disagree with this. As the most fundamental tool in a programmer's toolbox, I think devs have the right to ask for stability from their language/compiler. A new language version may mean new language features, but it's OK for devs to want to incorporate those features at their own pace, not have the language choose for them. Without a focus on backwards compatibility, this means devs have to choose between bug fixes and perf improvements and new language constructs. This isn't a good place to be in. At the same time, I understand the realization language designers and compiler devs have when they find out they were doing something wrong all along, or that an old feature was simply a special case of a new feature. Sometimes that means syntax breaking changes. It's hard to deal with, as the owner of a product, when you see something which you know could be better, but is held back by existing installs.
  - frowaway001 12y ago
    Well, at least in Scala developers have a choice. You can run the latest Scala compiler and still target a JDK6 runtime. Or use a very old Scala compiler and run it on JDK9 builds. Compare that with e. g. .NET where picking an older compiler potentially locks you into an older .NET version, too. Have a look at all the different CLR, .NET and language versions: It's a huge mess, only increasing with projects like WinRT, and building portable assemblies not being available in all Visual Studio versions until very recently. Of course, the problem is exacerbated by .NET's lackluster dependency management, and I'm not very optimistic that the .NET community is able to build a decent competitor to NuGet to keep it from stagnating, due to "Microsoft products first"-approach of Microsoft shops and Microsoft's inability to contribute to existing open-source projects.
  - deleted 12y ago
    [deleted]
- virtualwhys 12y ago
  Nice backhanded complement, the linked document explicitly mentions the automatic source code migration tool to address backwards compatability with the new Scala version (which, in terms of breaking changes [new collections] won't be coming until 2017 at the earliest). re: linking Scala to C++, Stroustrup can only dream of the linked roadmap for C++
  - tormeh 12y ago
    Well, I love Scala, but it can get confusing sometimes.
- mamcx 12y ago
  I think that attitude is great. I always move the code/libs forward alongside write it, and I a solo developer and code in several languages and maintain code. This work great for example, with obj-c where things are moving fast and all the changes in some ways cut the size of the code. In fact, moving the code forward is very cheap in contrast to stick for too long then eventually the pain is too hard. I learn this when try to move a large codebase from .NET 1 to 2, in one single shoot. Months on this (and back them we are a team). HOWEVER, the idea is mark deprecated things, build bridges and do something like GO that could rewrite/upgrade itself.
- teacup50 12y ago
  I hate that they don't take backwards compatibility seriously. There is an enormous cost to a lack of reliability and consistency in your tools; every time a significantly popular language generates bitrot through an incompatible change, hundreds of thousands of man hours are wasted. I've seen too much perfectly good, well-made, entirely stable code that did not need any changes bitrot -- simply due to a lack of platform care for stability. Ignoring stability is merely a way to optimize for the laziness of the few implementors, as opposed to optimizing for the many users.: If you can't support an API over time, then don't ship it; if you're shipping APIs and language design features that require regular churn, the problem is in your design process. I've got a firm eye on Java 8+ as a route away from Scala.
  - adriaanm 12y ago
    We do take compatibility seriously. Others have given examples in this thread how we do this technically. I don't think any design process can guarantee perfection at first try, hence we prefer steady improvement over stagnation. When we decide it's important to change something, there's advance warning through deprecation.
    - tormeh 12y ago
      I realize I exaggerated by using the word "lax", btw. Not my intention to hurt any feelings. Sorry.
    - teacup50 12y ago
      If you took it seriously, you wouldn't break the language with every major release, and you'd spend more time not shipping things that are obviously poorly thought out. No design process can guarantee perfection at first try, but that means you have to invest the effort to maintain what you produce that's imperfect. Simply accepting that you'll produce garbage is how you produce more garbage. "Stagnation" is what happens to the hundreds of thousands of lines of code in the world that you bitrot with every breaking changes. When you invest more effort in craftsmanship, you're not stagnating the language.
- PopsiclePete 12y ago
  It's a double-edged sword. C++ is C++ partly because the language doesn't change willy-nilly from underneath you. I could probably still compile C++ code from 1996, you can't even compile Scala code from 2012. To you, that's a feature. To me, it's a sign that the language designers don't know what the heck they're doing and are throwing everything at the wall, watching what sticks and what doesn't. I have very little faith in Scala because of this. It's a language that doesn't know what it is now, what it wants to be tomorrow, what it wants to look like to act like...I despise C++ but I'd never, in a million years, start a new project in Scala. I'd have to rewrite it in a year. Maybe once the Scala gurus figure out what they're doing and release some kind of stable "spec", it'd be worth checking out. Until then, it's just a cool toy. On how that's done, look at Go. Go 1 was released over 2 years ago and there have been no backwards-breaking changes yet, nor will there be. That's how you build a community. My 2 cents.
  - frowaway001 12y ago
    Did you just make that up, or is there any actual experience backing up your claims? Sorry, but that just reads like the usual "let's throw some random claims together I have read on the Internet from people who never actually used the language either" which everyone knows by now. Do you have anything worthwhile to add to this discussion?
    - coldtea 12y ago
      >Do you have anything worthwhile to add to this discussion? Do you? For one, he mentions what he wrote is just his "2 cents", and he is entitled to his opinion. Second, he provides factually true statements to support his opinion, e.g that you need to make syntax changes to compile previous Scala code on later versions of the Scala compiler. You might agree or not agree with him, but he states what he believes, and supports it with arguments and counter-examples (e.g the Go reference). OTOH, besides the insult to the parent, your comment is content-free.
      - frowaway001 12y ago
        >> Do you have anything worthwhile to add to this discussion? > Do you? I already have? > he is entitled to his opinion This doesn't mean he should be immune to scrutiny when making claims which are intended to drag the discussion into boring flame-wars. > he provides factually true statements to support his opinion Like "I'd have to rewrite it in a year."? Have a look at how long Scala releases are supported, both officially and with commercial support. That statement is just factually false. Apart from that it's the usual comparison with C++ which don't provide any interesting insight except showing that the author has not much clue about the topic. > release some kind of stable "spec" Scala, like Java or C++, are evolving languages. While having some kind of mechanically checked spec (which is what Scala developers are working on) would be great, we have to accept that almost no language manages to do that. All three languages (and most other languages as well) have compilers which differ from the spec in some cases, and specs which leave out important details important to compiler implementations. I don't see the reason for singling out one language. > Go [...] Well, it's not kind of hard to have a stable language (let's just ignore all the changes in Go which broke programs for a minute (Go's runtime and its "GC" are probably the largest offenders)) if it could have been rightfully called obsolete in the 1970ies. What's missing in this comparison is the level of usefulness achieved by the language. As an example, whitespace and brainfuck have probably been stable right after their creation, it's just they are no that useful to solve today's problems. More expressive language are harder to keep stable, but it's not that you don't gain anything in return.
thescrewdriver 12y ago
Summary: Scala 2.12: Focus on leveraging JDK8 features and interop Scala next: Collections framework simplification Scala next next: Language improvements
- CmonDev 12y ago
  It's a shame they are not focusing on the most lagging bit - CLR/Mono support.
  - thescrewdriver 12y ago
    There doesn't seem to be much demand or interest for that overall. They recently discontinued the .NET support. Almost everyone was using it on the JVM. Any specific reason why you'd need CLR instead of the JVM?
programminggeek 12y ago
It feels like a faster complier is still a ways out. That's really too bad.
- kasey_junk 12y ago
  I really do not understand this continued complaint about Scala compilation. I've been developing in Scala for over 4 years full time and have never had compile times be the major bottle neck in my workflow. Between incremental compilation and good modularity test times dominate my "waiting" cycles and that is on the order of seconds. Hardly noticeable given my think/type loop is much slower than that. I have any number of complaints about Scala but compile times is way down on my list. I'm generally interested in what sort of compiler performance is expected. That said, it might be a generational difference as I've worked on projects where full compiles happen overnight...
  - harryh 12y ago
    How much code are you compiling? At Foursquare (with 100s of thousands of lines in our bigger servers) compilation times are awful. We're solving this by better modularizing, but it's a long journey.
    - kasey_junk 12y ago
      Admittedly, the largest Scala code base I've worked on was ~200K LOC size which is pretty small. But even that under a full compile/test cycle we were talking minutes in the worst case, dominated by test time. Incremental compile/test cycles were measured in 10s of seconds. What do you mean when you say "awful" and how does that compare to your test cycles?
    - oelang 12y ago
      It's too easy in scala to create a giant mudball codebase where every file depends on half the project. Managing the compile graph is almost impossible when you have 20 hackers on the same codebase. Sometimes I wish that scala had some compiler-flag that signals these problems, maybe a restricted mode or something with annotations.
juliangamble 12y ago
Some context - the lead developer on the Scala Compiler, Paul Phillips, went slightly AWOL last year, and presented the talk "We're doing it all wrong" https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg http://www.slideshare.net/extempore/keynote-pnw-scala-2013 http://www.slideshare.net/extempore/keynote-pnw-scala-2013 He still seems slightly burnt by the whole thing: https://twitter.com/extempore2/status/493633548994097154 https://twitter.com/extempore2/status/493633548994097154 Other critiques of Scala collections have been made with the Typelevel library https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz which aims to fix these issues. This post, 'Next Steps', seems to have come out of Martin Odersky's response to the situation. I commend him for taking practical and thought out action.
benjaminjackman 12y ago
I really wish they'd stop grouping procedure syntax in with things like xml literals and forSome syntax. Procedure syntax is still used a majority of the time when able judging by the commits on github and it has several benefits whereas the others are rarely if ever used. Removing it while leaving things like postfix operators in, but behind a -feature flag is senseless.
- frowaway001 12y ago
  Compared to the other features you mentioned, procedures are actively harmful. That's the reason why they are (slowly) going away.
  - kasey_junk 12y ago
    In what possible way is the procedural syntax harmful?
    - frowaway001 12y ago
      People want to write methods, but forget the =. In the worst case, the result is silently swallowed and the bug manifests itself only later at the use-site, not at the point of declaration.
      - kasey_junk 12y ago
        The exact same complaint could be registered about any function that doesn't have an explicit return type, yet there is no move to make that mandatory.
        frowaway001 12y ago
        No. If the method has no explicit return type, it is inferred. It's really reducing the usefulness of type inference if a trivial error can flip the switch from "the return type is computed from the last expression of the method body" to "the method body is ignored completely, and () is returned instead". Apart from that, there is a move to make explicit return types mandatory in some places; for instance when defining implicit conversions or when declaring abstract methods in traits.

95 points by jfb 12y ago

I love how they don't take backwards compatibility so seriously. A lax attitude to backwards compatibility means they can actually have the syntax get less bad over time, instead of becoming C++. Scala does have some less-than-obvious things that need to be fixed.

frowaway001 12y ago
I like how most of the sentences in this comment try to present some questionable claims as facts, with the usual comparison with C++ casually thrown in.
- nmrm 12y ago
  The #1 item on Aida specifically mentions breaking backward compatibility is an option. The #1 item on Don Giovanni is "clean up syntax".
  - deleted 12y ago
    [deleted]
- tormeh 12y ago
  I'm not a fan of rigor; I prefer to communicate in a short, simple way and let people fill in the blanks. But here's some better argumentation: There are non-obviousnesses in the Scala syntax: Watch this talk from Scala Days: http://www.parleys.com/play/53a7d2c7e4b0543940d9e551/chapter0/about http://www.parleys.com/play/53a7d2c7e4b0543940d9e551/chapter... A language with backwards syntax compatibility will have either constant or deteriorating syntax over time: This requires a cost function for language and library syntax. I define this as being a combination of syntax size, syntax consistency and syntax readability (as measured by learning curve for new developers). Syntax here includes the syntax and interface to features in libraries, not just the core language. Obviously, already existing syntax cannot be improved upon without breaking compatibility. This is bad as long as the existing syntax is not perfect, which is (almost) always. One can add better, additional syntax to mitigate but size and inconsistency will grow and new developers will have to understand the old syntax anyway, so you cannot fix existing bad syntax by adding new replacements. Any new syntax will either adhere to old, bad rules or break consistency with the old, neither of which are optimal. Conclusion: Backwards compatibility means you're fucked. C++'s syntax is bad: This is straddling the line between subjective and objective. I can't imagine any measure by which this is not true. If you want to claim otherwise please remember that extraordinary claims require extraordinary evidence.
  - frowaway001 12y ago
    I object to you claim of Scala developers "not taking backward compatibility so seriously" and the "lax attitude". Just compare Oracle's approach–of letting an employee announce on Twitter that they are changing Generics in Swing, and that people should download a JDK9 build, compile their code and see whether things break–with Scala's approach of automatically and continuously building ~1.000.000 lines of publicly available code against Scala to detect breakages before they happen. Or compare the tools Java/Scala gives you for managing deprecations, both in the library (@deprecated) and external tooling (migration manager). Scala developers go the great lengths to improve and evolve the language while they try to minimize the work needed to move between language versions. See the recent improvements in Eclipse for an example. I also find the comparison with C++ pointless, boring and–to be honest–ridiculous, as well as the remark about "less bad" syntax.
    - tormeh 12y ago
      Oh, yeah, I exaggerate sometimes. Not really planning to stop, honestly. I think Java never breaks compatibility in the core language or standard library, right?
      - frowaway001 12y ago
        They started to do that recently.
        ryanobjc 12y ago
        How exactly? You can still -target 1.4 and there hasn't been any removed APIs.
        frowaway001 12y ago
        Incompatible changes: - Ongoing changes to method selection within major and minor releases - Various breakages when generics where introduced - Various breakages when Swing was generified in Java 5, 7 and 9 - Change of visibility or removal of methods caused by security issues - Deprecation and upcoming removal of various methods due to modularization plans
adamors 12y ago
That also means that people will never pick it for anything that needs long term development/maintenance.
- tormeh 12y ago
  They will if they know what's good for them. If not (and I have no doubt that often this is the case) then that's their problem.
- frowaway001 12y ago
  This assumes that past releases are not maintained, updated and stop existing as soon as a new version is released. None of this is true. Java people do the same thing: They pick a version and stay with it, and migrate if/when it makes sense for their project.
  - ryanobjc 12y ago
    Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. 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?
    - adriaanm 12y ago
      There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.
      - kasey_junk 12y ago
        Scala 2.9 is 3 years old. That is a trivially short amount of time.
        frowaway001 12y ago
        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). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
bad_user 12y ago
Very relevant is the timing. The first stable version of Scala 2.12 won't be released until Jan 2016. Also, no source compatibility breakage is considered without a migration tool available, also mentioned in the timeline.
- benjaminjackman 12y ago
  Migration tools aren't panacea they don't fix stackoverflow answers, pdfs, blog posts, existing tutorials, talks, slides, examples, mailing list posts, or irc logs. They also require locking a codebase and making massive changes all at once. It should be preferred to just add them as -Xlint:XXX warning / -Xlanguage:XXX features that can be opted into, along with a tool that will automatically update the code to best practices. This way no legacy codebase has to undergo the massive cross-cutting refactor required when running a migration tool, instead they can opt into the features they want, and new users copy pasting in code will see that code work.
  - modersky 12y ago
    I completely agree. We'll try to make the boundary between old and new versions as flexible as possible and both lint tools and language imports will be an important part of that. Note also that the rewritings we consider are in their majority rather trivial. E.g. insert a ": Unit = " every time you used procedure syntax, or wrap every XML literal in xml"""...""". The one thing that scares me a bit is experimental features. These will not port cleanly, and my advice right now would be: If you want your code to survive transitions without major rewrites, don't use experimental features. They might be tempting, but they can well be a trap down the line.
DCKing 12y ago
Although I agree they have a good attitude towards deprecation and backwards compatibility, I do not believe their progressive attitude works necessarily implies a lax attitute to backwards compatibility. Investigation is underway for more sweeping changes where backwards compatibility can be broken on the fundamental level. This is the Dotty project [1], which will influence development of Scala 3. [1]: https://github.com/lampepfl/dotty https://github.com/lampepfl/dotty
- virtualwhys 12y ago
  Umm, Scala 3 = Scala "Don Giovani" = Scala 2.14 (backed by Dotty); that's the gist I got from the linked post (thus the DOT calculus reference in this section of the document) A ways away, but they're spelling it out now: der Dotty cometh ;-) Sounds like 2018 if the roadmap plays out as planned. Looks tasty, wish it were more like 2016.
hackerboos 12y ago
Scala wasn't adopted by a company I worked for because they didn't take backwards compatibility seriously. I believe they were breaking on point releases at one stage.
- kev009 12y ago
  I feel like this might be a prophetic litmus test of where to work. Example: Is the company able to handle moving targets, or is the culture so fucked they marry things like JDK 1.4 because they can't handle basic evolution.
  - mrkrwtsn 12y ago
    I disagree. It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. Different organizations have different priorities. Many times new versions give you features that are worth the effort taken to update. In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. It's flawed to say that this means the culture is "fucked up".
    - frowaway001 12y ago
      > It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. How is this different from e. g. Java? Developers pick a version which works for them and stick with it until it makes business sense to upgrade. > In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. How is this the case for Scala?
      - kasey_junk 12y ago
        I've been developing Scala full time since 2.7. I have not had a release yet that didn't involve changing code to recompile to each new version. I also have Java projects that were written in pre 1.0 releases that have updated to 1.7 without a single code change. This is due to a different set of priorities. Each of those priorities has different costs and benefits but to act like Scala's lack of backwards compatibility doesn't have a cost is unfair.
taeric 12y ago
On the flip side, if all you were used to were systems such as Scala, it would be bloody amazing how documents that were typeset with tex still typeset. Or, any C program I wrote 20+ years ago can still compile and work.
- kasey_junk 12y ago
  I've definitely written C code that took advantage of specialized compilers and OS calls that would most certainly not work on modern commodity hardware. C portability is all about limiting the features you use after all. If you limit yourself to a small subset of Scala features it has all been backwards compatible as well. (That's not to say, I think that Scala does a good job with backwards compatibility)
  - taeric 12y ago
    How small of a subset are we talking about here? And yeah, I realize it is a bit unfair, as much of the "c language" is not about fancy containers and collections. This is something I still admire in Knuth's tex, though. Having a typesetting language that is effectively "archival" is impressive. I love that I can load up any of the .tex files from his site and they still work, today. Even his cweb language snippets benefit from this. It may seem somewhat odd and cryptic by some modern aesthetics, but it also hasn't been touched in years and still works.
    - kasey_junk 12y ago
      To be honest, it would need to be an extremely small set of Scala code. But, more to the point is that you are glossing over decades worth of discussions, fights & costs associated with C code being compatible from machine to machine, compiler to compiler, and year to year. C got to backwards compatibility via longevity. Scala de-emphasizes backwards compatibility on purpose so it isn't surprising that it isn't good. Tex is built for a very small, constrained, and well known problem space. It isn't surprising that you can get it right faster than a general purpose language. Yet, even Tex has been supplanted even it it's own wheel house.
Locke1689 12y ago
I kind of disagree with this. As the most fundamental tool in a programmer's toolbox, I think devs have the right to ask for stability from their language/compiler. A new language version may mean new language features, but it's OK for devs to want to incorporate those features at their own pace, not have the language choose for them. Without a focus on backwards compatibility, this means devs have to choose between bug fixes and perf improvements and new language constructs. This isn't a good place to be in. At the same time, I understand the realization language designers and compiler devs have when they find out they were doing something wrong all along, or that an old feature was simply a special case of a new feature. Sometimes that means syntax breaking changes. It's hard to deal with, as the owner of a product, when you see something which you know could be better, but is held back by existing installs.
- frowaway001 12y ago
  Well, at least in Scala developers have a choice. You can run the latest Scala compiler and still target a JDK6 runtime. Or use a very old Scala compiler and run it on JDK9 builds. Compare that with e. g. .NET where picking an older compiler potentially locks you into an older .NET version, too. Have a look at all the different CLR, .NET and language versions: It's a huge mess, only increasing with projects like WinRT, and building portable assemblies not being available in all Visual Studio versions until very recently. Of course, the problem is exacerbated by .NET's lackluster dependency management, and I'm not very optimistic that the .NET community is able to build a decent competitor to NuGet to keep it from stagnating, due to "Microsoft products first"-approach of Microsoft shops and Microsoft's inability to contribute to existing open-source projects.
- deleted 12y ago
  [deleted]
virtualwhys 12y ago
Nice backhanded complement, the linked document explicitly mentions the automatic source code migration tool to address backwards compatability with the new Scala version (which, in terms of breaking changes [new collections] won't be coming until 2017 at the earliest). re: linking Scala to C++, Stroustrup can only dream of the linked roadmap for C++
- tormeh 12y ago
  Well, I love Scala, but it can get confusing sometimes.
mamcx 12y ago
I think that attitude is great. I always move the code/libs forward alongside write it, and I a solo developer and code in several languages and maintain code. This work great for example, with obj-c where things are moving fast and all the changes in some ways cut the size of the code. In fact, moving the code forward is very cheap in contrast to stick for too long then eventually the pain is too hard. I learn this when try to move a large codebase from .NET 1 to 2, in one single shoot. Months on this (and back them we are a team). HOWEVER, the idea is mark deprecated things, build bridges and do something like GO that could rewrite/upgrade itself.
teacup50 12y ago
I hate that they don't take backwards compatibility seriously. There is an enormous cost to a lack of reliability and consistency in your tools; every time a significantly popular language generates bitrot through an incompatible change, hundreds of thousands of man hours are wasted. I've seen too much perfectly good, well-made, entirely stable code that did not need any changes bitrot -- simply due to a lack of platform care for stability. Ignoring stability is merely a way to optimize for the laziness of the few implementors, as opposed to optimizing for the many users.: If you can't support an API over time, then don't ship it; if you're shipping APIs and language design features that require regular churn, the problem is in your design process. I've got a firm eye on Java 8+ as a route away from Scala.
- adriaanm 12y ago
  We do take compatibility seriously. Others have given examples in this thread how we do this technically. I don't think any design process can guarantee perfection at first try, hence we prefer steady improvement over stagnation. When we decide it's important to change something, there's advance warning through deprecation.
  - tormeh 12y ago
    I realize I exaggerated by using the word "lax", btw. Not my intention to hurt any feelings. Sorry.
  - teacup50 12y ago
    If you took it seriously, you wouldn't break the language with every major release, and you'd spend more time not shipping things that are obviously poorly thought out. No design process can guarantee perfection at first try, but that means you have to invest the effort to maintain what you produce that's imperfect. Simply accepting that you'll produce garbage is how you produce more garbage. "Stagnation" is what happens to the hundreds of thousands of lines of code in the world that you bitrot with every breaking changes. When you invest more effort in craftsmanship, you're not stagnating the language.
PopsiclePete 12y ago
It's a double-edged sword. C++ is C++ partly because the language doesn't change willy-nilly from underneath you. I could probably still compile C++ code from 1996, you can't even compile Scala code from 2012. To you, that's a feature. To me, it's a sign that the language designers don't know what the heck they're doing and are throwing everything at the wall, watching what sticks and what doesn't. I have very little faith in Scala because of this. It's a language that doesn't know what it is now, what it wants to be tomorrow, what it wants to look like to act like...I despise C++ but I'd never, in a million years, start a new project in Scala. I'd have to rewrite it in a year. Maybe once the Scala gurus figure out what they're doing and release some kind of stable "spec", it'd be worth checking out. Until then, it's just a cool toy. On how that's done, look at Go. Go 1 was released over 2 years ago and there have been no backwards-breaking changes yet, nor will there be. That's how you build a community. My 2 cents.
- frowaway001 12y ago
  Did you just make that up, or is there any actual experience backing up your claims? Sorry, but that just reads like the usual "let's throw some random claims together I have read on the Internet from people who never actually used the language either" which everyone knows by now. Do you have anything worthwhile to add to this discussion?
  - coldtea 12y ago
    >Do you have anything worthwhile to add to this discussion? Do you? For one, he mentions what he wrote is just his "2 cents", and he is entitled to his opinion. Second, he provides factually true statements to support his opinion, e.g that you need to make syntax changes to compile previous Scala code on later versions of the Scala compiler. You might agree or not agree with him, but he states what he believes, and supports it with arguments and counter-examples (e.g the Go reference). OTOH, besides the insult to the parent, your comment is content-free.
    - frowaway001 12y ago
      >> Do you have anything worthwhile to add to this discussion? > Do you? I already have? > he is entitled to his opinion This doesn't mean he should be immune to scrutiny when making claims which are intended to drag the discussion into boring flame-wars. > he provides factually true statements to support his opinion Like "I'd have to rewrite it in a year."? Have a look at how long Scala releases are supported, both officially and with commercial support. That statement is just factually false. Apart from that it's the usual comparison with C++ which don't provide any interesting insight except showing that the author has not much clue about the topic. > release some kind of stable "spec" Scala, like Java or C++, are evolving languages. While having some kind of mechanically checked spec (which is what Scala developers are working on) would be great, we have to accept that almost no language manages to do that. All three languages (and most other languages as well) have compilers which differ from the spec in some cases, and specs which leave out important details important to compiler implementations. I don't see the reason for singling out one language. > Go [...] Well, it's not kind of hard to have a stable language (let's just ignore all the changes in Go which broke programs for a minute (Go's runtime and its "GC" are probably the largest offenders)) if it could have been rightfully called obsolete in the 1970ies. What's missing in this comparison is the level of usefulness achieved by the language. As an example, whitespace and brainfuck have probably been stable right after their creation, it's just they are no that useful to solve today's problems. More expressive language are harder to keep stable, but it's not that you don't gain anything in return.

thescrewdriver 12y ago

Summary: Scala 2.12: Focus on leveraging JDK8 features and interop Scala next: Collections framework simplification Scala next next: Language improvements

CmonDev 12y ago
It's a shame they are not focusing on the most lagging bit - CLR/Mono support.
- thescrewdriver 12y ago
  There doesn't seem to be much demand or interest for that overall. They recently discontinued the .NET support. Almost everyone was using it on the JVM. Any specific reason why you'd need CLR instead of the JVM?

programminggeek 12y ago

It feels like a faster complier is still a ways out. That's really too bad.

kasey_junk 12y ago
I really do not understand this continued complaint about Scala compilation. I've been developing in Scala for over 4 years full time and have never had compile times be the major bottle neck in my workflow. Between incremental compilation and good modularity test times dominate my "waiting" cycles and that is on the order of seconds. Hardly noticeable given my think/type loop is much slower than that. I have any number of complaints about Scala but compile times is way down on my list. I'm generally interested in what sort of compiler performance is expected. That said, it might be a generational difference as I've worked on projects where full compiles happen overnight...
- harryh 12y ago
  How much code are you compiling? At Foursquare (with 100s of thousands of lines in our bigger servers) compilation times are awful. We're solving this by better modularizing, but it's a long journey.
  - kasey_junk 12y ago
    Admittedly, the largest Scala code base I've worked on was ~200K LOC size which is pretty small. But even that under a full compile/test cycle we were talking minutes in the worst case, dominated by test time. Incremental compile/test cycles were measured in 10s of seconds. What do you mean when you say "awful" and how does that compare to your test cycles?
  - oelang 12y ago
    It's too easy in scala to create a giant mudball codebase where every file depends on half the project. Managing the compile graph is almost impossible when you have 20 hackers on the same codebase. Sometimes I wish that scala had some compiler-flag that signals these problems, maybe a restricted mode or something with annotations.

juliangamble 12y ago

Some context - the lead developer on the Scala Compiler, Paul Phillips, went slightly AWOL last year, and presented the talk "We're doing it all wrong" https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=TS1lpKBMkgg http://www.slideshare.net/extempore/keynote-pnw-scala-2013 http://www.slideshare.net/extempore/keynote-pnw-scala-2013 He still seems slightly burnt by the whole thing: https://twitter.com/extempore2/status/493633548994097154 https://twitter.com/extempore2/status/493633548994097154 Other critiques of Scala collections have been made with the Typelevel library https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz which aims to fix these issues. This post, 'Next Steps', seems to have come out of Martin Odersky's response to the situation. I commend him for taking practical and thought out action.

benjaminjackman 12y ago

I really wish they'd stop grouping procedure syntax in with things like xml literals and forSome syntax. Procedure syntax is still used a majority of the time when able judging by the commits on github and it has several benefits whereas the others are rarely if ever used. Removing it while leaving things like postfix operators in, but behind a -feature flag is senseless.

frowaway001 12y ago
Compared to the other features you mentioned, procedures are actively harmful. That's the reason why they are (slowly) going away.
- kasey_junk 12y ago
  In what possible way is the procedural syntax harmful?
  - frowaway001 12y ago
    People want to write methods, but forget the =. In the worst case, the result is silently swallowed and the bug manifests itself only later at the use-site, not at the point of declaration.
    - kasey_junk 12y ago
      The exact same complaint could be registered about any function that doesn't have an explicit return type, yet there is no move to make that mandatory.
      - frowaway001 12y ago
        No. If the method has no explicit return type, it is inferred. It's really reducing the usefulness of type inference if a trivial error can flip the switch from "the return type is computed from the last expression of the method body" to "the method body is ignored completely, and () is returned instead". Apart from that, there is a move to make explicit return types mandatory in some places; for instance when defining implicit conversions or when declaring abstract methods in traits.