Two killer applications for Scala

48 replies

Fri, 2011-06-17, 07:42

andrevandelft

Joined: 2010-02-07,

In the thread "How to get people to adopt Scala", Darwin expresses his
opinion that Scala needs a killer application. I agree. Two good
candidates would be project building and XML transformations. In my
job I have seen that using Ant and XLST can lead to disorders.

- SBT looks good (as far as I can see); it may become a big success.

- There does not seem to be much learning material helping the
migration from XSLT to Scala. It would be useful when current XLST
code can be translated to Scala. There has been an EPFL project named
xslt2src (http://lamp.epfl.ch/~emir/projects/), but it is not
supported any more.

I think that advertising Scala as a solution for these areas will be
more effective than as a solution for parallelism.

I'm not sure in what ways SBT improves over Maven. The main featurefor me is continuous compilation/testing, and that could probably befixed in Maven.

I agree. As much as I like sbt for its own sake, I see the fact that you need to use a non-standard tool instead of Maven as a (fairly serious) drawback. I also think sbt 0.10.0's syntax is a bit exotic, more so than 0.7.x's.Cheers,Erik

In the thread "How to get people to adopt Scala", Darwin expresses his
opinion that Scala needs a killer application. I agree. Two good
candidates would be project building and XML transformations. In my
job I have seen that using Ant and XLST can lead to disorders.

- SBT looks good (as far as I can see); it may become a big success.

- There does not seem to be much learning material helping the
migration from XSLT to Scala. It would be useful when current XLST
code can be translated to Scala. There has been an EPFL project named
xslt2src (http://lamp.epfl.ch/~emir/projects/), but it is not
supported any more.

I think that advertising Scala as a solution for these areas will be
more effective than as a solution for parallelism.

I don't have any statistics to back this up, but it would seem to me that the proportion of software looking to migrate away from XSLT is *significantly* smaller than the proportion of software that'll be running on current generation multi-core machines and would benefit from an easy speed boost.

On Jun 17, 4:00 pm, Kevin Wright wrote:
> 2011/6/17 André van Delft
>
> I don't have any statistics to back this up, but it would seem to me that
> the proportion of software looking to migrate away from XSLT is
> *significantly* smaller than the proportion of software that'll be running
> on current generation multi-core machines and would benefit from an easy
> speed boost.

I can only give my own experiences. In my organisation I do not see a
need for parallel programming.But I have seen hundreds of thousands of
lines of Ant and XSLT code; these are in fact software, but they have
not been treated as such. There are no coding standards, the XML
syntax distracts from the content, and refinements (macro's) are
cumbersome so that lots of lines are copied and pasted.

IMO there would be an opportunity for Scala to come to the rescue.
Especially for the XLST code base a working translator to Scala would
be helpful, as well as training material on using Scala as an
alternative for XLST.

I can only give my own experiences. In my organisation I do not see a
need for parallel programming.But I have seen hundreds of thousands of
lines of Ant and XSLT code; these are in fact software, but they have
not been treated as such. There are no coding standards, the XML
syntax distracts from the content, and refinements (macro's) are
cumbersome so that lots of lines are copied and pasted.

IMO there would be an opportunity for Scala to come to the rescue.
Especially for the XLST code base a working translator to Scala would
be helpful, as well as training material on using Scala as an
alternative for XLST.

I believe not everyone shares your desire to move away from XSLT. In our
environment, it works fine and moving to something ike Scala would be
viewed as a backward step.

On the build tool, I also think Maven has that market niche pretty much covered.

I
think "killer apps" will be in areas where existing solutions are
notably deficient, and there's something about Scala that makes any new
solution using that noticeably better. Neither of the two proposed
"killer apps" meet that

My other problem with the two proposed apps are that they are of
interest only to a small part of the overall community that might be
interested in Scala.

We've un-mavenized to SBT where-ever we could and been happier for it. What SBT brings to the table is a first-class language for writing build programs. SBT is killer, but not killer in the way that people who use Ant and Maven regularly would want[1]. SBT is killer to Scala programmers in the same way that cake and leiningen are killer to Clojure programmers - less typing and no barriers to defining your builds the way you want without leaving the language you like.

-- Jim Powers
[1] Generally speaking "more of the same" would accurately describe their wants. With Ant and Maven's integration (to varying degrees of success) into IDEs it's doubtful that SBT will make any significant penetration outside of the Scala universe: people have spent time learning Ant and Maven and now their IDEs manage most of that XML drudgery for them. SBT is a build tool where the "up" is writing Scala to get the job done, so, in the limit is substantially not IDE friendly.

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

2011/6/17 Josh Suereth :
> Which has a few serious bugs I was never able to fix...

My original assertion wasn't that Maven was a perfect replacement. I
was simply thinking that SBT doesn't seem to add anything
fundamentally new to the table besides a different config-syntax.

I should add that I do like the Maven way of declaring metadata and
relying on "best practices" to get the job done. I can see how a
Scala-syntax in the config could be a slight benefit if you rather
script your build. On the other hand it should be simple enough to
"script" maven by writing your own plug-ins too.

Being a maven plugin developer, I'd say SBT is hands-down a better alternative. The only lacking it has is the myriad of pre-existing plugins. SBT takes the metadata/"best practices" approach but makes scripting plugins *much* easier! Try it out if you haven't yet.
2011/6/17 John Nilsson <john [at] milsson [dot] nu>

2011/6/17 Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>:
> Which has a few serious bugs I was never able to fix...

My original assertion wasn't that Maven was a perfect replacement. I
was simply thinking that SBT doesn't seem to add anything
fundamentally new to the table besides a different config-syntax.

I should add that I do like the Maven way of declaring metadata and
relying on "best practices" to get the job done. I can see how a
Scala-syntax in the config could be a slight benefit if you rather
script your build. On the other hand it should be simple enough to
"script" maven by writing your own plug-ins too.

I really like:
- Subprojects are very nice for multiple related projects! (needs
auto complete for "project" command though)
- Easy to start continuous compilation / or testing using ~.
- I also really like using Scala to configure build. It is sooo
much better than XML.

Room to grow:
- Needs more first class IDE support.
- It feels strange at first.

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

On 17 June 2011 19:26, JamesJ <james [at] kybios [dot] com> wrote:

+1 SBT

I really like:
- Subprojects are very nice for multiple related projects! (needs
auto complete for "project" command though)
- Easy to start continuous compilation / or testing using ~.
- I also really like using Scala to configure build. It is sooo
much better than XML.

Room to grow:
- Needs more first class IDE support.
- It feels strange at first.

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

Ditto. You don't convince people to use a language by telling them it's easy to build programs in that language. The follow-up question will always be: "Great, but what about the language itself?" and you're back to square one.
-- Cédric

What was the killer app for Java? Or for C++? Why do you think Scala has to have one?If one wants to sell to the enterprise, one needs to prove ROI. Switching to Java would typically shave off 40% or more of cold hard cash that would need to be spent over a lifetime of a typical large C++ enterprise application.
What is Scala's ROI compared to Java in different application areas? Are there areas where the ROI is already proven?

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

On 17 June 2011 19:26, JamesJ <james [at] kybios [dot] com> wrote:

+1 SBT

I really like:
- Subprojects are very nice for multiple related projects! (needs
auto complete for "project" command though)
- Easy to start continuous compilation / or testing using ~.
- I also really like using Scala to configure build. It is sooo
much better than XML.

Room to grow:
- Needs more first class IDE support.
- It feels strange at first.

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

Unconvinced about?

The need for a killer app?

That there are killer apps?

It's not clear to me that there is a useful definition to a "killer app" for Scala. There are two problem as far as I can see: 1. Those consuming the claim "the killer app for scala has arrived and is ..." might not agree about the "killer-ness" of such an app. 2. Folks are free to disagree with what ever definition we give to the notion of "killer app". As one final note: often killer-app-ness is identified (if at all) retrospectively, making it hard to target achieving such a state prospectively.
What I find as killer about Scala is how it helps me every time I sit down to write code. Further, it is a very deep language that gives me a lot of "headroom" in terms of how I can express the solution to the problems I tackle. The elevator pitch being: less typing, more work done, better. Of course, these sentiments are predicated on a couple of things: 1. I'm sticking to the JVM as a target for what I write 2. Compared to Java almost all directions are "upward", nobody would be talking about Scala at all if it achieved a status of actually being worse than Java as a language by some measure. Now this said, other JVM languages are going to make similar claims. Consider this: JRuby can run Rails apps, is that "killer"? For certain people I'm sure it is, it isn't for me.
Before worrying about "killer apps" for Scala it may be worthwhile to consider what "killer" would mean in this context. For me, Scala has already achieved killer status. Likely my sentiments are not shared.
-- Jim Powers

I'd share Cedric's point of view (and some others as well):
- Assuming that "killer" apps like Actors or XLST or SBT would sway
Enterprise customers shows a lack of understanding how Enterprise
software development works... Next time you see some architect/manager
from large corp. try to persuade him/her that they need to change the
entire programming eco-system from Java/JEE to a new language
because... it has a nice build tool and multithreading library. I can
almost predict the reaction since I've seen in different shades many
times already.
- I happen to think that a language DOES NOT need a killer app to be
successful. One would argue to the oposite: just a take a look at
Ruby's fiasco with RoR or Groovy and Grails. Without super-glue tie-up
to RoR, for example, Ruby might have a different future vs. it's
current state of affairs. Ditto for Groovy.

I happen to think that moving from Java to Scala has similar effect of
moving from C/C++ to Java 15 years ago. It reduces time and money - in
some cases dramatically. Scala shines with its almost algebra-like
clarity and simplicity, inner beauty and uncanny elegance, as well as
subtle trade-offs towards everyday productivity. Advantages of Scala
are much bigger and more profound than whatever individual libraries
or tools bring.

When I advocate for Scala to GridGain clients I always give us as a
prime example (putting our money where our mouth is). We developed DSL
and entire management/monitoring technology in Scala and I honestly
say there was may be 2-3 times savings in time (and therefore money)
we spent on it relatively to developing it in Java. And as project
gets bigger - the saving are just piling up more.

We don't use Actors or SBT (first is too primitive for performance
fine tuning and second doesn't provide enough value to switch from our
Ant build infrastructure)... Your milage is likely to vary though.

I realize that this is rather an unorthodox point of view given core
constituency of Scala groups (language enthusiast and alike - which
includes me, btw). But I have seriously vested interest in seeing
Scala making a dent in Enterprise Java armor - and hence my comments
here.

On Jun 16, 5:16 pm, André van Delft wrote:
> In the thread "How to get people to adopt Scala", Darwin expresses his
> opinion that Scala needs a killer application. I agree. Two good
> candidates would be project building and XML transformations. In my
> job I have seen that using Ant and XLST can lead to disorders.
>
> - SBT looks good (as far as I can see); it may become a big success.
>
> - There does not seem to be much learning material helping the
> migration from XSLT to Scala. It would be useful when current XLST
> code can be translated to Scala. There has been an EPFL project named
> xslt2src (http://lamp.epfl.ch/~emir/projects/), but it is not
> supported any more.
>
> I think that advertising Scala as a solution for these areas will be
> more effective than as a solution for parallelism.

Regardless of whether a killer app might be useful, speculating about what it might be is less than useful. Seriously: while I think that languages have sometimes had killer apps, nobody has ever figured them out in advance. When Ruby was at a similar point in its lifecycle, nobody saw Rails coming. When Java was at a similar point, we all thought that browser applets were going to be its be-all-and-end-all; the idea of using it server-side just made people scratch their heads.
If you think Scala is wonderful for a particular use case, talk up that use case to end users, and figure out what enhancements would make it fabulous. But the tit-for-tat arguments about which purpose is the One True Killer App are near-certain to be relegated to the dustbin of history. We will know if Scala had a killer app in 5-10 years. For now, better to simply find uses that are great, and make them so...

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

Unconvinced about?

The need for a killer app?

That there are killer apps?

It's not clear to me that there is a useful definition to a "killer app" for Scala. There are two problem as far as I can see: 1. Those consuming the claim "the killer app for scala has arrived and is ..." might not agree about the "killer-ness" of such an app. 2. Folks are free to disagree with what ever definition we give to the notion of "killer app". As one final note: often killer-app-ness is identified (if at all) retrospectively, making it hard to target achieving such a state prospectively.
What I find as killer about Scala is how it helps me every time I sit down to write code. Further, it is a very deep language that gives me a lot of "headroom" in terms of how I can express the solution to the problems I tackle. The elevator pitch being: less typing, more work done, better. Of course, these sentiments are predicated on a couple of things: 1. I'm sticking to the JVM as a target for what I write 2. Compared to Java almost all directions are "upward", nobody would be talking about Scala at all if it achieved a status of actually being worse than Java as a language by some measure. Now this said, other JVM languages are going to make similar claims. Consider this: JRuby can run Rails apps, is that "killer"? For certain people I'm sure it is, it isn't for me.
Before worrying about "killer apps" for Scala it may be worthwhile to consider what "killer" would mean in this context. For me, Scala has already achieved killer status. Likely my sentiments are not shared.
-- Jim Powers

There's only 2 ways you'll sell to an enterprise customer like this:1. Save them money2. Reduce some (perceived) riskA single killer app can invariably be sold on one of these points, but it's a *hard* way to go about the sale. Far better is an entire technology that can reduce cost or risk on a far wider scale.

Regardless of whether a killer app might be useful, speculating about what it might be is less than useful. Seriously: while I think that languages have sometimes had killer apps, nobody has ever figured them out in advance. When Ruby was at a similar point in its lifecycle, nobody saw Rails coming. When Java was at a similar point, we all thought that browser applets were going to be its be-all-and-end-all; the idea of using it server-side just made people scratch their heads.
If you think Scala is wonderful for a particular use case, talk up that use case to end users, and figure out what enhancements would make it fabulous. But the tit-for-tat arguments about which purpose is the One True Killer App are near-certain to be relegated to the dustbin of history. We will know if Scala had a killer app in 5-10 years. For now, better to simply find uses that are great, and make them so...

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

Unconvinced about?

The need for a killer app?

That there are killer apps?

It's not clear to me that there is a useful definition to a "killer app" for Scala. There are two problem as far as I can see: 1. Those consuming the claim "the killer app for scala has arrived and is ..." might not agree about the "killer-ness" of such an app. 2. Folks are free to disagree with what ever definition we give to the notion of "killer app". As one final note: often killer-app-ness is identified (if at all) retrospectively, making it hard to target achieving such a state prospectively.
What I find as killer about Scala is how it helps me every time I sit down to write code. Further, it is a very deep language that gives me a lot of "headroom" in terms of how I can express the solution to the problems I tackle. The elevator pitch being: less typing, more work done, better. Of course, these sentiments are predicated on a couple of things: 1. I'm sticking to the JVM as a target for what I write 2. Compared to Java almost all directions are "upward", nobody would be talking about Scala at all if it achieved a status of actually being worse than Java as a language by some measure. Now this said, other JVM languages are going to make similar claims. Consider this: JRuby can run Rails apps, is that "killer"? For certain people I'm sure it is, it isn't for me.
Before worrying about "killer apps" for Scala it may be worthwhile to consider what "killer" would mean in this context. For me, Scala has already achieved killer status. Likely my sentiments are not shared.
-- Jim Powers

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

I don't think Andre's idea is too far off the mark. I've written a
Maven plug-in. It is downright painful, and Scala just may be the
cure. Maybe there is a vibrant ecosystem of build applications that
are enabled by Scala's unique characteristics. And I've definitely hit
walls with XSLT.

As Andre pointed out, I originated the thought of the "killer app"...
or platform or feature. Or rather, I intended to express to the panel
at Scala Days that something that is merely incrementally better than
an incumbent technology has a lot of inertia to overcome, much as
swimming with improper technique means you will encounter
significantly more drag. (For a real life example, see Unix vs. Plan
9.) In particular, I pointed out that many of Scala's ambassadors
argue their points in terms of programming language features, which I
believe are often lost on people who are not interested in programming
languages. And furthermore, I find many feature-oriented arguments to
express an arbitrary viewpoint rather objective reasoning.

My opinion is that, for Scala's adoption to come to a tipping point,
its language features should only be incidental to the outcomes they
are on a whole able to produce. In my original post to this list, I
pointed out how several popular languages have had several secondary
factors that vastly expedited their adoption. Let me reiterate one
example that I made in that post for Sergei's benefit: Java's killer
feature was write-once-run-anywhere, i.e. the Java virtual machine;
indeed, this was why my team chose it when this decision needed to be
made nine years ago, and we are able to support a dozen platforms this
way, some of them very arcane.

To be honest, Sergei, I have trouble explaining C++'s adoption. I will
perhaps weakly offer that it provided some of the abstraction afforded
by Smalltalk but still maintained the runtime efficiency of C. But let
me point out additionally that Ruby, which is an older language than
Java, did not gain widespread adoption until Ruby on Rails came out
many years later. Same with Python, which is older than both Ruby and
Java.

These specific points to the side, Sergei, I think your position is
the same as mine. Indeed, I would consider it a faithful transmission
of my beliefs if you were to rephrase it in the following manner: What
will make Scala so compelling as to surpass most people's hurdle rate?

Personally, I think something like Spark of U.C. Berkeley, or yes,
GridGain, could be the killer platform that boosts Scala's adoption.
Actors is another. Of course, there is no way to predict these things,
but as I am a Scala fan who assumes that Scala will in fact achieve
ubiquity at some point, I think it is entertaining to try to predict
what will cause Scala to tip over into exponential growth.

Frankly, I was disappointed that the panel either did not offer an
opinion or missed my point completely. So strong is the tendency to
speak in terms of programming language features that one panelist
started arguing with me about static typing vs. dynamic typing. From
what I can tell, there is an argument to be made for each side; see
Clojure. Little did he realize that I was on his side and that I could
probably argue with him all day on the topic without getting anywhere,
which was my point. Me in particular: I have some background in
programming languages, work on program analysis in my day job, and was
in fact going to PLDI, a conference on programming languages, the
following week.

-Darwin

On Jun 17, 5:02 pm, Kevin Wright wrote:
> There's only 2 ways you'll sell to an enterprise customer like this:
>
> 1. Save them money
> 2. Reduce some (perceived) risk
>
> A single killer app can invariably be sold on one of these points, but it's
> a *hard* way to go about the sale. Far better is an entire technology that
> can reduce cost or risk on a far wider scale.
>
> On 17 June 2011 21:14, Justin du coeur wrote:
>
>
>
> > Regardless of whether a killer app might be useful, speculating about what
> > it might be is less than useful. Seriously: while I think that languages
> > have sometimes had killer apps, nobody has ever figured them out in advance.
> > When Ruby was at a similar point in its lifecycle, nobody saw Rails coming.
> > When Java was at a similar point, we all thought that browser applets were
> > going to be its be-all-and-end-all; the idea of using it server-side just
> > made people scratch their heads.
>
> > If you think Scala is wonderful for a particular use case, talk up that use
> > case to end users, and figure out what enhancements would make it fabulous.
> > But the tit-for-tat arguments about which purpose is the One True Killer
> > App are near-certain to be relegated to the dustbin of history. We will
> > know if Scala had a killer app in 5-10 years. For now, better to simply
> > find uses that are great, and make them so...
>
> > On Fri, Jun 17, 2011 at 3:38 PM, Jim Powers wrote:
>
> >> On Fri, Jun 17, 2011 at 2:57 PM, Paul Hudson wrote:
>
> >>> I think things have lost focus a bit. The original statement was not
> >>> really "sbt is better than maven". It was "sbt (or other build application)
> >>> is a 'killer app' for scala". To be that. sbt has to be overwhelmingly
> >>> better than the alternatives, enough to drive Scala adoption (following the
> >>> definition herehttp://en.wikipedia.org/wiki/Killer_application).
>
> >>> Put me in the "unconvinced" bucket.
>
> >> Unconvinced about?
>
> >> - The need for a killer app?
> >> - That there are killer apps?
>
> >> It's not clear to me that there is a useful definition to a "killer app"
> >> for Scala. There are two problem as far as I can see: 1. Those consuming
> >> the claim "the killer app for scala has arrived and is ..." might not agree
> >> about the "killer-ness" of such an app. 2. Folks are free to disagree with
> >> what ever definition we give to the notion of "killer app". As one final
> >> note: often killer-app-ness is identified (if at all) retrospectively,
> >> making it hard to target achieving such a state prospectively.
>
> >> What *I* find as killer about Scala is how it helps me every time I sit
> >> down to write code. Further, it is a very deep language that gives me a lot
> >> of "headroom" in terms of how I can express the solution to the problems I
> >> tackle. The elevator pitch being: less typing, more work done, better. Of
> >> course, these sentiments are predicated on a couple of things: 1. I'm
> >> sticking to the JVM as a target for what I write 2. Compared to Java almost
> >> all directions are "upward", nobody would be talking about Scala at all if
> >> it achieved a status of actually being *worse* than Java as a *language* by
> >> some measure. Now this said, other JVM languages are going to make similar
> >> claims. Consider this: JRuby can run Rails apps, is that "killer"? For
> >> certain people I'm sure it is, it isn't for me.
>
> >> Before worrying about "killer apps" for Scala it may be worthwhile to
> >> consider what "killer" would mean in this context. For me, Scala has
> >> already achieved *killer* status. Likely my sentiments are not shared.
>
> >> --
> >> Jim Powers
>
> --
> Kevin Wright
>
> gtalk / msn : kev [dot] lee [dot] wri [dot] [dot] [dot] [at] gmail [dot] com
> mail: kevin [dot] wri [dot] [dot] [dot] [at] scalatechnology [dot] com
> vibe / skype: kev.lee.wright
> quora:http://www.quora.com/Kevin-Wright
> twitter: @thecoda
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side of
> the ledger" ~ Dijkstra

Thank you for the very detailed response Darwin.Indeed, I do think our positions are very similar. The difference is in expression: you express the adoption threshold criterium in emotional terms, I express it in business terms.
To prove to businessmen that Scala is ready for the prime time, someone needs to come up with case studies showing the return on investment compared to Java, Ruby etc. Sounds like a project for a business major. Maybe Scala-sympathetic CS professors could talk some of their business school counterparts into sponsoring such studies?

A clearly demonstrated benefit of 20% over incumbent technologies is usually considered sufficient to start a pilot project. A 40% benefit professed by a reputable authority (e.g. Gartner Group) tends to start the ball rolling in a hurry. The decision makers also need simple specific guidelines expressed as sound bites, e.g. "Use Scala+Akka for concurrent high-performance fault-tolerant applications" (well, that one is actually still too geeky; coming up with fresh and catchy industry-specific soundbites is not as simple as it may seem).
Best,Sergei.

These specific points to the side, Sergei, I think your position is
the same as mine. Indeed, I would consider it a faithful transmission
of my beliefs if you were to rephrase it in the following manner: What
will make Scala so compelling as to surpass most people's hurdle rate?

To prove to businessmen that Scala is ready for the prime time, someone needs to come up with case studies showing the return on investment compared to Java, Ruby etc.

I'm not even convinced this is necessary.
Do you remember such a study about Java? Or C++? Or C# or Visual Basic?I don't.All these languages achieved emergence and ubiquity through percolation, not because of one pivotal moment or event that convinced everyone that suddenly, the technology was ready for prime time.
I still harbor some skepticism that Scala can cross that chasm, not because of the language itself but because I don't think there is a strong urge to replace Java. Most Java programmers like the language.
For revolutions to happen, you need to have a minimum amount of people willing to pick up pitchforks, and I just don't see this happening regarding Java in the near future.
-- Cédric

The adoption of popular languages of the past haven't been driven by such studies. What makes you think they're necessary now? (and, I might add, such studies are few and far between and mostly lie on the spectrum from dubious to pure marketing lies)

Thank you for the very detailed response Darwin.Indeed, I do think our positions are very similar. The difference is in expression: you express the adoption threshold criterium in emotional terms, I express it in business terms.
To prove to businessmen that Scala is ready for the prime time, someone needs to come up with case studies showing the return on investment compared to Java, Ruby etc. Sounds like a project for a business major. Maybe Scala-sympathetic CS professors could talk some of their business school counterparts into sponsoring such studies?

A clearly demonstrated benefit of 20% over incumbent technologies is usually considered sufficient to start a pilot project. A 40% benefit professed by a reputable authority (e.g. Gartner Group) tends to start the ball rolling in a hurry. The decision makers also need simple specific guidelines expressed as sound bites, e.g. "Use Scala+Akka for concurrent high-performance fault-tolerant applications" (well, that one is actually still too geeky; coming up with fresh and catchy industry-specific soundbites is not as simple as it may seem).
Best,Sergei.

These specific points to the side, Sergei, I think your position is
the same as mine. Indeed, I would consider it a faithful transmission
of my beliefs if you were to rephrase it in the following manner: What
will make Scala so compelling as to surpass most people's hurdle rate?

> Next time you see some architect/manager
> from large corp. try to persuade him/her that they need to change the
> entire programming eco-system from Java/JEE to a new language
> because... it has a nice build tool and multithreading library.

Your example is not what I would think of as a killer application,
feature, or platform. Note that I am arguing your point exactly, that
changes that are merely incremental will not be enough to propel Scala
to ubiquity. People already have workarounds for limitations that they
have encountered, are good at using them, and are perhaps even
hesitant to abandon them. Let me clarify what I mean with my own
example (please excuse me if you already read my original post): The
killer platform for Objective-C is the iPhone; for the most part, if
you want to tap into the tremendous iPhone app market, you will have
to use Objective-C. The iPhone, a platform, propelled Objective-C to a
fair amount of ubiquity.

Here are additional examples to illustrate further what I mean. If
your business creates desktop applications for Windows, then you will
likely use C# and .NET. If your business is a Facebook app, then you
will probably use PHP, the native language of Facebook, because its
libraries are supported the best. (I know friends that have learned
PHP simply in order to write Facebook apps!) Note that, in all the
examples I mentioned, the language features themselves do not play a
significant role in why they are adopted.

In our case, what does the Scala community uniquely offer or can
uniquely offer in the future that in quite a black-and-white manner
makes business sense? For example, if programmable cars suddenly
became a hot market, and auto makers only released a Scala-based
platform, then you bet Scala will leap in popularity. By being the
default on a platform, Scala can be what Perl is to system
administrators.

Most realistically, I think it is becoming common for products to
actually require more computational power; and distributed, parallel
computation is often the answer. Wouldn't it vastly favor Scala's
adoption if the canonical platform for such a style of computation
actually required the use of Scala? (Come on, GridGain! If you improve
your documentation, you can be this platform ;-)!)

If we are to consider the latest buzz words, maybe we can think of a
way to make Scala the definitive "cloud language", whatever that would
mean.

On another note, someone mentioned Gartner. I would like to add that
this is also my impression of how CTOs make IT purchasing decisions.

Your example is not what I would think of as a killer application,
feature, or platform. Note that I am arguing your point exactly, that
changes that are merely incremental will not be enough to propel Scala
to ubiquity. People already have workarounds for limitations that they
have encountered, are good at using them, and are perhaps even
hesitant to abandon them. Let me clarify what I mean with my own
example (please excuse me if you already read my original post): The
killer platform for Objective-C is the iPhone; for the most part, if
you want to tap into the tremendous iPhone app market, you will have
to use Objective-C. The iPhone, a platform, propelled Objective-C to a
fair amount of ubiquity.

True. Another example following this line of thought: Android has increased the popularity of Java even further. I suspect that a lof of developers are now learning Java just so they can write Android applications, whereas they had no interest in the language or the platform before.

Most realistically, I think it is becoming common for products to
actually require more computational power; and distributed, parallel
computation is often the answer. Wouldn't it vastly favor Scala's
adoption if the canonical platform for such a style of computation
actually required the use of Scala? (Come on, GridGain! If you improve
your documentation, you can be this platform ;-)!)

The problem with this assumption is that Scala's added value in terms of concurrency still needs to 1) be established and 2) provide a significant quantum jump over what's currently doable in Java.
About 1): Actors and parallel collections are interesting but they still haven't proven that they are vastly superior to current Java solutions and for 2), Java has a lot of established API's and technologies that seem to do a fine job at tackling the parallelism problem (j.c.u and fork/join in terms of API's, products such as Coherence, Terracotta, Gridgain or even application servers for more vertical apps).
I think Scala is going to have a hard time cracking that nut.-- Cédric

Sure, I remember plenty of studies of Java vs. other languages ROI. They were abundant in the late nineties (oh God - in the previous century :-). E.g. quick googling returns this list of references: http://www.artima.com/weblogs/viewpost.jsp?thread=8142Virtually *every* Microsoft product sold to the enterprise had associated case studies highlighting ROI and other business metrics. And yes, to a practicing programmer most of the studies looked either unnecessary or dubious. Business "science" is not all that precise.
I figure you simply weren't exposed to them. But people somewhere up up the hierarchy, in larger companies, were. And people of that kind sign the checks that Typesafe and other Scala ecosystem companies could use. In some places they also make decisions concerning what the company-approved programming languages are.

I was not one of these people, yet I was one of those who would present the studies to them and influence their decisions. Believe me, in general they couldn't care less about the fine technical aspects, yet they were very sensitive to the ROI (return on investment), TCO (total cost of ownership), NPV (net present value), VAR (value at risk), and other business metrics that introduction of a new technology was supposed to improve.
Please note that this is not an alternative to percolation through word of mouth based on technical excellence of a product. My first point is that both approaches are valid and necessary for wide adoption. My second point is that most current members of the Scala community appear to be underestimating the first point. And my third and final point is that the Scala "sales and marketing" will do better when the first point is taken more seriously. Like it or not, many of the people handling the money want business justifications and don't care much about technical ones.

To prove to businessmen that Scala is ready for the prime time, someone needs to come up with case studies showing the return on investment compared to Java, Ruby etc.

I'm not even convinced this is necessary.
Do you remember such a study about Java? Or C++? Or C# or Visual Basic?I don't.All these languages achieved emergence and ubiquity through percolation, not because of one pivotal moment or event that convinced everyone that suddenly, the technology was ready for prime time.
I still harbor some skepticism that Scala can cross that chasm, not because of the language itself but because I don't think there is a strong urge to replace Java. Most Java programmers like the language.
For revolutions to happen, you need to have a minimum amount of people willing to pick up pitchforks, and I just don't see this happening regarding Java in the near future.
-- Cédric

I will throw in my two cents. Please bear in mind I am a fairly new scala developer.To the wider question of what would help the wider adoption of the programming language. I do think that it begins with better support for the language itself. A build tool like sbt might be that "killer app" but it seems to be the wrong bet to make for wider adoption of the language itselft. I don't see anyone saying " As an enterprise we are going to adopt Scala because its got the most awesome build tool ever". Not going to happen.
At the end of the day people should have the ability to adopt the language independent of some of the first tools/applications that was created using that Langauge. IMO such a push could be more a hindrance than a boon. An enterprise using gradle should be able to experiment and incrementally adopt scala without having to move to sbt. In the long run, I think we will see multiple languages working well on the java platform seamlessly. JDK7 invokedynamic is another step closer to that, weather it helps scala or not.
I am going to skip the part about why I like Maven and dont plan to switch to anything else. And I am understanding why when someone asks for maven support on IRC or user-lists they are suggested to use SBT.
For a language in its nascent state such as Scala, initial smooth integration into whatever ecosystem people are used to is just as important as an enterprise wanting to scale and build everything on Scala.
Here are the superficial but important aspects that will give the impression of a mature language and help Scala's adoption greatly1) Better IDE ( eclipse ) support and more stable maven integration. As much is REPL is pretty neat, please don't suggest using REPL and text editor.
( scala-ide 2.0.0-beta is great. But, still is buggy and I had a nightmare the past couple of days trying to use it with STS. I believe the the problem is that scala-ide comes with its own JDT weaving and has incompatibility issues ).
2) The sooner binary compatibility the better.3) On a minor note, as much as there a few books on scala, I find the online resources scattered around. As a groovy developer I think their community edited documentation ace and our new team members think so too. Suppose you googled "groovy process management", you end up in this getting started page. Perfect to get started quick and there is an advanced tutorial right bellow. Can't find an equivalent for scala at least from a few minutes of googling. Where as a lot of scala terms end up at the api page which IMO is not the perfect place to get started.
thanksArunLead Architect/Engineer | Incentica LabsOn Fri, Jun 17, 2011 at 2:02 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:

There's only 2 ways you'll sell to an enterprise customer like this:1. Save them money
2. Reduce some (perceived) riskA single killer app can invariably be sold on one of these points, but it's a *hard* way to go about the sale. Far better is an entire technology that can reduce cost or risk on a far wider scale.

Regardless of whether a killer app might be useful, speculating about what it might be is less than useful. Seriously: while I think that languages have sometimes had killer apps, nobody has ever figured them out in advance. When Ruby was at a similar point in its lifecycle, nobody saw Rails coming. When Java was at a similar point, we all thought that browser applets were going to be its be-all-and-end-all; the idea of using it server-side just made people scratch their heads.
If you think Scala is wonderful for a particular use case, talk up that use case to end users, and figure out what enhancements would make it fabulous. But the tit-for-tat arguments about which purpose is the One True Killer App are near-certain to be relegated to the dustbin of history. We will know if Scala had a killer app in 5-10 years. For now, better to simply find uses that are great, and make them so...

I think things have lost focus a bit. The original statement was not really "sbt is better than maven". It was "sbt (or other build application) is a 'killer app' for scala". To be that. sbt has to be overwhelmingly better than the alternatives, enough to drive Scala adoption (following the definition here http://en.wikipedia.org/wiki/Killer_application).

Put me in the "unconvinced" bucket.

Unconvinced about?

The need for a killer app?

That there are killer apps?

It's not clear to me that there is a useful definition to a "killer app" for Scala. There are two problem as far as I can see: 1. Those consuming the claim "the killer app for scala has arrived and is ..." might not agree about the "killer-ness" of such an app. 2. Folks are free to disagree with what ever definition we give to the notion of "killer app". As one final note: often killer-app-ness is identified (if at all) retrospectively, making it hard to target achieving such a state prospectively.
What I find as killer about Scala is how it helps me every time I sit down to write code. Further, it is a very deep language that gives me a lot of "headroom" in terms of how I can express the solution to the problems I tackle. The elevator pitch being: less typing, more work done, better. Of course, these sentiments are predicated on a couple of things: 1. I'm sticking to the JVM as a target for what I write 2. Compared to Java almost all directions are "upward", nobody would be talking about Scala at all if it achieved a status of actually being worse than Java as a language by some measure. Now this said, other JVM languages are going to make similar claims. Consider this: JRuby can run Rails apps, is that "killer"? For certain people I'm sure it is, it isn't for me.
Before worrying about "killer apps" for Scala it may be worthwhile to consider what "killer" would mean in this context. For me, Scala has already achieved killer status. Likely my sentiments are not shared.
-- Jim Powers

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Sure, I remember plenty of studies of Java vs. other languages ROI. They were abundant in the late nineties (oh God - in the previous century :-). E.g. quick googling returns this list of references: http://www.artima.com/weblogs/viewpost.jsp?thread=8142Virtually *every* Microsoft product sold to the enterprise had associated case studies highlighting ROI and other business metrics. And yes, to a practicing programmer most of the studies looked either unnecessary or dubious. Business "science" is not all that precise.
I figure you simply weren't exposed to them. But people somewhere up up the hierarchy, in larger companies, were. And people of that kind sign the checks that Typesafe and other Scala ecosystem companies could use. In some places they also make decisions concerning what the company-approved programming languages are.

I was exposed to them. I was often asked to respond to them (when presented with these "studies" by various "people somewhere up up the hierarchy"), because those same "people somewhere up up the hierarchy" had no clue about how to assess the veracity of the claims being made. I never encountered one that was remotely useful in deciding what language to use in developing products. In organizations where perhaps the technical staff was less discerning perhaps these fluff pieces made a difference.

I was not one of these people, yet I was one of those who would present the studies to them and influence their decisions. Believe me, in general they couldn't care less about the fine technical aspects, yet they were very sensitive to the ROI (return on investment), TCO (total cost of ownership), NPV (net present value), VAR (value at risk), and other business metrics that introduction of a new technology was supposed to improve.
Please note that this is not an alternative to percolation through word of mouth based on technical excellence of a product. My first point is that both approaches are valid and necessary for wide adoption. My second point is that most current members of the Scala community appear to be underestimating the first point. And my third and final point is that the Scala "sales and marketing" will do better when the first point is taken more seriously. Like it or not, many of the people handling the money want business justifications and don't care much about technical ones.

Great, all that's necessary is for Typesafe to fabricate some marketing filler that passes the "smell test" to convince businesses without the necessary talent to use Scala to replace their... what?

VB-based desktop development process? Not going to happen, no "native" GUI tools for Scala, and VB programmers are likely (and correctly) not going to value most of Scala's features.

Java-based desktop development process? Not going to happen for the same reasons as for VB above.

C/C++-based financial analysis system? Probably not.

So then what are the scenarios where Typesafe (and others) would make the case for Scala adoption? Probably as part of your pre-existing Java-based server-side software infrastructure[1]. However, only if such an organization perceives the need to accelerate such development and they recognize the competitive advantage they would gain with such a boost in developmental productivity. In my experience, internal IT development is often not viewed in this way[2].
Honestly, I think that eventual incorporation of Scala into the enterprise will just happen organically. It will start with folks that can appreciate the value Scala represents in terms of software development productivity and quality. The more paranoid organizations will closely track these early-adopter "crack-pots" to try to decide if the bets people place on Scala pay off, if they do then they will adopt Scala themselves. The more slow-moving organizations will wait for enough "white-papers" to accumulate to convince them to jump on the band-wagon (these folks are years away from even seriously considering Scala, if ever).
Sadly, there will be plenty of folks within various organizations that understand the value of a language like Scala but will simply fail to make the case for it (we just had a case of this on the mailing list recently, fortunately it was a victory for Scala). Such folks can either keep hammering away or choose to leave their organizations for places more friendly to its adoption.
-- Jim Powers[1] We already know that start-ups are willing to take risks and choose Scala as part of their development tool-box
[2] Of course there are plenty exceptions.

Sure, I remember plenty of studies of Java vs. other languages ROI. They were abundant in the late nineties (oh God - in the previous century :-). E.g. quick googling returns this list of references: http://www.artima.com/weblogs/viewpost.jsp?thread=8142Virtually *every* Microsoft product sold to the enterprise had associated case studies highlighting ROI and other business metrics. And yes, to a practicing programmer most of the studies looked either unnecessary or dubious. Business "science" is not all that precise.
I figure you simply weren't exposed to them. But people somewhere up up the hierarchy, in larger companies, were. And people of that kind sign the checks that Typesafe and other Scala ecosystem companies could use. In some places they also make decisions concerning what the company-approved programming languages are.

I was exposed to them. I was often asked to respond to them (when presented with these "studies" by various "people somewhere up up the hierarchy"), because those same "people somewhere up up the hierarchy" had no clue about how to assess the veracity of the claims being made. I never encountered one that was remotely useful in deciding what language to use in developing products. In organizations where perhaps the technical staff was less discerning perhaps these fluff pieces made a difference.

I think I understand what you are saying. And I agree with that. Yet - to clarify - I'm talking about a different kind of studies. The ones conducted by an independent trusted third party, not the usual marketing fluff one would find on a vendor Web site. The ones that a person somewhere up the hierarchy would pay $2K-$10K for - in a form of a report or an industry conference. Not a study of Scala in particular but a study that mentions and compares Scala with other technologies, putting it at some advantageous coordinate in a "magic quadrant", and thus legitimizing it for enterprise use.

I was not one of these people, yet I was one of those who would present the studies to them and influence their decisions. Believe me, in general they couldn't care less about the fine technical aspects, yet they were very sensitive to the ROI (return on investment), TCO (total cost of ownership), NPV (net present value), VAR (value at risk), and other business metrics that introduction of a new technology was supposed to improve.
Please note that this is not an alternative to percolation through word of mouth based on technical excellence of a product. My first point is that both approaches are valid and necessary for wide adoption. My second point is that most current members of the Scala community appear to be underestimating the first point. And my third and final point is that the Scala "sales and marketing" will do better when the first point is taken more seriously. Like it or not, many of the people handling the money want business justifications and don't care much about technical ones.

Great, all that's necessary is for Typesafe to fabricate some marketing filler that passes the "smell test" to convince businesses without the necessary talent to use Scala to replace their... what?

VB-based desktop development process? Not going to happen, no "native" GUI tools for Scala, and VB programmers are likely (and correctly) not going to value most of Scala's features.

Java-based desktop development process? Not going to happen for the same reasons as for VB above.

C/C++-based financial analysis system? Probably not.

So then what are the scenarios where Typesafe (and others) would make the case for Scala adoption? Probably as part of your pre-existing Java-based server-side software infrastructure[1]. However, only if such an organization perceives the need to accelerate such development and they recognize the competitive advantage they would gain with such a boost in developmental productivity. In my experience, internal IT development is often not viewed in this way[2].
Honestly, I think that eventual incorporation of Scala into the enterprise will just happen organically. It will start with folks that can appreciate the value Scala represents in terms of software development productivity and quality. The more paranoid organizations will closely track these early-adopter "crack-pots" to try to decide if the bets people place on Scala pay off, if they do then they will adopt Scala themselves. The more slow-moving organizations will wait for enough "white-papers" to accumulate to convince them to jump on the band-wagon (these folks are years away from even seriously considering Scala, if ever).

Once again, I agree with what you are saying. Yet once again - to clarify - the accumulation of studies does not happen all by itself. There are some actions that the promoting entity can do to make it happen quicker. For instance, identify the "industry influencers", find a way to them through the network of trusted connections, and make sure they are getting periodic updates about the Scala ecosystem progress, free passes to relevant events etc.
A lot of developments that may seem incidental and organic are in fact initiated and accelerated by persistent organized effort behind the scenes... I think the world needs a good Scala conspiracy :-)

-- Jim Powers[1] We already know that start-ups are willing to take risks and choose Scala as part of their development tool-box
[2] Of course there are plenty exceptions.

A lot of developments that may seem incidental and organic are in fact initiated and accelerated by persistent organized effort behind the scenes... I think the world needs a good Scala conspiracy :-)

Of course, if there *was* a conspiracy then you wouldn't know about it...No true conspiracy is publicly known, as it wouldn't be a conspiracy then.
I could tell you more, but there's *absolutely nothing* to tell you about, honest!

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

I think I understand what you are saying. And I agree with that. Yet - to clarify - I'm talking about a different kind of studies. The ones conducted by an independent trusted third party, not the usual marketing fluff one would find on a vendor Web site. The ones that a person somewhere up the hierarchy would pay $2K-$10K for - in a form of a report or an industry conference. Not a study of Scala in particular but a study that mentions and compares Scala with other technologies, putting it at some advantageous coordinate in a "magic quadrant", and thus legitimizing it for enterprise use.

This reminds of a cartoon:http://www.savagechickens.com/2011/06/corporate-survivalist.html

I think I understand what you are saying. And I agree with that. Yet - to clarify - I'm talking about a different kind of studies. The ones conducted by an independent trusted third party, not the usual marketing fluff one would find on a vendor Web site. The ones that a person somewhere up the hierarchy would pay $2K-$10K for - in a form of a report or an industry conference. Not a study of Scala in particular but a study that mentions and compares Scala with other technologies, putting it at some advantageous coordinate in a "magic quadrant", and thus legitimizing it for enterprise use.

A lot of developments that may seem incidental and organic are in fact initiated and accelerated by persistent organized effort behind the scenes... I think the world needs a good Scala conspiracy :-)

Although true, the ironies about this are simply impossible to ignore. Java, an, hrm, what euphemism shall I use, underwhelming language when it was introduced was increasingly adopted over several years due to such a conspiracy. This adoption probably has set back the popular propagation of eminently worthwhile language features[1] more than a decade. Even today, after millions of man-hours poured into the JVM features are missing from it that were proved useful more than 30 years ago[2]. Scala, one of several languages that have brought to the JVM some of the fruits of decades of research in language design, finally seems to be capturing the attention of people who work on the JVM (often coming from a Java-based background) and to further its adoption we have to concoct a new conspiracy. Although I understand why such things need be done it doesn't make one feel any less dirty :-/.
-- Jim Powers
[1] First-class functions for starters, the list runs on for a while from there.[2] Tail-call-optimization anyone?

Although true, the ironies about this are simply impossible to ignore. Java, an, hrm, what euphemism shall I use, underwhelming language when it was introduced was increasingly adopted over several years due to such a conspiracy.

That's what a people don't understand: Java succeeded because it simplified things. It imposed itself not because it gave users power but because it remove tediousness.
As for being "underwhelming", there is a bit of 20/20 hindsight going on there: it was a pretty revolutionary language in 1995, and not just because it popularized garbage collection.

This adoption probably has set back the popular propagation of eminently worthwhile language features[1] more than a decade.

All the languages that offered such features at the time (and before) never succeeded, so I think that not supporting them was a pretty good decision in hindsight.

Even today, after millions of man-hours poured into the JVM features are missing from it that were proved useful more than 30 years ago[2].

TCO is useful but it would certainly not appear in the top ten features that a language needs to support in 2011. Much less in 1995.

On Saturday June 18 2011, Cédric Beust ♔ wrote:
> On Sat, Jun 18, 2011 at 7:22 PM, Jim Powers wrote:
> > ...
>
> > This adoption probably has set back the
> > popular propagation of eminently worthwhile language features[1]
> > more than a decade.
>
> All the languages that offered such features at the time (and before)
> never succeeded, so I think that not supporting them was a pretty
> good decision in hindsight.

The better is the enemy of the good and that was Java's advantage in the
late 90s and onward. Now it can reasonably be argued that Scala (and
other newer languages) have turned the tables on Java.

So it goes. And I think we can all agree it ain't over yet, though I
think we in the Scala community can expect a decade at least before
some language, probably as-yet uninvented, pulls the same trick on
Scala.

This entire conversation is pointless. It has been demonstrably proven that the lack of a killer application is not a barrier to wide adoption and it is also quite apparent that killer apps, in any event, tend to come from a clear blue sky.I want a massive yachtIn order to buy a massive yacht, I need only be a billionaire.Simple - I have reduced my problem to making a billion dollars!Who has a billion dollars?Why, Larry Ellison does!Let's do what Larry Ellison did...Except, of course, most billionaires became billionaires precisely because they were doing something which other people were *not* doing. So now the problem is reduced to: must create something really amazing that no-one has done before.If any of us knew how to do this, we wouldn't give a stuff about scala/Java/Haskell but would instead be sipping cool martinis (*) on a yacht somewhere in the south Pacific (**)Chris* - or cocktail of your choosing** - or paradise of your choosing

As for being "underwhelming", there is a bit of 20/20 hindsight going on there: it was a pretty revolutionary language in 1995, and not just because it popularized garbage collection.

False. There has never been a time in Java's history where it has been revolutionary, that was it's primary selling point. This is not 20/20 hindsight: I was an active software developer before Java came on the scene. It succeeded because of a well-run marketing campaign on the part of Sun. What is relevant is all of my points are irrelevant as a matter of history. Today we have things like HotSpot-enabled JVMs(among others), likely the only worth-while product(s) of the Java era, and Scala (among others) is bringing aspects of modernity to it. Going back to the the main point of the original post: are there Scala-related applications that can be called "killer". I don't think so, and I don't think that "killer" in the form of applications and/or tools (built in and around Scala) is going to have much meaning. The reality is that Scala is "killer" itself merely because it is popularizing (on the JVM) language features that were worked out ~post-1980 (and some that date back to the 50s).

This adoption probably has set back the popular propagation of eminently worthwhile language features[1] more than a decade.

All the languages that offered such features at the time (and before) never succeeded, so I think that not supporting them was a pretty good decision in hindsight.

Nonsense. Consider this: JavaScript had first-class functions since it appeared in 1995. Today, thanks to browsers, it is the most widely disseminated language ever (of course it has plenty of its own warts). Many people are picking up JavaScript as their first language because of trivial access to the necessary tools and run-times for the language. I don't see the streets littered with exploded heads as a result of using features still considered too "advanced" for Java programmers.

Even today, after millions of man-hours poured into the JVM features are missing from it that were proved useful more than 30 years ago[2].

TCO is useful but it would certainly not appear in the top ten features that a language needs to support in 2011. Much less in 1995.

Again nonsense. What was the TCO for Java in 1995? Effectively infinite (or some very large number): few people knew the language and other languages (C/C++) were well-established at the time and you could find developers with those skills on every street-corner. Garbage collection was the only thing Java had to offer (remember: interpreted only, JIT didn't show up until 1997[still green threads], HotSpot showed up in 2000). Even the "write once run everywhere" mantra was a falsehood for many many years (it's still dubious today).
Again, all of this is irrelevant. Scala's TCO, since it is designed to "fit into" the Java eco-system well, it going to include the cost of exploded heads of people who, in 2011, cannot grock first-class functions, type constructors, algebraic data types, etc. For those individuals and organizations who can "survive" such a transition, payoffs (or profit!) awaits. For others, well, better luck next time I guess.
-- Jim Powers

As for being "underwhelming", there is a bit of 20/20 hindsight going on there: it was a pretty revolutionary language in 1995, and not just because it popularized garbage collection.

False. There has never been a time in Java's history where it has been revolutionary

Not even applets?
How many technologies were there in 1996 that let you run stuff in your browser?I have many other examples in mind but the problem with being categorical with statements such as "False" is that it only takes one counter example to prove you wrong (not that I think you'll accept it anyway).

, that was it's primary selling point. This is not 20/20 hindsight: I was an active software developer before Java came on the scene. It succeeded because of a well-run marketing campaign on the part of Sun.

Sun's marketing didn't really start until the late 2000. Before that, you just had the main Java creators hanging out at the regular OO conferences, spreading the word (the earlier I remember hearing about Java was OOPSLA in 1995 in Monterey) and demonstrating HotJava (another fairly revolutionary product, if you ask me).

What is relevant is all of my points are irrelevant as a matter of history. Today we have things like HotSpot-enabled JVMs(among others), likely the only worth-while product(s) of the Java era

And the fact that millions of lines of Java code power most of the web sites that you visit on a daily basis, but I guess that's a detail to you.

This adoption probably has set back the popular propagation of eminently worthwhile language features[1] more than a decade.

All the languages that offered such features at the time (and before) never succeeded, so I think that not supporting them was a pretty good decision in hindsight.

Nonsense. Consider this: JavaScript had first-class functions since it appeared in 1995.

And this invalidates my point because Javascript was extremely popular in 1995, right?

Again, all of this is irrelevant. Scala's TCO, since it is designed to "fit into" the Java eco-system well, it going to include the cost of exploded heads of people who, in 2011, cannot grock first-class functions, type constructors, algebraic data types, etc.

Yeah, yeah, anyone not understanding functional programming is doomed to poverty and unemployment.We've heard that one before.
-- Cédric

The stated intention of this discussion is to think of how Scala is
penetrating or is going to penetrate the wider market. But yes, some
of this conversation is pointless bantering by Scala fans :P.

> It has been demonstrably proven that the lack of a killer application is not a barrier to wide adoption...

I'd be interested in hearing you go into more detail on this point. We
have already come up with several examples of popular languages that
have required an external force to bring it to prominence. Some of
them languished for many years until their killer application/feature/
platform came along. Just to revisit one example: If you want to
program the JVM, for a long time your only option was Java. It also
came up during the panel at Scala Days that Java achieved prominence
because it was what you used to write applications for the popular
application servers. In either case, Java the language did not achieve
prominence due to any inherent quality: While you "chose" Java, your
true intention was to program the JVM or to write a Web app.

The bigger point, expressed in several ways by several different
people already, is that incremental improvements to an incumbent
technology is not a compelling business proposition.

> and it is also quite apparent that killer apps, in any event, tend to come from a clear blue sky.

I like to think that we have already anticipated several in this
discussion. And in the case of Java, several insights motivated its
creation. One was that the rapidly gaining popularity of the World
Wide Web needed a programming language. Indeed, while applets did not
work out, J2EE/"Java EE" was not accidental or unanticipated. The JVM
similarly solved a pressing need. These hardly came from a blue sky
IMO.

People have stated elsewhere that, in addition to these insights,
which are technical, Sun *made sure* they were known through extensive
marketing. The killer app idea aside, which I'm glad has generated
this much discussion, we need to keep in mind that we have to compete
on more than just language features.

> I want a massive yachtIn order to buy a massive yacht, I need only be a billionaire.Simple - I have reduced my problem to making a billion dollars!Who has a billion dollars?Why, Larry Ellison does!Let's do what Larry Ellison did...
> Except, of course, most billionaires became billionaires precisely because they were doing something which other people were *not* doing. So now the problem is reduced to: must create something really amazing that no-one has done before.

Your analogy is perhaps intended to show that we are reducing our
problem to something that is at least as hard as itself. On the
contrary, we have come up with several possibilities already. At least
one is an open research problem (see the Pervasive Parallelism Lab),
the solution of which will definitely meet your criterion of
originality. I don't know much about the build tools market, but we
have insight from an insider that there is room for disruption.

Personally, I've been hearing quite frequently that "the free lunch is
over". This is in reference to the slowing progress we are making in
single-core performance and the corresponding need for parallelism in
software. This is a real problem that people are clamoring to find a
solution for and is something that members of the Scala community can
set out to solve (and they are!).

> If any of us knew how to do this, we wouldn't give a stuff about scala/Java/Haskell but would instead be sipping cool martinis (*) on a yacht somewhere in the south Pacific (**)
> Chris
> * - or cocktail of your choosing** - or paradise of your choosing

On the contrary, many of us here are language enthusiasts. Surely,
some of us would be sure to at least bring a notebook computer loaded
with the latest PLDI conference proceedings for some "light" reading!
Indeed, this very fact, which others and I have asserted, cloud our
judgment on what may or may not influence someone else's language
choice.

As for being "underwhelming", there is a bit of 20/20 hindsight going on there: it was a pretty revolutionary language in 1995, and not just because it popularized garbage collection.

False. There has never been a time in Java's history where it has been revolutionary

Not even applets?

No. Applets first appeared in HotJava (~1997). Implementing Applets in a browser implemented in Java was a straight-forward outcome of building such a browser in the first place. ActiveX controls showed up in IE 3 ~1996. This, is, of course, sticking to browsers. I was automatically shipping around executable code over the Internet as part of my senior-thesis project work at collage (~1988). I certainly don't mean to trivialize the work that has since gone on to make distribution of code on the internet (especially inside of browsers), but this work is merely a logical continuation of previous work.

How many technologies were there in 1996 that let you run stuff in your browser?

I have many other examples in mind but the problem with being categorical with statements such as "False" is that it only takes one counter example to prove you wrong (not that I think you'll accept it anyway).

The evidence is not in you favor. Also, if you wish to be pedantic rather than honest, you'll eventually nail me on some triviality enabling you to ignore the preponderance of the evidence in favor of the view that Java represented a very conservative, incremental, market play by Sun rather than some meaningful advancement in language and runtime design.

, that was it's primary selling point. This is not 20/20 hindsight: I was an active software developer before Java came on the scene. It succeeded because of a well-run marketing campaign on the part of Sun.

Sun's marketing didn't really start until the late 2000. Before that, you just had the main Java creators hanging out at the regular OO conferences, spreading the word (the earlier I remember hearing about Java was OOPSLA in 1995 in Monterey) and demonstrating HotJava (another fairly revolutionary product, if you ask me).

Yes, but that version of HotJava did not include applets. Applets came later. Granted HotJava was cool, but it was a browser written in Java running in an interpreter, do you doubt that such an accomplishment could not be achieved using any other language running on any other interpreter? Further, significant marketing efforts on Sun's part began in earnest with the release of Java 2 (1.2) ~1998.

What is relevant is all of my points are irrelevant as a matter of history. Today we have things like HotSpot-enabled JVMs(among others), likely the only worth-while product(s) of the Java era

And the fact that millions of lines of Java code power most of the web sites that you visit on a daily basis, but I guess that's a detail to you.

No, it's not a detail, and I was confining my points to the Java language and the run-times that have since emerged, not to "all the stuff written in it". Safe to say that much of the Internet "as I know it" is also written in PHP, I'm not interested in assessment of programming language "goodness" as a function of popularity.

This adoption probably has set back the popular propagation of eminently worthwhile language features[1] more than a decade.

All the languages that offered such features at the time (and before) never succeeded, so I think that not supporting them was a pretty good decision in hindsight.

Nonsense. Consider this: JavaScript had first-class functions since it appeared in 1995.

And this invalidates my point because Javascript was extremely popular in 1995, right?

Making claims that language popularity is a good indication of the quality of language design is useless. The designers of JavaScript had the forethought to include first-class function values because it was useful. Given this feature alone many control-flow options open up. Java's paternalistic view of what programmers "need" is hardly inspiring

Again, all of this is irrelevant. Scala's TCO, since it is designed to "fit into" the Java eco-system well, it going to include the cost of exploded heads of people who, in 2011, cannot grock first-class functions, type constructors, algebraic data types, etc.

Yeah, yeah, anyone not understanding functional programming is doomed to poverty and unemployment.We've heard that one before.

Never made this claim, never will. The programming world is polyglot by nature (I still regularly see advertisements for COBOL programmers in the New York Times). I have no illusions about Scala's success trajectory. Gaining some (as yet undefined) % of the total JVM-based development will constitute success. I expect that most of the development on the JVM will remain firmly with Java, and Scala, along with Clojure, JRuby, Groovy, etc. will (in total) acquire a healthy minority share of JVM development. What Scala has to offer is: type less, get more done, better. I evangelize is point of view because I think that Scala can do this better than its competitors on the JVM. If you're not on the JVM then please learn Haskell (or Racket).
-- Jim Powers

Yeah, yeah, anyone not understanding functional programming is doomed to poverty and unemployment.We've heard that one before.

Never made this claim, never will.

Sorry for misinterpreting but"For those individuals and organizations who can "survive" such a transition, payoffs (or profit!) awaits. For others, well, better luck next time I guess."
kinda sounded like it.

The programming world is polyglot by nature (I still regularly see advertisements for COBOL programmers in the New York Times). I have no illusions about Scala's success trajectory. Gaining some (as yet undefined) % of the total JVM-based development will constitute success. I expect that most of the development on the JVM will remain firmly with Java, and Scala, along with Clojure, JRuby, Groovy, etc. will (in total) acquire a healthy minority share of JVM development.

Agreed.

What Scala has to offer is: type less, get more done, better. I evangelize is point of view because I think that Scala can do this better than its competitors on the JVM. If you're not on the JVM then please learn Haskell (or Racket).

Depends for what purpose, I guess. To get a job outside the JVM, .net is an obvious choice. For personal curiosity, Haskell should definitely be on the short list, along with a few other ones.
-- Cédric

Sun's marketing didn't really start until the late 2000. Before that, you just had the main Java creators hanging out at the regular OO conferences, spreading the word (the earlier I remember hearing about Java was OOPSLA in 1995 in Monterey) and demonstrating HotJava (another fairly revolutionary product, if you ask me).

I think we need to consider marketing wider - as a two-way communication between the vendor and the customers. In that vein, let me insert some less-known facts:
(1) Sun's Java marketing started in earnest in 1995, with release of front-page article about it in Mercury News (Silicon Valley major newspaper) and announcement at SunWorld.
(2) By 1996, Java was known widely enough to draw huge crowds to a first JavaOne conference at Moscone Center in San Francisco, where Java was "sold" to enterprise developers not only by Sun, but also by Netscape and other influential companies. I was there, and the very first conference was already enormous and beautifully choreographed markering event.
(3) In 1997, Microsoft joined the fray with Visual J++, supported by huge marketing budget, in a bid to "embrace and extend" Java. Everybody in the Microsoft developer community learned about Java and could try it out using familiar Visual Studio tools. This effort only ended in 2004.
(4) In 1996 and 1997, pioneering Java enterprise projects were given huge priority by the Sun top brass. Senior VP would come to a project site and listen to praises and complaints from "the front-line trenches". I've been there, so this is a first-hand knowledge. That's how Sun got the whiff of Java failing as applet platform but getting surprisingly robust traction on the server side. Focus and investment patterns were quickly adjusted.
(5) Sun hardware was provided with discounts to pioneering Java shops in 1996 and 1997 and some of it for free (e.g. JavaStations - the ill-fated thin client that could only run Java byte code). There was never-ending stream of marketing and educational materials, books and training presentations sponsored by Sun.
So, Java's quick rise can be attributed to many factors, yet we shouldn't discount Sun's smart and aggressive marketing from the get-go.

Wow, that is really good info, Sergei. I am particularly impressed by
bullet point #4, which stated that the top brass at Sun listened to
market feedback and very deliberately made the appropriate
adjustments. Not too different from how Martin is known to mingle with
actual developers at events like Scala Days, which is good for Scala.

Altogether, I like that you frame marketing as a "two-way
communication between the vendor and the customers", whereas elsewhere
in this conversation, it has been demonized. Really, as you have
shown, it doesn't have to be evil; it can be a vehicle for ensuring
that users' needs are met.

Now that you brought this up, I wonder if a panel discussion on how to
convince someone to use Scala at Scala Days, where almost everyone is
already sold on Scala, is more cathartic than effectual. The marketing
efforts and the conversation have to extend beyond those interested
enough in Scala to pay money to become attendees at a two-day
conference.

-Darwin

On Jun 19, 12:34 pm, Sergei wrote:
> 2011/6/19 Cédric Beust ♔
>
> > Sun's marketing didn't really start until the late 2000. Before that, you
> > just had the main Java creators hanging out at the regular OO conferences,
> > spreading the word (the earlier I remember hearing about Java was OOPSLA in
> > 1995 in Monterey) and demonstrating HotJava (another fairly revolutionary
> > product, if you ask me).
>
> I think we need to consider marketing wider - as a two-way communication
> between the vendor and the customers. In that vein, let me insert some
> less-known facts:
>
> (1) Sun's Java marketing started in earnest in 1995, with release of
> front-page article about it in Mercury News (Silicon Valley major newspaper)
> and announcement at SunWorld.
>
> (2) By 1996, Java was known widely enough to draw huge crowds to a first
> JavaOne conference at Moscone Center in San Francisco, where Java was "sold"
> to enterprise developers not only by Sun, but also by Netscape and other
> influential companies. I was there, and the very first conference was
> already enormous and beautifully choreographed markering event.
>
> (3) In 1997, Microsoft joined the fray with Visual J++, supported by huge
> marketing budget, in a bid to "embrace and extend" Java. Everybody in the
> Microsoft developer community learned about Java and could try it out using
> familiar Visual Studio tools. This effort only ended in 2004.
>
> (4) In 1996 and 1997, pioneering Java enterprise projects were given huge
> priority by the Sun top brass. Senior VP would come to a project site and
> listen to praises and complaints from "the front-line trenches". I've been
> there, so this is a first-hand knowledge. That's how Sun got the whiff of
> Java failing as applet platform but getting surprisingly robust traction on
> the server side. Focus and investment patterns were quickly adjusted.
>
> (5) Sun hardware was provided with discounts to pioneering Java shops in
> 1996 and 1997 and some of it for free (e.g. JavaStations - the ill-fated
> thin client that could only run Java byte code). There was never-ending
> stream of marketing and educational materials, books and training
> presentations sponsored by Sun.
>
> So, Java's quick rise can be attributed to many factors, yet we shouldn't
> discount Sun's smart and aggressive marketing from the get-go.

False. There has never been a time in Java's history where it has been revolutionary

Not even applets?
How many technologies were there in 1996 that let you run stuff in your browser?

Seriously: I was writing plug-ins for Netscape 1. Not cross-browser, to be sure -- but on the other hand, writing genuinely sophisticated cross-browser Java applets in the Netscape/IE 3 generation was *fiendishly* difficult. I pulled it off, but it took many months of frustrating, hair-pulling effort. (Dear lord, I remember the horror of trying to navigate the just-contradictory-enough security models.)
And in general, Java the *language* was good but not revolutionary at the time. I mean, I was tangentially involved with the Ada '95 effort. That language was a fair bit more sophisticated than Java in many ways, and coming from a government project -- rarely the best recommendation for a revolutionary programming language.
Java did a pretty good job of consolidating a bunch of ideas that were then cool. But as a language, it didn't do anything revolutionary -- it just pulled together a bunch of good strands, to make a solid step in *standard* practice at the time. In that, I tend to think of the current best cognate as C#, which has consistently sat behind the state of the art but tended to pull good ideas into the mainstream. Scala is in a sense doing the same (not too much is genuinely *revolutionary*), but a major leap further ahead in doing so, not being as conservative about it. (And being much more careful than usual to do everything in an internally-consistent way, which is quite refreshing...)