Posts Tagged ‘Python’

On Arc

Tuesday, February 12th, 2008

Arc is a new dialect of Lisp from Paul Graham, founder of Y Combinator and what is now Yahoo Stores. It aims to “make programs shorter” — PG’s unassuming description of what he sees as the fundamental purpose of programming languages. As an example, a function that returns double its argument can be written: [* _ 2].

The initial public release of Arc is itself a paragon of brevity: one directory, fourteen files, and less than 5000 lines of code (which includes a HTML engine and web-server). Check out the installation instructions and the tutorial, which assumes no prior knowledge of Lisp.

What’s fascinating for me, as a programmer and interaction designer, is the deliberate and public attention being given to the core expressiveness of the language itself.

What’s fascinating for me, as a programmer and interaction designer, is the deliberate and public attention being given to the core expressiveness of the language itself. The release is essentially a prototype of the things you can say and how you say them — and not of the efficiency or capacity of the resulting system. The former is a matter of design, the latter of engineering. Features like modules and Unicode character support were omitted, because although they’re fundamental to the implementation of the language, they’re not fundamental to its design. While the two undoubtedly affect each other, it seems appropriate to focus on design first. After all, what’s the point of a great implementation of a language that no one wants to use? (Although one could argue that this is the current state of Java.)

Some people have criticized Arc for being nothing more than a thin wrapper atop Scheme (in which the release is implemented) or for not having tackled enough difficult problems. As PG has pointed out in his rebuttals, he wants to provide the best language from the point-of-view of the people who are going to use it, whether the implementation is short or long, easy or difficult. In any design process, you want to do as little as you can to allow people to experience the thing you’re designing. This lets you iterate rapidly, try lots of ideas, and create a better result than you would by toiling away on your own. In the case of a programming language, of course, experiencing the prototype means writing programs in it - and for this you need an implementation. Don’t, however, confuse the prototype with the product. The former exists to generate new designs; only the latter is primarily intended for use. If you try Arc, do it with the intention of improving the language, not (necessarily) of building systems with it. It’s not yet ready for the latter.

Arc has some aspects that should help it to evolve into an effective way to build systems. Foremost among them: it has a leader.

Arc does have some aspects, however, that should help it to evolve into an effective way to build systems. Foremost among them: it has a leader. To see the importance of this, compare Python to Common Lisp. Python is run by one person (Guido van Rossum), giving it stability and consistency without inhibiting growth and change.

Common Lisp, on the other hand, has a fourteen-year old standard that’s an amalgamation of the work of many people — both inconsistent and obsolete. Anything not in the standard has likely been done in differently in each implementation, so many programs don’t work in more than one. This creates a fragmented eco-system of libraries, limiting the resources you can build upon. While it’s small now, if Arc can stay unified under the direction of Paul Graham, we should end up with a large, evolving, and compatible set of libraries and tools. In fact, we may finally get an acceptable Lisp.

My other hope for Arc (besides becoming a great language itself), is that it will generate broader interest and activity in the area of programming language design (as distinct from implementation). While there are lots of great new languages out there, most of them simultaneously evolve the language and its implementation, and limitations of one affect the other. By encouraging us to start with the design and then figure out the implementation, Arc should lead to languages that are better in both.

© 2009 Synthesis Studios. All rights reserved. Terms & Conditions | Privacy Policy | Accessibility