JavaScript?

The "Java of FP" could be C# or F# (although Microsoft isn't willing to go multi-platform, so that might stop it becoming "successful", by many definitions).

But honestly, I don't think there is a powerful enough vector available to carry FP. C had Unix. Java had the net. A novel way to think about the next "Java of FP" is to think of what vector could matter, and then what FP language is well-placed to be carried by it.

Mobile phones are all I can think of at the moment, but no FP has come of it; the netbooks (which are becoming phones) are plain ol' PCs; and the iPhone runs Objective-C (doesn't it?). What's the next IT revolution?

Actually, time_management is right: the next IT revolution is clearly multi-core.

EDIT: I keep hearing about Intel's CUDA for multicore on GPU's, but it's pretty much the anti-FP, being "recursion free" http://en.wikipedia.org/wiki/CUDA#Limitations

Data point one: the rise of the netbook. They have slower, single-core processors, and are fast enough for most of the mainstream stuff people want to do: web, email, word-processing. Netbooks are getting faster (and this is needed for some webapps e.g. that musical score webapp is a little sluggish on my eee PC). But what is more important in a netbook is weight and battery life - that is what is needed. Performance isn't needed.

Data point two: even in video games, the wii console is the most successful of the present batch. It is unusually low powered even for single-core (and in coincidence, one of its competitors, the PS3, is multi-core). Performance isn't needed.

Data point three (an exception): some applications do need performance (weather simulation; google server farms), but these are already multi-core, and have been for a long time (the core used to be in separate computers, but the app was multi-core).

I'm arguing that most of the mainstream market can't absorb faster performance (and the high-performance market has already solved the problem).

Ripe for Disruption?: It's common for whole industries to overshoot what is needed, in terms of the particular metric they have worked at improving for years. Their corporate organization, product development and marketing are based on improving that aspect, and selling that aspect. When the basis of competition shifts, you get a new set of leaders, because the old ones can't adapt.

http://www.galois.com/blog/2008/08/29/gpugen-bringing-the-po...

There's also something similar called Obsidian:

http://lambda-the-ultimate.org/node/3016

http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf

http://www.cse.chalmers.se/~joels/writing/dccpaper_obsidian....

Don't get me wrong: I like the intellectual challenge, and I especially like the Haskell community - they are nice people, excited about what they're doing, very helpful, and just not interested in putting down other languages - and I think there is real beauty in Haskell. It's like a branch of mathematics.

Disclosure: I'm terrible at Haskell's intellectual challenge. It makes me feel stupid. I hate that.

  sum ys = 
	  let sum' [] total = total
	      sum' (x:xs) total = sum' xs (total+x)
	  in sum' ys 0

It could be presented a bit differently, but the underlying idea seems approachable.

* I'm thinking of monads, in particular; whether they actually are or whether it's just due to the way they've been presented is another question.

Pattern matching is awesome. It makes code immensely more readable.

Also, having masses of Haskell blog posts saying, "No, monads are actually not that hard, here's (an explanation that probably won't actually make all that much sense)." probably doesn't help to dispel the myth that Haskell is hard / impractical / whatever.

  sum ys = sum' ys 0
    where sum' list total =
      case list of
        []   -> total
        x:xs -> sum' xs (total + x)

- algebraic types. haskell has type inference, so it can do the right thing while you only describe the function as operating on lists. now look at java...strong typing but no intelligent inference, which is why you are forced to write retarded java like HashSet<Integer> s = new HashSet<Integer>()

- pattern matching. you can describe functionality based on the pattern of the data

this isn't just syntax. these are really powerful fundamental features of the language

I guess that you don't know that generics in Java were derived from Haskell type classes and designed by the same man who added monads to Haskell.

  doSomething :: HashSet Int -> HashSet Int

It's true that you can omit most of the type signatures and let the compiler figure it out but nobody really writes Haskell code that way if they want it to be comprehensible by human readers.

It recently dawned on me that this is what makes it hard for me to understand snippets of Haskell. Specifically, trying to parse the precedence relations in a sequence of tokens uninterrupted by any kind of punctuation.

Say what you will about Lisp, it is always very clear which arguments go to which functions, what the scoping boundaries are, etc.

The usual claim is that the immutability of FP will avoid the problems of different processes writing to shared memory, because they only read it.

But Erlang is famous for its concurrency, and this is not due to it being a FP; it is due to its shared-nothing pure-message passing (from Smalltalk). It's another solution.

If you have multi-cores, the problem is not what you do within one core (we can already manage that); it's that you have many cores. If [1] they have their own local memory, then pure-message passing is the inevitable solution.

Anyway, that's my reasoning - I'm interested to hear your reasoning.

[1] At the moment, the on-chip memory is (very small) cache, and so shared memory is an option... but I think it's also inevitable that we'll get sufficient local memory for each core to execute code independently.

One thing I've picked up, looking at Clojure, is that the lack of mutable state allows certain cool optimizations. For example, let's say you have a map A with a million key-value pairs. You want to do something with B = A + (k', v'). In a mutable-state language, you'd physically add (k', v') to the map, which is usually implemented as a hash table. Clojure creates a new map (32-ary tree) for B that shares most of its pointers and structure with A, which allows you to do FP without FP's greatest drawback, which is the copying of large data structures. Since the nodes will never change, this sharing is entirely safe. A remains entirely unchanged, so a thread working with A still has A.

Functional programming doesn't actually eliminate side effects and mutability. Haskell has the IO and Array monads. Clojure has refs and agents. FP simply segregates them from the rest of the program so that they exist only when desirable, and can be more easily managed.

I don't know the details about cache and local memory. This is a weak area for me.

I guess you made that one up on the spot. Go read about "Purely Functional Data Structures" http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf or have a look at Haskells Data.Map implementation for another example.

Hey, you can even simulate Haskell's lazyness to implement some Persistent Data Structures efficiently in Java.

Or can Haskell's laziness help with this? Can it somehow avoid actually creating the new copy, but instead just return the correct value when you reach the end of the list? So that the new copy is never actually made, but it just behaves as if it was?

Instead of working with [a] lists, work with [a] -> [a] prepender functions. So the analogue of [1, 2, 3] is f: \x -> [1 2 3] ++ x. Then the analogue of the append of f and 4 is f . (\x -> [4] ++ x), where the . represents composition. Appending using these analogues, I believe, is O(1) instead of O(n).

To "evaluate" an element of this "closure space", just apply it to the empty list.