[Shootout-list] Re: Optimizing for speed vs. beauty

[Bengt Kleberg]

Brandon J. Van Every wrote:
> Bengt Kleberg wrote:
> 
...deleted
>>Extra LOC was
>>
>>>clearly the most 'beautiful' way to handle my class of low-level
>>>problems.  Yet I imagine some HLL guy would just make vampire cross
>>
>>1 if you mean that you have to write comments to explain what you are
>>doing, then comments are not counted as lines of code.
> 
> 
> No, I mean that I put 1 ASM instruction per line.  C code that might get
> turned into ASM later, or that will produce proper ASM if handed the
> right instruction sequence, gets written exactly the same way.  1
> ASM-equivalent instruction per line.

last time i wrote assmebler was more than 10 years ago. i interpret you 
paragraph to mean:

given an assembly snippet like this (normal style):

	LDR	r1, [r0], #4
	ADD	r4, r4, r1

you would write it like this:

	LDR
	r1,
	[r0],
	#4

etc. correct?


> LOC is bullshit.  It doesn't respect problem domains.

surely LOC, beeing a number, has no possibility so show respect?
or do you mean that human beeings using LOC does not show respect :-)

>>as an aside i
>>find this to be wrong. they should be since some langauages
>>needs lots of comments, while others do not.
> 
> 
> Again bullshit.  *Human beings* need comments, languages do not.

see my comment above as to why a language might need to have comments 
written beside it.
ie, computer languages are written for
1 the maintainer
2 the compiler

if i say that the language needs comments, it is like saying that ''the 
blind man needs a helping hand to cross the street''. and, no, i do not 
mean that they should be surgically equipped with an extra, helping, hand.


>>2 the number of bugs per LOC is about constant for all languages
> 
> 
> For what, the constant valued mythical 'average' or 'median' programmer?
> In a 7 person elite team, or a 100 person drool team at some dinosaur
> corporation that everyone's either fleeing or milking because it'll go
> bankrupt in 2 years?  More bullshit.

actually you are almost correct here. it is statistics, which is quite 
close to bullshit.


> I would have thought Fred B. Brooks' "The Mythical Man Month" would have
> put all this stuff to rest long ago, but I guess you can't get people to
> stop believing in LOC.

i belive that they exist. if they are still here after one stop beliving 
in them, they are real.


>>(atleast this was the case when i partook in a course on
>>safeware about
>>5 years ago). therefore one might want a low LOC count per program.
> 
> 
> Low compared to what?  Compared to the mathematical decomposition of the
> task you have to do, or some dream of yours?  How on Earth would you
> objectively establish a lower bound for LOC?  Transform your code like
> some obfuscated C contest until it's all on one line?

for the obfuscating qestion, see 3 below.
as for what we compare too, that is other computer languages, solving 
the same problem.


>>3 it is possible to ''cheat'' by having artificially long
>>lines. those ''cheats'' are not of interest for this discussion.
> 
> 
> But you're on a slippery slope as to what's a 'cheat' and what's 'good
> style'.

you are correct. however, in this case we can define ''better style'' as 
the one that uses the most LOC. just beacuse we are trying to avoid 
long, difficult to read, lines.
if we have too spares, and horisontally strung out code, we would not 
use this criteria.

remeber, just because you can not define quality does not mean that it 
does not exist.


bengt