I was just about to code an IF and used COND instead, even with the extra parens, and thought about Arc and the principle I recall Mr. Graham stating rather unequivocally (hope I get this right, but it made a strong impression at the time) that any syntax suggestion that made code shorter was A Good Thing.<p>My non-trivial exercise in Arc gave me syntax anxiety, because the shortening was usually achieved by syntax cleverness requiring a pause while I reminded myself of the shortcut's usage.<p>Now that I think on it, I recall Mr. Graham saying another big design principle was that the language be small enough to keep in one's head, and it seems to me that would argue against cleverness as well as specification index page cont.<p>I am just wondering if Mr. Graham has any follow-up thoughts on language design based on his Arc experience, and specifically on the "shorter is better" rule.
From my experience, I have seem many cases where the "let's help api users/client code developpers save some keystrokes" mentality has brought a lot of issues.<p>Not sure if related to the question though, but still I think shorter is better only applies as one of the principles, among "explicit is better than implicit", "do not try to guess" and "code is read ten times more often than written".<p>Another example would be the hello world one liners. Some languages are very proud to have a hello world in 11 characters, but if just because of the hello world you add a new special grammar like "print to screen what is between curlies if not inside another token", then you are doing it wrong.
The shorter the code, the less room there is for bugs to hide. There are exceptions to that rule but they are not nearly as common as people make them out to be.