The future of the programming languages. What about Java?

I hope you had the opportunity to watch the video of “The future of the programming language“. This conference is led by Anders Hejlsberg, the architect of C#. He explains simply what, on his opinion, will be the next generation of languages. The main points are:

His presentation is really good and clear. I have learnt many things and I’m convinced that the Microsoft laboratories are ones of the best labs in the world. At the end of the show, he says that he doesn’t understand why Java don’t have functional approach at this time. As a Java developer, I have to admit that the .net platform becomes really powerful. I like the idea of programming using the language of your choice.

Functional programming

Anders gives a brief overview of what the functional programming is. For sample, with Imperative languages, it’s quite common practice to write:

x=x+1

Since we have programmed in this way for many years, sometimes we forget that other scientists don’t use the same reasoning. In mathematics, you should write a function as:

y=x+1

The calculation of y doesn’t change the value of x. On this example, it seems easy to think like this. To illustrate this sample, just imagine that a class named “Number” in Java.

public class NumberImperative {
    private int _value;
 
    public NumberImperative(final int value) {
        _value = value;
    }
 
    public int getValue(){
        return _value;
    }
 
    public void add(final int numberToAdd){
        _value += numberToAdd;
    }
 
    public void substract(final int numberToSubstract){
        _value -= numberToSubstract;
    }
}

and a second solution:

public class NumberFunctional {
    private final int _value;
 
    public NumberFunctional(final int value) {
        _value = value;
    }
 
    public int getValue(){
        return _value;
    }
 
    public NumberFunctional add(final int numberToAdd){
        return new NumberFunctional(_value + numberToAdd);
    }
 
    public NumberFunctional substract(final int numberToSubstract){
        return new NumberFunctional(_value - numberToSubstract);
    }
}

I know that you would like to write: int y = x + 1;. but it is not what we’re talking about here ;-) . These two samples of code gives basic knowledge of the two approaches. So to test these codes, we use this simple class:

public final class DemoNumber {
    public static void main(final String[] args) {
        final int x = 5;
        // imperative
        final NumberImperative numberImperative = new NumberImperative(x);
        numberImperative.add(1);
        System.out.println("imperative: " + numberImperative.getValue());
 
        // functional
        final NumberFunctional numberFunctional = new NumberFunctional(x);
        final NumberFunctional resultNumberFunctional = numberFunctional.add(1);
        System.out.println("functional: " + resultNumberFunctional.getValue());
    }
}

And the output is:

imperative: 6
functional: 6

I imagine your face at this time: “this guy loves to write a lot of lines of code!”. Remember that it is just a case study and in real-life, we don’t need to write this kind of class. If you are used to develop thread-safe code, you have recognized that the functional implementation is an immutable class and you know that it is the easier way to solve concurrent issues. The JDK has a lot of immutable classes that you instantiate all the time: String, Integer, Double, etc.

Concurrent programming will become a must-have competency in the next years: this is how we can consume the multi-core microprocessors. With the NumberImperative class, we will have side-effects on runtime since the member “_value” is not synchronized. And even if we synchronize this field, we can have race conditions if the following method is called by two threads with the same reference:

public void atomicProblem(final NumberImperative numberImperative){
        if (numberImperative.getValue() == 0){
            numberImperative.add(1);
        }
    }

If you have read the Brian Goetz’s book “Java Concurrent in practice“, you probably use annotations in your own code. We would annotate the NumberImperative class with @NotThreadSafe and the NumberFunctional with @Immutable.

Functional languages are immutable by default. If we want to make a field mutable, we must add a keyword. For sample, using Closures, you may have a look at Refs and Transactions. Using F#, the mutable keyword exists. In Scala, the “var” and “val” keywords are available.

The unavoidable migration

The current problem we have is that it is pretty hard to build a thread-safe software because JCIP annotations are not used enough. The standard Java classes are not annotated and if someone in your team doesn’t read the Brian Goetz’s book, he/she probably doesn’t know how to write thread-safe classes and annotate them. In my team, I always consider that: if a class doesn’t have a JCIP annotation then it is not thread-safe. But such a great tool as Findbugs doesn’t help you if you don’t annotate your classes. So, it is still hard to find concurrency bugs.

So, how to force programmers to go to concurrent programming? I personnaly think that we can’t tell to every Java developers to check their code against concurrenry issues. I’ve met a lot of coders who don’t like to read books so, the JCIP book won’t be a solution. Java has been created in 1995 by James Gosling: it was 14 years ago. At this time, the only solution we have found to build concurrent software in Java is to increase its verbosity (annotations) and to launch static analysis tools on code. But you know that tools doesn’t reduce the complexity, it just enables you to manage it. On my opinion, to force people to learn new methodologies, a new language is unavoidable. In this way, developers will have to learn, to change their habits.

Do you need to give up Java?

Presently, the answer is certainly no. Java is popular and it will take time before the community wants to change for another language. I think new languages are for early adopters and new languages will take years to rise. In this article, we can read

If it is true that bloggers express some concerns about Java’s future, Daniel Weinreb stresses that “it’s used in so many places now that we’re very unlikely to see it disappear” and, according to James Iry, “it is still and will remain for quite awhile one of the a handful of “safe” choices for an IT manager”

So, as a Java developer, we have to prick up one’s ears on the market and to prepare ourselves to a migration in the next five years. Currently, we always have to develop concurrent code using the existing tools and so, we must read Brian Goetz’s book and be really careful when we write code in a multi-threaded context.

And you, what do you advice to Java developers?

EDIT: I see that the opinions on this post are mixed on Dzone. Comments about your agreement or your disagreement are welcome: please share your point of view.

EDIT2: I have written a post to precise my conclusion here.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Reddit
  • Yahoo! Buzz

11 Comments

Comments 21

  1. James Iry wrote:

    Scala doesn’t have a “ref” keyword. It has “val” which is more or less the same thing as declaring a variable final in Java. It also has def, but that’s just the keyword used to define a method or function (Java doesn’t use one, but many languages do). Here’s what your example code looks like in Scala

    case class NumberImperative(var value : Int) {
    def add(numberToAdd : Int) = value += numberToAdd

    def subtract(numberToSub : Int) = value -= numberToSub
    }

    case class NumberFunctional(value : Int) {
    def + (numberToAdd : Int) = new NumberFunctional(value + numberToAdd)

    def – (numberToSub : Int) = new NumberFunctional(value – numberToSub)
    }

    object DemoNumber {
    def main(args : Array[String]) {
    val x = 5;

    val numberImperative = NumberImperative(x)
    numberImperative add 1
    println(”imperative: ” + numberImperative.value)

    val numberFunctional = NumberFunctional(x)
    val resultNumber = numberFunctional + 1
    println(”functional: ” + resultNumber.value)
    }
    }

    Imperative or functional, Scala is still cleaner.

    Posted 19 Apr 2009 at 4:33 am
  2. ModernRonin wrote:

    > the declarative aspect (concentrate on the what and not on the how) I always laugh my ass off when people bring this point up. It sounds good, on paper. But then you start to think about it a little harder and you realize that we already have a language that is purely "what" and says nothing about "how". That language is SQL. And everyone *hates* it. It’s dense and cryptic when it’s not being overly verbose and annoying. And performance? Forget it. You pay $100k/yr for an Oracle license so you can have the best query optimizer in the biz, and THE DAMN THING PICKS THE WRONG INDEXES, your queries crawl, and you end up having to dig down into the "how" layer anyway, manually hinting the damn DBMS so it’ll use the right ones. Everyone wants a language that DWIM. But it’s never going to happen. Even other people have trouble guessing WYM. You can forget about any computer based on current technology doing it. Like [the XKCD comic says](http://www.xkcd.com/568/) – no programming language can save you from your own mental imprecision and abstractional ambiguity.

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 9:34 am
  3. bob wrote:

    I seriously hope that your not trying to support a new concurrency model for java as modeled in other languages just because java.lang is not annotated.

    That is the most ridiculous thing I have ever heard.

    Posted 19 Apr 2009 at 10:44 am
  4. adam77 wrote:

    He makes a good point about functional languages (as in no side effects)* being better suited to parallel processing. ** higher order functions don’t make a language functional/declarative

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 10:55 am
  5. coder-friendly wrote:

    Hello James Iry,
    Sorry for the error. I have never developed in Scala at this time. So, thank for your explanation.
    Coderfriendly

    Posted 19 Apr 2009 at 11:01 am
  6. coder-friendly wrote:

    Hello Bob,
    I know that it may sound ridiculous but for me, it’s not. Previously, I was convinced that the verbosity of Java was not a problem. Here, I just say that, for me, it is a problem to code without those annotations. I always need to read the documentation to know whether the classes are thread-safe or not (and it is common to not find the information). And when you use a lot of external APIs, it is terrible to develop in multi-threaded systems.
    If we develop a new system with new APIs developed by great coders, then, I’m okay, Java is right for developing concurrent program. But, in the real world, I have never seen this kind of project.
    I don’t say that it is the only reason to look at other languages, it is just the one which has the more impacts on my daily work. If we browse the blogs, we can find a lot of bloggers who explain their own reasons.
    I hope that this explanation let you understand (I don’t say share ;-) ) my point of view.
    Coderfriendly

    Posted 19 Apr 2009 at 11:08 am
  7. theone3 wrote:

    .NET is also doing all these things. What’s new?

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 11:37 am
  8. siva wrote:

    custom forths (small, simple and sexy) will be the future

    Posted 19 Apr 2009 at 1:30 pm
  9. dcueva wrote:

    1 Immutable classes are thread safe 2 Java is bad because it is not immutable by default 3 … 4. prepare to migrate!! Lame argument. It is easy to build immutable classes in java whenever you need them. Downvoted.

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 4:44 pm
  10. Michael wrote:

    I haven’t read Brian Goetz’s book but what is the rationel for annotating not-threadsafe versus threadsafe. It’s much more likely that ppl who write threadsafe classes to even be aware of threadsafety as opposed to ppl who write not-threadsafe classes – beginners and alike.

    Posted 19 Apr 2009 at 6:06 pm
  11. coder-friendly wrote:

    Hello Michael,
    Even if you are aware about thread-safety, you can make mistakes. Brian Goetz gives this definition: “A class is thread-safe if it behaves correctly when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, and with no additional synchronization or other coordination on the part of the calling code.” So, when you design a thread-safe class, you select a strategy on which the calling code can rely. You can read the javadoc of CopyOnWriteArrayList: the author has chosen between cost and efficiency. There are many articles of Brian Goetz on the developerWorks.
    I hope I have answered to your question.

    Posted 19 Apr 2009 at 6:37 pm
  12. dhjdhj wrote:

    I’m entertained by the comments at the top about writing x=x+1 In the Algol/Pascal world, we write x := x + 1 and read it as "x is assigned x + 1" thereby making it very clear that we are not expressing an equality.

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 6:48 pm
  13. ModernRonin wrote:

    For a long time I’ve been an advocate of throwing out "=" entirely, replacing it with "<-" for assignment and "==" for comparison. I.e.: i <- i +1; // i gets i + 1 i == 7; // is i equal to 7 i = 7; // ILLEGAL SYNTAX; COMPILE-TIME ERROR

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 8:35 pm
  14. Narrator wrote:

    Indeed, too much abstraction makes it hard to debug performance problems.

    This comment was originally posted on Reddit

    Posted 19 Apr 2009 at 8:38 pm
  15. ModernRonin wrote:

    To be fully clear – I’m not against the idea of more DWIM-y languages. I love perl, for example. I’m just skeptical that the DWIM thing is this miracle solution to all our problems. And SQL is a great example of how badly you can screw up with DWIM. Brooks told us that there were no silver bullets, but for some reason we keep proclaiming new fad X to be the silver bullet. Before DWIM it Agile. Before Agile it was OO. Before OO it was… etc.

    This comment was originally posted on Reddit

    Posted 20 Apr 2009 at 1:43 am
  16. taggart wrote:

    >Lame argument**:** It is easy to build immutable classes in java whenever you need them. Fixed. That something *can* be done in a language does not mean the language makes it easy (both in implementation and performance) to do. Sometimes [a different language](http://clojure.org/) is the right choice.

    This comment was originally posted on Reddit

    Posted 20 Apr 2009 at 2:09 am
  17. notoriginal wrote:

    I guess I don’t get the point. Perhaps = vs == is confusing for people totally new to programming, but after that I didn’t think it was an issue.

    This comment was originally posted on Reddit

    Posted 20 Apr 2009 at 7:11 am
  18. Dominique De Vito wrote:

    I am quite inline/agree with the 4 points ;-)
    (1) the Domain Specific Language (internal and external DSL)
    (2) the declarative aspect (concentrate on the what and not on the how)
    (3) the convergence between static and dynamic languages
    (4) the emergence of functional languages (imperative ones are not appropriated to multi-threading processing)

    (1) Almost everybody has noticed the rise of DSL out there. I can add some languages are more suitable than others for building DSL, like those derivated from Java: Groovy and Scala
    (2) the introduction of annotations, into a mainstream language like Java, is the beginning of the declarative road
    (3) static and dynamic languages do converge. For example, read my post about JS and Java: “A false piece of news may become real as Java and JS move closer” http://www.jroller.com/dmdevito/entry/a_false_piece_of_news
    (4) and, yes, functional languages do emergence. Java, and more than that, C#, have more and more functional features. I have written old posts (in 2005) about it: “Thoughts about Java, C# future and OCaml (?) relationships” – http://www.jroller.com/dmdevito/entry/thoughts_about_java_c_future – and “More ramblings on programming languages” – http://www.jroller.com/dmdevito/entry/more_ramblings_on_programming_languages – and more recently “Functional programming on-going adoption as a side-effect” – http://www.jroller.com/dmdevito/entry/functional_programming_on_going_adoption

    Posted 20 Apr 2009 at 10:29 pm
  19. coder-friendly wrote:

    Hello Dominique,
    Thank you for your comment. I have to admit that I have never used Groovy, I put it on my TODO list ;-) . I agree with your remarks on the declarative road of annotations. And I read your posts and I like one of your conclusion: “With other words, if you except something new in your life, just try to do also something new. So, why not trying FP?”.

    Posted 20 Apr 2009 at 11:06 pm
  20. Dominique De Vito wrote:

    I should mention here that this conclusion is derivated from an Einstein’s quote. Let’s give back to Einstein what it belongs.

    Posted 20 Apr 2009 at 11:43 pm
  21. dibblego wrote:

    > It is easy to build immutable classes in java whenever you need them. [No it isn't.](http://functionaljava.org/).

    This comment was originally posted on Reddit

    Posted 04 Jul 2009 at 11:23 am

Trackbacks & Pingbacks 2

  1. From The future of Java. Am I wrong? | Coder-friendly on 21 Apr 2009 at 8:13 pm

    [...] would like to come back on my last post named “The future of programming languages. What about Java?“. First, I want to thank you for your comments even when you express a disagreement: [...]

  2. From Evolving the Java language: generics were hard to implement | Coder-friendly on 09 May 2009 at 4:40 pm

    [...] a previous post, I’ve said that Java is not adapted to concurrency and that, in the next years, some [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

Additional comments powered by BackType