I’ve just come across an excellent article on eWeek titled Programming Superstars Eye Parallelism where some of the brightest computer scientists ever discuss on the Next Big Thing (TM).

James Gosling, creator of Java at Sun, Anders Hejlsberg, creator of Turbo Pascal at Borland and C# at Microsoft and Bertrand Meyer, creator of Eiffel reflect on “”What will you do with a 4,000-core machine?”

Multicore processors

Most of us buying computers now have dual-core processors like the Intel Core Duo I have on my MacBook. The same company has communicated on its Tera-Scale research program and has announced that 10-cores processors will be ready in two years. Intel is even experimenting with 80-cores processors…

Sun Microsystems already sells an 8-core processor with 4 hardware threads per core = 32 threads. It is, of course, the UltraSPARC T1 (Niagara) processor. It even has a successor called T2 which has 8 hardware threads per core i.e. 64 threads…

So the future is going to be massively multi-core.

The problem

Anders Hejlsberg says that “the models we have today for concurrency don’t work. Developers need to move an abstraction level up and he sees a resurgence of functional programming and its influences.” And the others agree.

Simply said, the way we program today (with C/C++/Java/C#/whatever) does not work on massively multi-core processors. This is because of state being shared among the cores and, hence, the necessity to use synchronization mechanisms a lot. The immediate consequence is that it becomes impossible to write programs which are free from deadlocks and starvation as the number of possible interleavings is massive. Exhaustive testing is impossible.

Functional programming to save the world

Joe Armstrong, the creator of Erlang, has spoken eloquently on why functional programming languages, which can be defined as languages without variables, are much more suitable to write concurrent (and parallel) applications than imperative languages that we all use today (like C/C++/Java/C#/etc)

Basically (and I quote),

    No Mutable Data Structures = No Locks = Easy to parallelize!

Incidentally, this is one of the reason I’m teaching Concurrency and Parallelism: I so deeply want functional programming to succeed!

I have been using Erlang for a month now to teach concurrent programming and, in my opinion, my students have loved it (and I too!)

Conclusion

The future is concurrent and parallel. And, according to the best, the future is also functional (very interesting things are happening in research, for example, F# and Data Parallel Haskell). Erlang is already here and is beautiful (and powerful).

I knew those hours I spent learning Scheme when I was younger were going to be useful.

I’m happy.

This Java program I got from a blog does not compile:

import java.util.*;

class Egg
{
}

class Muffin
{
}

public class Breakfast
{
  private List<Egg> eggs;
  private List<Muffin> muffins;

  public void add(List<Egg> moreEggs) {
    this.eggs.addAll(moreEggs);
  }

  public void add(List<Muffin> moreMuffins) {
    this.muffins.addAll(moreMuffins);
  }
}

The error message is:

name clash: add(java.util.List<Muffin>) and add(java.util.List<Egg>) have the same erasure

I was amazed when I saw that. I finally found an explanation in this forum.

What is happening is that (I quote) “Parameterized types (aka Generics) are only to restrict the use to enter the right object into the collection. All the generic information is erased by the compiler.”

So that why I got a name clash error. Both add(java.util.List<Muffin>) and add(java.util.List<Egg>) are in fact the same method add(java.util.List)!!!

Generics in Java are only used at compile time. They don’t even exist at run time!

PS:

I am a fan of Erasure, the group. Vince Clark was the initiator of Depeche Mode after all…