Parallel Rogue-like benchmark

[Joseph Rushton Wakeling]

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.