Beating the Arc Challenge in Clojure | Hacker News Reader

Beating the Arc Challenge in Clojure

bestinclass.dk

32 pointslbj4 comments

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.

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.

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

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

Reply on news.ycombinator.com