Paul, in emphasising code brevity I think you are missing a greater good. I believe most of us subconsciously look for a language that is frictionless -- one that allows us to express our ideas without the language getting in the way. To me this is a far more appropriate measure of a language's power than the length of a program. I'd love a language that would allow me to stay in flow* and express my creativity without having to stop and think about the actual language itself. That would be the ultimate Zen power tool.
To be more specific here are three attributes that seem to aid frictionless flow. (perhaps in order of importance) -
--> Expressiveness -- i.e. simple, explicit and unambiguous abstractions.
--> Obviousness and readability. -- i.e. no need to decipher tokens, and the code structure illuminates the intention and flow of the process.
--> Terse. -- i.e. apart from the obvious benefit of requiring less work it also helps me 'keep the whole program in my head'.
There's nothing wrong with brevity of course, but when pursued for it's own sake it seems to be counter productive, in that when you focus on terseness alone there can be a tendency to ride roughshod over the more important attributes: expressiveness and obviousness. You then end up with code that's not as enjoyable to create and whose beauty is lost, except perhaps initially to it's creator.
BTW Paul, this is a great first shot, so a big thank you. I, for one, am routing for Arc to be a widespread success, if only so I can do most of what I need to do in a language that I really enjoy.
I think by aiming toward brevity, what he is actually aiming for is the ability to refactor code into something more brief.
The idea is that by ensuring the progression of long code becoming shorter, and by upholding his second principle (axiomaticity), he is making sure that the code he does factor out will be useful to future programmers. He is removing the need to write common boilerplate code -- and giving the ability to remove boilerplate code to all programmers.
And that supports the idea that PG likes about Lisp -- that the language evolves with the program. The reason it seems to only be good for web programs is that his principle application is a web program. If he were to work on some other kind of program, say a word processor, you would see different kinds of abstractions.
The point is that the language can be adapted to ANY kind of application. That is what he is aiming for. And that's why he doesn't want you to have to count library import statements. He wants to compare the code you have to write repeatedly, not the once-off code. He is claiming that the code you have to write repeatedly indicates how expressive a language is. If you have to repeat yourself, then the language does not adequately represent the abstraction you want to capture.
That's what _On Lisp_ is about. That's what basically all of his Lisp essays are about. Paul Graham is aiming for brevity so that he knows that any programmer can make their program brief by evolving the language. Brevity is a sign of a tight fit between language and the concepts expressed in the program.
To be more specific here are three attributes that seem to aid frictionless flow. (perhaps in order of importance) -
--> Expressiveness -- i.e. simple, explicit and unambiguous abstractions.
--> Obviousness and readability. -- i.e. no need to decipher tokens, and the code structure illuminates the intention and flow of the process.
--> Terse. -- i.e. apart from the obvious benefit of requiring less work it also helps me 'keep the whole program in my head'.
There's nothing wrong with brevity of course, but when pursued for it's own sake it seems to be counter productive, in that when you focus on terseness alone there can be a tendency to ride roughshod over the more important attributes: expressiveness and obviousness. You then end up with code that's not as enjoyable to create and whose beauty is lost, except perhaps initially to it's creator.
BTW Paul, this is a great first shot, so a big thank you. I, for one, am routing for Arc to be a widespread success, if only so I can do most of what I need to do in a language that I really enjoy.
* On Flow -> http://www.life2point0.com/2006/06/the_little_book.html