[nickik]

So you did a little lisp in your undergraduate days and now you are a expert, compared to all the people who write clojure on a daily bases and are happy with it?

Also LISP (I assume you are talking about Scheme or Common Lisp and not the 60s langauge) is not the same as Clojure. It does share some syntax and some ideas but its also very diffrent in many ways.

You might prefer your legacy java in the simple case, buts lets talk again when that java code has to do concurrency or other complex problems.

> Most of the modern functional languages read closer to the spoken word.

Its actually a absolut non-goal of clojure to 'read like the spoken word'. Its a goal of clojure to write code in a simple way, simple meaning a speration of concerns were each part is easy to reason about.

[namdnay]

> lets talk again when that java code has to do concurrency

For single-instance applications, sure. But for scalable systems, 90% of your concurrency is handled by whatever message broker you're using anyway. Tasks, Async processing, Blokcing Queues etc etc - they're all handled by your JMS provider.

[nickik]

Sure, if you have a one of solution you can take out and it works for you then it does not matter if you use clojure, php or java.

However often you find that its not enougth for you and then you will have to write some costume code yourself. You might think one message passing system is enougth but then its more and now you have to manage message from three subsystems in your application.

Ill use a langauge that makes things easy when things are easy and not very hard if they are hard.

[jbooth]

Doing concurrency right is very, very easy in just plain Java. ExecutorService is all you need, it's even 100% FP as long as you remap "anonymous class with 1 method" to "lambda" in your head.

[weavejester]

Executors solve a specific concurrency problem (i.e. futures), but they're not a general solution for cross-thread communication.

[jbooth]

Well, then there's BlockingQueues as noted above. Callables, Runnables and BlockingQueues are a great setup for CSP-style concurrency.

[weavejester]

That's still far from a general solution.

Let's consider an example. One of the classic concurrency problems is managing a bank transfer. In this problem it's important that the debit and credit operations happen atomically. If one operation fails, then both operations should fail.

In Clojure, we'd write:

    (defn transfer [from to amount]
      (dosync
        (alter from - amount)
        (alter to + amount)))

How would you write the same thing in Java?

A lot of the problems with dealing with concurrency are in communication between threads. BlockingQueues and Executors only deal with a small subset of concurrency problems, and blocked threads are a fairly inefficient use of resources compared to async solutions.

[nickik]

I have probebly not done much Java Concurrency. Sure you can simulate CSP with Blocking Queues but since you bind real threads you will run into tons of problems.

Why dont we ask Brian Goetz a Java Language Architect how "easy" it is, read his book [1] and then lets talk again how easy it is.

[1] http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...