[vworld-tech] Modern MUD server design

[Brian Hook]

> If you're being conservative, I submit that making performance
> analyses based on isolated benchmarks against unrelated
> implementations is unwise.  

That wasn't my intent.  I was making an initial decision based on 
available data.  Given lack of data (Mozilla JS) I basically had two 
options:  do an implementation and measure the performance myself, or 
discount that option.

I opted for the former, primarily because of time constraints, and 
also because other options (e.g. Lua) provided much of the 
functionality that I need.

While you can argue that lack of knowledge/awareness of an 
implementation isn't a particularly good excuse, that's the one I'm 
using =)

> Conservative, to me, is making careful analysis of your performance
> requirements in the large, and finding a tool -- be it a language
> runtime, a database subsystem, a rendering engine or a networking
> stack -- that matches your requirements most closely.  That's a
> fair bit more work than reading the GLCS, though, and sadly most
> people don't do it.

Depends on what you're being conservative about.  In this case, I was  
trying to be conservative about the choice of language _modulo 
available data_.  I can't justify fact-finding on every language that 
isn't well documented in the wild (with regards to things that I need 
to have documented).  This is why I haven't bothered trying to get 
TOM, Obj-C/GNUStep, and other equally interesting candidates up and 
running as well.

> the last time, to point out why I think that you -- and others, no
> doubt, you're just the one brave enough to post about it -- are
> likely doing your application a disservice by relying as you seem
> to be on a single (unrelated, in fact) data point for the analysis
> of something that is, by your own admission, critical to the
> quality of your software.

To be clear, that's not the ONLY data point I was relying on!  Sheesh, 
I'm not quite THAT stupid.  The GCLS is a benchmark, and benchmarks 
really do suck for many, many things.  Drawing a concrete conclusion 
about the relative performance of different implementations from GCLS 
is very sketchy at best, and I'm aware of that (having dealt with 
benchmark suites daily in another life).

The point I was trying to illustrate is that when an implementation 
and/or language is not particularly well discussed, measured, poked 
and prodded, then the onus falls on the interested individual to do 
all that work -- and that individual simply may not have the time to 
go to that level of effort.  If JavaScript was really, REALLY 
compelling in terms of features over, say, Lua, then I might have 
expended the effort, but my admittedly cursory examination did not 
lead me to believe that.

That said, if you can evangelize it successfully such that I feel like 
a dumbass for not taking it more seriously, well, my ego isn't so big 
that I wouldn't change my mind =)

> I don't know what sorts of embedding docs you're looking for -- it
> would not surprise me to discover that there are more for those
> languages, though, as they enjoy a wider "open" developer community
> -- but you might find the various embedding guides linked from here
> to be useful:

Sorry, I conflated two points and they ended up sounding like one.  
The issue about docs/embedding was meant to be separate from the issue 
about performance measurement.

> embedding.  It is almost certainly not the droid you're looking for.

Right, but I couldn't really tell that from the description.  In fact, 
from the description it sounded very close to what I wanted, without 
actually know what the hell it was. =)

>From the intro docs:

"The XPToolkit is a collection of loosely related facilities, from 
which application writers can pick and choose, which provide a 
platform independent API to some commonly exploited platform-specific 
machinery, e.g., bringing up a dialog"

Which sounded a lot like what I was looking for, but wasn't.

Brian