Guava is one such library that adds a number of functional pattern support, including lazy evaluation of transformations of collections. With a bit of finagling, one could implement them from scratch though. (for some reason the forum is eating my indents…)


public List nameList(List people) {
return Lists.transform(people, new Function() {
public String apply(Person person) {
return person.getName();
}
});
}

Whereas e.g. scala has a lot of support for functional idioms, largely due to first class functions and convenient shorthand:


def nameList(people: List[Person]) = people.map(_.name)

Same method, less headaches.

As for why the java std lib doesn’t have a Range class, I have no idea. This is a simple way to create one:

http://stackoverflow.com/a/6828887/1057157

Sometimes I think functional programmers are pleased by the fact that only them can understand their code. Functional code produce much less source code than procedural’s for doing some complex scientific algorithm. In fact, functional code almost mimics mathematical notation. On the other hand, procedural is more algorithmic in the sense that you can organize your solution as an ordered sequence of tasks – and not a reverse order or a fixed-point trick making every stuff anonymous (the fewer the identifiers the better for functionalists).

That said, I love Javascript, the convergence between the functional and procedural worlds. You can do anonymous recursions with something like a Y combinator or even making something more legible like encapsulating named recursive functions inside another (outer) function which holds static parameters in relation to the inner function.

Nope.

- You can always compromise and use loops instead of tail recursion, and still have mostly “functional” java code. If you do this there is no “performance bugs”
- Functional Java (http://functionaljava.org/) has no problem with recursion
- If you actually need recursion (i.e. the function cannot be written tail-recursively) the most natural way is to use the stack instead of making an explicit stack. Turn up the stack size.

In the meantime, you wasted YEARS programming in (and defending) an UNFIXABLE BRAINDEAD PARODY OF A LANGUAGE/RUNTIME/ECOSYSTEM, whilst you might have saved yourselves the troubles and used a sane one.

Of what use is that JVM can be fast in microbenchmarks when you kill that advantage with layers upon layers of needles abstractions and wrappers and libraries that allow you to do ___ when this can be done in a few lines in a sane language ?

In the end a LARGE applications written in Ruby/Python/Tcl/$whatever$ can be faster then Java ones (and more flexible / maintainable) because you don’t need shitloads of useless boilerplate nor tons of XML, there are no pointless hoops to jump through, just plain solution which even slower runtimes can execute faster than JVM will execute your mammoth blobs.

ALSO:

All idiots crying “This is not how you would do this in Java, … yada yada”: it seems to me that this was the point of the post, which you somehow missed. But missing the point is perhaps to be expected from average [Java] code monkey.

Both will tend to be hard to understand and have hidden bugs. But that doesn’t mean that it is *always* a bad idea. And both will require careful implementation from the programmer.

Just as it is a bad idea to unnecessarily use Parallel & Concurrent programming in Java; it is also a bad idea to unnecessarily use functional programming in Java.

I think this is the point of this post. But you wrote the title as if it was a single universal truth. This reminds me of the ‘[XXX] considered harmful’ articles.

Clojure does not do ‘lazy evaluation’. Clojure uses strict evaluation, like Lisp, Scheme, SML, OCAML, Erlang, …

Clojure supports lazy lists. As a data structure – not in evaluation.

See also http://en.wikipedia.org/wiki/No_true_Scotsman