<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Justin Grant wrote:
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com"><br>
<div class="gmail_quote">
<div>Haskell has many mutable data structures too</div>
</div>
</blockquote>
It does? I didn't know that; I thought it didn't. (I'm only up<br>
to chapter 9 in "Real World Haskell".)<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">
<div class="gmail_quote">
<div> (as does Clojure, it's built on Java). </div>
</div>
</blockquote>
In my previous mail, when I discussed Clojure, I wasn't<br>
including the "arbitrary calls into Java" part of Clojure.<br>
In fact, I'm looking forward to see how Clojure sews<br>
together its approach with the use of Java libraries.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">
<div class="gmail_quote"><br>
<div>Memory-management is a completely different problem that
requires a different solution than does concurrent programming. Memory
allocation is always required by any program. </div>
</div>
</blockquote>
Well, actually, the way that GPGPUs and DSM chips are programmed<br>
does not use malloc/free, as I understand it. It's just a question of<br>
the right tool for the job.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">
<div class="gmail_quote">
<div>Who's to say that the user will always be writing concurrent
programs ? </div>
</div>
</blockquote>
Sure, I agree.<br>
<br>
On the other hand, soon nearly every personal computer (assuming<br>
that that continues to have a meaning!) will have multiple cores.<br>
In fact, we're pretty close to that now. Sometimes it's easy<br>
to keep cores busy simply because there are many background<br>
processes, but the number of cores continues to rise. I recently<br>
was shopping for a new desktop and found that there are<br>
consumer computers using the Intel i7 with 8 cores. So<br>
it seems not unreasonable to assume that there will be more<br>
and more need for languages that handle concurrency.<br>
As you say, not every job needs to worry about that kind<br>
of close concurrency; but more and more jobs are going<br>
to. At least, many people think that's what's coming.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">
<div class="gmail_quote">
<div>'Everything looking like a nail' and all that.<br>
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.<br>
</div>
</div>
</blockquote>
There is always a tradeoff between giving an application,<br>
or a subsystem, more, or less, power.<br>
<br>
Here's a simple example. Our Lisp system at ITA has many<br>
configuration parameters. What we used to do (we have<br>
not quite gotten rid of this yet) is to create named<br>
configurations, which worked by having a file full<br>
of Lisp forms that was loaded. That's a lot of power;<br>
a config file could do anything doable from Lisp.<br>
<br>
But for many reasons, we've decided that a declarative<br>
form of configuration has a lot of advantages, and<br>
we now use structured configuration files, e.g.<br>
each line has a key, a colon, and a value (but<br>
a bit more complicated than that, JSON in some<br>
cases). We reduce the power, but now programs<br>
can interpret config files and do various useful<br>
operations on them.<br>
<br>
In my experience, I've seen this kind of architectural<br>
tradeoff come up over and over again. More power<br>
is not necessarily better; it depends on a lot of things.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">
<div class="gmail_quote"><br>
</div>
Clojure has intentionally ignored many approaches taken in CL (not a
judgment, just an observation).<br>
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). </blockquote>
Yes, that's quite true.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">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.<br>
</blockquote>
Well, I'm not sure that's very important. There are extremely<br>
good reasons to build a Lisp on top of a JVM, and additional<br>
extremely good reasons to expose that as part of the language<br>
definition. It's not what you'd do if you were designing a<br>
new language in a vacuum, but these days it's no longer<br>
realistic to do that. The ability to take advantage of the existing,<br>
and always improving, JIT compiler and garbage collector<br>
technology, the portability, and the ability to tie into the<br>
huge number of both general and highly specialized<br>
JVM libraries, has enormous practical value. The idea<br>
that we'd ever get enough firepower behind Lisp that<br>
we could replicate all of that is entirely impractical.<br>
I had been advocating this kind of approach for at<br>
least a year before I ever heard of Clojure!<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com"><br>
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. <br>
Java was never just a language, it's always been a language, the jvm
and the libraries. <br>
Clojure inherits the legacy of all this because of it's design.<br>
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.<br>
</blockquote>
I agree with all of that. Although there are an impressive number of<br>
users (given that it's so new and it's based on Lisp and so on) of<br>
Clojure, I agree with you that the issues you mention above have<br>
probably not been explored sufficiently that we can come to<br>
a very clear judgement about how it all works out or doesn't<br>
and what to do about it.<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com">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 ?<br>
</blockquote>
I guess I'm more optimistic than you are, but only time will tell.<br>
<br>
-- Dan<br>
<blockquote type="cite" cite="mid:561d14600905201743m698f6541qb4df0f5d006b880@mail.gmail.com"><br>
Good luck ...<br>
<br>
<br>
<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>