On 24/08/13 06:58, H. S. Teoh wrote:
> In none of the above examples did I try to deliberately game with the
> metric. But the metric is still pretty inaccurate, and requires
> subjective judgment calls.

It's a heuristic, rather than a metric, I'd say.  But as a heuristic it may be useful to compare things like

    (i) what's the minimal number of lines needed (not artificially compressing
        them!) to write the algorithm idiomatically?

   (ii) how many more (or less) lines do you need to optimize the code for
        performance?

  (iii) how many more lines do you need to parallelize the code effectively and
        safely?

By the way, for your example:

> 	auto formatYear(int year, int monthsPerRow)
> 	{
> 	    enum colSpacing = 1;
> 	    return
> 		datesInYear(year)
> 		.byMonth()
> 		.chunks(monthsPerRow)
> 		.map!(r =>
> 			r.formatMonths()
> 			 .array()
> 			 .pasteBlocks(colSpacing)
> 			 .join("\n"))
> 		.join("\n\n");
> 	}

Although obviously there are only 3 _logical_ lines there (the function declaration, the enum, and the return statement), here I'd be inclined to say the number of _significant_ lines is 12 (I'm ignoring the braces).  The fact that you needed to spread the expression out across multiple lines in order to be readable does carry useful information about the language, IMO.

That doesn't necessarily say the language is _bad_.  It's difficult to see how a language could reduce the space needed for that expression without also reducing comprehensibility.

On Sat, Aug 24, 2013 at 12:13:06AM -0700, Walter Bright wrote:
> On 8/23/2013 10:23 PM, H. S. Teoh wrote:
> >>Like I said, you can still game it. I think some common sense applies, not a literal interpretation.
> >You conveniently snipped the rest of my post, which postulates a far better metric that's no harder to apply in practice. :)
> 
> You can't compress by visually looking at the code, and LOC is a unit that people fairly intuitively understand.
[...]

What's so difficult about running zip on the code?

The fault of LOC is precisely that people "fairly intuitively" understand it. The problem is that no two people's intuitions ever match.  So any conclusions drawn from LOC must necessarily be subjective, and really not that much better than saying "I feel like language A is better than language B, because I just like it better, and besides, it has a nicer color (aka better LOC or whatever other subjective metric)."

Which is fine, if that's what you're looking for. But let's not pretend it has anything to do with the objective quality of a language.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

I think that there is a lot speaking against sloc.

First it's often (ab?)used for "Ha! My language x is better than yours. I can write a web server in 3 lines, you need 30".
And then slocs say a lot of things about a lot of things. Like: Experience (being new or not used to X I'll need more lines in X than in "my" lang, say, D), built in vs. library, coding style, and others.

In the end "100 sloc in X vs. 180 sloc in Y" quite often means close to nothing. Putting it bluntly: If I know enough about all the relevant details of the languages+environment to arrive at having sloc mean anything useful, I won't need that comparison in the first place.

On Saturday, 24 August 2013 at 16:19:07 UTC, H. S. Teoh wrote:
> The fault of LOC is precisely that people "fairly intuitively"
> understand it. The problem is that no two people's intuitions ever
> match.  So any conclusions drawn from LOC must necessarily be
> subjective, and really not that much better than saying "I feel like
> language A is better than language B, because I just like it better, and
> besides, it has a nicer color (aka better LOC or whatever other
> subjective metric)."

That sounds to be the exactly what we wish to capture.

> Which is fine, if that's what you're looking for. But let's not pretend
> it has anything to do with the objective quality of a language.

See above. What use is an objective measure when peoples taste for a language is subjective?

On 8/24/2013 9:17 AM, H. S. Teoh wrote:
> What's so difficult about running zip on the code?

It's not so easy to run zip on a snippet in a magazine article, as opposed to visually just looking at it.


> The fault of LOC is precisely that people "fairly intuitively"
> understand it. The problem is that no two people's intuitions ever
> match.  So any conclusions drawn from LOC must necessarily be
> subjective,

Language comparisons are *always* subjective.

A corollary to that is one can always game any supposedly objective criteria.

On Saturday, 24 August 2013 at 04:59:41 UTC, H. S. Teoh wrote:
[..]
> A far more reliable measure of code complexity is to look at the
> compressed size of the source code (e.g., with zip), which is an
> approximation of the Kolgomorov complexity of the text, roughly
> equivalent to the amount of information content it has.
[..]

Not always. Using long names vs. short ones will substantially inflate zip file size, but will not affect LOC count.

Paul Jurczak:

> Using long names vs. short ones will substantially inflate zip file size, but will not affect LOC count.

On the other hand if you use a very good compressor (like the PPMd of 7Zip or even better a PAQ by the good Matt) the identifier names that are mostly a concatenation of English words will be compressed to around 1-2 bits/char.

Bye,
bearophile

On Saturday, 24 August 2013 at 17:01:56 UTC, Ramon wrote:
> I think that there is a lot speaking against sloc.
>
> First it's often (ab?)used for "Ha! My language x is better than yours. I can write a web server in 3 lines, you need 30".
> And then slocs say a lot of things about a lot of things. Like: Experience (being new or not used to X I'll need more lines in X than in "my" lang, say, D), built in vs. library, coding style, and others.
>
> In the end "100 sloc in X vs. 180 sloc in Y" quite often means close to nothing. Putting it bluntly: If I know enough about all the relevant details of the languages+environment to arrive at having sloc mean anything useful, I won't need that comparison in the first place.

I once worked in a project where QA and PM people would look at all the metrics one can generate out of Sonar (http://www.sonarqube.org/) and as side-effect dictate software design decisions based on them.

The reason being, we the coders, started to write code and unit tests that would drive the metrics into the numbers given as target for the project metrics.

If you don't know it, there is an online version to play with here
http://nemo.sonarqube.org/

We joked it was QDD, QA Driven Development.

--
Paulo

On 24/08/13 19:01, Ramon wrote:
> I think that there is a lot speaking against sloc.
>
> First it's often (ab?)used for "Ha! My language x is better than yours. I can
> write a web server in 3 lines, you need 30".

Don't know about a web server, but I remember somewhere online I found this really cool 3-line quicksort that you can do in Haskell :-)

    qsort []     = []
    qsort (x:xs) = qsort (filter (< x) xs) ++ [x]
                   ++ qsort (filter (>= x) xs)

On 8/25/13 3:57 PM, Joseph Rushton Wakeling wrote:
> On 24/08/13 19:01, Ramon wrote:
>> I think that there is a lot speaking against sloc.
>>
>> First it's often (ab?)used for "Ha! My language x is better than
>> yours. I can
>> write a web server in 3 lines, you need 30".
>
> Don't know about a web server, but I remember somewhere online I found
> this really cool 3-line quicksort that you can do in Haskell :-)
>
>      qsort []     = []
>      qsort (x:xs) = qsort (filter (< x) xs) ++ [x]
>                     ++ qsort (filter (>= x) xs)

This is one of the worst PR functional programming has ever gotten, and one of the worst things FP has done to the larger community. Somebody should do hard time for this. And yes, for that matter it's a great example in which SLOCs are not a very good measure.

Andrei