|XP is just a number|
Paul Graham points out that if another language requires 3 times as much code, coding a similar feature will take three times as long. Actually, I think he's mistaken here. Development time, IMHO, does not scale linearly with the size of the program. I don't have any statistics handy (anyone, anyone, Bueller?), so this is only a suspicion, but the longer your program, the more bugs you're going to have. This will slow development time even more.
I do not follow this argument. Sure, if your program is longer, you will have more bugs. But how does that translate into the claim that development time doesn't scale linearly with program length? Why would the number of bugs grow superlinear?
However, I think it's a mistake use the "development time is linear with code size" when comparing developing in different languages. Sure, a Perl program might be smaller in size than a Java program. But Perl programs are likely to contain more regular expressions than Java programs. Regular expressions are an language in themselves - a very dense language to be precise. But I would not want to make the claim that regular expressions contain less bugs than other code, just because they are more dense! In fact, it's probably the other way around.
I would say that dense languages tend to have more bugs per line of code than less dense languages. Don't forget that Perl gives you a lot of rope. That makes for shorter programs, but it also gives you more opportunity to hang yourself.
There is also a large class of bugs that are language independent. Bugs in the design will be bugs, regardless whether the implementation is written in Perl, LISP or Java. Those bugs do not scale at all with the length of the implementation.
Maintenance speed, and speed of implementing new features isn't dominated by program size. What's far more important is a good design. I'd rather add some new functionality in a well designed C program of 1,000,000 lines of code than a new features in some horribly written Perl program of 1,000 lines of OO-maze. And I'm a far better Perl coder than C coder. And then we haven't even talked about the development environment. How is source control being done? What's the testing environment, etc, etc.