From: amylaar@mcshh.Hanse.DE (Joern Rennecke)
Subject: Re: Darker Realms - The Mudlib
Organization: Point of Presence & MCS Hamburg
Date: Fri, 4 Sep 1992 04:54:06 GMT

jacob@fy.chalmers.se (Jacob Hallen) writes:

>In article <1992Aug20.040039.1426@mcshh.Hanse.DE> amylaar@mcshh.Hanse.DE (Joern Rennecke) writes:
>>Hmm, no wonder the code won't work like it should when you never care to
>>incorporate it correctly.

>But we haven't incorporated it, Lars has, and I think you have had the chance

He picked a version that already had several successors... And then
incorporated 'fixes' that made the cache inconsistent ... I think he already
had some time problems at this date.

>of testing what he has done, and correcting any of his mistakes. And I hardly

No, i haven't had, 3.0.51 was terribly delayed, and when it came out, i was
cut off from the net for some time with only little news reading and mail
capability.

>expect him to find obscure leaks in the middle of your code.

>>b) Documenting code is extremely inefficient when the basic design is
>>unfinished. Because The comments will vanish with the code when you realise
>>that a piece of code needs replacement. And i haven't seen a bug-free
>>and complete LPmud gamedriver yet.

>This is the lamest excuse I have ever heard. If you make your code available
>for FTP, you must expect other people to use it, and unless you have
>delusions of grandeur, you must expect your code to contain bugs. How do

No, i suspect, but never expect it to contain bugs...  code of smaller or
medium complexity is typically bug-free when i finished writing.
And most of the bugs that creep into the draft of more complex code
will show up either in simple test runs or all by themselves when i'm taking
a break from programming...

>you expect the poor people you lure into using your stuff to be able to find 
>and repot your bugs? Do you expect them to be able to fix them themselves?

Pretty simple: xyz does not do what it should do. Why should the average LPC
programmer need inside knowledge of the gamedriver. when you write
save_object(filename); , for instance, you want variables to be saved. You
won't care how the driver figures out arrays and mappings that are identical
and constructs handy descriptions for recursive data structures.

>What you do is that you load the inefficiency onto your victims, who have
>to understand your cryptic and undocumented code.

It's not really undocumented. Just a bit terse documented.

To find cryptic code, you only have to look at the two parse_commands...
At least i find the way to fix the bugs.

>>>So instead of arguing why your code should be hard to read, why don't you
>>>change your coding habits. You will do yourself a favour and we can start

I rather fix a bug than explaining at length when and why the code won't work.
Is that that bad a habit?
>>>using your code again.
>>
>>Readability without functionality is useless. And there is still a great deal
>>of unimplemented stuff in the gamedriver, some even pointed out by gaping
>>holes in the code...
>>
>Functionality without readability is useless, especially in a changing
>environment. You must expect that someone else takes your code and modifies

Some parts of the driver might be replaced quite rapidly with something else...
I need a changed type concept and value/lvalue indexing sheme to get the
room for further expansions i need...
So why should i comment the current intermediate state to an extent that
even a non-programmer might think that it's nice prose.

Besides, my comments and variable names are always in english, not in
german or swedish, unlike the ones from some other driver hackers...

>it for some other use, or reimplements it with an other algorithm that

First i try to get the a suitable algorithm myself... Not only something
that does the job in finite time with finite memory, but rather a stronger
constraint than 'finite' ....

>turns out to be more suitable under the given circumstances. If you don't heed
>this, your code will be useless to all people apart from yourself.

Of course, these simple linear searches are the easiest to understand...
almost declarative...

	Amylaar
Newsgroups: rec.games.mud.lp