

Beating the Arc Challenge in Clojure - lbj
http://www.bestinclass.dk/index.php/2009/12/beating-the-arc-challenge-in-clojure/

======
wheels
This really shouldn't be labeled "beating" (note, neither the Ruby nor Go
versions claimed such). This takes more parse tree entries than the Arc
version, which was the metric defined there.

------
ynniv
I wouldn't say "beating" so much as "playing", since the challenge is to
compare the length of the programs that accomplish the task. Your compojure
solution accomplishes this at the request level, passing data between request
handlers using session variables. The current arc solution has only one
request handler for the entry point, and then uses temporary anonymous
handlers to chain the session. This is something which could probably easily
be added to compojure, since clojure has language features similar to arc.

------
lbj
Please notice the 'update' sections, where Compojures Sessions Middleware has
been implemented.

~~~
ericlavigne
In the arc version you can navigate to the same url in multiple tabs, and each
of those tabs will work independently. In order to make that work you need, in
addition to the per-user session, a per-page session.

It probably makes more sense if you look at an example. Take a look at the
multicounter example for seaside:

    
    
         http://seaside.st/about/examples/multicounter
    

Notice the automatically generated k parameter that appears in the URL when
you press one of the ++ or -- links. That is the id string for the per-page
session.

Scroll to the bottom of that page and you will see the code. I would love to
code web pages like that. Compojure is not up to the challenge, and I don't
think that weavejester is interested in changing that. Compojure is designed
for REST applications, and we are talking about the polar opposite of REST.

Edit: Of course I also should have included seaside's answer to the arc
challenge:

    
    
         http://www.lukas-renggli.ch/blog/take-the-arc-challenge

