Impact of Lambdas
Java 8 will introduce functional programming blocks into the mother language, Java, which of course you already know is object oriented in concept. The new concept is Lambdas. Java will have an element of functional programming, but it will not be functional, far from it. For many Java developers, that will be enough. For the minority of engineers who have experienced new ideas ever since Bruce Tate‘s famous foray in his book Beyond Java, this will not be enough. Again this is a prediction that I suppose is fairly standard, those developers will stay with Scala, Groovy, JRuby, or Clojure or whatever suits their fancy. Oh, the term Lambdas is derived from the computer science calculus invented by Alonzo Church, who is famous with Alan Turing for a important mathematical conjecture.
Lambdas will change the game in the Java programming language. The new Java Collection Library, which will embrace Lambdas, will force new library changes for all open source frameworks. As a library maintainer, I think, then, Lambdas force you to evolve your API, rewrite it from scratch, adapt it or let your software degrade and become legacy. Humble library maintainers, however, have a finite amount of time to change. The question is, will they do so?
I believe that Lambdas will be a good stepping stone for learning. It can only help the popularity of Scala and other alternative JVM languages that have had functional blocks for several years already. Lambdas are desperately late to the programming language game and yet the rewards will give Java another bolt of life well to the next decade.
Where Scala goes from here, nobody truly knows and such a generic statement is too obvious and my intention is not to patronise. The original push for Scala the programming language was that nice cosy feeling of marrying functional programming with object-orientated concepts. The hybrid does actually work, yet criticism still abounds around Scala’s complexity. The advanced Scala practitioners, themselves, have to look at the ease-of-development features and the simplicity surrounding their own library works. One would hope that these libraries can improve and be more relevant for new learners. The name of the game is all about onboarding customers (my own synonym for non-paying developers). The future of Scala is very much dependent on the idea of mindshare. New engineers to the language and ecosystem will have a standard set of questions. They will ask a lot of them: can I be productive in Scala? A yes or no answer suffices here. Will it help me in the future? What is the use of functional programming anyway? Is it worthy of my investment of quality time? I don’t want to bet on the wrong technology, because it is time that I can never get back. As a developer you will have to answer these questions for yourself.
As to prove a point in my paragraph. I, myself, have had to drop the Scala programming ball so-to-speak. I also stopped my JavaFX coding in my free time too for several months. Because I just finished writing a big Java EE 7 book that in reality took all my time. I suspect there are other people who, like me, caught the Scala early interest bug, who also had other necessary distractions. These are deflections from further Scala adoption and from further learning. Nevertheless, I am fascinated with Scala still, because it is one window to the functional programming world without leaving the JVM. I prefer Scala over Clojure: my bag and my football. I do hope to be back at the ACCU 2014 in Bristol with a new Scala talk that raises the bar higher.