| |
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.
|
|