Re: [MUD-Dev] **sigh** OOP wars and defining RDBMS

[Jeff Kesselman <jeffk#tenetwork,com>]

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 
(intobject(2)).plus(intobject(2))
(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
>>felxability. 
>
>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
>languages...

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
>that easy?).

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.

JK>
Jeff Kesselman
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net

-----BEGIN GEEK CODE BLOCK-----
     Version: 3.1
     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------ 

Speak Geek!
http://krypton.mankato.msus.edu/~hayden/geek.html