An old meme of the "seven, plus or minus two" variety has surfaced. I saw it recently in this interview with Guido van Rossum about Python. He writes:
This is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines.I've seen this idea crop up in other places over the last week. The idea it expresses--that we have finite carrying capacity, and can get more things done quicker if we can avoid having to pack excess, low-value "stuff"--is a powerful meme. Non-technical managers can understand it.A 20,000-line Python program would probably be a 100,000-line Java or C++ program. It might be a 200,000-line C program, because C offers you even less structure. Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program. For smaller scales, it works in the same way. A 500-line program feels much different than a 10,000-line program.
But there's a dark side. If things get too compressed, if the abstractions are too dense, a body of code can be just as hard to debug. I suspect that there are "appropriate" densities for both code and abstractions, and perhaps appropriate mixes of weak vs. strong abstractions, but that's about as far as I've thought it through.
You can indeed reach a level where the code density is too high: consider APL or Forth. With APL, even if you didn't have the bizarro-planet character set, and a ton of comments, each line could take a couple of hours to read and understand.
I've never had to debug a "production" APL program (not sure one exists
For what it's worth, Perl seems to be the "baby bear" of density: not too much and not too little, but just right.
