MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...)
- To: mud-dev#null,net
- Subject: Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...)
- From: Ola Fosheim Grøstad <olag#ifi,uio.no>
- Date: Mon, 1 Sep 1997 10:09:38 +0200 (MET DST)
(I'm being short, because I don't feel like taking things over and
over again)
[Ola:]
>>2. reloading may not give you what you want, it is easy to make
>>blunders
[J C Lawrence:]
>Who says that you have to reload text? Why not make it orthogonal?
>Text, code, data, read, write, its all the same really.
Reload text?
>3. fixing a bug in the code may not be enough if the bug is >present
>in the stored structure.
>
>Then make the code and the stored structure one and the same. I fail
>to see a reason for the persistance mechanisim to distinguish between
>code and data.
What difference does this make? Besides I need a lot of power, hence
compiled, optimized code.
>>I only have some experience with persistence, maybe there are
>>approaches that are better, but I know for sure that I wouldn't rely
>>on persistence alone in any long term project.
>
>??? I don't understand. How could one rely on persistance alone for
>a project?
I'll help you out: using a language provided persistent object-store
for saving state upon termination. We've so far discussed programs
running in a shared memoryspace, so saving during runtime isn't
really theoretically interesting.
>which engendered that post. Many of the areas that Greg asked about
>had frequently been discussed here, and I assume, were areas that Greg
>has little familiarity with.
Mebbi, I don't know Greg. I only "know" what I read.
>Sure, it is, or should be, fairly easy to swap out a a list for a hash
>table for a BTree or whatever. However moving a base design from a
>weighted tree or web to a neural net is a sufficient paradigm shift
>that its rarely that easy. In cases like that, if the principles can
>withstand it, I recommend taking the big design and implementation
>leaps early.
Well, anyone attempting to introduce neural nets without running
separate prototypes for quite some time would most likely fail anyway..
:^)
Of course, what one has to think about is whether one need browsability
(for all objects do ...) or other type of functionality. So a list
cannot easily be swapped out for a hashtable if order is important...
>>BUT I do believe, with the help of whatever libraries being
>>available, some general programming knowledge and the major reference
>>books, that "hobby" projects will be able to provide running systems
>>exploring new concepts, provided that the designteam is able to focus
>>on a few concepts. I don't believe it is lack of specialized
>>knowledge (such as NLP design) that prevents them from surfacing.
>
>Agreed.
>
>--
>----------(*) Internet: coder#ibm,net
>...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
>
- Thread context:
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...), (continued)
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...),
coder coder#ibm,net, Sun 31 Aug 1997, 18:25 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...),
coder coder#ibm,net, Sun 31 Aug 1997, 18:57 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books.,
Jon A. Lambert jlsysinc#ix,netcom.com, Sun 31 Aug 1997, 19:52 GMT
- Re: [MUD-Dev] Looking for books...,
clawrenc clawrenc#cup,hp.com, Wed 20 Aug 1997, 02:10 GMT
[ Other Periods
| Other mailing lists
| Search
]