Arc FAQ

Where do I get it?

Arclanguage.org.

Why do you need to design a new language?

It would be surprising if we didn't still need to design more languages. That would amount to saying that programming language design is now a solved problem, and that the final, perfect language has now been designed. It does not seem that way to me-- not by a long shot. The number of still open questions makes my head spin.

Why is it called Arc?

The name is a reference to bottom-up programming. This means customizing the language to suit your application, yielding a program shaped like an arch, rather than a lintel. Since brevity is another aim, we lopped off the h.

Why did you keep car and cdr?

Because we couldn't think of any better alternatives. It would have been misleading to use first and rest or head and tail, because conses are fundamentally pairs; lists are one thing you can build with them, but not the only thing.

There's no conventional name in English for the first and second halves of a pair. If you have to make up names, car and cdr are pretty good choices, because they're short and the same length and naturally composable (e.g. cadr).

Is Arc object-oriented?

The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes.

We believe Lisp should let you define new types that are treated just like the built-in types-- just as it lets you define new functions that are treated just like the built-in functions. We don't believe that every program should consist of defining new types.

Why not use some other delimiter than parentheses?

We tried various possibilities. Square and curly brackets lose because they are less directional than parens (left and right differ in fewer pixels); < and > lose because they don't wrap around enough to enclose expressions longer than tokens.

Won't allowing <new possibility> confuse people reading code?

E.g. (a i) could be a function call or an array reference.

If you make a language terser, you necessarily have more possibilities for what an expression might mean. For example, because functions are a data type in Lisp, someone new to Lisp might complain that he can't tell whether a parameter x is a function or an integer. This is an inevitable consequence of making a language more powerful. It is up to the programmer (as it always is) to avoid using the language in a way that confuses readers.

Why not build Arc on top of Java/Parrot/.NET?

We're trying to make something for the long term in Arc, something that will be useful to people in, say, 100 years. (If that sounds crazy, remember that we're already up to 50.) So (a) we're not in a hurry to save effort; when you're trying to make something that will last 100 years, there is plenty of time to work on it, and (b) we don't want to adhere to anything that isn't timeless, lest the whole project curl up like a bimetallic strip.