Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion Ants: Clojure vs. Common Lisp
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Rich Hickey  
View profile  
 More options Jun 15, 2:30 pm
Newsgroups: comp.lang.lisp
From: Rich Hickey <richhic...@gmail.com>
Date: Mon, 15 Jun 2009 11:30:33 -0700 (PDT)
Local: Mon, Jun 15 2009 2:30 pm
Subject: Re: Ants: Clojure vs. Common Lisp
On Jun 14, 3:30 pm, Pascal Costanza <p...@p-cos.net> wrote:

> Hi,

> I have reimplemented the Ants simulation example that comes with Clojure
> in Common Lisp, more precisely in LispWorks, using its multiprocessing
> and graphics capabilities.

No, you haven't. What you've implemented is a pale imitation of the
ants simulation that neglects its most important features.

> Furthermore, it doesn't use STM as in Clojure, but rather a solution
> based on locks, which doesn't seem to be much harder to me and required
> only very little tweaking. Since there is no need to monitor read and
> write accesses to shared mutable state in the lock-based version, it
> should also be more efficient.

It doesn't come close to doing the same job.

The ants simulation was designed to show how to do things that are
difficult to do without an STM. It is not simply a demo of how to use
multiple threads to make ants move around on screen.

STM lets you make decisions based upon consistent information. So,
e.g. in the Clojure version when the ant looks around and sees food on
an empty space, and makes a decision to pick it up, it will be able to
do so without finding it missing or the space occupied, i.e. it will
atomically be able to make a decision and act upon it, even one
involving multiple ad hoc elements. In your code you've made it so the
ants can't see each other, thus removing the coordination problem
rather than solving it. The Clojure code can handle arbitrary sets of
read/modify operations, on arbitrary sets of involved data,
consistently.

You use timeouts on your locks, and silently fail to do the requested
operation if the lock times out. But the caller of move expects it to
work - it's not called maybe-move-if-we-can-get-the-lock. What if
evaporate did something important? It wouldn't be ok for it to skip
some steps if it can't get the locks.

There's more. You hold locks on an ongoing basis, vs obtaining and
releasing in a scope - always tricky and dangerous. Do you know how
that will behave should those locks map to OS resources? How might non-
scoped locks thwart optimization? In move, you obtain the new lock, do
some work, then unlock the old, and right now that work might be
trivial. But what happens when someone comes along later and makes the
work something that can fail? You risk orphaning a lock on such
failure. You simply cannot use locks without proper error handling.

The Clojure ants sim also tackled the 'reporting' problem. How can you
get a consistent view of a world with many concurrent updates without
stopping it? The Clojure render function works with a consistent
snapshot of the world. There's no chance of it drawing the same ant
twice, or two ants in the same place. You've taken all the challenge
out of it by removing correlated data. Still, your code can show a
view of the world that never existed. You might think it's no big deal
when you are just painting in a game-like sim, but the techniques in
the Clojure version work in serious situations when related things
need to add up, and yours simply won't.

In short, your version doesn't compare whatsoever to what the Clojure
version provides. By making the problem simpler you've destroyed its
purpose, and you've avoided the illustrative challenges.

The purpose of the ants sim was to demonstrate techniques for handling
multithreaded applications where units of work involve consistent,
arbitrary, overlapping subsets of information, and, reporting
consistently on correlated data subject to concurrent modifications.
The Clojure version demonstrates that and your version does not.

Rich


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google