[MUD-Dev] **sigh** OOP wars and defining RDBMS
jeffk at tenetwork.com
Mon Sep 1 12:57:04 New Zealand Standard Time 1997
At 08:16 AM 9/1/97 PST8PDT, you wrote:
>Messages, methods, functioncalls... Actually I thought Self was the
>one to say there is nothing but objects, not Smalltalk? Personally I
>prefer the distinction between class and instance to be explicit as that
No, I wasn't sugegsting Smalltal khad no classes. What Iw as sayign is that
your code "world" is only objects and that even somethign like 2+2 is done as
(Thats pseudo code nto smalltalk. Smalltalk has the syntax from mars.)
>>MUD project. Ild note that for the record, thet orer of langauegs yo
>>uspecified at least in terms of C++ to JAVA shows a general trend AWAY from
>>staticlky bound "maximally efficient" langauges and twoard such
>Wait, JAVA? How many applications executing the java virtual machine
>do you run on your computer? Besides JAVA is algol like, yes?
>Compiled optimized Java would be as efficient as most other algol type
I've been workign in JAVA sicne the beginning of its release and have been
doing a numerb of comemrical projects in it for quite soem time. i ALWAYS
run under the VM. You lsoe most of the worthwhioel advnatges if yo
ucompile down to native code and linmk. In that cas eJAVA becoems simply a
prettier C++ IMO and fairly worthless.
>Yes, there is more and more cycles, but as there are getting more and
>more commercial actors into the MUD market the ones that gets most out
>of those cycles (as well as providing a usable design) essentially will
Nope. Disagree 100%. Our compuerts are reltively cheap. We must have 30
Sparc stations already anc can go buy and drop more itno our scalable
service architecture at the drop of a hat.
Thsoe who win will be those who can provide the msot compeeling experience
over time. Thsi demands flexability. Im stating this with over a years
woth of experience dealign witha comemrcial grtaphic MUD (DSO).
>win. You may of course take another approach and throw distribution at
>the problem and write off the hardware costs by an assumed gain in
>development time (although efficient largescale distribution isn't all
We've solved it. Efficiency is nto the issue for us, macheins are cheap.
Scalability was the issue and our entire system architecture is a zero
bottleneck almsot infinitly scalabale system.
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net
-----BEGIN GEEK CODE BLOCK-----
GCS/CC/E/IT/MC d+(++)@ s: a C++++$ ULSC+++(++++)$ P++(+++)$ L++
E--- W++$ N++$ o+ K--? w++(+++)$@>--- O+(++)>$ M+>$ !V PS++ PE+
Y+ PGP- t+ 5+ X- R+(++)$>+++* tv+ b+>++ DI+++ !D G e++ h r+++ y+++
------END GEEK CODE BLOCK------
More information about the MUD-Dev