The Offbytwo Blog

So as everyone probably knows by now Paul Graham’s Arc programming language is finally out in limited beta. The new language has been met with a fair bit of criticism. Paul has responded by expressing the motivation behind his design: helping make programs shorter. Paul’s idea is that languages that allow one to write shorter programs are inherently more powerful. He backed this up with the Arc challenge: writing a simple web application in other languages and seeing how they compare to Arc.

If you get impatient here’s the challenge

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.

And if you’re curious here’s the solution in Arc

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

I’ll have to admit this is pretty impressive at first sight. (Well, there’s a small trick here and that’s that PG patented the approach used here, although the patent does currently belong to Yahoo). Folks have complained that this isn’t relevant because they need designer friendly HTML, cross browser support and a couple of other features of a real world site. Paul called this corporate bureaucracy and to his defense Hacker News is running in Arc and works pretty good for me.

I thought about this challenge some more and realized this is a terrible test for a language that claims to be “the hundred-year language“. A problem is that the challenge only illustrates Arc’s power at creating web applications (at least simple prototypes of applications). My reason for this complaint is that I happen to do more than just web programming. I occasionally have to write software for embedded systems, real-time video processing, interfacing with hardware devices over C APIs or serial port communication, shell scripting and text processing.

So what I really need is a language that can excel at all of the above. Personally I think that’s pretty tough for any one language to accomplish. I think there are trade-offs involved so when a language becomes good at one thing it starts to be worse at others. Some languages might excel at text processing and scripting but not be great at writing assembly level code. Others might allow you to write operating systems and probably not be great at writing web applications.

I’m not convinced a language can excel at all of the above. But there is a solution: languages that allow the programmer to create domain specific languages. This allows the programmer to create the necessary abstractions for the given domain and then write an application in that new language. This is guaranteed to create the most succinct and clear way to express the problem at hand.

The good news is that some languages already exist that allow programmers to do this. The most likely candidates come from the Lisp family: namely Common Lisp and Scheme). Now there are problems with both that I won’t even start to address here. But I’ll quote Paul on this:

McCarthy didn’t get very far along it in his paper. And after that the language passed into the hands of his grad students, who at the time were more worried about the exigencies of making an interpreter run on the IBM 704 than continuing McCarthy’s axiomatic approach. We’ve been living with their hacks ever since. Steele and Sussman tried to start over when they first began working on Scheme, but they seem to have been practically the only ones. And they made, at least from the point of view of brevity/power, some serious mistakes early on.

So there is room for improvement.

What should a language do to be a true “hundred-year language”? It should make it easier for programmers to write DSLs. So here’s my challenge:

Implement Arc in your favor language (or better yet in a language you invent) and then see how your implementation of Arc compares to other languages. The language with the “shortest” code wins. I’ll use Paul’s rules and measure the size of the code tree.

I believe the winner of this challenge will have the most powerful macro system and I believe might have a shot at being a true hundred-year language. Since Paul wrote the book on macros this should be interesting.