I agree with kc5tja and will expand on his/her comments.
I question the value of simply making a program shorter. A shorter program will have fewer bugs than a longer one but even that is not the point. The point is that any program worth keeping will have to be maintained.
The critical question is "will the person who has to maintain the code understand the code as written and thus be able to maintain it correctly?" I suggest that both very terse and very verbose languages fail to communicate the what, why, and how by their code alone. They require massive external documentation to support understanding. THAT alone defeats the goal of simply making the code shorter.
I suggest the correct goal is to create a language that MINIMIZES the total of code, documentation, training, and learning curve to maintain it correctly. Unfortunately, that goal is orders of magnitude more difficult to achieve than merely short code.
In my 40+ years of system development, there is one language that achieves the goal of shortness without comprise: APL. Its close to possible to simulate today's weather starting from the big bang using no more than two or three lines of code using APL. However, once you get it working, neither you nor anyone else can comprehend the how, what, and why of the code. APL is the ultimate language for the disposable program: use it once and delete it. Is that really your goal for ARC? If it is, then ignore my comment.
One last question. If your goal is to optimize the production of disposable programs, have you considered the well known effect that such programs become part of "the product" as promised by the marketing department and/or some out of control salesman? Then, in a few months, they will demand that hundreds of new and incompatible features be added to make the product "better"? Will the terseness of your language save you then or will you endlessly be starting over from scratch? Your goal contains not only the seed of your defeat but also its leaf, branch, trunk, and roots.
There is a future in which the past must be supported. Have pity on those who follow you. Do your job right and they will praise you. Continue on this path and your name will be brightly lighted with the flames of oblivion.
> However, once you get it working, neither you nor anyone else can comprehend the how, what, and why of the code.
I think I agree, except that your example is bad - complex weather would emerge from /simple/ cell interactions, and the program itself would be short and simple. But that's a similar idea to what I'd fear from a maximally compressed language - what if someone could write terse code where the meaning emerges from interactions in a way that only a genius could follow? It could be impenetrable and unmaintainable to non-geniuses. But I guess an ordinary language could have such programs, as well.
There's another weakness (I think) in pg's criteria for Arc, though he probably just failed to mention it, or just as likely I failed to notice - it would be possible to make Arc programs shorter by multiplying custom operations in Arc for all occasions. His criteria should be, minimize /N x the length of Arc plus the length of each program in some representative set/.
> But I guess an ordinary language could have such programs, as well.
Yes. In fact a very high percentage of all software written falls into that category. The challenge is to write clear maintainable code in any language. The language can help or hinder the process but it cannot solve the problem (aka there is no silver bullet). Language terseness compounds the problem mostly by extending the learning curve beyond economic practicality.
PS: if you want a really tiny language, use FORTH. Its trivial to write totally incomprehensible programs in it. Its compiler, os, and executing environment can live in less than half of a 1K 8 bit computer. Multiple programs can live in the rest. Its a brilliant concept that totally solves the wrong problem.
