From: behrends@arctecws-12.dfki.uni-kl.de (Karl Reimer Behrends)
Subject: Gamedriver engineering (Was: Re: Gamedriver survey [LONG])
Reply-To: behrends@dfki.uni-kl.de (Karl Reimer Behrends)
Organization: University of Kaiserslautern, Germany
Date: Tue, 13 Oct 1992 04:00:29 GMT

In article <14926@chalmers.se>, d8andjo@dtek.chalmers.se (Johan Andersson) writes:
|> In article <1992Oct4.161059.22188@rhrk.uni-kl.de> behrends@arctecserv-1.dfki.uni-kl.de (Karl Reimer Behrends) writes:
|> 
|> Here we go again... First though,
|> 
|> Joern (aka Amylaar) produces good code, functionality-wise, I doubt there
|> is any GD hacker, since Lars quit, that has put down more time and effort to
|> make the GD more efficient, than Joern.

Please add bug-free to efficient.

|> This does not mean that Joerns code
|> is free of bugs.

Of course not. No program of that size can ever claim to be correct in its
entirety. Yet there seem to be fewer bugs in his driver than in others.

|> With Joerns style of coding bugs means that he corrects
|> them, noone else. This is why CD has choosen not to use his code.

Of course you are free to decide what code you use and what code you don't use.
However, I don't think your arguments concerning readability of Amylaar's
code are valid. But we will discuss this later on.

|> > Err. You didn't get my point. I never said that Amylaar's code is that
|> > simple that you could give it to a CS freshman without expecting problems.
|> >
|> I'm sorry Reimer this argument does not hold. None of the CD crowd are
|> CS freshmen. We all have considerable experience, I have an MS, Jacob has
|> been teaching in the CS dept for 10 years, Carl has been, and still is
|> sysadmin for the mathdep, and Lennart (aka Marvin) is one of the Dr's at
|> the CS dep. You might reflect at Lennarts statements when seeing some 
|> especially nasty part of Joerns code: 'How can so much do so little?' and
|> 'I cant make heads or tails of this code'.

Oops. Fundamental misunderstanding. I never suggested anybody at CD was
incapable. What I wanted to say is that Amylaar uses non-trivial code sometimes.

|> > Bertrand Meyer of Eiffel
|> > fame once wrote on the topic of software reuse something like that: That to
|> > convince a programmer to use somebody else's mousetrap, it has to be a damn
|> > good one. ;-) It seems you prefer mousetraps labelled CD. ;-)
|> >
|> It is preferable to have the responsible programmer at armslength so you
|> can twitch his ear when a nasty bug crops up. There is however rather large
|> chunks of the CDdriver that are not made by us. Examples are the library code
|> by Germano Caronni and the sprintf code by Dave Bennett.

This sounds logical, but is far too restrictive an assumption to be of any
use in a real programming environment. If you don't ever rely on code written
by other people you go on inventing the wheel again and again. This can be
most clearly seen when using libraries (even simple ones like libc.a, libm.a),
compilers or operating systems written by other people. You have to rely on
other people's code - you just can decide to what an extent you are doing that.

|> As for software reuse, the key is that understanding of someone elses code
|> must not take longer than writing up the same functionality yourself. What
|> that implies for Joerns code is left as an exercise to the reader.

No. The idea of software reuse is not at all that simple. The proof is simple:
If this was the key to software reuse, you could only use software delivered
in source form. While this is preferable, it is not always possible. Let's
tackle this systematically: According to basic principles of software
engineering writing a program involves (1) Specification, (2) Implementation,
(3) Verification and (4) Documentation. I don't now of any gamedriver where
(1) or (4) can be considered to be available. Neither Amylaar's driver nor the
CD driver nor MudOS meet these requirements even remotely. (2) is the focus
of the current discussion and will be discussed in more detail below. Suffice
it to say at the moment that nobody so far actually has given some objective
criterion by which Amylaar's driver fails to qualify.
But where (3) is concerned, Amylaar's gamedriver has a definite edge. I don't
know of any other gamedriver with a comparable bugfixes/time ratio.

|> I should end there, but I cant help use a bug example supplied:
|> 
|> >   1) continue within a switch. The CD driver prints a nice traceback before
|> >
|> Who wrote this code? Joern. We can not use his fix because we would
|> either need to understand it or accept Joerns entire new GD. The only 
|> logical alternative is to rewrite the switch-case code.

Hmm, I should've mentioned the memory leak in parse_command() instead. ;-)
Actually I half expected this kind of reply when giving the bug.

Now I really start wondering what's so difficult about the switch() code.
It can't be the code in interpret.c because every self-respecting programmer
should recognise binary search when he sees it. So it has to be the compiler
part. But the use of heaps for priority queues or sorting is (or should be)
widely known - and that's by far the most difficult part of it. Even the
variable names are selfexplanatory. So where's the hard stuff? I cannot help
but noticing that without Amylaar's code the most difficult single algorithm
within the gamedriver is hashing with collision resolution by chaining. Thus
I guess simplicity is mistaken for readability. Of course, storing pointers
to strings instead of the strings themselves wreaks havoc with CD's binary save
routines. But since execution of a piece of code is done more often than a
reboot this is justified in my opinion.

The same applies for alists - they are so simple a concept that LISP programmers
have been using them for decades (see John Allen's 'Anatomy of Lisp', printed
around 1974 or so, for example). Yet people (notably CD people) keep complaining
about them. The implementation again uses binary search and heapsort. So where's
the problem?

|> I think this example beautifully shows the problem with using unreadable 
|> and ununderstandable code. When a bug shows up, the entire thing must be 
|> rewritten.

True enough. But this applies to a far greater extent where Design/Specification
bugs are concerned - such as the lvalue lifetime bug which requires major
surgery in the compiler. And I still challenge you to show what it is that
makes Amylaar's code unreadable in your opinion.

And then, in article <14928@chalmers.se> you wrote:
|>  Lastly:
|>
|>    Jacob wrote:
|>    > PS. If Amylaar gets a job without net access, a girlfriend or some other
|>    > mudfree life, where does that leave you? Relying on a one man show isn't
|>    > the best of options. DS
|>
|> > So you're going to devote your life to gamedriver support, huh? ;-)
|> >
|> The point is that Jacob does not have to. 

Of course not. Nobody has to. But he made it sound as if he did. So I questioned
that.

|> > Actually, what you suggested for Amylaar to happen, did already occur to
|> > Lars (quite intelligent of him - MUD != Life, come to think of it, and he
|> > already spent enough of it for muds).
|> >
|> Right and as Lars codes in a readable way, people could continue where
|> he left off.

So who has besides Amylaar if it's that easy? People are known to have
implemented simple bugfixes or written new efuns, but who has really picked up
where he left? I can only repeat, repeat and repeat: Changing gamedrivers in
a more than trivial way is a task for experts.

|> > And so far his is the only choice for people whose MUDs still run in compat
|> > mode and want to have a stable gamedriver.
|> >
|> True until Joern tires of mudding. Then when leftover bugs crops up, noone,
|> or at least exceptionally few, will be able to continue where he leaves off.

Same with any other gamedriver. Sorry.


					Reimer Behrends