Consider code size, which is easy to measure -- and examples are over the net. Compare e.g. C/Java with the usual suspects (Ruby, Perl, Python, PHP, etc). For many applications, the scripting code is half the size.
A given programmer tend to produce a certain number of lines per day. Ergo, shorter coding time.
Coding time with an edit/compile/test cycle might be offset by modern IDEs (I have no data on this).
>>"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing.
Coding size costs money; both to write and to support. Money is one of the big motivators today...
>>[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all
I don't know much about PHP, but it is well known that the first version was written as Perl scripts.
(I don't know, does Lisp really have such problems with its community? Write anything bad about Python and you'll get flamed to a crisp, Ruby has a lots of childish rah-rah etc.)
I agree with your overall argument that less code = better. What I don't agree with is that that conclusively demonstrates good design. I think all of the scripting languages have design problems that were solved before the languages were ever written. For what it's worth, I don't consider Java well designed either. All of it's insights already existed elsewhere [1].
Lines of code is also a bad metric. You have to also count characters, etc. There was a study that did just this for C++, Java and Smalltalk. Java was 3 times more concise than C++ and Smalltalk 3 times more concise than Java.
[1] Interfaces would be the closest Java was to inventing something but Smalltalk had these informally (and some environments would let you work with them directly).
>>I think all of the scripting languages have design problems that were solved before the languages were ever written.
I don't disagree. But many/most of those design decisions were made to ease learning path, etc.
I should know by now that it is hard to argue "worse is better" to a CL guy. :-)
(C++ is quite a bit more flexible than Java; what feature took so much more characters? afaik -- with modern libraries, you can be very productive in C++. It isn't used so much because of the pain, I guess...)
Sorry for assuming you were aware of this.
Consider code size, which is easy to measure -- and examples are over the net. Compare e.g. C/Java with the usual suspects (Ruby, Perl, Python, PHP, etc). For many applications, the scripting code is half the size.
A given programmer tend to produce a certain number of lines per day. Ergo, shorter coding time.
Coding time with an edit/compile/test cycle might be offset by modern IDEs (I have no data on this).
>>"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing.
Coding size costs money; both to write and to support. Money is one of the big motivators today...
>>[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all
I don't know much about PHP, but it is well known that the first version was written as Perl scripts.
(I don't know, does Lisp really have such problems with its community? Write anything bad about Python and you'll get flamed to a crisp, Ruby has a lots of childish rah-rah etc.)