<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body text="#000000" bgcolor="#ffffff">
Justin,<br>
<br>
Justin Grant wrote:
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com"><br>
<div class="gmail_quote">
<div>That being said, I really do like some of the features that I've
seen in Clojure (speaking from actual experience using Clojure and CL).
Forcing immutable data structures on users to simplify the language
implementation issues </div>
</div>
</blockquote>
I would say that the immutable data structure make the language
implementation<br>
more difficult, not easier. The point is for the language to make
things easier<br>
for the programmer, by taking on hard jobs (such as efficient GC,
optimization<br>
of generated code, etc).<br>
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com">
<div class="gmail_quote">
<div>or to make concurrent programming 'easier' </div>
</div>
</blockquote>
I don't see the reason for the quotation marks around "easier".<br>
<br>
Here at ITA, we had a big debate about whether each Lisp<br>
process should have multiple request-handling threads, or<br>
each just one. Many pros and cons were identified. But<br>
one of the major points made (by some extremely experienced<br>
programmers) is that using concurrent threads was much too<br>
dangerous. In a complex system that uses shared mutable<br>
data structures, you need to get the concurrency control<br>
absolutely right.<br>
<br>
For example, we might have each Lisp<br>
process maintain some kind of cache. Rather than<br>
having N copies of the cache, one for each thread,<br>
we might want to save both memory (only one copy)<br>
and time (fewer fetches) by sharing the cache between<br>
threads. Other things would be shared as well.<br>
It also hurts that Common Lisp does not define<br>
thread-safety on various operations, since Common<br>
Lisp's spec is written as if there were only ever<br>
one thread. This is one of the main reasons we<br>
decided to create a whole Lisp process for each<br>
request-handling thread.<br>
<br>
In contrast, database management systems do NOT<br>
get into trouble when applications use concurrency.<br>
This is because their concurrency control is based<br>
on a transaction model. True ACID transactions<br>
are very easy to think about and reason about.<br>
It is much more easy to "prove" correctness.<br>
(By "prove", I mean "convince yourself for<br>
sure that it works".)<br>
<br>
We know now that the wonderful concept of<br>
transactions can be adopted from the DBMS<br>
world into the programming language world.<br>
I consider this a truly major breakthrough<br>
in the progress of modern computer language<br>
technology. Of course, not every language<br>
will find this appropriate, but it's quite impressive<br>
how many of the new languages that are<br>
currently being created have adopted the<br>
same paradigm: mostly use immutable objects<br>
and also provide transactions.<br>
<br>
Given the choice of being "forced" to use<br>
this to do concurrent programming, versus<br>
being given the "power" to do any old<br>
kind of locking I want, I'll gladly take<br>
the former, just as I am happy to give<br>
up the ability to write my own malloc,<br>
and I am happy to pay the cost of<br>
having my array bounds checked<br>
automatically.<br>
<br>
<br>
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com">
<div class="gmail_quote">
<div>is neither of them. The one thing I would change in Clojure is
this very thing. Even Haskell has it's monads </div>
</div>
</blockquote>
You can do monads in Clojure. Monad in Haskell are just a library,<br>
not part of the very heart of the language. It's a design pattern,<br>
and Clojure has all the fundamental power needed to implement<br>
that pattern. (There was discussion of this at the Int'l Lisp<br>
Conference. I am not quite familiar enough with this all to<br>
defend what I just said, but ask Ravi Nanatavi of Bluespec<br>
who writes actual product code in Haskell every day.)<br>
<br>
<br>
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com">
<div class="gmail_quote">
<div>and Lisp allows for functional and imperative styles to be
mixed. <br>
</div>
</div>
</blockquote>
Those words can be used in various ways, so I won't<br>
try to address this question at a direct level. But the<br>
greater points are: Clojure does give you a wide variety<br>
of ways to program. But if Clojure's "mostly immutable<br>
with transactions" paradigm does limit me, that's OK,<br>
particularly if the job at hand calls for close and<br>
relatively complex concurrency needs.<br>
<br>
That's not to say that Clojure is the Right Language for<br>
All Problems. Here at ITA, we do plenty of Java,<br>
and we use C/C++ in several places where it's<br>
the most appropriate tool for the job.<br>
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com">
<div class="gmail_quote">
<div><br>
There may be an important lesson here ...<br>
</div>
</div>
</blockquote>
At the very least, I think discussing these issues can<br>
be enlightening and educational for all of us, including<br>
me of course.<br>
<br>
-- Dan<br>
<blockquote type="cite" cite="mid:561d14600905201542u71187051j139400d8009abb8a@mail.gmail.com">
<div class="gmail_quote">
<div><br>
</div>
</div>
<pre wrap="">
<hr width="90%" size="4">
_______________________________________________
Openmcl-devel mailing list
<a href="mailto:Openmcl-devel@clozure.com" class="moz-txt-link-abbreviated">Openmcl-devel@clozure.com</a>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" class="moz-txt-link-freetext">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
</body>
</html>