[Openmcl-devel] Speed, compilers and multi-core processors
mevins at mac.com
Thu May 21 02:37:20 EDT 2009
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
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.
More information about the Openmcl-devel