[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[John Buehler]

Ola Fosheim Grostad writes:
> Bruce wrote:

>> There's also the whole argument in favor of components and those
>> types of systems which were heavily promoted by John Buehler some
>> months ago, and with good reason.

> I view "components" as something invented for business applications
> which tend to deal with rather stable domains or no hard realtime
> requirements or serious interdependency performance issues AND which
> have to deal with a bunch of existing legacy systems and lots of
> bloat and incompetent programmers...

The stability of a domain is absolutely an important part of creating
quality software.  This is true whether you're using components or
not.  Stability implies time, and time permits understanding.  Lack of
comprehension is the number one reason that we have bugs (my own
assertion).  Precise contracts are a claim that both sides of a
contractual interaction can know very specific things about what's
going to happen during that interaction.

> But for state-of-the-art MUDs... Why put up a concrete wall between
> your modules?  This is not good for a system that is supposed to
> evolve.  By advocating components one just says that one has given
> up finding a good flexible design AND that you know exactly where
> flexibility will be needed.  In a virtual world however,
> dependencies tend to be related to groupings like geographical areas
> and you seldom can say that there will never exist dependencies
> between different types (classes) in the future! On the contrary, to
> have depth (which most MUDs don't have) you want LOTS of relations
> between those types if you can handle it.

If you want a fluid environment, it means that you will not have
stability.  By definition.  You can go through a stabilization period,
but the cost of finding a problem during that period can be
extraordinary - to the point of ending an entire project.

What you're talking about is essentially the current development
methodology: use smart people to juggle the details in their heads and
hope to stay on top of all the issues.  Rely on the contracts that
experienced engineers carry around in their heads because they've
already built the silly things 10 times.  That's where we get database
specialists, networking specialists, etc.  These problems get resolved
in code over and over and over again.  The expertise of these
individuals is not being captured unless we get around to a standard.
A standard is a precise contract, and it's fairly obvious what the
value of those contracts have been over time.  Only when we nail down
interactions do we get to advance to the next layer or level of
problem solving.  If standards had never evolved, we'd still be
writing assembly code and building applications no more complex than a
clock.

> IMHO layers, modularity, invariants, separation of responsibilities,
> refactoring and all that is good, but components-as-advocated
> (specification based, stable, 3rd party replaceable, no need to
> recompile etc) are not!

And this echoes the sentiments of the vast majority of the software
development community.  Taking the time to come up with precise
contracts takes too long, so we crank out code at a furious rate.  And
that code is buggy.  But not buggy enough to annoy consumers.  When
the day comes that somebody takes the time to produce very high
quality code with equivalent functionality of existing products, that
somebody will eat everyone else's lunch.  Personally, my money is on
the Indians.

> Obviously if you are going to implement a MUD design of the 1990's
> then you can get away with the performance penalty and the
> inflexibility which comes with components... However, you can
> achieve the same thing without the performance issues by being
> disciplined about which classes you depend on (like which header
> files you include, which is easy to verify).

For starters, components do not produce a performance penalty.  Using
a component that isn't suited to what you're doing produces a
performance penalty.  There is nothing inherent in components that
produces a performance penalty.  Further, the inflexibility that
you're referring to is the same inflexibility that comes from having
to use standardized parts in any construction process.  Note that
you're using standard network protocols, standard schedulers, standard
file systems, etc.  The reason that you can build the software that
you do today is because of a very coarse-grained componentization that
has been happening over the past 40 years or so.  We very inflexibly
use Unix or Windows, but that frees us up to solve other problems.
Neither Unix nor Windows is probably the optimal solution to the
problems that they solve with regard to games, but they're good
enough.

> (This is not to say that you cannot implement certain modules as
> components with no penalty, but the core that constitutes the MUD
> cannot be built with components without penalty...)

To be sure, we found that immediately nailing down contracts without
taking some time to use them was a suicidal pursuit.  When coming up
with something new, new contracts need to be explored to see how they
should be used.  This does not mean that the methodology of capturing
contract specifications is impractical.  It simply means that the
contracts will be in a state of flux.  Working with contracts was a
bit like finding a Rosetta stone for software development.  Lots of
things that I had done for years became very clear to me, such as
changing a the signature of a function.  That's a change of contract,
and our compilers help us to sort that out.  But changing the behavior
of a piece of software without informing the software that uses it is
not something that current tools support - yet such things can be
lethal on a non-trivial project.

Anyway, that's my three dollars' worth.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev