-1

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

Philomath
  • 115
  • 4
  • Concise and expressive seem somewhat conflicting in this context. – Casey Patton Jul 12 '11 at 00:39
  • I meant [Expressive power](http://en.wikipedia.org/wiki/Expressive_power) (mostly practical expressivity). Edited. – Philomath Jul 12 '11 at 00:54
  • Wouldn't a language like C be considered very expressive but not very concise? Wouldn't low level languages in general be more expressive but less concise? This is why I think these terms seem conflicting. – Casey Patton Jul 12 '11 at 00:57
  • @Casey Patton: that's "theoretical expressivity" (in the above Wikipedia article). Maybe I'm mistaken, but in my view (practical) expressive power means the ability to express clearly what is wanted without need to struggle with low level details. A person is expressive if he can express himself clearly using concepts rather then acts, "premature optimization is the root of all evil" is more expressive then "if one works on his code to make it faster before it's finished, he will introduce all kinds of problems in his code" – Philomath Jul 12 '11 at 01:26
  • I'd just note that the overhead of a "hello world" rarely tells much about the expressiveness of the language in general. `10 ? "hello world"` is short, but ancient BASIC still isn't what I'd think of as very expressive. – Jerry Coffin Jul 12 '11 at 05:35
  • @Jerry Coffin: You are right. For whom it may concern: feel free to edit the question as appropriate. – Philomath Jul 12 '11 at 06:08
  • 2
    "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
  • Check [this out](http://programmers.stackexchange.com/questions/89620/clean-readable-code-vs-fast-hard-to-read-code-when-to-cross-the-line/89624#89624), especially the **Added:** part, since you're asking about a tradeoff. – Mike Dunlavey Jul 12 '11 at 18:02
  • @S.Lott: please forgive a newcomer. Now is better? – Philomath Jul 12 '11 at 18:33
  • Conciseness is a function of language design. Speed is a function of compiler design. The two are often correlated but not directly related. Your premise is flawed. What was the question you actually wanted to ask? – Alex Feinman Jul 12 '11 at 18:36
  • 2
    @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
  • @Alex Feinman: Haven't you heard about language performance comparisons? of course it all depends on the compiler, but it's common knowledge that C is faster then ruby, right? sure this can change some day depending on the compiler/interpreter, but this doesn't mean we can't compare their performance as for now. Given that Ruby is more concise then C, which one is higher in concise to speed ratio (as for now)? So I'm speaking about the correlation not the relation. – Philomath Jul 12 '11 at 19:15
  • 1
    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
  • 1
    @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 Answers2

7

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...

gnat
  • 21,442
  • 29
  • 112
  • 288
wvoq
  • 538
  • 3
  • 6
  • 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](http://shootout.alioth.debian.org/help.php#gzbytes) – igouy Jul 12 '11 at 19:55
  • I truly wonder how Prolog graph would look like. – SF. Jul 13 '11 at 09:11
  • @SF - Prologs are included on the [OUT-OF-DATE](http://shootout.alioth.debian.org/gp4/code-used-time-used-shapes.php) 2008 web pages – igouy Jul 13 '11 at 22:22
2

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.

Jerry Coffin
  • 44,385
  • 5
  • 89
  • 162
  • 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