I haven’t heard of any studies in that direction, although a few people try to do find something, like “how long are the programs comparatively” etc., similar to this quickly googledIEEE paper.
I assume that because
programming languages are used by humans, and
most of a programming language’s quality is based upon its actual effects on humans in the target group, and
for real work we value long-term effects
such a study is unfeasible, i.e. too much effort, too expensive. And probably not that much related to programming language features (as most popular languages converge to some degree, especially on the most important axises). Also, “fewer symbols/lexemes/special-purpose-constructs” is an advantage only under certain conditions, meaning: the question asked may very well already determine the answer.
That’s the short version. The full paper is here. I found it while looking for a similar comparison that I remembered seeing mentioned several times when I had been interested in Common Lisp and it turned out to be a follow-up to that. Oh, and those things actually looked at time spent programming, so they didn’t measure only silly things like program length.
It was excessive to call it “silly” but program length still seems very imperfect way to measure the ease of writing programs in a given language. Better to directly measure things like programming time or number of bugs.
It’s silly when you’re measuring it in “lines of code”, because “line” is a somewhat arbitrary construct, for which “chunks of text delimited by newlines” is a worse approximation than most people think. (Quick proof: in many languages, stripping out all the newlines yields an equivalent program, so that all programs are effectively one-liners.)
Then it’s a good thing I didn’t measure it that way, or use that term in this entire thread! Whenever I did refer to measures of program length, it was with constructions such as:
some can span a broader array of programs using fewer symbols (due to how they combine and accumulate meaning faster)
Thanks for digging that up! Also, I did not want to imply that only silly things are measured, but rather that the most interesting questions are still unanswered due to various constraints.
I haven’t heard of any studies in that direction, although a few people try to do find something, like “how long are the programs comparatively” etc., similar to this quickly googled IEEE paper.
I assume that because
programming languages are used by humans, and
most of a programming language’s quality is based upon its actual effects on humans in the target group, and
for real work we value long-term effects
such a study is unfeasible, i.e. too much effort, too expensive. And probably not that much related to programming language features (as most popular languages converge to some degree, especially on the most important axises). Also, “fewer symbols/lexemes/special-purpose-constructs” is an advantage only under certain conditions, meaning: the question asked may very well already determine the answer.
That’s the short version. The full paper is here. I found it while looking for a similar comparison that I remembered seeing mentioned several times when I had been interested in Common Lisp and it turned out to be a follow-up to that. Oh, and those things actually looked at time spent programming, so they didn’t measure only silly things like program length.
Why is program length a silly thing?
It was excessive to call it “silly” but program length still seems very imperfect way to measure the ease of writing programs in a given language. Better to directly measure things like programming time or number of bugs.
It’s silly when you’re measuring it in “lines of code”, because “line” is a somewhat arbitrary construct, for which “chunks of text delimited by newlines” is a worse approximation than most people think. (Quick proof: in many languages, stripping out all the newlines yields an equivalent program, so that all programs are effectively one-liners.)
Then it’s a good thing I didn’t measure it that way, or use that term in this entire thread! Whenever I did refer to measures of program length, it was with constructions such as:
Thanks for digging that up! Also, I did not want to imply that only silly things are measured, but rather that the most interesting questions are still unanswered due to various constraints.