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