Arc is getting a fair amount of attention these days, and that in turn seems to be inspiring discussion of lots of other interesting languages.

Arc has also been getting a fair amount of flak, as you might expect from anything that's getting attention and tries to do something different. Paul Graham responded to this with "Take the Arc Challenge," a post inviting people to write a program that produces a simple three-page web workflow.

Write a program that causes the url said (e.g. http://localhost:port/said) to produce a page with an input field and a submit button. When the submit button is pressed, that should produce a second page with a single link saying "click here." When that is clicked it should lead to a third page that says "you said: ..." where ... is whatever the user typed in the original input field. The third page must only show what the user actually typed. I.e. the value entered in the input field must not be passed in the url, or it would be possible to change the behavior of the final page by editing the url.

Paul Graham, Take the Arc Challenge

Paul provides his answer for Arc, which uses a quite nice (and patented!) continuation-based API:

(defop said req
  (aform [w/link (pr "you said: " (arg _ "foo"))
           (pr "click here")]
    (input "foo")
    (submit)))

This challenge seems a bit disingenuous to me. Paul says, "Nor does it depend on some sort of esoteric libraries that Arc has and other languages don't...", but that is exactly what it does. Arc has a novel web-app system built in. (I know it's novel 'cause it's patented.) This example plays directly to Arc's strength, while simultaneously ignoring the crufty details--like Javascript, CSS, images, and databases--that make up most web sites.

(I'm not saying Arc can't handle these things--I don't know if it can--but the challenge problem ignores them, which makes it artificially clean and simple.)

So I would like to propose a different challenge: the Fit challenge. Implement Fit in your language, and show us how your language's abstractions, libraries, or other geewhizzery makes your Fit implementation more compact, more readable, more maintainable, or just more fun than the competition.

Fit, if you haven't heard of it, is a tool from Ward Cunningham for creating executable requirements documents. (Sort of.) I happen to be the project coordinator. Fit makes a great challenge for several reasons:

1. It's a real app, not a toy example, used around the world.
2. It exercises a lot of interesting areas: parsing, IO, reflection, third-party code integration.
3. It's designed to be ported. It doesn't depend on specific language features or libraries, but it allows you to take advantage of what you have.
4. It's small. You can implement it in a few days' work.

Fit is also self-testing. The self-test documents that Fit executes (the Fit specification and examples) aren't as complete or even as good as they should be, but they'll get better.

So, you think your language is the hottest tamale ever put on sliced bread? Take the Fit challenge and prove it. Start with our Tips for Core Implementers.