[sldev] sljirastats.com Linden Metrics Report

[Callum Lerwick]

On Fri, 2008-04-18 at 07:07 -0400, Felix Duesenburg wrote:
> There is quite a heavy dependency of the viewer application on the 
> correctness of added resources. In other words, hard coded parts of the 
> program need outside resources to be correctly structured or they would 
> fail. I really mean structure, not just language dependent snipplets of 
> text, or colors or the like. Examples of that are keywords.ini and the 
> entire GUI skin files collection, and certainly some more parts of the 
> viewer which I'm not yet too familiar with.

> I may be totally off with this, missing out a mention of the reasons for 
> why the current structure is the way it is. Can someone help with a 
> pointer if that is the case?

How about:

Rule of Representation: Fold knowledge into data, so program logic can
be stupid and robust.
http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263

At the same time:

Rule of Generation: Avoid hand-hacking; write programs to write programs
when you can.
http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878742

So arguably *automatically generated* code is acceptable. But you need
to strictly disallow hand-hacking of generated code. Don't even put it
in the SCM, make the build system generate it for you.

But I think the real issue here is:

Rule of Repair: Repair what you can — but when you must fail, fail
noisily and as soon as possible.
http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538

The viewer has the "failing" part down, but fails at the graceful and
noisy part. It crashes and gives you no useful diagnostic output as to
what the problem is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/11fc0a47/attachment.pgp