[MUD-Dev] Embedded languages, object persistance... ack.

[J C Lawrence]

On Mon, 3 Jan 2000 15:20:42 -0500 
Jay Carlson <nop at mitre.org> wrote:

> The big lose of persistence is that it's harder to get things back
> to a known state if your code screws up.  

In general this is a function of transaction and logging models.
Given a well implemented transactional model rolling back the log to 
the last set of compleat transactions *should* be cheap and fast.

> By forcing programmers to explicitly manage state, you force them
> to spend some time thinking about these kinds of things.  

Which I would generally view as a Bad Thing.  It is not directly
related to or supportive of their task at hand, acts as a
distraction, and makes their life needlessly complex.

> OTOH, when you're prototyping it's not something you care much
> about.

Too true.

>> -doesn't have every object in memory, only when needed, otherwise
>> on file.

> MOO trivially satisfies this; after all, there are many fine lines
> of code in the kernel to do it, so why duplicate?

MOO relies on the OS VM to handle paging.  This is not necessarily
wise as there is (little?) attempt to ensure data locality, minimum
working page size, etc.  I recall a thread on MOO-Cows a couple
years back that went into some of the pathological corners of this
area in some detail.  I'd also note that this simple point (or
rather the reflection in the impact of going disk based) was one of
the basic design assumptions that Marcus Ranum wanted to disprove
(and did) with UnterMUD (or was that Uber?)

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev