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.
Many people here don't seem to understand what is meant by backwards compatibility in the context of the JVM. Scala has very good source compatibility, this means that scala code from 2012 compiles just fine with the latest scala compiler.
Compared to Java, Scala has poor binary compatibility between mayor releases: a library compiled with scala 2.10 will not work with scala 2.11 In java you can use jars created with java 1.3 in your java 8 project.
Go doesn't guarantee binary compatibility either, they (just like scala) guarantee source compatibility.
> I could probably still compile C++ code from 1996, you can't even compile Scala code from 2012.
You might be surprised. Try compiling PRCS [1], for example.
There are two problems that you're likely to encounter. One, C++ standards compliance has always been a challenge (as a result of overly complex language design), and older compilers often weren't compliant. g++ 3.x in particular comes to mind. The other problem is that people often inadvertently used non-portable language extensions that allowed non-compliant code to compile.
That's not counting the language-independent issue with evolving libraries, where the 1996 version compiles, but is essentially useless, and the 2014 version is subtly (or not so subtly) different (if it hasn't been discontinued).
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?
>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.
>> 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.
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.