[MUD-Dev] Fw: 16K mud server competition !

[Miroslav Silovic]

"Jay Carlson" <nop at mitre.org> writes:

> "Miroslav Silovic" <silovic at zesoi.fer.hr> writes on Tuesday, April 04, 2000
> 7:52 AM:
> 
> > Otherwise, you can just write a MUD in
> > Java or Common LISP (The Language With Everything On, or Did You
> > Really Think That -Emacs- Was Big? or MMap Twenty Megabytes On
> > Startup), and use all the available libraries for these languages - as
> > a result, you'd get really small code indeed, and it'd want to link to
> > megabytes of runtime environment.
> 
> Lisp gets a bad rap here.  Just about every C app on the system gets to mmap
> in libc.so, and from there it gets worse:

Okay, that was meant as a joke (I'm guile's early adopter, and I wrote
10-20,000 lines of Scheme and went as far as to actually try and write
a bit of a MUD in Common LISP, using CMUCL implementation).

My main gripe with Common LISP is that there still isn't any single
implementation that satisfies all of the following:

	- within 1/3 speed of C (CMUCL, ACL does this)
	- realtime, generational GC (ACL checks)
	- optimised CLOS implementation (ACL)
	- free, source available (CMUCL, CLISP check)
	- source actually readable and compilable (CLISP check)
	- active development (ummmm... CLISP)

IMHO guile+hobbit come close to be useful for Real Work (esp. with
Greg Harvey's upcoming garbage collector), but while guile duplicates
most of CL features, it doesn't do that in a standard way (although
that isn't all that important for MUDs).

> KDE looks pretty svelte in comparison---the terminal only needs 4M
> of shared libraries to come up.  I'm still trying to forget the
> project from a few years ago that linked in truly massive piles of
> CORBA and auto-generated libraries....

Note that you'd have to link GUI libs -in addition- to runtime libs of
whatever language(s) you chose to code with.

Also, KDE chose MICO as their ORB. I failed to find a sufficiently
strong set of adjectives to apply to MICO that'd also pass the basic
net decency principles (but you get the idea) - that thing overuses
templates, can't short-circuit same address space calls (i.e. if
you're using CORBA to just wrap a shared lib, then a Real ORB wouldn't
add a huge overhead of serialising all your data, sending it via IIOP
from one bucket in your process to another, then unpack it all and
call the function, it would call the bloody function and just get on
with it), and uses DII for EVERYTHING. Lesson: CORBA is actually a
good idea, but some of the implementations suck beyond belief. When in
doubt, use ORBit (and help the guys doing C++ binding, if you're after
C++ - otherwise stick with C, Perl and Python).

-rwxr-xr-x   1 silovic  lss        288692 Apr  4 11:45 /opt/beta/lib/libORBit.so.0.4.0
-rwxr-xr-x   1 silovic  lss        179012 Apr  5 14:02 /opt/beta/lib/libglib-1.2.so.0.0.6

--
How to eff the ineffable?



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