[MUD-Dev] Java and Javascript

[Caliban Tiresias Darklock]

At 11:11 AM 2/14/98 +0000, Mat Chatterley wrote:
>
>Absolutely agreed that the browser interface is not useful. If anything,
>it means a waste of resources!

No it doesn't! Quit assuming that your MUD is the only damn thing I want to
do while I'm online! I want all the same integrated features I'm used to,
dammit, and your client can most definitely make use of forward and back
while I'm playing if you use an interface that uses that -- like a separate
help window on the side in a frame, for example. Browser-based clients can
provide a lot of functionality and a lot of convenience, and I see a lot of
that being ignored on the archaic argument that it's a "Waste of
resources". I look at my desktop right now and I see a machine with more
memory, a larger screen, faster video, and a bigger disk than we would even
have DREAMED of five years ago. I have more memory on my SOUND CARD than I
had on the system I was using just a couple years ago. (Okay, so most
people don't have 28 megs on their sound cards, but you get my point. Hell,
five six ago my machine had four megs of memory and was considered a
workhorse; now, I have 8 megs on my video card and 6 megs on a 3D
accelerator, 28 megs on a sound card, and 128 in the main system, or a
total of over forty times that amount of memory.) We no longer live in an
environment of conservation. We live in an environment of fantastic
abundance, and I get a lot more upset by programs that sit around in 512K
of memory swapping to disk when I have 88 megs of free memory even AFTER
loading up twelve other applications. It's THERE. Use it. What's the bigger
waste: the program that takes twelve megs of memory for data, or the
program that leaves twelve megs of memory sit idle while it reads the data
straight off the hard drive? 


Christ, people, we go out and buy games now that require 32 megs of memory
and 400 megs of hard drive, and solve them in two weeks. I think we can
spare a similar level of resource commitment for an ongoing MUD, provided
the distribution method is reasonable. Rule of thumb: The "average" machine
at any given point in time is the machine that cost $1500 last year. Today,
that machine is a Pentium-2 at 233 MHz with 4 GB disk and 64 MB. We can
assume that the user has at least a 12x CD-ROM and 32- or 64- bit sound
card, and that his video card has at least 2 MB on it but probably 4 MB. We
can therefore assume that in a year, this will be the average. Program
accordingly. Manage resources accordingly. And quit bellyaching about the
resources being used on the client. Yes, every time I look at my Windows
desktop my 1970's-era programming discipline rears its ugly head and tells
me just how many clock cycles my system is wasting on these pretty pictures
when it COULD be doing my work. But that's modern computing for you, and
that's life. 

Resources are there to be used. If you think it's waste, go write command
line utilities. I have and use and love several of those, for this exact
reason: they do what they say they'll do, they do it fast, and they don't
screw around with real-time interfaces. Batch jobs are alive and well.
There's plenty of room for both types of people in the computer industry,
but let's not put command line mentalities in a GUI environment or GUI
mentalities on the command line, okay?
 
>Or, since the browser implementations of Java seem to be flawed, require
>the user to download a JRE (runtime environment without the development
>tools and such) for their system. OTOH I've had no troubles with
>in-browser Java as yet, but am not using 'cutting edge' features, either.

Yeah, exactly. I really want to download the JRE and install it. I'm just
hankering for a chance to close all programs, edit my registry, modify the
system files Windows isn't supposed to need anymore except for DOS
compatibility, and reboot my computer twice. Sorry, I'm playing a different
game.

>You may well encounter troubles (Ack! I'm tired/sloshed, I nearly typed
>'you may well encounter trousers').

Well, we all know where men's minds live. ;) 

Incidentally, if I ever encounter trousers in the course of programming a
MUD client, I'm dropping the project immediately. That's a Bad Omen, and I
think it's one of the signs of the apocalypse listed in the book of
Revelations.
 
>> >Should I be looking at both Java *and* Javascript, to complement each 
>> >other, or should I concentrate on using just one of them? 

Debugging will be a lot harder if you use a combination. However, if you
can leverage an existing codebase by interfacing the two, by all means do
so. If you understand and feel comfortable with both technologies, use both
of them. If you feel more comfortable with Java, use it. More comfortable
with JScript? Use it. They're just interfaces. Your major problem with
going straight JScript is the inherent statelessness of HTTP, so you should
probably use at least some Java to maintain a persistent network connection
(assuming you need one). I'm sure you can do a pretty decent MUD without
it, but saving state is one of those 'big things'. 

What ever happened to single player games? I don't like team sports and I
don't like competition and mainly I want something that I can play and have
fun with even if there's no one else there. Most of the time there isn't
going to be anyone else involved. (Sort of like my sex life.) This network
game boom has really caused a lot of the single player stuff to suffer.