The folly of Arc

Somewhat belatatly I learned that Arc had finnally been released. A few moments of excitment soon ended when I learned that what had been released was a set of mzScheme macros. Worse yet a set of MzScheme macros which require an old version of said language, because the latest version breaks something.

Having read 'Arc is Out' I have to say that I haven't seen anything is contradictory to good software engineering practice in a very long time, at least not outside writing which is meant to be satirical.

How Ironic that Paul Grahams Announcement of the language spends several paragraphs belittling attempts to not break existing code when releasing new versions of a language. Interestingly He pre-picked the two things that everyone would object to:

1. Supporting ASCII only
2. Shipping with a table based web framework.

On the first of these points. No wrong answer you should have supported UTF-8 to begin with. The ability to do character set conversions can wait, but at a base UTF-8 seems like the way to go. Right here a lot of programmers who need to use languages other than English will say, this isn't worth it, even to mess about in.

On the second point. This isn't just not Politically correct, its plain wrong. Tables are ridged structures which do not sport much in the way of experimentation. Do the same thing with Divs and Spans and you can experiment, shape and reshape, make things align differently. I don't know anyone at the W3C personally but I can respect that they have spent a very long time thinking about the problems of markup languages. Somehow I'm more inclined to trust them then a single person who is effectively saying I'm right and the rest of the world is wrong.

Looking at the rest of the Essay, Yes lists are good but lets be honest they are not always the best choice. In most programs I may not know exactly what I want but I'll have a fair idea, and no I wouldn't represent a point as a list, I'd use a tuple. Why? Because chances are I know that I need two elements, or three elements and that all my points will have that many elements.

Using the right data structure for the right job is frequently important. For the most part I prefer to do this early rather than late, and can usually work out where I need a List, or a Tuple or a Hash or a Set.

Where structures with named fields come into there own is that while experimenting I can add fields at any time. I f I used Lists or even tuples this becomes much harder. When you know your points are just lists it takes an awful lot of discipline to not treat them as such, and sooner or later doing so is going to come back and bite you.

I speak from experience here I've dealt with data structures which where just nested lists (something like seven layers deep) and it was not fun. Worse yet code which references things by field name is much easier to read then code which has indexes peppered all over it instead.

All in all I'm sad to say that I won't be looking any deeper into Arc, because if fails my basic tests on what languages are worth spending time on. Last time I ignored my standards I spent several weeks looking into newLisp, even though I had grave misgivings on the Authors memory management philosophy of one reference to any object (ever), and Dictionaries can exists as top level objects only.

One day there will come a Lisp to rule them all, but it would appear that Arc is not that language.