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

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

>Im talking the fudnemntals of RDBMS theory.  The afct that any data can be
>organized into a set of linked tables and the software that derives from
>that theory that allwos the storage of any data in a common format
>organized for fast retireval on a secondary storage device..
>
>You're talkign abotu teh development of a aprticualr kidn of applciation
>based on that theory.

Actually I believe it was the other way around but... The theory evolved
because... etc... Besides I do know some database theory (although I try
to stay away from it because I find normalforms etc extremely
unattractive) and modelling methods like NIAM. So don't explain that stuff,
I just don't like it. :*)  Waste of time, really.

>Everythign is an object.  Function calsl do not exist. Parents are muteable
>and   unknown and reached simply and  only by throwing the emssage back
>onto tehc all tree.  Maybe what Im describing is "ful lencapsulatioN' as
>muchas  anything but I dont think you have a true OOPL withotu ful
>lencapsulation.

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
maps onto how humans deals with the world, and I want single inheritance
because of the ease of reasoning it provides.  I also prefer that the
language differentiate between object and "execution-stabs" (function).

I'm not bashing languages based on cloning, or with heavy
runtimesystems.  They just don't suit me. Except I want a transparent
incremental garbagecollector.  You are of course entitled to make
your own definitions of OOPL. To me OOP is about modelling, a state of
mind, I can implement my design in any language, with more or less
effort.  So, to me a OOPL is a language that supports my OO design
goals. (C++ for the current project)

>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...

>We have LOTS of cycels these days anmd more all the time.
>Correctness of code and maintainabiltiy are fast becomign more important
>then optimal coe efficiency.

I've seen no evidence that compiled languages that supports
compiletime resolution of types is preventing correctness of code.

C++ prevents correctness because it sucks, and promotes hacks.
If you really care about correctness then you'd have to go for
applicative/functional programming (recursion/pure lisp).  Why? 
Because hoare-logic (which is what you would use for proving
iterative stuff) isn't as complete and easy as onewould like it
to be... (Yeah,I know some of the shitty program verification theory
as well. Only slightly more interesting than database theory :*)

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

Ola.