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

[Brandon J. Van Every]

Bengt Kleberg wrote:
> Brandon J. Van Every wrote:
> >
> > 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?

No, incorrect.  The 1st example has 1 ASM instruction per line.  I don't
know why anyone would ever do the 2nd example.

> > 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 :-)

"Lines Of Code" isn't a number.  If it were, we could say what number it
is, like '7' or something.  Then I could just say '7' in place of 'LOC'.
"Lines Of Code" is a concept.  The concept does not show respect for
problem domains.

Ah hell!  42.

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

Would a bloody severed hand do?

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

Hey, maybe 42 is the statistical bullshit constant!

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

Aw shoot, for a minute there I thought you meant the people.

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

And *they* determined a lower bound of problem decomposition how,
exactly?  You could do it for trivial problems, i.e. 'this loop'.  Not
for any complex program.  Too much tied into semantic choices.

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

Yes I aaaaaaiiIEEEEEEEE <WHONK>

> in this case we can define ''better style'' as
> the one that uses the most 42.

Really.  And I thought most people valued economy of expression, to the
extent that it isn't obfuscating.  X += 27;  *p++;  for (i=0; i<n; i++)

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

The notion of 'quality' as an organizing behavioral symbol exists.


Cheers,
42