Java as a mudserver language

[Cynbe ru Taren]

Jeff Kesselman notes:

| I thought [Java had deficiencies as a mudserver
| language] too, which was why I designed and wrote the
| kelvin suite, but I'm now abandoning kelvin because with
| 1.1 some very important (to me) holes in JAVA were
| filled.  The "reflection" library in 1.1 solved most of my
| architectual issues.
|
| Just note that if all you've looked at is 1.0 you might want to look
| at 1.1 again, it has grown a lot...
| 
| SUN btw is also promising a JIT (just in Time compiler) by the fall that
| will make JAVA run as fast as native c++... and Sun to date has missed
| neither a promise nor a date on ANY of their JAVA stuff.

All good points, in general!In my personal case, on the other hand:

1)  I'm stubborn.

2)  I figure that if I drop a project every time I get 120,000
    lines into it and some attractive-looking alternative pops
    up, I'll never finish anything at all :).  Better to complete
    one project at a time.

3)  To my eye, Java still shows a lot of signs of the fact that
    it started as a language for programming toasters, and was
    never intended for anything as sophisticated as virtual world
    implementation.  As far as I can tell, it has no real multiuser
    concept, it has no concept of versioning sufficient to handle
    updates of class definitions while continuing to support millions
    of pre-existing instances of the class spread over thousands of
    servers, supporting transparent diskbasing would require
    writing a new vm from scratch, the OO system is kinda lame, in
    particular numbers can't be objects and you can't promote fixnums
    to bignums sanely -- I also believe multiple inheritance will be
    a big win in sophisticated world design -- the current Java notion
    of doing reference-counting over WAN is imho nutso in a general
    mud context (perhaps not in some more controlled intranet contexts),
    transparent networking is not and will not be supported, the security
    model seems to me dubious/inappropriate in the sort of distributed
    mud context I'm interested in, and in general Java is trying hard
    to be fast and stupid rather than rich and flexible ala cutting-edge
    languages.  Plus, Java is written with the Wirthian philosophy that
    the programmer is an idiot who needs to be given dull tools lest
    s/he cut her fingers, rather than the C/lisp philosophy that the
    programmer is competent to be trusted with sharp tools suited to
    the job.  (E.g.: Java rejects overloading because is can be used
    to write more obscure code.  It can also be use to write clearer
    code, but that's not the half of the glass the Java designers or
    interested in.  Which is fine, except that as a programmer, I'd
    rather have my tools helping me than deliverately crippling me.)
    In short, Java rubs me the wrong way on many personal, 
    idiosyncratic issues on which reasonable people can disagree :)

4)  I'm employed professionally writing mudservers in Java;  I'd
    as soon not be doing anything too similar in my sparetime, to
    avoid friction and conflict of interest with my employer.

5)  There are clearly gonna be lots of people writing mudservers in
    Java:  Isn't clear I'd contribute much by writing one more. Muq,
    on the other hand, looks like it will at least contribute
    something a little different :)