addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupsimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1outlookpersonJoin Group on CardStartprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [ljc] Why hasn't Scala and functional programming taken off

From: Kevin W.
Sent on: Friday, October 4, 2013 9:28 PM

There's a killer app alright, if being able to program on upcoming iterations of hardware can be considered an app.  Herb Sutter described it very well in this article from 2004:

The trend is to take all those extra transistors from Moore's law, and push them into making extra cores.  We've already gone as far as we can in using them for speed (and this includes using a substantial potion of the die for L1 cache).  If anything... the trend is now to make the cores smaller and slightly slower; both so that you can fit more on and to make big cuts in power consumption.

This is best seen in GPUs.  Just look at the 7000 series radeons - the 7750 has 512 cores and is efficient enough that it can be cooled with just a heatsink (no fan required).  Successive models in the series add cores 100s at a time, with the 7970 offering a whopping 2048.  This is enough that they can afford to just disable 256 of them to produce the cheaper 7950.

So many cores that you can afford to lose 256 of them to defects and still have an awesome amount of power available... It bears thinking about!

Admittedly... We don't program GPUs with Java or Scala (yet); not unless you're using something like JavaCL or ScalaCL, although Oracle *do* have plans afoot that will allow the JVM to use the GPU as a resource. More importantly, GPUs tend to be trendsetters, so you'll be seeing those kind of numbers on your CPU well within your career.  It's hard to imagine, but our brains simply aren't hard-wired for usable instincts about exponential growth.

You can already buy a mobile phone with 8 cores.  Following More's law that'll be pushing 100 cores in a mere 3 years, and 1000 cores 3-4 years later.  That 1000 cores, on a *mobile phone*, within a decade.  GPUs will probably plateau a bit once they hit one core per pixel (and that's on 4K screens) but it does mean we'll finally have ubiquitous real-time ray tracing.

Time and again, studies have shown that thread and synchronisation based concurrency can't be effectively scaled to that level, so shared mutable state is simply not an option.  Given how soon we'll have thousands of cores on even mobile phones, and that heavy use of immutable objects is the only way to effectively manage them, FP is the only game left in town.

On 4 October[masked]:42, Stephen Henderson <[address removed]> wrote:
Thinking about it, maybe another reason that Scala and the other FP languages have been growing slower than might be expected is the lack of an obvious 'killer app'.

With the other languages which really took off in the last 10 years they generally addressed a big gap in the ecosystem and it was immediately obvious how they could make life easier. e.g. going from perl to python or ruby for doing scripting or php to Rails for web development. In these cases you could immediately see how the language would make your life easier and save time/money from doing a couple of tutorials or watching a presentation.

Scripting languages like Python and Ruby in particular were also less affected by lack of tooling because a lot of the typical use cases don't need a full IDE anyway.

Going from java to scala is much more subtle and other than saving on verbosity there's no immediate gain in productivity on this kind of scale.  There are gains to be had long term in the sense that you have all the FP tools to approach problems but it's not an overnight improvement. Coupled with the tooling issues it's been a hard switch to justify if your team is comfortable with java (and java's still a perfectly good language for a lot of use cases).

I think that's starting to change though as more mature frameworks are coming out. The Play 2.0 framework and Akka have been fairly major ones for Scala in the last 18 months (yes, you can use them in java as well but it can be ugly) and Play in particular was the game changer for us. (for anyone who hasn't tried it I really recommend having a play with the Typesafe Activator it's a very nicely done interactive tutorial on scala/akka/play which also includes corresponding examples in java for reference).


Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy