[MUD-Dev] MUD Design Fundamentals (Was: Looking for

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

>>Well, databases as such are typically shared among many clients, and that
>>is their design rational.  They are typically accessed by batchlike
>>functions (at least conceptionally).  I think there is a big difference
>
>No, sorry.
>
>A database sevrer does this.  But Cold for instance is absed on ndbm which
>is a full data base library that is linked directly to your code and uses
>individual fiels per application.
>
>What your are describing is a implementation feature of a partoicualr
>applciation of an rdbms-- that of an rdbms server.

THAT was the design rational for databases, historically.  You may of
course use a database with only one "client" if you choose, for convinience
or whatever.  They are however accessed in manner that is conceptually
viewed as atomic execution of functions, where the database is consistent
(or should be) before and after that execution (conceptually that execution
does not extend in time either, it happens instantly).  But, with only a
single client you loose much of the advantage with using a database,
although for some designs it may be convienient.  It is however way
below optimal in terms of execution during runtime.  If you only use
the database for saving upon termination, then that is overkill.
When one discuss approaches to server design, one should keep the general
case in mind.  All textbased MUDs currently existing are higly discrete
and static in nature and would map nicely onto a traditional database
system, but the systems I am interested in would not.  They are way to
iterative, dynamic and fluid-like in nature.  The overhead would
simply be overwhelming.

>No, it does not.

Yes, it does. :)

>You need to loo at small talk and/or Cold.  I already treid to explain how
>you stoire the structure of an object within an rdbms.  I am afraid if that
>failed I can't think of how to make it any clearer.  EVERYTHIGN n a
>computer is ultimately data, even code and the sstructure of your data.
>Itc an be amde as hardcoded or as flexible as you wish-- ist up to you.  

You haven't told me how to make a distinction between realtime information
and other types of information.  And the fact remains, if you change your
object-system (class-hierarchy if you like)  you need a wipe if the data
stored in the internal structure is reflected on the secondary storage
device. (which it will if you use straight persistence)

Anyway, if realtime information is no problem, why don't you just use
plain core-dumping for saving your data between executions?? Tell me!
Core-dumping would be the most efficient and easy way to do persistence,
wouldn't it?

>>Anyway, for all practical purposes, I think C++ or other OO languages
>>decending from ALGOL/SIMULA was implied here.  I care about control and
>
>Well, OO was really first fully developed as a cocmept with Smalltalk.

Well, actually it was first developed with Simula in 1967. Explain what
you mean by "fully".  I've had both of the authors of Simula as lecturers
so I feel I'm up to date on this one :)  Of course, as Nygaard would
probably tell you, Americans don't like to admit that Europe was first...
So, I'm not going to go through a lot of trouble of convincing you,
you've probably got what you say from your lecturers. :P

(A sidenote: Knuth wanted to use Simula in his classes, but wanted a
discount, the board of directors wouldn't let him, they believed that
the lifetime of software would be at most 4 years or so, and thus wanted
instant revenues. So Knuth went with other languages, to Nygaard's
dismay...)

Anyway, you cannot get away from the fact that ALGOL-type languages 
(simula, pascal, c, c++, java) maps nicely onto the current von
Neuman machine architectures, and in fact microprocessors are optimized
towards such languages (+ fortran).  So for any practial purpose you'd
want to go with an algol like language for any computationally intensive
application.

>Frankly I think in the case of C++ (I havent done Smalltalk) youa re
>talking "Object DEesign" languages as oppseod to true "Obejct oriented"
>languages.
>
>There IS a difference, a fudnemental one, and its very hard to decroibe to
>someoen who hasnt worked with the latter.

If I remember correctly, Smalltalk was designed to provide the user with
programming power.  Smalltalk is no more "true" Object Oriented than
Simula, Beta, Java, Eiffel, Self, etc.  C++ sucks as a language, but
is efficient, and does provide the major mechanisms for implementing an
object system.

The major difference however, is in attitudes towards OO among humans,
not in languages.

The scandinavian school focus on Object Oriented Analysis.  They focus
on objects as a mental way for the designer to structure information in
a manner that is suitable for reasoning and implementation.  Simula was
(as the name suggests) designed for making programming simulations
easier. Hopefully programmers write object oriented programs even when
using ansi-C.

The american school focused on OO as a manner of extending programming-
languages with new mechanisms, abstract datatypes etc...

To me OOP is a state of mind, but you could probably say that Smalltalk
provides good support for prototyping.  (which I think it is used for
commercially, quite a lot)

As far as I can recollect there is at least 3 approaches to OO languages:
- class based
- cloning based
- actor based

I prefer the class based as it better conveys how humans perceive the world.
It is important to remember that OO is only something typical for the human,
not something that is typical of the world or the computer.

(Just for the record, yes I know that Self, implement classes through
cloning, but I want my mentalmodel to be supported in the language. I could
do object oriented programming on a turing machine if I wanted to, but I
don't.)

>>My main point was that persistance isn't neccessarily going to save your
>>butt, although it "sounds like magic".  I would at least go for secondary
>>backup functions that store information in an easily parsable format for
>
>Thats a totally different issue. NOTHIGN repalces the need for backups.
>period. The end.

No, it is not. If persistence is totally reliable and did what it should
ideally do, you would not need to store information in two ways.
Period.

>>saving and loading the most essential information.  If not, you are
>>probably stuck with your initial design, or have to accept more clean
>>wipes than you like.
>
>But THIS is incorrect.

So what happens in your Smalltalk when you make radical changes to your
object system??  You have program the transformations, don't you?

I view virtual worlds as longterm evolutionary systems...

(I don't think we'll ever agree, I'm not going to waste a lot of time
on convincing you. I've had a similar discussion before.  All I'm saying
is that persistence is not as useful, advantagous and easy as one first
may think it is.)

Ola.