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

[Justin Grant]

> Haskell is more restrictive than Clojure, not less. The language defined by
> Haskell 98 has no way whatsoever to perform assignment. Monads provide a way
> to *simulate* assignment, but what they actually do is not assignment (much
> less simple assignment).


Yes, Haskell is a 'purely' functional language so it may 'appear' more
restrictive than Clojure but that is not the case at all. Let's not get hung
up on semantics : both references and arrays can live in state monads or the
IO monad. These are two methods of structuring imperative effects in
Haskell. Haskell has many mutable data structures too (as does Clojure, it's
built on Java). Haskell also has variable binding (as does Clojure). Refs
and Agents in Clojure are fine if that's your thing. I'd argue that other
languages do a much nicer job of this. Also, Haskell being a 'purely'
functional language has nothing to do with it's concurrency features. For
that 'Concurrent Haskell' has been put forward by SPJ etc. but this is an
explicit extension to the language that allows atomically-mutable state in
concurrent applications. It's arguable that Haskell has been through years
of trying to be 'purely' functional with hardly much success.


Clojure takes the same approach to managing threads that Common Lisp does to
> managing memory allocation. If Clojure's design in this area represents
> "patronizing assumptions", then so does Common Lisp's memory-management
> design.


Memory-management is a completely different problem that requires a
different solution than does concurrent programming. Memory allocation is
always required by any program. Any language designer making that assumption
is always correct. The same assumption cannot be made by a language designer
about concurrency.
Who's to say that the user will always be writing concurrent programs ?
'Everything looking like a nail' and all that.
This problem exists at another level and is best handled by the programmer.
Sure it's nice to make such an assumption at a language design level if you
must but make it optional and in doing so allow the programmer more power.


Common Lisp is designed to make winning easy in the area of memory
> management. Clojure takes that design as a given, and in addition is
> designed to make winning easy in the area of concurrent programming. If you
> really want malloc and free, don't use Common Lisp. If you really want locks
> and simple assignment, don't use Clojure.
>

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.
Customer approved platforms, existing investments and the 'industry
standard' all factored heavily in Clojure's design at some cost to giving
the user more power (it's all on the Clojure website). This makes for
Clojure being the 'industry standard' Lisp, for better or worse. Clueless
managers may end up praising it the way they did Java after reading about it
in some magazine.

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.
Java was never just a language, it's always been a language, the jvm and the
libraries.
Clojure inherits the legacy of all this because of it's design.
The magnitude and scope of these problems is yet to be discovered by the
Java/Clojure community when they get into building real systems and
extending current systems on the JVM with existing libraries.
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. You'll likely hear the
more experienced Clojure users suggest wrapping these problems up in macros
or something. Who wants that job ?

Good luck ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090520/9854b5f2/attachment.htm>