Ants: locks vs stm

http://groups.google.com/group/comp.lang.lisp/msg/a86c91091ae16970

by silkodyssey • 17 years ago

69 19 17 years ago

groups.google.com

itistoday2• 17 years ago

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:

http://blip.tv/file/812787

tc2• 17 years ago

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.

[1] http://p-cos.net/documents/hygiene.pdf

diN0bot• 17 years ago

full thread is somewhat more interesting than one guy's bitchy smackdown. http://groups.google.com/group/comp.lang.lisp/browse_thread/...

scott_s• 17 years ago

It might be worth noting that "one guy" is the designer and implementer of Clojure.

rbancroft• 17 years ago

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.

icey• 17 years ago

If you follow CLL, Rich and Pascal have had a back and forth on the newsgroup on more than this occasion.

utx002• 17 years ago

talk about loop abuse:

     (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)

sbt• 17 years ago

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.

itistoday2• 17 years ago

You can write bad Python code too. Lisp is no longer one language, there are many Lisp variants that don't have CL's looping construct.

tc2• 17 years ago

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.

gamache• 17 years ago

I'd call that loop use.

This might as well be the poster child for why LOOP is an awesome macro.

sketerpot• 17 years ago

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.

[1] http://common-lisp.net/project/iterate/

gruseom2• 17 years ago

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.

arohner• 17 years ago

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.

gruseom2• 17 years ago

I like your analogy.

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.

chwahoo• 17 years ago

The similiarities between GC and STMs extend beyond this particular debate as Dan Grossman describes in his 2007 OOPSLA paper: http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla...

Ants: locks vs stm

Related Stories