Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In general, the more concise & flexible a language is the slower is the execution of programs written in this language. on the other side, the fast languages are mostly overly verbose, requiring you to write several lines just to output "hello world", which means harder development time and is more error prone.

so the question is, is there any measurement of the conciseness to speed ratio?. if yes, how is it called and where can I find some information about it. thanks.

note: one can create a language of single letter tokens, p h printing hello world, that's terseness. conciseness means -for our purpose- as defined here :

Giving a lot of information clearly and in a few words; brief but comprehensive

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Corbin March, GlenH7, user61852 Sep 12 '13 at 17:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Concise and expressive seem somewhat conflicting in this context. –  Casey Patton Jul 12 '11 at 0:39
"feel free to edit the question as appropriate". That makes precious little sense. Some of us would close it, because that's appropriate. If we can't figure out what you're talking about, it might be better if you actually explained things by updating the question, not in a long series of hard-to-understand comments. –  S.Lott Jul 12 '11 at 10:31
@Philomath: Forgiveness and newcomer don't matter. Make the question as good as possible. Asking others to edit your question is pretty silly. It's your question. There's something you want to know. Make it very, very clear, what you want to know. –  S.Lott Jul 12 '11 at 18:43
I disagree with a premise. Many of the C compilers are obviously very good at emitting fast assembly because they have been around for a while. Just because you are closer to the metal, does not necessarily mean that you are faster. You still must have a very good compiler. Often a compiler for high-level lang can do a better job than a human in a lower level lang. .Net code can on occasion be faster than C++ because it JITs to a particular architecture. Also, Scott Meyers in Effective STL claims that more abstract can be faster. Finally, I could emit C code with Clojure - fast and concise. –  Job Jul 12 '11 at 22:19
@Job: and we should add the hardware architecture to the equation. If the compiler will have an influence for the task of mapping the higher level instructions into an optimal set of low level instructions, at the hardware level, one can design instructions that are of higher level (and operate at higher speed) then the equivalent finer-grained set of corresponding instructions. In the metal level, "conciseness" may lead to more speed (not only because of cpu's high-level instruction set, but because of related side effects, such as density of code, and its ability to fit into the caches). –  Thiago Silva Sep 12 '13 at 21:21

2 Answers 2

You might be interested in shootout.alioth.debian.org, particularly the code/time shapes. The linked page plots speed vs. loc for some benchmarks in various programming languages.

From more-concise at page left to less-concise at the right, from slower at page top to faster at the bottom.

These scatter plots show the fastest programs contributed for each programming language implementation, measured on this computer -- so they don't show ↓ slower more-concise programs that still seem relatively fast.

These are not the only programs that could be written. These are not the only programming languages. These are not the only compilers and interpreters. These are not the only tasks that could be solved. These are just 10 tiny examples...

share|improve this answer
Good answer, but I'd more like to see data about languages in their normal state, not when that's the contest. Better still, directions about how to measure it correctly (i.e. how can conciseness be measured objectively), lines of code is not the best measure as it's terseness rather then conciseness. –  Philomath Jul 12 '11 at 18:39
@Philomath - 1) what's "languages in their normal state"? 2) that URL does not show a "lines of code" measure –  igouy Jul 12 '11 at 19:55
I truly wonder how Prolog graph would look like. –  SF. Jul 13 '11 at 9:11
@SF - Prologs are included on the OUT-OF-DATE 2008 web pages –  igouy Jul 13 '11 at 22:22

Although they don't directly address the question you asked, you might find the Stepanov benchmark somewhat interesting. It deals only with a single language (C++) and programming with differing levels of abstraction within that language. I'd guess the higher levels of abstraction fit more closely with your idea of "practically expressive".

It defines levels from 0 to 12, starting from essentially C-like code using hand-written loops operating on pointers, and progressing to pre-written algorithms operating on iterators, etc.)

At one time, it was common to see penalties on the order of 2:1 (sometimes even more) for the higher levels of abstraction, even though it was carefully designed so a compiler should have been capable of producing the same output for all cases.

With most modern compilers, that's exactly what you get. You need to increase the number of iterations to get meaningful results (e.g., changing ::iterations from 25000 to 500000). With that change, and a modern compiler with optimization enabled, you can pretty much count on a ratio of 1.0 for every level of abstraction it defines. Depending a bit on some luck, you might even see the higher abstraction levels executing minutely faster than the lower ones (I've seen it, though I'm pretty sure it wasn't meaningful).

While this doesn't directly address the question of one language versus another, it does hint at the idea that expressiveness doesn't have to carry a penalty. At the same time, it's probably worth adding that even the most abstract code in this benchmark is fairly verbose compared to, say, Perl.

share|improve this answer
Thank you, pretty much what I meant, just that I want to compare languages (which one has the lowest penalty per abstraction ratio), not levels within a particular language. –  Philomath Jul 12 '11 at 18:48
@Philomath: Right, I figured that was pretty much what you were trying to get at. Unfortunately, trying to do it across languages and remain even close to meaningful/accurate/objective is a lot more difficult (and no matter what you do, advocates of any "losing" language are almost sure to point out that this doesn't reflect actual use of that language -- and probably not for the winning language either). –  Jerry Coffin Jul 12 '11 at 19:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.