2008-11-06: The Seven Deadly Sins of Arc

Arc is Paul Graham's dialect of LISP, that aimed to finally create a usable dialect of Lisp. It was released some months ago, and I played with it and even contributed some code to the Anarki Arc effort. In this post, I'd like to note why I think it has proved to be mostly irrelevant and so quickly went into obscurity.

The Seven Deadly Sins of Arc are:

  1. Not Many Exciting Features and Paradigms - Arc may be more brief than other Lisp dialects, and removed a lot of extraneous syntax, but it doesn't seem to sport many exciting features and paradigms. It seems like a Scheme-like-language only slightly better and slightly worse at the same time.

    Graham made a call for advice on his site, looking for ideas no how to improve Arc, but it seems very few of them made it into the final language.

  2. Standard State-of-the-Art Features are Missing - Arc has no built-in Object-Oriented Programing (OOP) system and it also lacks namespaces. Both of these features are part of the absolute minimum expected of any language today.

  3. No Version Control was Used for Arc - when Graham published arc0.tar (more about it later) on his site, it was just a tar. He didn't publicise the URL for a version control system that he used for work on Arc. And in this article he claims he's recently been using a mostly-disconnected computer to do his work, which indicates he's oblivious of the importance of using a remote version control repository for constant work.

    I don't have a lot of confidence in a program that's not kept under version control, and neither do most professional programmers.

  4. No Automated Tests Suite - Arc shipped without any automated tests. If an obscure feature was broken, then Graham could not find out. Nor did he have the specification-feature inherent in the automated test suite. Also the lack of Test-Driven-Development (TDD) for its development was distressing. Maybe that's what Graham calls exploratory programming

  5. Basic Usability is Missing: there was no way to do ./arc filename.arc to execute a file directly from the command line. I had to add it to Anarki Arc, myself.

  6. Weird Versioning - the first released Arc version was arc0.tar. The second was arc1.tar and the third was arc2.tar. Normally, one would expect that version 1.0 of an open-source project would be very mature, much less version 2.0, but in Arc's case they were incremental releases, released after a short time.

    So the versioning used by Graham is strange, not very conventional and confusing.

  7. Brevity Taken to Non-sensical Extremes - Arc tries to be as brief as possible, which is good, but it sometimes defies common sense and convention. For example the (not) function in Arc is (no) so the code reads (if (no a) (pr "a is false")) (is that even English?).

  8. Bonus! No line numbers in errors - that's right, when something goes wrong in an Arc progam, then you don't get a line number where it occured. How can one write anything but toy programs this way? Of course, given that executing files from the command line was not supported, it may not be very surprising.

In short, if you were hoping for a usable and modern dialect of Lisp, then Arc is not the answer, and won't be without a lot of work. I was told Clojure is much better than Arc, which I have little experience with, but may be better. (Although the fact that it targets the JVM is somewhat of a turnoff).

But Arc, as it currently stands, is not the answer. Graham had a lot of time to invest in polishing Arc before its release, but it's not polished at all. The initial flurry of interest in Arc seems to be largely gone now, and it seems unlikely that it will ever mature into something professional and usable. Arc gave me some ideas on how to create a more usable Lisp, but it otherwise lacked essential feature and is still lacking. I'm going to look elsewhere for a usable Lisp dialect.