> Measures of what types of people learn new languages
> fastest would also help, because new hires are more likely
> to need that language training. Information on when the
> transition of various systems to the new language needs to
> occur must be provided (granted that this is less of an
> issue with Java to Scala).

I am not on the Java field nor in Scala but somehow I am interested the ideas of the new languages so I just checked Artima's online Scala tutorial (at least for the first few pages).
So I just checked the doc as an outsider of the Java biosphere.

These thoughts came my mind during reading through the first pages:
- the paper admits that it clearly adopted some of the benefits of the new scripting languages, namely maps in for example Python. The example gave me the impression that the code is still longer than it would be in Python. This makes me no feel that this language could be a better scripting alternative.
- Erlang is mentioned many times, however that language IMHO did not really proved apart from one of the products of Ericsson.
- When someone to new Java and Scala wants to learn Scala, it is disturbing to see that the simple hello world uses some other product from a different language; namely it uses java.lang.String . Does it mean if one wants to learn Scala, he/she is needed to know Java before?

Any correction or criticism welcomed.

>Does it mean if one wants to learn Scala, he/she is needed to know Java before?

with scala, you're moving onto a whole new platform - the jvm. although you can create a language that runs on jvm and doesn't contain anything from java, still you better learn something about jvm.
it's not needed, but it's often assumed and yes, it feels strange. actually, it might be quite challenging to create a tutorial that doesn't mention java, just jvm as a prerequisite. scaladoc is very brief and doesn't describe apis in detail, but again relies on javadoc.
this is maybe? one of the areas where scala folks could do better job despite the possible duplication of information. i think that for scala noobs (like myself), it'd be worth it to explain some apis in greater detail

If we can't get the businesses on board with adopting a new language, those who choose to do so will be taking risks. Those risks sometimes pay off, and articles about those migrations (like the one at guardian.co.uk:http://www.infoq.com/articles/guardian_scala ) will provide good case studies. I find the guardian.co.uk discussion fascinating because they seem to have totally backed into Scala development, as a result of starting from writing tests in Scalatest.

And, as is pointed out above, new language adoption is a chicken/egg problem.

What will strengthen the call for adoption, and what I think several people here are saying, is a killer app for Scala, something that you can do in Scala that is super hard to do in other languages. I wonder if the parallel collections in 2.9 might drive toward that (and suspect that they might).

My frustration as a developer is that "kids these days" (grin) seem to be content with "their father's Buick", wanting to stick with the old tried and true languages and complain about other languages being too hard, when in fact they have simply forgotten that there was a learning curve to languages like Java too. ;-)

As a business owner, I have seen my developers thrive using new technologies and create apps easily in the new languages or toolkits. Furthermore, they often take ideas back to the older technologies and make apps that run on those technologies better (e.g., more maintainable, more clearly written, etc.) as well.

> My frustration as a developer is that "kids these
> days" (grin) seem to be content with "their father's
> Buick", wanting to stick with the old tried and true
> languages and complain about other languages being too
> hard, when in fact they have simply forgotten that there
> was a learning curve to languages like Java too. ;-)

Hmm, I don't think Java's learning curve was as steep, though: Most people (perhaps not those reading Artima) just happily write

static void main{..}

, or

doPost() {..}

, etc., and then write one statement per line between the curly braces, maybe divide every 100 lines or so into a method... I bet that many Java apps are just basically that, and you can no doubt create lots of functionality just doing that, e.g., generate HTML, process reports, etc. And most Rails apps are probably like that, too, and probably most COBOL apps, PHP, Perl, etc. The language is not that important in that paradigm, really. I'm not sure when the repertory of things that can be done with that paradigm runs out, but it has not yet. Maybe concurrency will force people to think differently, I'm not sure. But Scala certainly makes that paradigm look outdated and clumsy, and forces a different thinking on someone. Java didn't. This may also partly have to do with the culture of the Scala community vs the Java community. As far as I can tell, the Scala community tends to attract rather sophisticated developers who enjoy learning new paradigms. I don't recall that the Java community early on (ca '95/'96) had that sort of a sentiment.

> But Scala certainly makes
> that paradigm look outdated and clumsy, and forces a
> different thinking on someone. Java didn't. This may also
> partly have to do with the culture of the Scala community
> vs the Java community. As far as I can tell, the Scala
> community tends to attract rather sophisticated developers
> who enjoy learning new paradigms. I don't recall that the
> Java community early on (ca '95/'96) had that sort of a
> sentiment.

Even if it did, by 1999 (or thereabouts) java had been co-opted pretty thoroughly by the Fortune X00 types, and turned into New COBOL. Like New Coke, it too got replaced (semantically, of course) by the thing it was supposed to replace. For that reason alone, Scala isn't likely to be much of a player in the Enterprise. There's some R and C and even smalltalk there, but only in niches.

> If the classic ROI analysis is "not very good", what is a
> distinctly different and better way to quantify the
> business value of a change of technology to users?

Net present value (NPV) is the preferred method. ROI ignores the time value of money and has other technical issues such as you can have a ROI of a one year but then lose money for 10 years following that.

> I'll add that it's different strokes for different folks,
> but for anyone to push a change in a business based solely
> on intangibles should realize that the dot-com 90s have
> come and gone. There's got to be at least some hard
> returns.

I don't disagree per se but often the values put on things are somewhat arbitrary. You can't make too much of them. Generally, people will fudge the numbers to make their preferred choice look better.

For example, something like "this project will make us 20% less likely to suffer a security breach in the next year which would on average cost us $10,000,000" might be reasonable but are by no means 'hard' numbers. The numbers are simply guesses. Educated guesses at best. Sometimes trying to boil down things to numbers can hide really important information. It might be that a security breach could destroy a company. Does it help to explain the value of continuing to exist vs. not existing as a company? I'd say not, in most cases.

> > My frustration as a developer is that "kids
> these
> > days" (grin) seem to be content with "their father's
> > Buick", wanting to stick with the old tried and true
> > languages and complain about other languages being too
> > hard, when in fact they have simply forgotten that
> there
> > was a learning curve to languages like Java too. ;-)
>
> Hmm, I don't think Java's learning curve was as steep,
> though...
>
Java's learning curve wasn't nearly as steep in 1995 as Scala's is today, but I think that's also true of Java's learning curve today. Java's learning curve today is a lot steeper than it was in 1995, and it will get steeper still in the coming releases once they add more features, like closures.

One thing Java did that may have helped its adoption was start out with a very minimalist set of features. It didn't have enums. It didn't have generics. It didn't have much in the way of collections. It didn't and still doesn't have closures. This did make it quicker to pick up, but the downside was it made it more clunky to actually use. But that appearance of simplicity might have helped it get adopted, even though some of the features that were lacking made programmers lives more complicated once they adopted it. (Look at the first edition of Effective Java, at the mass of code recommended to work around the lack of an enum, for example.)

Scala by contrast is far more a feature-complete language than Java was originally. So that makes it more complex as a language, but those features make programmers lives simpler once they actually start using it. So it is kind of the opposite tradeoff of early Java.

> Java's learning curve wasn't nearly as steep in 1995 as
> Scala's is today, but I think that's also true of Java's
> learning curve today. Java's learning curve today is a lot
> steeper than it was in 1995, and it will get steeper still
> in the coming releases once they add more features, like
> closures.

For me it seems Scala would like to turn existing Java users into Scala users, but what is the rationale behind Scala for the totally newcomer? It is more than strange to learn Java, forget it a bit, then learn Scala.
It would be also more than strange to tell someone to learn some Assembly first then C++ because the language is not "self contained". Do I miss something from the picture?

Her analogy with the cars fall flat due to versioning. Java syntax changed drastically from 4 to 5. The introduction of Generics made the language much less verbose. Greater functionality can be achieved with less code because of Generics, e.g. Generifying your persistence layers takes away from a lot of repetition. Frameworks like Wicket enable re-usable components, enhancements to refactoring tools in IDE's, the enhanced for loop etc. So I don't quite agree with that analogy it distorts things - apples to oranges??

> > Java's learning curve wasn't nearly as steep in 1995 as
> > Scala's is today, but I think that's also true of
> Java's
> > learning curve today. Java's learning curve today is a
> lot
> > steeper than it was in 1995, and it will get steeper
> still
> > in the coming releases once they add more features,
> like
> > closures.
>
> For me it seems Scala would like to turn existing Java
> users into Scala users, but what is the rationale behind
> Scala for the totally newcomer? It is more than strange to
> learn Java, forget it a bit, then learn Scala.
> It would be also more than strange to tell someone to
> learn some Assembly first then C++ because the language is
> not "self contained". Do I miss something from the picture?
>
I think maybe you're missing what "Java" means in this context. It doesn't mean Java the language as much as Java the platform. Scala is just a user interface in a way that allows you to program Java the platform. You definitely need to know about the platform you're programming. (You could also use Scala to program the .Net platform, in which case you'd need to know a lot about that platform.) In practice, though, you'd very often need to know Java too, because that's the lingua franca of the Java platform, and there's lots of Java code all over the place that you might encounter and need to read and understand while working on a Scala project.

> In practice, though, you'd very often need to know Java
> too, because that's the lingua franca of the Java
> platform, and there's lots of Java code all over the place
> that you might encounter and need to read and understand
> while working on a Scala project.

One of the selling points of Scala is "access to all that java code living in libraries", so there is some weight to the point that Scala coding is Scala/java coding. The same is true for any jvm hosted language. I don't know enough about .NET/CLR languages to know whether C/C++/C# is as important over there.