12 ms·

Scala founder: Language due for 'fundamental rethink'

174 points by snydeq 12y ago

noelwelsh 12y ago
It's reassuring to see that the various groups working on Scala seem to have the same broad goal in mind. I also think it is important to not let the language ossify due to legacy -- which is the problem that kills many languages.
- Avshalom 12y ago
  Outside of maybe Fortran and Cobol I can't think of anything that was A)alive enough to be killed B)killed by ossification.
  - pjmlp 12y ago
    And even those have modern standards. Object Cobol anyone?
    - Avshalom 12y ago
      Honestly i 'm just guessing on Fortran and COBOL. I wasn't there when they lost prominence. I just know that no other languages actually lost significant amounts of popularity for not changing (java? Its maybe less popular but calling it dead is not even wrong).
  - rch 12y ago
    > Each new release of Delphi attempts to keep as much backwards compatibility as possible to allow developers to continue to use existing code without incompatibility of interfaces or functionality. https://en.wikipedia.org/wiki/Delphi_(programming_language) https://en.wikipedia.org/wiki/Delphi_(programming_language)
    - Avshalom 12y ago
      I'm pretty sure Delphi died from having to compete with essentially free C# and its better integration with Microsoft's ecosystem. And a little bit from the shifting of the overton window away from paying for languages. And mismanagement of Borland/Inprise. And about a dozen other factors before "lack of (breaking) change in the language".
      - Roboprog 12y ago
        It's 1996. Java runs on Linux, Delphi doesn't. Java also runs where Delphi runs. Java is free. Java 1.1 with inner classes looks much like recursive blocks in Pascal (albeit without procedural types -- function pointers to C folks). THE END. (sadly, as I really liked Borland Pascal)
  - judk 12y ago
    Java isn't dead, but it suffered greatly during the hibernation years starting with the Oracle takeover.
  - VLM 12y ago
    "killed" might be a bit strong, but the overall story of "stop working on perl 5 in favor of working on perl 6" contains some aspects of the concept.
mjburgess 12y ago
What a confused interview. If the audience is for people who are interested in knowing scala's timeline then saying "isnt Java 8 functional now because it has lambdas" is either dumb or trying to be dumb on behalf of a java audience who doesnt care about the scala timeline.
- mseepgood 12y ago
  Or "another language that's becoming popular, Node.js"
  - _random_ 12y ago
    Lol - "language", it's not even a platform.
    - seanmcdirmid 12y ago
      Libraries, frameworks, and languages are actually quite similar; it was long ago that when people said "Ruby" they actually meant "RoR".
- acjohnson55 12y ago
  I agree. It hardly sheds any light on what's really going on in the Scala community or why.
bubblicious 12y ago
I'm really hoping that functional languages will evolve in a way that they become more readable at a glance.
- EdwardDiego 12y ago
  Scala can be as readable or as unreadable as you like. Which is the problem with using Scala in a corporate environment, it can become a terrible weapon in the hands of a bad developer.
  - seanmcdirmid 12y ago
    You also have to decide whether to use scala as a functional language or as a better java. Each approach has its merits and drawbacks.
    - judk 12y ago
      Do you think Scala could succeed with a "Scala--" fork: "Java, the good parts". Just a few things like type inference and implicits and case classes would be enough to make Java devs drool without getting scared by FP or performance scares.
      - frowaway001 12y ago
        That exists: http://en.wikipedia.org/wiki/Pizza_%28programming_language%29 http://en.wikipedia.org/wiki/Pizza_%28programming_language%2...
      - seanmcdirmid 12y ago
        You could totally use Scala as a language without the laziness, which can be quite a pain when doing perf-sensitive work. Traits are also a huge deal. I don't think the community wants to go in that direction though. Who Scala attracted was a lot of FP programmers (Haskell/ML) who wanted to do work on the JVM; not Java programmers looking for a better alternative to Java on the JVM. So is life.
_random_ 12y ago
"Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have." Very aligned with my opinion. I would add that having strong static type system with opt-in dynamic types system (syntax integrated) adds even more power (e.g. C#).
cies 12y ago
> Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have. I tend to disagree. OOP can borrow some FP stuff (as we see with map/each/select/reject in Ruby for instance, or lambda's in Java); or to take it broader: imperative can borrow some from declarative. But "fusing" the two will cause FP's ease-of-reasoning ("just functions and data structures") to be lost. On top of that, when using a strictly typed discipline (like Scala does), the types will become really messy. So when it comes to FP, I like it pure-and-typed (a la Haskell), or untyped (like the Lisps), but not mixed-paradigm. When it comes to OOP/imperative I like to mix in as much of FP/declarative as makes sense (like Ruby does for instance).
- seanmcdirmid 12y ago
  I agree with this, but I always used scala as a OO language mixed with FP features. I prefer OO, but many in the scala community were adamantly on the FP side (7 years ago, not sure today). About OO: subtyping leads to semi unification which really complicated type inference. I'm beginning to think it might not be a good idea to combine FP unified features with OO semi unified features.
  - cies 12y ago
    > I always used scala as a OO language mixed with FP features Good point! Must admit that I did not write a lot of Scala, but I always approached it from the FP side :)
- pjmlp 12y ago
  So you don't use type classes in Haskell? Neither touch F# or OCaml. Nor CLOS in Lisps.
  - cynicalkane 12y ago
    A major advantage of typeclass polymorphism vs dynamic polymorphism is that typeclasses enable parameteric polymorphism, and parameteric polymorphism enables reasoning that is lost if types can "pretend" to be a supertype. For instance, in Haskell you can prove a functor instance has at most one implementation (if we disallow diverging values), uniquely given by fmap id === id. GHC can automatically derive it for you. If you have dynamic polymorphism this is lost because now you can have "nonuniform" functor instances that behave differently for different types while still satisfying the functor laws. More generally, parameteric polymorphism eliminates a large number of "behavior surprises" that can lurk in OO code. And with existential types I never find myself missing dynamic polymorphism. Similarly, in Clojure, if I find myself using dynamic behavior, it's either to interact with Java or as a hacky version of parameteric behavior.
cies 12y ago
"The language is the code's biggest API" -- my own words. Breaking that API will result in a new language. Scala, like several other languages (JS, PHP, Perl), has had very little time to iterate on it's syntax before it got widely used. All these languages want/need to make breaking changes to their syntax, at which point they are at risk of becoming fragmented. Python3 was not even so much different, still it was (and still is) a hard upgrade for the community. I really hope Scala manages though, it's the largest FP-on-JVM community I guess, so good luck!
- MetaCosm 12y ago
  Well -- they have the Python 3 disaster to learn from... you can't break backwards compatibility for minor gains -- if you are going to break it -- break everything you must and make the new thing much better -- half measures in this regard suck.
  - hippiehippo 12y ago
    Python is a dynamic language and a compiler can't do much in helping you move from 2 to 3. You really need good test coverage.
    - stcredzero 12y ago
      Dynamic language notwithstanding, the transition was badly designed, in terms of being supportable by automation and providing a cost/benefit motivation for upgrade. With something like that, pretty good = disastrously inadequate.
  - Pacabel 12y ago
    It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take. Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point. Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language. Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless. Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose. The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that. The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption. Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.
matwood 12y ago
With the release of Java 8 I wonder if Scala is getting squeezed from both sides. Java 8 on one and Clojure on the other.
- frostmatthew 12y ago
  Relevant: Will Java 8 Kill Scala?[1] (spoiler: Betteridge's law applies) [1]http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/ http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/
  - pjmlp 12y ago
    Depends if the question is targeted to startups using the JVM or the classical bureaucratic enterprise.
- virtualwhys 12y ago
  Unlikely, Clojure is very much its own thing, won't draw those that are drawn to Scala (rich type system, (G)ADTs, performance, etc.). That branch of potential adoption is minisicule anyway (even compared to Scala which relative to Java is itself tiny). So, the elephant in the room is indeed Java 8. Will Scala at long last be killed? Perhaps, but highly unlikely, Scala lives and dies on its ecosystem (Akka, Play, Spark, Spire, Spray, etc.) which are seeing ever increasing enterprise adoption. If anything Java 8 and the JVM improvements made and coming will aid all languages on the JVM that are different enough from Java 8+, which Scala, Ceylon, and of course, Clojure, are. The only JVM language made vulnerable by Java 8 is, IMO, Kotlin.
  - pps 12y ago
    Clojure is becoming increasingly popular in banks in the UK. (as I heard from trusted person)
    - seanmcdirmid 12y ago
      What's up with the UK? Scala is also becoming increasingly popular in banks in the UK (as I heard from trusted persons). CLOS, Smalltalk, and Objective C (before it was cool) were for a long time very popular on Wallstreet.
zak_mc_kracken 12y ago
Funny, when I read the headline, I thought this was referring to Paul Phillips saying that "Scala is unfixable" [1] in the other thread. He's also a Scala founder and he's also saying the language needs a fundamental rethink. Interesting how the interpretation can vary. [1] https://news.ycombinator.com/item?id=8277626 https://news.ycombinator.com/item?id=8277626
- TheDom 12y ago
  Paul is not a "Scala founder". Martin Odersky started to create Scala, the language, by himself 10 years ago. Typesafe, the company around it, was founded 5 years ago and Paul was one of the co-founders.
stevewepay 12y ago
Are there any risks to adopting Scala as a language for a project knowing that it will change over the next few years? It sounds like as opposed to an evolution, they are going to change the language itself, which sounds like backwards incompatibility and refactors within a few short years if you don't want to be considered legacy.
- eplanit 12y ago
  If stable longevity for your project's implementation is important (as your question implies), then I think Scala does present additional risk (relative to stable/mainstream languages). It sounds to me, too, that they are thinking of changing fundamentals in the language/system. This could lead to something like the Python2vs3 scenario for a while. If you base on current Scala, you might (likely) later find yourself doing either a re-write, or being relegated to a "compatibility" library. You're wise to ask.
- frowaway001 12y ago
  No, not really. There might be a few changes, but probably nothing which can't be fixed automatically by a tool/IDE. (They are investing in that currently.) Additionally, if your code compiles with version X without warnings, it should compile with version X+1, too. (Otherwise that would be a bug.) Apart from that, stable versions are supported for a long time, so just like in Java you can migrate when you feel comfortable with it.
- acjohnson55 12y ago
  It depends on what you're doing. If you're really pushing forward with experimental features, sure, there's some risk. But if you're using common libraries, you probably have more to worry about staying up to date with the library interfaces than the language changes.
tel 12y ago
I find Odersky's comments on Swift very apt. I think both Scala and Swift are aimed at being mergers between FP and existing OO systems and both of them feel a little warty for the effort. I really applaud trying to merge the benefits of FP and OO. I think it's going to be a much larger and harder project than either Scala or Swift will benefit from, but I'm really glad that they're exploring the design space.
aaronharnly 12y ago
How did Odersky miss Yammer's citing Scala's complexity as a reason for moving away from it? Odersky said: > In terms of complexity, I don't know whether Yammer featured that, but you definitely do hear that a lot [from] many people. The first paragraph (after introductory greetings) of Yammer's letter which explains its action [1]: > Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. [1] https://gist.github.com/anonymous/1406238 https://gist.github.com/anonymous/1406238
- the_af 12y ago
  Indeed. Another example from the fourth paragraph of the letter: "Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. The number of concepts I had to explain to new members of our team for even the simplest usage of a collection was surprising: implicit parameters, builder typeclasses, "operator overloading", return type inference, etc. etc." It seems very clear the language's complexity was a major problem for Yammer.
- tormeh 12y ago
  I wonder if that means Odersky's not really listening to criticism, which would be really bad. EDIT: He does, he just doesn't remember where it's coming from.
VLM 12y ago
Comments on compiler speed as a problem? I find it sometimes to be a bit slow.

174 points by snydeq 12y ago

It's reassuring to see that the various groups working on Scala seem to have the same broad goal in mind. I also think it is important to not let the language ossify due to legacy -- which is the problem that kills many languages.

Avshalom 12y ago
Outside of maybe Fortran and Cobol I can't think of anything that was A)alive enough to be killed B)killed by ossification.
- pjmlp 12y ago
  And even those have modern standards. Object Cobol anyone?
  - Avshalom 12y ago
    Honestly i 'm just guessing on Fortran and COBOL. I wasn't there when they lost prominence. I just know that no other languages actually lost significant amounts of popularity for not changing (java? Its maybe less popular but calling it dead is not even wrong).
- rch 12y ago
  > Each new release of Delphi attempts to keep as much backwards compatibility as possible to allow developers to continue to use existing code without incompatibility of interfaces or functionality. https://en.wikipedia.org/wiki/Delphi_(programming_language) https://en.wikipedia.org/wiki/Delphi_(programming_language)
  - Avshalom 12y ago
    I'm pretty sure Delphi died from having to compete with essentially free C# and its better integration with Microsoft's ecosystem. And a little bit from the shifting of the overton window away from paying for languages. And mismanagement of Borland/Inprise. And about a dozen other factors before "lack of (breaking) change in the language".
    - Roboprog 12y ago
      It's 1996. Java runs on Linux, Delphi doesn't. Java also runs where Delphi runs. Java is free. Java 1.1 with inner classes looks much like recursive blocks in Pascal (albeit without procedural types -- function pointers to C folks). THE END. (sadly, as I really liked Borland Pascal)
- judk 12y ago
  Java isn't dead, but it suffered greatly during the hibernation years starting with the Oracle takeover.
- VLM 12y ago
  "killed" might be a bit strong, but the overall story of "stop working on perl 5 in favor of working on perl 6" contains some aspects of the concept.

mjburgess 12y ago

What a confused interview. If the audience is for people who are interested in knowing scala's timeline then saying "isnt Java 8 functional now because it has lambdas" is either dumb or trying to be dumb on behalf of a java audience who doesnt care about the scala timeline.

mseepgood 12y ago
Or "another language that's becoming popular, Node.js"
- _random_ 12y ago
  Lol - "language", it's not even a platform.
  - seanmcdirmid 12y ago
    Libraries, frameworks, and languages are actually quite similar; it was long ago that when people said "Ruby" they actually meant "RoR".
acjohnson55 12y ago
I agree. It hardly sheds any light on what's really going on in the Scala community or why.

bubblicious 12y ago

I'm really hoping that functional languages will evolve in a way that they become more readable at a glance.

EdwardDiego 12y ago
Scala can be as readable or as unreadable as you like. Which is the problem with using Scala in a corporate environment, it can become a terrible weapon in the hands of a bad developer.
- seanmcdirmid 12y ago
  You also have to decide whether to use scala as a functional language or as a better java. Each approach has its merits and drawbacks.
  - judk 12y ago
    Do you think Scala could succeed with a "Scala--" fork: "Java, the good parts". Just a few things like type inference and implicits and case classes would be enough to make Java devs drool without getting scared by FP or performance scares.
    - frowaway001 12y ago
      That exists: http://en.wikipedia.org/wiki/Pizza_%28programming_language%29 http://en.wikipedia.org/wiki/Pizza_%28programming_language%2...
    - seanmcdirmid 12y ago
      You could totally use Scala as a language without the laziness, which can be quite a pain when doing perf-sensitive work. Traits are also a huge deal. I don't think the community wants to go in that direction though. Who Scala attracted was a lot of FP programmers (Haskell/ML) who wanted to do work on the JVM; not Java programmers looking for a better alternative to Java on the JVM. So is life.

_random_ 12y ago

"Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have." Very aligned with my opinion. I would add that having strong static type system with opt-in dynamic types system (syntax integrated) adds even more power (e.g. C#).

cies 12y ago

> Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have. I tend to disagree. OOP can borrow some FP stuff (as we see with map/each/select/reject in Ruby for instance, or lambda's in Java); or to take it broader: imperative can borrow some from declarative. But "fusing" the two will cause FP's ease-of-reasoning ("just functions and data structures") to be lost. On top of that, when using a strictly typed discipline (like Scala does), the types will become really messy. So when it comes to FP, I like it pure-and-typed (a la Haskell), or untyped (like the Lisps), but not mixed-paradigm. When it comes to OOP/imperative I like to mix in as much of FP/declarative as makes sense (like Ruby does for instance).

seanmcdirmid 12y ago
I agree with this, but I always used scala as a OO language mixed with FP features. I prefer OO, but many in the scala community were adamantly on the FP side (7 years ago, not sure today). About OO: subtyping leads to semi unification which really complicated type inference. I'm beginning to think it might not be a good idea to combine FP unified features with OO semi unified features.
- cies 12y ago
  > I always used scala as a OO language mixed with FP features Good point! Must admit that I did not write a lot of Scala, but I always approached it from the FP side :)
pjmlp 12y ago
So you don't use type classes in Haskell? Neither touch F# or OCaml. Nor CLOS in Lisps.
- cynicalkane 12y ago
  A major advantage of typeclass polymorphism vs dynamic polymorphism is that typeclasses enable parameteric polymorphism, and parameteric polymorphism enables reasoning that is lost if types can "pretend" to be a supertype. For instance, in Haskell you can prove a functor instance has at most one implementation (if we disallow diverging values), uniquely given by fmap id === id. GHC can automatically derive it for you. If you have dynamic polymorphism this is lost because now you can have "nonuniform" functor instances that behave differently for different types while still satisfying the functor laws. More generally, parameteric polymorphism eliminates a large number of "behavior surprises" that can lurk in OO code. And with existential types I never find myself missing dynamic polymorphism. Similarly, in Clojure, if I find myself using dynamic behavior, it's either to interact with Java or as a hacky version of parameteric behavior.

cies 12y ago

"The language is the code's biggest API" -- my own words. Breaking that API will result in a new language. Scala, like several other languages (JS, PHP, Perl), has had very little time to iterate on it's syntax before it got widely used. All these languages want/need to make breaking changes to their syntax, at which point they are at risk of becoming fragmented. Python3 was not even so much different, still it was (and still is) a hard upgrade for the community. I really hope Scala manages though, it's the largest FP-on-JVM community I guess, so good luck!

MetaCosm 12y ago
Well -- they have the Python 3 disaster to learn from... you can't break backwards compatibility for minor gains -- if you are going to break it -- break everything you must and make the new thing much better -- half measures in this regard suck.
- hippiehippo 12y ago
  Python is a dynamic language and a compiler can't do much in helping you move from 2 to 3. You really need good test coverage.
  - stcredzero 12y ago
    Dynamic language notwithstanding, the transition was badly designed, in terms of being supportable by automation and providing a cost/benefit motivation for upgrade. With something like that, pretty good = disastrously inadequate.
- Pacabel 12y ago
  It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take. Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point. Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language. Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless. Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose. The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that. The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption. Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.

matwood 12y ago

With the release of Java 8 I wonder if Scala is getting squeezed from both sides. Java 8 on one and Clojure on the other.

frostmatthew 12y ago
Relevant: Will Java 8 Kill Scala?[1] (spoiler: Betteridge's law applies) [1]http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/ http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/
- pjmlp 12y ago
  Depends if the question is targeted to startups using the JVM or the classical bureaucratic enterprise.
virtualwhys 12y ago
Unlikely, Clojure is very much its own thing, won't draw those that are drawn to Scala (rich type system, (G)ADTs, performance, etc.). That branch of potential adoption is minisicule anyway (even compared to Scala which relative to Java is itself tiny). So, the elephant in the room is indeed Java 8. Will Scala at long last be killed? Perhaps, but highly unlikely, Scala lives and dies on its ecosystem (Akka, Play, Spark, Spire, Spray, etc.) which are seeing ever increasing enterprise adoption. If anything Java 8 and the JVM improvements made and coming will aid all languages on the JVM that are different enough from Java 8+, which Scala, Ceylon, and of course, Clojure, are. The only JVM language made vulnerable by Java 8 is, IMO, Kotlin.
- pps 12y ago
  Clojure is becoming increasingly popular in banks in the UK. (as I heard from trusted person)
  - seanmcdirmid 12y ago
    What's up with the UK? Scala is also becoming increasingly popular in banks in the UK (as I heard from trusted persons). CLOS, Smalltalk, and Objective C (before it was cool) were for a long time very popular on Wallstreet.

zak_mc_kracken 12y ago

Funny, when I read the headline, I thought this was referring to Paul Phillips saying that "Scala is unfixable" [1] in the other thread. He's also a Scala founder and he's also saying the language needs a fundamental rethink. Interesting how the interpretation can vary. [1] https://news.ycombinator.com/item?id=8277626 https://news.ycombinator.com/item?id=8277626

TheDom 12y ago
Paul is not a "Scala founder". Martin Odersky started to create Scala, the language, by himself 10 years ago. Typesafe, the company around it, was founded 5 years ago and Paul was one of the co-founders.

stevewepay 12y ago

Are there any risks to adopting Scala as a language for a project knowing that it will change over the next few years? It sounds like as opposed to an evolution, they are going to change the language itself, which sounds like backwards incompatibility and refactors within a few short years if you don't want to be considered legacy.

eplanit 12y ago
If stable longevity for your project's implementation is important (as your question implies), then I think Scala does present additional risk (relative to stable/mainstream languages). It sounds to me, too, that they are thinking of changing fundamentals in the language/system. This could lead to something like the Python2vs3 scenario for a while. If you base on current Scala, you might (likely) later find yourself doing either a re-write, or being relegated to a "compatibility" library. You're wise to ask.
frowaway001 12y ago
No, not really. There might be a few changes, but probably nothing which can't be fixed automatically by a tool/IDE. (They are investing in that currently.) Additionally, if your code compiles with version X without warnings, it should compile with version X+1, too. (Otherwise that would be a bug.) Apart from that, stable versions are supported for a long time, so just like in Java you can migrate when you feel comfortable with it.
acjohnson55 12y ago
It depends on what you're doing. If you're really pushing forward with experimental features, sure, there's some risk. But if you're using common libraries, you probably have more to worry about staying up to date with the library interfaces than the language changes.

tel 12y ago

I find Odersky's comments on Swift very apt. I think both Scala and Swift are aimed at being mergers between FP and existing OO systems and both of them feel a little warty for the effort. I really applaud trying to merge the benefits of FP and OO. I think it's going to be a much larger and harder project than either Scala or Swift will benefit from, but I'm really glad that they're exploring the design space.

aaronharnly 12y ago

How did Odersky miss Yammer's citing Scala's complexity as a reason for moving away from it? Odersky said: > In terms of complexity, I don't know whether Yammer featured that, but you definitely do hear that a lot [from] many people. The first paragraph (after introductory greetings) of Yammer's letter which explains its action [1]: > Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. [1] https://gist.github.com/anonymous/1406238 https://gist.github.com/anonymous/1406238

the_af 12y ago
Indeed. Another example from the fourth paragraph of the letter: "Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. The number of concepts I had to explain to new members of our team for even the simplest usage of a collection was surprising: implicit parameters, builder typeclasses, "operator overloading", return type inference, etc. etc." It seems very clear the language's complexity was a major problem for Yammer.
tormeh 12y ago
I wonder if that means Odersky's not really listening to criticism, which would be really bad. EDIT: He does, he just doesn't remember where it's coming from.

VLM 12y ago

Comments on compiler speed as a problem? I find it sometimes to be a bit slow.