Lambda the Ultimate

It doesn't have to be quite that verbose.
Here is what you can do in pre generics Java (using reflection):

Algs.map(lst,
         new Function() {
           public int with(int x) {
             return x + 1;}});

this only works on lists of ints (pre-generics). Generics help, but the main problem is that you need an anonymous inner class in order to pass in a function.

for reference, in Scala this would look like:

lst.foreach(x => x + 1);

A fold:

lst.foldl(0)((sum,x) => x + sum);

When the expected type of an argument is a function, Scala has a very lightweight syntax.

...with Java 1.5 autoboxing would make the map methods' content look lot more reasonable, and by parameterizing Mapper you could elminate the cast and make it type safe. I'm not sure I would care how costly the extra anonymous class would be, as loading and JITing it would only happen once and would hopefully be dominated by whatever processing the loop is doing.

I've used this method fairly extensively in one project of mine, and usually the choice between this and a standard looping construct would come down to re-use: if I found myself writing the same looping code in other places, I'd pull it out into a class. In that particular project threading and synchronization was achieved through other means, so I didn't need to consider it. I also didn't have to worry about other people maintaining it, so complexity wasn't relevent. The biggest problem I encountered with it was when the body's action resulted in multiple results; creating a custom value class to return them or using some generic tuple class were both quite awkward.

They're better than nothing, but anonymous class syntax will never be as nice as an anonymous function or closure.

I'd agree the Java syntax is just lame; presumably it is always what one gets when shoe-horning a different paradigm into something already fixed in another style. Try another language that targets the JVM? Perhaps Scala, or even Jython? I realize that is sort of side-stepping the issue entirely.

to Scala. I'd think it'd still have the sensitivity to allocation speed (this is a problem with all functional languages) and the anonymous inner class problem (which is an effect of the JVM)- but it looks like it solves most of the syntax problems.

You really should consider Scala if you want to program in a functional style in the JVM. Syntactical conveniences aside (higher-order functions, ease of declaration for anonymous functions, etc), it has a better type system that tries to merge functional and OO styles nicely, it optimizes tail recursion (but not general tail calls) and many more good stuff (combinator parsing!).

I can't say much about the performance of functional code, but I believe there are no good reasons for it to be far worse than imperative Java code.

I'm looking at it for some work I may be doing. We definately need to be able to access legacy Java libraries- but we miss the power and experessiveness of Ocaml. Scala, which appears to be the bastard child of Ocaml and Java, would be perfect. I'd even be willing to accept a performance hit- write the 90% of the code that takes only 10% of the time in Scala, then write the 10% of the code that takes 90% of the time in "high-performance" Java. It'd still be a net win, IMHO.

The documentation has some tantalizing hints about Erlang-like distribution and fail-over features, but I haven't been able to find anything more about this. Are these features real, or just possible?

Well, I just began learning Scala, but I can tell you I don't intend to use Java anymore, except when strictly necessary. The good thing about it is that it's multi-paradigm, so if the functional style is lacking performance, you can write an imperative implementation in Scala, very similar to what you would write in Java, and with roughly the same performance characteristics.

And yes, I forgot to mention it in my original message, but the concurrency abstractions in Scala are great. Erlang-like message-passing concurrency is supported by existing classes. Take a look at the "Scala by Example" document, its last chapter is about concurrency.

I recalled this old mailing-list comment

"This is BTW my main gripe about Scala: it inherits Java's broken concurrency support, making it uninteresting for any application with significant concurrency issues, nonwithstanding the cute Erlang-like actor example in the beginning of the manual."

Ulf Wiger on comp.lang.functional

He goes on to say "Perhaps your best bet is to simply go with JCSP, if you really need to use Java..."

In what way is Java's concurrency broken? Java 5’s concurrency offers great performance and multi-processor support. Util.concurrent provides a nice framework of high-level high-performance concurrency abstractions which build upon Java's underlying primitives. Doug Lea recently said that if Java concurrency code is only ten times faster than the equivalent C code then it means that you haven't started to optimize (Java) yet.

Many systems which purport to do concurrency better, like Erlang, are actually only solving the much simpler and less useful problem of single-processor concurrency. In ten years we're all going to have 100 CPU cores/threads on our desktops and single-processor concurrency systems aren't going to be useful for anything. Already Sun has a CPU with 32 simultaneous processing threads.

Can you be more specific about exactly which languages you have in mind and why you think they only support single-processor concurrency?

Let's also try to distinguish between language issues and limitations that apply only to a specific implementation.

Can you be more specific about exactly which languages you have in mind and why you think they only support single-processor concurrency?

Erlang ( ">from LtU post) and Io (from the author's blog).

Let's also try to distinguish between language issues and limitations that apply only to a specific implementation.

I really love the Io language, but it is far more difficult to get it to take advantage of all of the CPU's of a multiprocessor system than it is with Java. There is only one implementation of Io so I don't know if you can distinguish between the implementation and the specification.

In the end, people need to run their code against implementations, not merely specifications, and until Erlang actually has a multi-processor implementation, any advantages it has over Java (in this environment), are purely hypothetical.

The original Java concurrency implementation, which is based on monitors, is broken. This has been documented by such luminaries as Per Brinch-Hansen. The concurrency code in Java 5 (which is based on Doug Lea's concurrency utilities) apparently does a good job of shielding the user from Java's peculiar implementation of monitors. But they are a recent improvement, any many people still retain the impression of Java concurrency they got from the earlier implementation.

Note that there is no incompatibility between JCSP and the Java concurrency primitives - JCSP is implemented on top of them, just as util.concurrent is. In fact, it seems likely that JCSP will eventually be ported to the new util.concurrent framework, since it will allow a cleaner implementation. What JCSP offers is a higher-level concurrency abstraction that is easier to work with, and more amenable to analysis. At one point it was being proposed as the concurrency library for Java 5, but util.concurrent won out in the end because (in my opinion) it provides an abstraction layer that is more familiar to most programmers.

Java's concurrency is broken compared to Erlang in that the thread model uses heavyweight OS threads. This does has the advantage of being multiprocessor but has the disadvantage of not being able to use the 'everything is a process' model that Erlang encourages.

Having very fast process creation times and the ability to create many thousands, if not millions, or processes makes concurrency oriented programming easier.

Note that Erlang maybe getting an SMP compatible implementation:
http://www.erlang.se/euc/05/1710OTPupdate.ppt

It compiles Scheme to JVM byte code, and easily interfaces with Java. It can also compile to C or .Net, so you can build libraries usable by many other languages. It also supports type inference.