[Openmcl-devel] Speed, compilers and multi-core processors

[mikel evins]

On May 20, 2009, at 7:43 PM, Justin Grant wrote:

> Yes, Haskell is a 'purely' functional language so it may 'appear'  
> more restrictive than Clojure but that is not the case at all.

No, it is actually more restrictive in the area under discussion,  
which is assignment. Clojure provides assignment; Haskell does not.  
You cite state monads and the IO monad, but they're not examples of  
assignment in Haskell; they're examples of lambda binding with a layer  
of syntax crafted to resemble the assignment forms in other languages.  
That's a dubious design decision, if it leads to people confusing what  
they do with assignment.

For examples of assignment in Haskell, we have to turn to FFI  
extensions; but once we do that, we can then also talk about Clojure's  
support for unrestricted assignment, and Common Lisp's support for  
malloc and free and pointer-bashing.

> Haskell being a 'purely' functional language has nothing to do with  
> it's concurrency features.

That's beside the point, which is that Haskell's restrictions make  
certain solutions workable that wouldn't be, otherwise. STM (Software  
Transactional Memory) is one example of such a solution, an example  
that also happens to be relevant because it's useful for concurrent  
programming, as well as because Clojure supports it, too.

Clojure and Common Lisp both do the same thing that Haskell does: they  
take away certain facilities because their absence makes certain  
solutions workable.

Concurrency is different from memory management in this respect only  
because multiple cores have become cheap and widespread long after  
large memories did. GC is a solution to the robustness and  
productivity problems caused by manual memory management. STM is a  
solution (one of several) to the robustness and productivity problems  
caused by manual concurrency management.

There are certainly many programs that don't involve a lot of  
concurrency, but Moore's law is over, and chipmakers are giving us  
more cores now instead of faster ones. Sure, some people will always  
want to manage their threads manually, just as some people will always  
want malloc and free. But some like GC, because it makes a bunch of  
headaches go away, and the cost of giving up malloc and free goes down  
all the time. As cores multiply, the same thing will happen for  
facilities that do for concurrency what GC does for memory management.

Of course, no one has to give up manual concurrency management, just  
as no one has to give up malloc and free. If you want malloc and free,  
use tools that offer them.

> Clojure has intentionally ignored many approaches taken in CL (not a  
> judgment, just an observation).
> Many choices were made because of Clojure's foundation (the JVM) and  
> this shows through when programming in the language beyond any  
> trivial examples.

Some were; Rich Hickey has been pretty forthcoming and explicit about  
exactly which decisions those were. Some of them may actually be  
important; certainly I find some of them annoying.

Jeremy suggested that someone could implement a Common Lisp designed  
around Clojure's concurrency features. You said you hoped not; I don't  
think you have anything to worry about. I don't think bolting  
Clojure's concurrency features onto Common Lisp buys much. Clojure's  
concurrency features work well because they're part of a package deal.  
I think it's pretty hard to fit that package deal into Common Lisp. I  
can imagine a Lisp other than Clojure that would fit it, but it  
wouldn't be Common Lisp.

> That's all fine, but another problem that Clojure faces is the  
> marriage of a language trying to be 'purely' functional on top of a  
> platform(including libraries) that will always be imperative.

Clojure is not a purely functional language and has never been  
intended to be one. If it were, using the JVM as a platform is no more  
a barrier than using a Von Neumann architecture as a platform is a  
barrier to Haskell.

> My bet is that you'll probably see lots of users effectively  
> programming in Java (but using s-exps) when they realize that using  
> the language with existing Java libs is a complete impedance mismatch.

That's not what we see so far, and I haven't seen any sign that it  
will be in the future. I have my quibbles with Clojure, but this is  
not one of them.



--me