I don't know anything about this and the flame/troll aspect of the thread makes me not want to. I was kind of hoping that a new Lisp on a new platform might have a chance at a fresh start clear of all that stuff.
I did notice one thing, though. Assuming that what Rich Hickey's saying is true, it would be better to point to something visible that the demo does that the knockoff can't do. If it's possible to appear to reproduce a demo without doing the hard parts, then maybe the demo wasn't actually demonstrating the hard parts. In that case a better demo would be a good idea. Such things can be hard to come by, though, as demos tend to be relatively simple and thus knockoffable.
This locks vs. STM debate is a lot like the old malloc vs. GC debates. "Look at my fancy new Java code. I just do foo = new Foo(); and everything is taken care of" and then a C++ guy responds with "so? I can do foo = new Foo(); delete foo; That's only one more line than your fancy GC system. My version is also faster because it doesn't waste time on GC".
Locks vs. STM will play out about the same way. It's hard to demonstrate all the things you don't have to care about with GC. Making a good demo that shows you don't need to worry about memory leaks, double freeing, memory corruption, etc is hard. The same is true of making a good demo for STM that illustrates all of the problems you don't have to worry about compared to locks.
I think the ants demo is a good idea technically. Now it just needs a set of "rules", similar to what Rich just posted.
It may be that there isn't a program that's both complex enough to make the problem visible and small enough to count as a demo. In that case, it might be better to call it a sample.
If it were my demo I'd focus on making the value visible. For example, if the value is correctness, then make it obvious when the state becomes incorrect. An incorrect program ought to hit this if it runs long enough.
(flet ((make-random-move (rankf)
(loop for place in places
for rank = (funcall rankf place)
collect (cons place rank) into ranks
sum rank into ranks-total
finally (loop with r = (if (zerop ranks-total) -1
(random ranks-total))
for (place . rank) in (shuffle ranks)
sum rank into current-ranks-total
when (< r current-ranks-total)
do (cond ((and (eq place ahead) (move ant)))
((eq place ahead-left)
(turn ant -1))
((eq place ahead-right)
(turn ant +1)))))))
(if (ant-food ant)
I've always loved how LOOP incorporates so many common looping idioms into one readable and writable form. It's ugly and hairy if you look at it closely, and certainly Iterate [1] is cleaner and more pleasing, but LOOP is still damn impressive.
Yeah, this piece illustrates why Python is such a success and Lisp is not. Lambda may be the ultimate imperative, but certainly not the most convenient in many cases.
You're not serious? The loop macro is the most Pythonic aspect of CL (c.f. list comprehensions). Your trouble handling that loop has nothing to do with lambdas.
right, but i'm guessing his (and mine) trouble handling that loop has more to do with loop that it does with us - at least that's what i tell myself so please be gentle
um, no it isn't. And that one guy happens to be the guy who invented clojure. Rich Hickey does often seem a bit testy at times, but I think it's because he is a bit of a visionary and it is tiring always having to drag along people that don't quite get it.
That actually makes a lot of sense, in context; I was wondering why/how Rich had enough time to pore over some random guy's implementation of ants, not knowing much about Pascal (until this HN thread). I think if people ignorant to his own accomplishments, it's because many F/OSS project mailing lists or IRC channels see messages from someone new to the project claiming a more naïve version of Pascal's email every few months (or weeks).
I haven't seen a smackdown like that in a while... but that was just too easy, the OP had no clue what he was dealing with.
Had he watched the Clojure concurrency video in which Rich extensively discusses the ant colony simulation and its purpose, he might not have made that mistake:
Pascal Costanza (the OP) is a smart guy. He's behind the ContextL and AspectL frameworks, and he just published an interesting paper on implementing hygienic macros within an unhygienic macro system [1]. But in this instance, it seems he clearly missed the point of the Ants exercise.
I did notice one thing, though. Assuming that what Rich Hickey's saying is true, it would be better to point to something visible that the demo does that the knockoff can't do. If it's possible to appear to reproduce a demo without doing the hard parts, then maybe the demo wasn't actually demonstrating the hard parts. In that case a better demo would be a good idea. Such things can be hard to come by, though, as demos tend to be relatively simple and thus knockoffable.