Developing a graphical MUD in Java

[Henrik Kniberg]

(sorry about the crosspost, but this involves more than just one
newsgroup...)

Hi fellow gamers!

I'm currently developing a graphical MUD in Java, and would like some
comments, tips, ideas, warnings, complaints, whatever from the MUD
community :o)

The graphics is view-from-top icon based (like the Ultima games).
Nothing really fancy, and that's the point - this is no VR MUD. I want
something BETWEEN textbased muds and VR muds, where the graphics isn't
the MAIN thing, but still makes it more colorful and user-friendly than
the text-based muds. It may be possible to make it VR later (using
VRML), but first I want a good game that stands for itself, with or
without dazzling graphics.

Right now I'm doing the technical stuff (client/server communication,
graphics, etc) but soon I'll need to implement the more social stuff
like how the world looks like, the social structures, economy, etc.

What I want is a mud where you DON'T have to spend hours upon hours
killing rats and dogs to achieve a level where you can go kill donkeys
and halflings instead, etc. I'm hoping for a more socially interactive
kind of mud with elements of economy and politics - in other words more
PC interaction and roleplaying. There will of course be the usual
dragon bashing and treasure hunting as well :) (OK, I know I'm not
being so concise, but these are just the general goals - I want to check
if you mudders out there agree).

I'm also trying to make a dynamic, flexible world where PCs really can
affect their environment (build things, destroy things, etc in a simple
way) - but not to the point of chaos. Hopefully it will be
self-regulating somehow, I really want to avoid lots of hardcoded
"rules".

If things keep going as well as they have so far there should be a
testable BETA version sometime in february (but don't quote me on
that...).

Those who are interested in more details can check out:

http://www.student.nada.kth.se/~d93-hkn/hamMUD/

--
Henrik Kniberg Royal Institute of Technology, Stockholm
WWW: http://www.student.nada.kth.se/~d93-hkn/
tel: +46 8 159790
email: d93...@nada.kth.se

[George Reese]

Henrik Kniberg (d93...@nada.kth.se) wrote:
: I'm also trying to make a dynamic, flexible world where PCs really can

: affect their environment (build things, destroy things, etc in a simple
: way) - but not to the point of chaos. Hopefully it will be
: self-regulating somehow, I really want to avoid lots of hardcoded
: "rules".

LPC is infinitely better suited to this task than Java, if this is one
of your primary design goals. Remember, that Java does not allow for
dynamic class updating, something which is very important to PC object
creation.

--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i think i've reached that point/where every wish has come true/
and tired disguised oblivion/is everything i do
-the cure

[oemlen]

In article <32AB34...@nada.kth.se>,

Henrik Kniberg <d93...@nada.kth.se> wrote:
>(sorry about the crosspost, but this involves more than just one
>newsgroup...)
>
>Hi fellow gamers!
>
>I'm currently developing a graphical MUD in Java, and would like some
>comments, tips, ideas, warnings, complaints, whatever from the MUD
>community :o)
>
>The graphics is view-from-top icon based (like the Ultima games).
>Nothing really fancy, and that's the point - this is no VR MUD. I want
>something BETWEEN textbased muds and VR muds, where the graphics isn't
>the MAIN thing, but still makes it more colorful and user-friendly than
>the text-based muds. It may be possible to make it VR later (using
>VRML), but first I want a good game that stands for itself, with or
>without dazzling graphics.

This project is already underway, but is being implimented in a
pre-existing, tested mud. It works outstandingly well, and overhead
mapping is flawless, as well as are room view of mobs/object and
inventory. I am just finishing up graphics before it will be released.
The only major hurdle is the fact that 99.5 percent of mudders couldn't
figure out how to install JAVA if their life depended on it. Anyway, the
graphics are icon based, and it works well. There should be a completely
functional, most-graphics-in beta available for free playing (yes, this is
a free project, unless it gets to the point where I have to hire graphical
artists, etc), by early january. Already it is playable, working, and
looks nice... it just needs some polishing.

Owen Emlen

[Tim Hollebeek]

In article <58fnp8$o...@dismay.ucs.indiana.edu>, oem...@ezinfo.ucs.indiana.edu writes:
> In article <32AB34...@nada.kth.se>,
> Henrik Kniberg <d93...@nada.kth.se> wrote:
> >(sorry about the crosspost, but this involves more than just one
> >newsgroup...)

Actually, if your post involves all MUDs, it belongs in r.g.m.misc *only*,
and NOT crossposted to all the groups. This post certainly doesn't involve
anything specific to the diku and lp groups.

Don't argue that people who want to read your post might not see it. If
people read r.g.m.lp and *not* r.g.m.misc, it is for a REASON, and you
should respect that.

---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

[George Reese]

Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
:

: In article <58fnp8$o...@dismay.ucs.indiana.edu>, oem...@ezinfo.ucs.indiana.edu writes:
: > In article <32AB34...@nada.kth.se>,
: > Henrik Kniberg <d93...@nada.kth.se> wrote:
: > >(sorry about the crosspost, but this involves more than just one
: > >newsgroup...)
:
: Actually, if your post involves all MUDs, it belongs in r.g.m.misc *only*,
: and NOT crossposted to all the groups. This post certainly doesn't involve
: anything specific to the diku and lp groups.
:
: Don't argue that people who want to read your post might not see it. If
: people read r.g.m.lp and *not* r.g.m.misc, it is for a REASON, and you
: should respect that.

Newsgroup nazi!

[Nathan Fenenga Yospe]

On 8 Dec 1996 23:55:24 GMT, bo...@visi.com, claiming to be George Reese,
posted to rec.games.mud.admin the following:

: Henrik Kniberg (d93...@nada.kth.se) wrote:
: : I'm also trying to make a dynamic, flexible world where PCs really can
: : affect their environment (build things, destroy things, etc in a simple
: : way) - but not to the point of chaos. Hopefully it will be
: : self-regulating somehow, I really want to avoid lots of hardcoded
: : "rules".

: LPC is infinitely better suited to this task than Java, if this is one
: of your primary design goals. Remember, that Java does not allow for
: dynamic class updating, something which is very important to PC object
: creation.

Ummm... NO. Learn Java a little better. Dynamic class updating can be
accomplished in a few ways... the most effective is a dynamic "implements"
structure. I know you think LPC is the greatest thing in the whole wide
world, but it has a number of TREMENDOUS limitations, and Java is a
complete and fully viable programming language. I thought the original
post rather interesting... if not currently embroiled in my own C++ based
projects at the moment (and one Java based extension to allow telnet
inlining on web browsers, with background graphics and control sequences
for those graphics... in essence, a way to put graphics into a text mud,
in the form of muted backdrops behind the text field pertaining to
current events) I would be very interested in participating in his
project.

--
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yo...@hawaii.edu

[George Reese]

Nathan Fenenga Yospe (yo...@Hawaii.Edu) wrote:
: On 8 Dec 1996 23:55:24 GMT, bo...@visi.com, claiming to be George Reese,

: posted to rec.games.mud.admin the following:
: : Henrik Kniberg (d93...@nada.kth.se) wrote:
: : : I'm also trying to make a dynamic, flexible world where PCs really can
: : : affect their environment (build things, destroy things, etc in a simple
: : : way) - but not to the point of chaos. Hopefully it will be
: : : self-regulating somehow, I really want to avoid lots of hardcoded
: : : "rules".
:
: : LPC is infinitely better suited to this task than Java, if this is one
: : of your primary design goals. Remember, that Java does not allow for
: : dynamic class updating, something which is very important to PC object
: : creation.
:
: Ummm... NO. Learn Java a little better.

I know Java very well, thank you.

: Dynamic class updating can be

: accomplished in a few ways... the most effective is a dynamic "implements"
: structure.

You obviously have no idea what I am talking about.

: I know you think LPC is the greatest thing in the whole wide

: world, but it has a number of TREMENDOUS limitations, and Java is a
: complete and fully viable programming language.

With respect to the task at hand, LPC is better.

: I thought the original

: post rather interesting... if not currently embroiled in my own C++ based
: projects at the moment (and one Java based extension to allow telnet
: inlining on web browsers, with background graphics and control sequences
: for those graphics... in essence, a way to put graphics into a text mud,
: in the form of muted backdrops behind the text field pertaining to
: current events) I would be very interested in participating in his
: project.

I don't think he has chosen the best language for the task.

And, by the way, you may know me for my LPC work, but I am much better
known for my java work :)

[Anthony C.]

In article <58fkhc$l...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
:LPC is infinitely better suited to this task than Java, if this is one

:of your primary design goals. Remember, that Java does not allow for
:dynamic class updating, something which is very important to PC object
:creation.

Java does support dynamic class updating.
--
Anthony Chen
Interactive Games Network
http://ign.cy-net.net

[George Reese]

Anthony C. (acc...@tam2000.tamu.edu) wrote:

: In article <58fkhc$l...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
: :LPC is infinitely better suited to this task than Java, if this is one
: :of your primary design goals. Remember, that Java does not allow for
: :dynamic class updating, something which is very important to PC object
: :creation.
:
: Java does support dynamic class updating.

Please explain how it allows this? If I have
imaginary.mudlib.obj.house loaded, modify it, and then want it in my
currently running mud, how do I do that?

The answer is: you can't.

[Anthony C.]

In article <58hdnr$s...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
>Anthony C. (acc...@tam2000.tamu.edu) wrote:
:: Java does support dynamic class updating.

:
:Please explain how it allows this? If I have
:imaginary.mudlib.obj.house loaded, modify it, and then want it in my
:currently running mud, how do I do that?
:
:The answer is: you can't.

Well the way I do it is to load all my classes with a custom
java.lang.ClassLoader as opposed to the standard ClassLoader.
When I want to load a new version I just read the bytes of the class
file either from the network or from a file, replace the old class
with the new class and it's done. All instances of the old version
that existed still use the old version all further instances created
with newInstance() will use the new version. Obviously you have to
be careful about conflicts by going thru the whole system and
unloading and then reloading all objects with the old definition.
However even if you dont do this you dont have any problems.
At some level you will have to define an interface though and
the interface is not loadable, this is due to the fact that
you dynamically invoke method names. However in JDK 1.1 (beta
released today ) you will have total flexibility as you can dynamically
find out method names then invoke them. If you want a full working
example of dynamic class loading take a look at the VPRO web server at
http://james.vpro.nl:7007. It dynamically loads and unloads classes.

:

[George Reese]

Anthony C. (acc...@tam2000.tamu.edu) wrote:

You are saying you can have two different versions of the same class
loaded in the same virtual machine at the same time? If so, I have
certainly learned something new today :)

[Alex Feely]

Please remove this thread from rec.games.mud.tiny. While I
will continue reading it in rec.games.mud.misc, this is not the
purpose of r.g.m.t. Nor r.g.m.admin, .diku, .lp, or even just
rec.games.mud.

--
======================================================================
The Microsoft Network is prohibited from redistributing this work in
any form, in whole or in part. Copyright (c) Alexander Feely,
1995. License to distribute this post is available to Microsoft for
$800. Appearance without permission constitutes agreement to these
terms. | ma...@mage.cybersoul.com
http://cybersoul.com/ (coming soon) | blu...@netcom.com
======================================================================

[Nathan Fenenga Yospe]

On 9 Dec 1996 16:11:39 GMT, bo...@visi.com, claiming to be George Reese, posted to rec.games.mud.admin the following:
: Anthony C. (acc...@tam2000.tamu.edu) wrote:
: : In article <58fkhc$l...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
: : :LPC is infinitely better suited to this task than Java, if this is one

: : :of your primary design goals. Remember, that Java does not allow for
: : :dynamic class updating, something which is very important to PC object
: : :creation.
: :

: : Java does support dynamic class updating.

: Please explain how it allows this? If I have
: imaginary.mudlib.obj.house loaded, modify it, and then want it in my
: currently running mud, how do I do that?

: The answer is: you can't.

Sure you can. Hell, I've got it working in C++.... have your modification
section part of the reference area of the action implements, and modify it
online, with whatever tools you build in. In short, create a sublanguage
for implementation. As for anything else... well, no... not as far as
recompile level rewrites... that's a very, very stupid thing to have in a
language with more complex features than an LP uses... its not like you
can make an alteration to MudOS and implement it while the mud is still
running.

[Tim Hollebeek]

[reminder: trim the newsgroups before responding to any post in this horridly
crossposted monstrosity]

In article <58hq4p$e...@news.Hawaii.Edu>, yo...@Hawaii.Edu writes:
> On 9 Dec 1996 16:11:39 GMT, bo...@visi.com, claiming to be George Reese, posted to rec.games.mud.admin the following:
> : Anthony C. (acc...@tam2000.tamu.edu) wrote:
> : : In article <58fkhc$l...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
> : : :LPC is infinitely better suited to this task than Java, if this is one
> : : :of your primary design goals. Remember, that Java does not allow for
> : : :dynamic class updating, something which is very important to PC object
> : : :creation.
> : :
> : : Java does support dynamic class updating.
>
> : Please explain how it allows this? If I have
> : imaginary.mudlib.obj.house loaded, modify it, and then want it in my
> : currently running mud, how do I do that?
>
> : The answer is: you can't.
>
> Sure you can. Hell, I've got it working in C++.... have your modification
> section part of the reference area of the action implements, and modify it
> online, with whatever tools you build in. In short, create a sublanguage
> for implementation. As for anything else... well, no... not as far as
> recompile level rewrites... that's a very, very stupid thing to have in a
> language with more complex features than an LP uses... its not like you
> can make an alteration to MudOS and implement it while the mud is still
> running.

BTW, could you explain "modification section part of the reference area
of the action implements" ? Either it has a few typos, or is so jargon
ridden I can't recognize the meaning.

You can, of course, alter MudOS while the mud is still running, since
with the proper options enabled MudOS can dynamically load code. Not
particularly *useful*, IMO, since almost anything one wants to do can
be done in LPC anyway. Whether one can modify MudOS on the fly isn't
really an issue anyway, since it is very rare that people need to
modify MudOS *at all*, let alone on the fly. In fact, I return a
majority of the requests for new features and/or changes in MudOS on
the basis that they can be done already (often easily) with the
existing functionality.

Like I said earlier, there are things that can't be done in LPC, but
there aren't many, and even fewer of them have anything to do with
MUDs.

BTW, why is it a "very, very stupid thing to have in a language with
more complex features than an LP uses" ?

I think you are insinuating that there are language elements in other
languages which are not present in LPC which make this feature
undesirable for those languages. Since many companies are pouring
tons of money into projects involved with adding this feature to other
languages (mostly C++) I think your "very, very stupid thing to have"
comment is just a *tad* strong.

In fact, the issues are almost always the same ones that come up with
distributed code bases, which are a *very* hot topic lately. Those
interested might want to check out http://www.lucent.com/inferno.

[George Reese]

Nathan Fenenga Yospe (yo...@Hawaii.Edu) wrote:

: On 9 Dec 1996 16:11:39 GMT, bo...@visi.com, claiming to be George Reese, posted to rec.games.mud.admin the following:

: : Anthony C. (acc...@tam2000.tamu.edu) wrote:
: : : In article <58fkhc$l...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
: : : :LPC is infinitely better suited to this task than Java, if this is one
: : : :of your primary design goals. Remember, that Java does not allow for
: : : :dynamic class updating, something which is very important to PC object
: : : :creation.
: : :
: : : Java does support dynamic class updating.
:
: : Please explain how it allows this? If I have
: : imaginary.mudlib.obj.house loaded, modify it, and then want it in my
: : currently running mud, how do I do that?
:
: : The answer is: you can't.
:
: Sure you can. Hell, I've got it working in C++.... have your modification
: section part of the reference area of the action implements, and modify it
: online, with whatever tools you build in. In short, create a sublanguage
: for implementation. As for anything else... well, no... not as far as
: recompile level rewrites... that's a very, very stupid thing to have in a
: language with more complex features than an LP uses... its not like you
: can make an alteration to MudOS and implement it while the mud is still
: running.

What the hell are you talking about? In LPC, you are a player object.
You are online in a loaded instance of that player object. You edit
the player object. You update it. New instances of the player object
are made as the new version of the player object while your old
instance remains untouched.

[Anthony C.]

In article <58hfum$3...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
>Anthony C. (acc...@tam2000.tamu.edu) wrote:
:: At some level you will have to define an interface though and

:: the interface is not loadable, this is due to the fact that

:You are saying you can have two different versions of the same class

:loaded in the same virtual machine at the same time? If so, I have
:certainly learned something new today :)

Yes that is correct - at least thats the way the behavior seems to work.
I have not seen this officially documented anywhere, so it is possible
that the behavior is undefined.

[George Reese]

Anthony C. (acc...@tam2000.tamu.edu) wrote:

In all the work I have done and all the resources I have consulted,
this has been shown to me to be impossible. And I do believe that
Java is a good language for writing *a certain kind of mud*. So,
given this experience and your lack of direct experience with it, I
think I would hold belief until I see it :)

The reason is that this is a fundamental violation of the principles
behind the Java virtual machine. In fact, versioning has been a major
issue with Java, especially among the distributed object folk.
Specifically, since all classes in Java are referenced by class
name... Let's take:

House.class in package imaginary.mud

If I compile Player.class in the same package, it will know certain
things about that class, specifically that
House my_house = h;

my_house.enterHouse(this);

is valid. At runtime, if Player.class is out of synch with the
House.class already loaded, I get a VerifyError. This gets worse when
you try to resolve things like:
* Class methods
* Calling my_house.enterHouse(this) with no enterHouse() method.

and so on.

LPC handles this stuff, and it does it in a nice fashion. The cost,
of course, is strict typing.

[Abigail]

On 8 Dec 1996 23:55:24 GMT, George Reese wrote in rec.games.mud.admin,rec.games.mud,rec.games.mud.diku,rec.games.mud.lp,rec.games.mud.misc,rec.games.mud.tiny:
++ Henrik Kniberg (d93...@nada.kth.se) wrote:
++ : I'm also trying to make a dynamic, flexible world where PCs really can
++ : affect their environment (build things, destroy things, etc in a simple
++ : way) - but not to the point of chaos. Hopefully it will be
++ : self-regulating somehow, I really want to avoid lots of hardcoded
++ : "rules".
++
++ LPC is infinitely better suited to this task than Java, if this is one
++ of your primary design goals. Remember, that Java does not allow for
++ dynamic class updating, something which is very important to PC object
++ creation.

C doesn't do dynamic class updating either, yet all LPC drivers
I know are written in C.

Abigail
--
Java is cute. Perl is practical.
[Nathan V Patwardhan in `Java Vs. Perl'
<53lq5i$s...@prometheus.acsu.buffalo.edu>]

[Tim Hollebeek]

In article <58i34g$f...@darla.visi.com>, bo...@visi.com writes:
>
> The reason is that this is a fundamental violation of the principles
> behind the Java virtual machine. In fact, versioning has been a major
> issue with Java, especially among the distributed object folk.
> Specifically, since all classes in Java are referenced by class
> name... Let's take:
>
> House.class in package imaginary.mud
>
> If I compile Player.class in the same package, it will know certain
> things about that class, specifically that
> House my_house = h;
>
> my_house.enterHouse(this);
>
> is valid. At runtime, if Player.class is out of synch with the
> House.class already loaded, I get a VerifyError. This gets worse when
> you try to resolve things like:
> * Class methods
> * Calling my_house.enterHouse(this) with no enterHouse() method.
>
> and so on.
>
> LPC handles this stuff, and it does it in a nice fashion. The cost,
> of course, is strict typing.

Not necessarily. Interfaces were actually originally introduced to
deal with problems like these and not the "Lets save ourselves some
work and avoid dealing with multiple inheritance" motivation that
seems to be the reason they are in Java.

As long as the interface remains unchanged and the new object conforms,
it seems the problems are greatly reduced, which would explain why this
tends to work in practice.

I would expect versioning problems still exist in general especially
with respect to pathological cases, but I haven't thought about it
that long. I do remember thinking about similar issues quite a bit
a couple years ago while involved in a discussion or two about what
it would take to make LPC strongly typed.

What one essentially ends up with is that there is an intermediate
level between completely static and completely dynamic where the
implementation can change, but if you need to change the interface
you're out of luck. Things like CORBA end up being approximately
this level. IMO the gains aren't that big over a fully dynamic
language.

[Abigail]

On 9 Dec 1996 16:49:26 GMT, George Reese wrote in rec.games.mud.admin,rec.games.mud,rec.games.mud.diku,rec.games.mud.lp,rec.games.mud.misc,rec.games.mud.tiny:
++ Anthony C. (acc...@tam2000.tamu.edu) wrote:
++ : In article <58hdnr$s...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
++ : >Anthony C. (acc...@tam2000.tamu.edu) wrote:
++ : :: Java does support dynamic class updating.
++ : :
++ : :Please explain how it allows this? If I have
++ : :imaginary.mudlib.obj.house loaded, modify it, and then want it in my
++ : :currently running mud, how do I do that?
++ : :
++ : :The answer is: you can't.
++ :
++ : Well the way I do it is to load all my classes with a custom
++ : java.lang.ClassLoader as opposed to the standard ClassLoader.
++ : When I want to load a new version I just read the bytes of the class
++ : file either from the network or from a file, replace the old class
++ : with the new class and it's done. All instances of the old version
++ : that existed still use the old version all further instances created
++ : with newInstance() will use the new version. Obviously you have to
++ : be careful about conflicts by going thru the whole system and
++ : unloading and then reloading all objects with the old definition.
++ : However even if you dont do this you dont have any problems.
++ : At some level you will have to define an interface though and
++ : the interface is not loadable, this is due to the fact that
++ : you dynamically invoke method names. However in JDK 1.1 (beta
++ : released today ) you will have total flexibility as you can dynamically
++ : find out method names then invoke them. If you want a full working
++ : example of dynamic class loading take a look at the VPRO web server at
++ : http://james.vpro.nl:7007. It dynamically loads and unloads classes.
++
++ You are saying you can have two different versions of the same class
++ loaded in the same virtual machine at the same time? If so, I have
++ certainly learned something new today :)

Hmm, George, have you read the FAQ lately? Surely, Java discussions
don't belong to rec.games.mud.lp?

Abigail -- Followups set.

[Anthony C.]

In article <58i34g$f...@darla.visi.com>, George Reese <bo...@visi.com> wrote:
:Java is a good language for writing *a certain kind of mud*. So,

:given this experience and your lack of direct experience with it, I
:think I would hold belief until I see it :)

Ok, well I have some sample code on my machine at home I will send it
to you.

:The reason is that this is a fundamental violation of the principles

:behind the Java virtual machine. In fact, versioning has been a major
:issue with Java, especially among the distributed object folk.
:Specifically, since all classes in Java are referenced by class
:name... Let's take:
:
:House.class in package imaginary.mud
:
:If I compile Player.class in the same package, it will know certain
:things about that class, specifically that
:House my_house = h;

:my_house.enterHouse(this);
:is valid. At runtime, if Player.class is out of synch with the
:House.class already loaded, I get a VerifyError. This gets worse when
:you try to resolve things like:
:* Class methods
:* Calling my_house.enterHouse(this) with no enterHouse() method.

These things are absolutely true, that is why you have to define an
interface or an abstract class which CANNOT change (that is what I said
in my previous post.). So you can make all the general things part of
a building interface, and then make house implement that interface,
or inherit the abstract method. Then the house would be reloadable
because everything refers to instances as buildings.

Building myHouse= myClassLoader.getClass("House").newInstance();

so you could do myHouse.enter() because its part of the interface for
Building. The new version of java will give you method tables
so you may not need the interface specification. But I doubt it.

:LPC handles this stuff, and it does it in a nice fashion. The cost,

:of course, is strict typing.

Yeah strict typing in Java too.

I thought I would keep this in all the groups that are listed because
Java can be used to write any of the above mentioned muds. Sorry if you
dont feel if that is a good enough reason.

[George Reese]

I understand the use of interfaces, but I still feel that this approach
is extremely limiting and requires a lot of mental contortions on the
part of novice developers. For example, your interface can never
change, since ostensibly something somethere refers to your class
through that reference.

[Henrik Kniberg]

OK, this is my last crosspost. Let's keep this discussion in
rec.games.mud.misc from now on.

I'm trying to start a discussion relating to mud in general, ie what
makes a mud fun, what ruins a mud, etc. This should also apply to
strict diku players and strict lp players (etc) so, if you are
interested, join the discussion in r.g.m.misc.

:o)

[AxL]

t...@wfn-shop.princeton.edu writes:
>> Henrik Kniberg <d93...@nada.kth.se> wrote:
>> >(sorry about the crosspost, but this involves more than just one
>> >newsgroup...)
>
>Actually, if your post involves all MUDs, it belongs in r.g.m.misc *only*,
>and NOT crossposted to all the groups. This post certainly doesn't involve
>anything specific to the diku and lp groups.
>

Uh, no. A misc newsgroup is for topics about a general subject
(muds) that don't fall under a specific topic (diku, tiny, lp, , etc...)
It could apply to 'all' muds, hence the cross-posting to 'all' mud
newsgroups.

>Don't argue that people who want to read your post might not see it. If
>people read r.g.m.lp and *not* r.g.m.misc, it is for a REASON, and you
>should respect that.
>

Thanks for the kind words, Mr. Netcop...we'll be sure to file
them in the appropriate place.
--
From the often twisted & deviant mind of: j_he...@oz.plymouth.edu
-AxL @)-->--- http://mindwarp.plymouth.edu/~axl axl@mindwarp
"In Christianity neither morality nor jay@{wiz,alcuin}
religion come into contact with reality at any point." - Nietzsche

[AxL]

abi...@ny.fnx.com writes:

>George Reese wrote:
>++ You are saying you can have two different versions of the same class
>++ loaded in the same virtual machine at the same time? If so, I have
>++ certainly learned something new today :)
>
>Hmm, George, have you read the FAQ lately? Surely, Java discussions
>don't belong to rec.games.mud.lp?
>

Yes, it may be diverging a bit, but on the whole this is
still relating to the discussion of a mud in a java environment, which
I would tend to say IS on-topic.
Christ, some people are getting just a tad bit too anal about
this 'on-topic' issue. Lighten up a bit.

>
>Abigail -- Followups set.
>

And, appropriately, unset.

[Abigail]

On 11 Dec 1996 22:48:50 GMT, AxL wrote in rec.games.mud.admin,rec.games.mud,rec.games.mud.diku,rec.games.mud.lp,rec.games.mud.misc,rec.games.mud.tiny:
++ abi...@ny.fnx.com writes:
++ >George Reese wrote:
++ >++ You are saying you can have two different versions of the same class
++ >++ loaded in the same virtual machine at the same time? If so, I have
++ >++ certainly learned something new today :)
++ >
++ >Hmm, George, have you read the FAQ lately? Surely, Java discussions
++ >don't belong to rec.games.mud.lp?
++ >
++ Yes, it may be diverging a bit, but on the whole this is
++ still relating to the discussion of a mud in a java environment, which
++ I would tend to say IS on-topic.

Well, if talk about 3K is off-topic for rec.games.mud.lp, I would say
discussing the internals of Java is certainly off-topic.

++ Christ, some people are getting just a tad bit too anal about
++ this 'on-topic' issue. Lighten up a bit.
++
++ >

I would have shut my mouth if it wasn't for
someone who likes to wave with faqs.

Abigail

[Jukka V Heinonen]

George Reese wrote:
> Please explain how it allows this? If I have

> imaginary.mudlib.obj.house loaded, modify it, and then want it in my

> currently running mud, how do I do that?
>

> The answer is: you can't.

Well, if we have an interface like:
interface X {
int getY();
void do_something(String);
...
}

And a class:
class X_1 implements X {...}

We create new mud classes with CLASS.create("X") which now creates
a new object of type X_1 and returns an object of type (interface X).

Then we want to change the X code to
class X_2 implements X {...}

After compilation we do CLASS.setImplementation("X", X_2)
and after this CLASS.create("X") creates new classes of class X_2...
(And we also get a simple version handling by the way...)

Bad things in this arhitecture:

* Makes inheritance a bit more complicated...

Well, I think the inheritance problem can be solved using
some preprocessing of the class sources... Anyway, as there are so
many ways of doing the inheritance I guess I just don't give any
of my ideas and I let the readers develop their own ones :)
(Some of my wilder ideas allow us to inherit variables from multiple
classes!)

* Existing objects still have their old code.

Well, this is true even in LPC and so I guess it's not important...

* Cannot change interface X without shutting the mud down, recompiling
the interfaces and then restarting.

I guess this might cause some difficulties...

But anyway, if we delete methods that some code is using
we just end up in difficulties... And I think deleting methods
isn't really interesting here; deletions could be delayed into the
far future without too much trouble...

Adding methods to the interfaces is a much more interesting question.
If the mud is rebooted at a regular basis (like once a day...) I guess
this would only be an annoying feature.
And if you're a good programmer I think you don't need to change the
interfaces very often. Since I don't have any experience about
coding in a mud environment I would like to get some comments about
this from those who have.

(Advertising: I put some times ago my ideas about creating a graphical
mud behind link: http://www.helsinki.fi/~jvheinon/gmud/)

- Jukka (\V/) Heinonen

[George Reese]

Jukka V Heinonen (Jukka.V....@Helsinki.FI) wrote:
: Bad things in this arhitecture:

:
: * Makes inheritance a bit more complicated...
:
: Well, I think the inheritance problem can be solved using
: some preprocessing of the class sources... Anyway, as there are so
: many ways of doing the inheritance I guess I just don't give any
: of my ideas and I let the readers develop their own ones :)
: (Some of my wilder ideas allow us to inherit variables from multiple
: classes!)
:
: * Existing objects still have their old code.
:
: Well, this is true even in LPC and so I guess it's not important...
:
: * Cannot change interface X without shutting the mud down, recompiling
: the interfaces and then restarting.
:
: I guess this might cause some difficulties...
:
: But anyway, if we delete methods that some code is using
: we just end up in difficulties... And I think deleting methods
: isn't really interesting here; deletions could be delayed into the
: far future without too much trouble...

I think the first and last objections are very important.

: Adding methods to the interfaces is a much more interesting question.

: If the mud is rebooted at a regular basis (like once a day...) I guess
: this would only be an annoying feature.
: And if you're a good programmer I think you don't need to change the
: interfaces very often. Since I don't have any experience about
: coding in a mud environment I would like to get some comments about
: this from those who have.

I agree with this last point. That is why I am doing a mud in Java.
My comments were addressing specific requirements enumerated by the
initial poster which indicated a need for heavy object versioning. I
think LPC is simply better if that is a primary major requirement.

[Bjorn Wesen]

There has been a major argument here about what supposedly "Java can/can't
do". Since I've written a complete java virtual machine for use on a mud,
from scratch, I think I can clarify some things.

First, Java itself as a language has nothing to do with your argument. Java
as a language is nice and clean, and I can't see any reasons not to use it
to code parts of a mudserver (been there done that). What you are debating
is what a VM allows you to do or not.

Second, in my JavaVM, you can reload classes dynamically as the mud is
running. There is absolutely no real obstacle to doing this. You have to
think about stuff like to rebind all dependant classes's optimized calls,
copy over values of static class member variables or reinitialize them,
etc. The java bytecode is designed with this in mind, since it features
late binding of everything.

I don't know where you got the perceived problems from, George. Computers
are our slaves, we can make them do what we want. Almost any problem is
solveable. I wouldn't go out shouting "it's impossible!" about anything.

Dissecture of Georges post:

George Reese <bo...@visi.com> wrote

> In all the work I have done and all the resources I have consulted,
> this has been shown to me to be impossible. And I do believe that

> Java is a good language for writing *a certain kind of mud*. So,
> given this experience and your lack of direct experience with it, I
> think I would hold belief until I see it :)

It's probably impossible in some of the most common VM's out there, yes.

> The reason is that this is a fundamental violation of the principles
> behind the Java virtual machine. In fact, versioning has been a major
> issue with Java, especially among the distributed object folk.

Oh, so I've gone and coded something that was "impossible" to code? Shit..
maybe I shouldn't tell anyone. What fundamental principles does dynamic
class loading in Java violate?

> Specifically, since all classes in Java are referenced by class
> name... Let's take:
>
> House.class in package imaginary.mud
>
> If I compile Player.class in the same package, it will know certain
> things about that class, specifically that
> House my_house = h;
>
> my_house.enterHouse(this);
>
> is valid. At runtime, if Player.class is out of synch with the
> House.class already loaded, I get a VerifyError. This gets worse when
> you try to resolve things like:
> * Class methods
> * Calling my_house.enterHouse(this) with no enterHouse() method.
>

> and so on.

If the VM is badly constructed, sure, it can take the easy way out and just
throw up on you if you load a class in the middle of everything. But this
has nothing to do with Java.

And if you reload a class after you have REMOVED methods from the class, of
course you'll get an error.

There is an implementation where this isn't the case, and that is when you
keep the old code. All new instances refer to the newly loaded version,
while all old instances will refer to the old code. However, this isn't
what you want in most cases in a mud at least.

> LPC handles this stuff, and it does it in a nice fashion. The cost,
> of course, is strict typing.

And Java handles it as well, in the same sense as "LPC" does. In fact, I
don't see why you're bringing LPC up all the time. If you're an LPC expert,
and not a java expert, don't try to argue about Java implementation
details.

> George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
> i think i've reached that point/where every wish has come true/
> and tired disguised oblivion/is everything i do
> -the cure

-----------------
Bjorn Wesen

[George Reese]

Bjorn Wesen wrote:
>
> There has been a major argument here about what supposedly "Java can/can't
> do". Since I've written a complete java virtual machine for use on a mud,
> from scratch, I think I can clarify some things.

This is not particularly useful with respect to the Java language.

> First, Java itself as a language has nothing to do with your argument. Java
> as a language is nice and clean, and I can't see any reasons not to use it
> to code parts of a mudserver (been there done that). What you are debating
> is what a VM allows you to do or not.
>
> Second, in my JavaVM, you can reload classes dynamically as the mud is
> running. There is absolutely no real obstacle to doing this. You have to
> think about stuff like to rebind all dependant classes's optimized calls,
> copy over values of static class member variables or reinitialize them,
> etc. The java bytecode is designed with this in mind, since it features
> late binding of everything.
>
> I don't know where you got the perceived problems from, George. Computers
> are our slaves, we can make them do what we want. Almost any problem is
> solveable. I wouldn't go out shouting "it's impossible!" about anything.

Perhaps impossible is wrong... Insane would be a better word :)

> Dissecture of Georges post:
>
> George Reese <bo...@visi.com> wrote
> > In all the work I have done and all the resources I have consulted,
> > this has been shown to me to be impossible. And I do believe that
> > Java is a good language for writing *a certain kind of mud*. So,
> > given this experience and your lack of direct experience with it, I
> > think I would hold belief until I see it :)
>
> It's probably impossible in some of the most common VM's out there, yes.

Writing a new VM defeats the entire purpose of using Java. In order to
use Java in a way that takes advantage of Java, you need above all else
to take a zero-install philosophy. You are already requiring people to
install YOUR VM.

> > The reason is that this is a fundamental violation of the principles
> > behind the Java virtual machine. In fact, versioning has been a major
> > issue with Java, especially among the distributed object folk.
>
> Oh, so I've gone and coded something that was "impossible" to code? Shit..
> maybe I shouldn't tell anyone. What fundamental principles does dynamic
> class loading in Java violate?

You cheated is what you did.
That misses the point.

> > Specifically, since all classes in Java are referenced by class
> > name... Let's take:
> >
> > House.class in package imaginary.mud
> >
> > If I compile Player.class in the same package, it will know certain
> > things about that class, specifically that
> > House my_house = h;
> >
> > my_house.enterHouse(this);
> >
> > is valid. At runtime, if Player.class is out of synch with the
> > House.class already loaded, I get a VerifyError. This gets worse when
> > you try to resolve things like:
> > * Class methods
> > * Calling my_house.enterHouse(this) with no enterHouse() method.
> >
> > and so on.
>
> If the VM is badly constructed, sure, it can take the easy way out and just
> throw up on you if you load a class in the middle of everything. But this
> has nothing to do with Java.
>
> And if you reload a class after you have REMOVED methods from the class, of
> course you'll get an error.

That is a huge part of my point!!!

> There is an implementation where this isn't the case, and that is when you
> keep the old code. All new instances refer to the newly loaded version,
> while all old instances will refer to the old code. However, this isn't
> what you want in most cases in a mud at least.

Not really. This is done all the time on LPMuds.

> > LPC handles this stuff, and it does it in a nice fashion. The cost,
> > of course, is strict typing.
>
> And Java handles it as well, in the same sense as "LPC" does. In fact, I
> don't see why you're bringing LPC up all the time. If you're an LPC expert,
> and not a java expert, don't try to argue about Java implementation
> details.

I am and LPC expert AND a Java expert. I do not think Java is a good
language where this is a heavy requirement, and your post has underlined
that fact heavily. Writing your own VM is NEVER a proper Java solution.
Otherwise, you are just writing Java to use the Java language, and Java
as a language is wholly unintersting.

--

[David Bennett (pinkfish)]

Jukka V Heinonen (Jukka.V....@Helsinki.FI) wrote:

: George Reese wrote:
: > Please explain how it allows this? If I have
: > imaginary.mudlib.obj.house loaded, modify it, and then want it in my
: > currently running mud, how do I do that?
: >
: > The answer is: you can't.
:
: Well, if we have an interface like:
: interface X {
: int getY();
: void do_something(String);
: ...
: }
:
: And a class:
: class X_1 implements X {...}
:
: We create new mud classes with CLASS.create("X") which now creates
: a new object of type X_1 and returns an object of type (interface X).
:
: Then we want to change the X code to
: class X_2 implements X {...}
:
: After compilation we do CLASS.setImplementation("X", X_2)

: and after this CLASS.create("X") creates new classes of class X_2...

: (And we also get a simple version handling by the way...)

Ugh. Call inthe hack police.

This would make coding in it the system quite horrifying, also
quite eay to stuff up. Especialy if you start fiddling
with macros to get it to do what you wish.

Java is not really designed to hanlde this sort of
application. It is more deigned to handle
static things. Where you download the code once and run it
forever.

It seems rather silly to try and force Java to do something which ist is not designed for
and not good at if there is another language floating that is.

Wombles in space,
David.
[DDT] Pink fish forever.

[Britton]

oemlen (oem...@ezinfo.ucs.indiana.edu) wrote:

: In article <32AB34...@nada.kth.se>,
: >Hi fellow gamers!
: >I'm currently developing a graphical MUD in Java, and would like some
: >comments, tips, ideas, warnings, complaints, whatever from the MUD
: >community :o)
: >The graphics is view-from-top icon based (like the Ultima games).
: >Nothing really fancy, and that's the point - this is no VR MUD. I want
: >without dazzling graphics.

: This project is already underway, but is being implimented in a
: pre-existing, tested mud. It works outstandingly well, and overhead
: mapping is flawless, as well as are room view of mobs/object and
: inventory. I am just finishing up graphics before it will be released.
: Owen Emlen

If Owen says it can be done, it can be done. If he is doing it in Java,
then Java is the way to do it. If you can get in working with him
somehow instead of starting from scratch yourself do it. He is good.

--
I like six eggs when starting on a journey. Fried - not poached. And
mind you don't break 'em. I won't eat a broken egg.
-- Thorin Oakenshield

[Theodore Milker]

Britton (fs...@aurora.alaska.edu) wrote:
: If Owen says it can be done, it can be done. If he is doing it in Java,

: then Java is the way to do it. If you can get in working with him
: somehow instead of starting from scratch yourself do it. He is good.

If Owen says to jump off a bridge, jump. If Microsoft says to buy
Windows 95, buy it. If you want to write your own programs, don't, try to
get in with Microsoft.

Sheesh, not everyone in this world is a lemming like you seem to imply you
are.
--
Dodger -- tmi...@cse.unl.edu
"Millions long for immortality who do not know what to do with themselves
on a rainy Sunday afternoon." -- Susan Ertz

[Anthony C.]

In article <58q6g4$5...@darla.visi.com>,
David Bennett (pinkfish) <d...@visi.com> wrote:
:It seems rather silly to try and force Java to do something which ist is not designed for

:and not good at if there is another language floating that is.
:Wombles in space,
:David.

People arent listening to me so this is the last post where I say
that you CAN load and reload classes in Java with a ClassLoader.
Old classes use the old implementation new classes use the new one.
All that is required is that you have an interface or an abstract class
that defines the behavior for the loadable class. This interface
cannot change as you have to staticly type the loadable classes
during compile to this interface or abstract class. I also have said
that this is NOT documented as allowable and may or may not work in VMs
outside of SUNs VM.

[George Reese]

Anthony C. (acc...@tam2000.tamu.edu) wrote:
: In article <58q6g4$5...@darla.visi.com>,

Which only serves to illustrate Pinkfish's point.

First, this means you have a mudlib of interfaces only and little or
no implementations (recipe for poor code reuse).

Second, it means you have to worry about which VM you use, which means
NON-PORTABLE, and thus not particularly Java.

[Bjorn Wesen]

George Reese <bo...@imaginary.com> wrote in <32B09A...@imaginary.com>...

> Writing a new VM defeats the entire purpose of using Java. In order to
> use Java in a way that takes advantage of Java, you need above all else
> to take a zero-install philosophy. You are already requiring people to
> install YOUR VM.

HUH? The JavaVM is part of the mud-base distribution, in exactly the same
sense as the LPC drivers are part of the LPMud distributions. It's totally
analogous. I'm 100% sure noone with brains would try writing a WHOLE
mudserver in java and run it on SUN's worthless JavaVM implementation. That
has never been my goal, I'm sorry if you thought that.

I think you are confusing what YOU think java is, with what OTHERS think
java is useful for. For you, java as a language is crap (and LPC is god).
For others, Java as a language is very nice. You have your notion of "the
entire purpose of java" while there are 5 billion other people in the world
with other notions.

> > > The reason is that this is a fundamental violation of the principles
> > > behind the Java virtual machine. In fact, versioning has been a major
> > > issue with Java, especially among the distributed object folk.
> >
> > Oh, so I've gone and coded something that was "impossible" to code?
Shit..
> > maybe I shouldn't tell anyone. What fundamental principles does dynamic
> > class loading in Java violate?
>
> You cheated is what you did.
> That misses the point.

I suggest you answer what these "fundamental violations of the principles
behind java" are that disallows the use of java in a mud, instead of waving
away the question.

> > And if you reload a class after you have REMOVED methods from the
class, of
> > course you'll get an error.
>
> That is a huge part of my point!!!

I'm interested in what this point is - there IS no magical way of resolving
this. Either you use the old code for existing instances and their
dependencies, or you overload the old code as well. Both ways are easy to
implement. In some cases the former method is wanted, in some cases the
latter is wanted. It's easy to let both forms coexist and the god who
reloads the class can choose.

> I am and LPC expert AND a Java expert. I do not think Java is a good
> language where this is a heavy requirement, and your post has underlined
> that fact heavily. Writing your own VM is NEVER a proper Java solution.
> Otherwise, you are just writing Java to use the Java language, and Java
> as a language is wholly unintersting.

Huh? Java is a _language_. I can write whatever VM I want, whatever Java
compilator I want, whatever class-library I want, and it's still Java as a
language - and Java as a language is very interesting. Why do you think
many companies and people are interested in Java->machine code compilers?
Because Java is an in many ways nicer language than C++, therefore, it's
still interesting even if you remove the platform independencies, change
the runtime premises, and change the runtime libraries.

You're not an expert in either LPC or Java if you can't think objectively
and see what others might want to use either language for.

So, what I (and others) have made, is a complete mud-driver, with a class
library interface to let people add classes and extend the drivers
fundamental c++ classes through Java. Classes can be dynamically loaded.
The driver runs on all UN*Xes we can get our hands on, as well as win32.
Java is a language perfectly suited for extending a mud in a way that not
very brilliant programmers can understand. All this, including the source
for the mud-driver, and the optimized multithreaded JavaVM, will be
released for free. All of it works beautifully. Now, tell me, where is the
great mistake I've done?

Or maybe it's like this: that you didn't expect to find anyone who actually
knows what they are talking about to argue with you in r.g.m.* groups.

> George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg

Bjorn

ps I do understand your point - that given the common VM implementations
(Sun's etc) you run into problems. But in my case, it isn't a goal to run a
mudserver on any of these implementations since they are far too inferior.
My goal is to take advantage of Java as a language, and take advantage of
existing Java compilers. What I do with the bytecode from the compiler, is
different from Sun's VM, but that doesn't change the way the Java
programmer has to think at all.

[George Reese]

Bjorn Wesen (exo...@sparta.lu.se) wrote:
: George Reese <bo...@imaginary.com> wrote in <32B09A...@imaginary.com>...

: > Writing a new VM defeats the entire purpose of using Java. In order to
: > use Java in a way that takes advantage of Java, you need above all else
: > to take a zero-install philosophy. You are already requiring people to
: > install YOUR VM.
:
: HUH? The JavaVM is part of the mud-base distribution, in exactly the same
: sense as the LPC drivers are part of the LPMud distributions. It's totally
: analogous. I'm 100% sure noone with brains would try writing a WHOLE
: mudserver in java and run it on SUN's worthless JavaVM implementation. That
: has never been my goal, I'm sorry if you thought that.

Yep, it is totally analogous. That asks the question, why Java
instead of LPC?

The point is not that I expect them to run it on Sun's
implementation. The point is that I do not want to worry about what
VM they are running on at all.

: I think you are confusing what YOU think java is, with what OTHERS think

: java is useful for. For you, java as a language is crap (and LPC is god).
: For others, Java as a language is very nice. You have your notion of "the
: entire purpose of java" while there are 5 billion other people in the world
: with other notions.

Well, I would venture 99% of the 5 billion people in the world give a
fuck about Java. Of those that do care, many of them are chanting the
mantra 'Write once, compile once, run anywhere'.

Your vision violates tha principle. The question then becomes, what
exactly do you think you are getting from Java?

And, by the way, I challenge you to point out any place that I have
suggested LPC is god. I am, after all, building a mud in Java. I
just happen to have the belief that Java is good at some things, and
LPC is good at others. The issue in question is one of LPC's
strengths and one of Java's weaknesses.

: > > > The reason is that this is a fundamental violation of the principles

: > > > behind the Java virtual machine. In fact, versioning has been a major
: > > > issue with Java, especially among the distributed object folk.
: > >
: > > Oh, so I've gone and coded something that was "impossible" to code?
: Shit..
: > > maybe I shouldn't tell anyone. What fundamental principles does dynamic
: > > class loading in Java violate?
: >
: > You cheated is what you did.
: > That misses the point.
:
: I suggest you answer what these "fundamental violations of the principles
: behind java" are that disallows the use of java in a mud, instead of waving
: away the question.

Write once, compile once, run anywhere? Heard that before? If you
went to JavaOne and have been in contact with people at Javasoft like
I have, you might know that is the most sacred fundamental principle
of Java.

: > > And if you reload a class after you have REMOVED methods from the

: class, of
: > > course you'll get an error.
: >
: > That is a huge part of my point!!!
:
: I'm interested in what this point is - there IS no magical way of resolving
: this. Either you use the old code for existing instances and their
: dependencies, or you overload the old code as well. Both ways are easy to
: implement. In some cases the former method is wanted, in some cases the
: latter is wanted. It's easy to let both forms coexist and the god who
: reloads the class can choose.

It is not easy to do. It requires sme nast contortions in your class
library as well as a bit of learning on the part of wizards.

: > I am and LPC expert AND a Java expert. I do not think Java is a good

: > language where this is a heavy requirement, and your post has underlined
: > that fact heavily. Writing your own VM is NEVER a proper Java solution.
: > Otherwise, you are just writing Java to use the Java language, and Java
: > as a language is wholly unintersting.
:
: Huh? Java is a _language_. I can write whatever VM I want, whatever Java
: compilator I want, whatever class-library I want, and it's still Java as a
: language - and Java as a language is very interesting. Why do you think
: many companies and people are interested in Java->machine code
: compilers?

In some cases, because they are clueless. In others because they wish
to leverage their Java knowledge across the enterprise. That has
nothing to do with what the true benefit of Java is.

: Because Java is an in many ways nicer language than C++, therefore, it's

: still interesting even if you remove the platform independencies, change
: the runtime premises, and change the runtime libraries.

Use Delphi.

: You're not an expert in either LPC or Java if you can't think objectively

: and see what others might want to use either language for.

Straight out of left field that. I am suggesting simply that the
feature in question is a weakness in Java and a strength of LPC.
Given said feature as a major requirement, one would think the
language stronger suited for it would be the language of choice.

: So, what I (and others) have made, is a complete mud-driver, with a class

: library interface to let people add classes and extend the drivers
: fundamental c++ classes through Java. Classes can be dynamically loaded.
: The driver runs on all UN*Xes we can get our hands on, as well as win32.
: Java is a language perfectly suited for extending a mud in a way that not
: very brilliant programmers can understand. All this, including the source
: for the mud-driver, and the optimized multithreaded JavaVM, will be
: released for free. All of it works beautifully. Now, tell me, where is the
: great mistake I've done?

Did I say you made a 'great mistake'? I simply said you missed the
point. You used Java in a manner which ignores its primary feature
while ignoring a language which does what you already set out to do.

: Or maybe it's like this: that you didn't expect to find anyone who actually

: knows what they are talking about to argue with you in r.g.m.* groups.

There are plenty of very, very smart people in this newsgroup who can
argue intelligently with me.

: > George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg

:
: Bjorn
:
: ps I do understand your point - that given the common VM implementations
: (Sun's etc) you run into problems. But in my case, it isn't a goal to run a
: mudserver on any of these implementations since they are far too inferior.
: My goal is to take advantage of Java as a language, and take advantage of
: existing Java compilers. What I do with the bytecode from the compiler, is
: different from Sun's VM, but that doesn't change the way the Java
: programmer has to think at all.

So if you understand my point, explain comments like:

"I'm 100% sure noone with brains would try writing a WHOLE
mudserver in java and run it on SUN's worthless JavaVM implementation. That
has never been my goal, I'm sorry if you thought that."

"I suggest you answer what these "fundamental violations of the principles

behind java" are that disallows the use of java in a mud, instead of waving
away the question."

"I think you are confusing what YOU think java is, with what OTHERS think

java is useful for. For you, java as a language is crap (and LPC is god)."

Kinda abusive, don't you think?

I would really like to know what you think Java as a language has to
offer that is new to the world. Even Sun itself does not promote Java
being useful as a language. And basic technology decisions on the
performance and behaviour of a single, initial instance of that
technology is generally short-sighted.

--

George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg

[George Reese]

Bjorn Wesen wrote:
> =

> George Reese <bo...@visi.com> skrev i inl=E4gg <58sebv$q...@darla.visi.co=
m>...

> > I would really like to know what you think Java as a language has to

> > offer that is new to the world. Even Sun itself does not promote Jav=

a
> > being useful as a language. And basic technology decisions on the
> > performance and behaviour of a single, initial instance of that
> > technology is generally short-sighted.

> =

> Java as a choice for mud language is good because 1) its object oriente=
d,
> 2) its garbage collected, 3) lacks explicit pointers and pointer
> arithmetics, 4) has easier syntax than C++, 5) compilers exist that com=
pile
> to a bytecode, which is perfect for a mud language, 6) is in hype, whic=
h
> means that a lot of people have learned the basics of it, 7) has a
> standardized classfile system which allows reuse of precompiled code
> between muds (even if I wouldn't really push for that).

LPC supports all except 6.

And while I do happen to think 6 is important, again I have to emphasize
given the requirement list we were discussing before, Java is not the
right language because it is weak in an area that was listed as a
primary requirement.

> Given the choice of creating a new language for a mud, and reusing an
> existing one, I choose Java because the language I would have created w=
ould
> have been very similar.
>
> Point 6 above is actually more important than you might think. If a per=
son
> wants to set up a mud, chances are much higher that she/he knows Java t=
han
> that she/he knows LPC, right? (Ok, chances are high the programmer know=
s C
> as well, which LPC is based on, but maybe not the semantics of classes
> there etc). So, the implementor and gods get a language they already ar=
e
> familiar with to write extensions in, and everybody are happy.

Well, I think this point is a bit overemphasized. Chances are your area
builder does not know what a programming language is. Java hype won't
help there one bit.
=

> I have never believed in Java as-is as a universal solution to platform=

> independentness. It's too slow, and as you say, it's a first initial
> instance of such a technology. But because of point 5 above and the nee=
d
> for an interpreted language, it's useful anyway.

Well, I believe in it that way for the long term. For the short term, I
think it makes a good platform independent technology.

> There is an additional benefit - if the mud ever gets a graphical
> interface, you can implement the Java AWT class library in a client-ser=
ver
> fashion, bound to players on the mud, in a similar way as X works. So, =
the
> programmer gets a well-known language and a well-known graphical interf=
ace,
> which channels the AWT calls to the player the code is currently handli=
ng.
> Viola, graphical muds without changing the mud-server core!

Java client + LPC server is trivial.
=

> Our model is this: a _fast_ C++ core game process, communicating with a=

> _fast_ C++ netserver process and a nameserver process. The game process=

> contains a multithreaded Java VM with a scheduler. This means it's poss=
ible
> to write code that sleeps, waits for happenings, spawns other threads, =
etc,
> in a totally safe fashion. The C++ core uses a C++ garbage collector,
> avoiding memory leaks. The core's basic classes are available in Java a=
s
> well through a C++->Java interface I've written. You can extend C++ cla=
sses
> in java, and pass BACK an instance of an extended class into C++, makin=
g it
> behave like it should.
> =

> The reason the C++ core handles game things is for speed. Interpreted o=
r
> even JIT'ed java is simply too slow to do everything in a large mud.
> Containment and basic movement is in C++, while combat systems, magic a=
nd
> skills are written in Java. However due to the C++-Java interface, you =
can
> stretch the border back and forth, so if someone really wants to pay th=
e
> performance penalty, he can write the entire mud in Java.
> =

> Bjorn

-- =

[Bjorn Wesen]

George Reese <bo...@visi.com> skrev i inlägg <58sebv$q...@darla.visi.com>...

> I would really like to know what you think Java as a language has to
> offer that is new to the world. Even Sun itself does not promote Java
> being useful as a language. And basic technology decisions on the
> performance and behaviour of a single, initial instance of that
> technology is generally short-sighted.

Java as a choice for mud language is good because 1) its object oriented,

2) its garbage collected, 3) lacks explicit pointers and pointer

arithmetics, 4) has easier syntax than C++, 5) compilers exist that compile
to a bytecode, which is perfect for a mud language, 6) is in hype, which

means that a lot of people have learned the basics of it, 7) has a
standardized classfile system which allows reuse of precompiled code
between muds (even if I wouldn't really push for that).

Given the choice of creating a new language for a mud, and reusing an
existing one, I choose Java because the language I would have created would
have been very similar.

Point 6 above is actually more important than you might think. If a person
wants to set up a mud, chances are much higher that she/he knows Java than
that she/he knows LPC, right? (Ok, chances are high the programmer knows C

as well, which LPC is based on, but maybe not the semantics of classes

there etc). So, the implementor and gods get a language they already are

familiar with to write extensions in, and everybody are happy.

I have never believed in Java as-is as a universal solution to platform

independentness. It's too slow, and as you say, it's a first initial

instance of such a technology. But because of point 5 above and the need

for an interpreted language, it's useful anyway.

There is an additional benefit - if the mud ever gets a graphical
interface, you can implement the Java AWT class library in a client-server
fashion, bound to players on the mud, in a similar way as X works. So, the
programmer gets a well-known language and a well-known graphical interface,
which channels the AWT calls to the player the code is currently handling.

Viola, graphical muds without changing the mud-server core!

Our model is this: a _fast_ C++ core game process, communicating with a

_fast_ C++ netserver process and a nameserver process. The game process

contains a multithreaded Java VM with a scheduler. This means it's possible
to write code that sleeps, waits for happenings, spawns other threads, etc,

in a totally safe fashion. The C++ core uses a C++ garbage collector,

avoiding memory leaks. The core's basic classes are available in Java as
well through a C++->Java interface I've written. You can extend C++ classes
in java, and pass BACK an instance of an extended class into C++, making it
behave like it should.

The reason the C++ core handles game things is for speed. Interpreted or

even JIT'ed java is simply too slow to do everything in a large mud.

Containment and basic movement is in C++, while combat systems, magic and
skills are written in Java. However due to the C++-Java interface, you can
stretch the border back and forth, so if someone really wants to pay the

performance penalty, he can write the entire mud in Java.

Bjorn

[David Bennett (pinkfish)]

Bjorn Wesen (exo...@sparta.lu.se) wrote:

[Your point about it being popular therefor good]

One word for you: Microsoft.

Aparyt from that. Most OO people will agree t hat Eifel is a far
better interpreted language (in fact a far better oo language)

hy is it not used? Becaise it is not free. Why is java used?
Because it is free. This does not nessessarily equate to good.

Bing well,
David.
[DDT] Growing cabbages in the dark.

[ne...@ogham.demon.co.uk]

"Bjorn Wesen" <exo...@sparta.lu.se> wrote:
>2) its garbage collected, 3) lacks explicit pointers and pointer
>arithmetics, 4) has easier syntax than C++, 5) compilers exist that compile

Can someone explain to me why some people feel that lack of pointers is a
good thing in a language? IMHO any language without pointers is rather
crippled. If Java is to be taken seriously as an *all* purpose language as some
people would have us believe then its going to have to have some transplanted
into it and fast. Besides which , even if it did have pointers no ones forcing
you to use them, after all you can write a C program without explicitly
using them.

As for garbage collection , big deal. Whose to say the garbage collection
code in the VM isn't broken so it leaks memory anyway? The implementation
of the JavaScript interpeter in netscape 2 certainly had this problem.

NJR

[ne...@ogham.demon.co.uk]

"Bjorn Wesen" <exo...@sparta.lu.se> wrote:
>HUH? The JavaVM is part of the mud-base distribution, in exactly the same
>sense as the LPC drivers are part of the LPMud distributions. It's totally
>analogous. I'm 100% sure noone with brains would try writing a WHOLE
>mudserver in java and run it on SUN's worthless JavaVM implementation. That
>has never been my goal, I'm sorry if you thought that.

'Scuse me for butting in here but you seem to have missed the point of Java,
that being that a java program can be run on any browser or whatever client
on any system just by downloading the bytecode. What exactly is the difference
between different Java programs requiring different VMs and different binary
files requiring different processors? In fact the latter at least has the
advantage of speed so why not just do that instead, compile your program
down to machine code for each individual architecture and get people to downloadthe one appropriate for their machine (since they'll have to download your VM
anyway).

>For others, Java as a language is very nice. You have your notion of "the
>entire purpose of java" while there are 5 billion other people in the world
>with other notions.

Yeah , like your average rice farmer in China for example really thinks "Hmm ,
now how can I extend the Java virtual machine..." while cycling to his paddy
field in the morning :)

>language - and Java as a language is very interesting. Why do you think

No it isn't. Its just another object oriented version of C minus a lot of
functionality.

NJR

-----------------------------------------------------------------------------
Microsoft - When Do You Want To Crash Today?

[Bjorn Wesen]

ne...@ogham.demon.co.uk wrote

> "Bjorn Wesen" <exo...@sparta.lu.se> wrote:
> >2) its garbage collected, 3) lacks explicit pointers and pointer
> >arithmetics, 4) has easier syntax than C++, 5) compilers exist that
compile
>
> Can someone explain to me why some people feel that lack of pointers is a
> good thing in a language? IMHO any language without pointers is rather
> crippled. If Java is to be taken seriously as an *all* purpose language
as some
> people would have us believe then its going to have to have some
transplanted
> into it and fast. Besides which , even if it did have pointers no ones
forcing
> you to use them, after all you can write a C program without explicitly
> using them.

You quoted me out of context. On the line above my quote, there was this
nice row:
"Java is good for a mud language because:".
Hence I don't talk about java as an allpurpose language at all. It's not.

In a MUD language, 2 things are important to think about: 1) it NEEDS to be
crashproof and "idiotproof", 2) it should be easy to understand for
beginners.

Allowing pointer arithmetics and casting pointers back and forth is equal
to begging for crashes. Pointer arithmetics is needed for speed in cores
etc, not in a highlevel mud extension language.

Allowing both pointers and object datatypes is begging for confusion among
beginners (when to use . and when to use ->).

Now another misunderstanding/misreading: I wrote that Java lacks explicit
pointers, not that it lacks pointers. In fact, "pointer" is the ONLY
datatype apart from the basics like boolean/integer/long/float. There is no
datatype called 'array' or 'object of type X'.
In java you do:

MyClass c = new MyClass(5,6,7);

Suspiciously similar to pointers in C++ or? Yup, c IS a pointer
technically. But it's called "reference" in Java, and can't be casted
from/to integer types etc so you can't do arithmetics on it (hence no
pointer arithmetics). There is no need for special dereferencing of them
either since there is no datatype of type 'MyClass' in the system. Hence
you reference c like this:

c.MyMethod(99);

with a dot instead of the ->.

> As for garbage collection , big deal. Whose to say the garbage collection
> code in the VM isn't broken so it leaks memory anyway? The implementation
> of the JavaScript interpeter in netscape 2 certainly had this problem.

I suggest trying programming in a GC'ed language. Most programmers who have
programmed large systems in non-GC'ed languages, agrees that the problem of
having to keep track of what code is owner of what objects (and hence
responsible for deleting them) is a huge annoyance factor. Not to mention
leaks.

Waving away GC as "big deal" is probably a famous last word. It really is a
relief to not have to always keep thinking on who's going to delete what,
like in situations where a method has to return a new object, and has to
put the (stupid) demand on the caller that the caller disposes of the
object when it's done.

It wouldn't surprise me at all if Netscapes GC leaks memory. For our VM we
use a C++ GC that has been under development for years and is used in Xerox
products etc.

Bjorn

[George Reese]

ne...@ogham.demon.co.uk wrote:
>
> "Bjorn Wesen" <exo...@sparta.lu.se> wrote:
> >2) its garbage collected, 3) lacks explicit pointers and pointer
> >arithmetics, 4) has easier syntax than C++, 5) compilers exist that compile
>
> Can someone explain to me why some people feel that lack of pointers is a
> good thing in a language? IMHO any language without pointers is rather
> crippled. If Java is to be taken seriously as an *all* purpose language as some
> people would have us believe then its going to have to have some transplanted
> into it and fast. Besides which , even if it did have pointers no ones forcing
> you to use them, after all you can write a C program without explicitly
> using them.

Name one critical thing you can do with pointers that you cannot do in
Java.

Pointers only server to introduce errors conditions into programs.
Furthermore, adding them to Java would bring up a serious security
problem.

--

[Jukka V Heinonen]

>I agree with this last point. That is why I am doing a mud in Java.
>My comments were addressing specific requirements enumerated by the
>initial poster which indicated a need for heavy object versioning. I
>think LPC is simply better if that is a primary major requirement.

If I have understood correctly you are doing a mud that doesn't allow
the class code to be dynamically altered while the mud is running?
If this is the case I would like to know how this could be done without
making the system expansion/debugging difficult?
If this is not the case then could you tell how have you done the
dynamic updating of the code?

Anyway, you can do something like LPC with multiple
versions of a single class running at the same time
in a java-friendly way without any ClassLoader hacks.
The system would only need to change the class names in the .class
file before compiling. It would be easy to hide the exact details from
the users so that it would be no harder than writing a normal java program.
This would be more limited when compared to LPC in that it would
require standard interfaces that cannot be changed while the mud is
running...

The only requirement from the java system is that you can compile class
files with Runtime.exec() and that the class files are stored in
a directory tree.

On the second thought I just don't know whether I would like to do
something like this. Perhaps LPC would be better suited for this
purpose...
One point for java is that it has JIT compilers and I guess
you can even compile single class files into native machine code
(at least in the near future?) which would make the code run faster...
On the other hand I have no idea how fast Java, java compiled into
native mc and LPC run... (Does anybody know this?)

[David Bennett (pinkfish)]

ne...@ogham.demon.co.uk wrote:
:
: "Bjorn Wesen" <exo...@sparta.lu.se> wrote:
: >2) its garbage collected, 3) lacks explicit pointers and pointer
: >arithmetics, 4) has easier syntax than C++, 5) compilers exist that compile
:
: Can someone explain to me why some people feel that lack of pointers is a
: good thing in a language? IMHO any language without pointers is rather
: crippled. If Java is to be taken seriously as an *all* purpose language as some
: people would have us believe then its going to have to have some transplanted
: into it and fast. Besides which , even if it did have pointers no ones forcing
: you to use them, after all you can write a C program without explicitly
: using them.

Pointers are dangerous. They are very uncolled access
to memory and cause lots of problems, not only with
memory leakage but with readability and ease of coding. A ssignificant
number of hard to track bvugs in C are rlated to bad pointer
usuage. With a nice oo language you can use controled memory allocation
instead: ie create a new object.

Not a pointer fan,
David.
[DDT] Staring att the sea, staring at the sand.

[David Bennett (pinkfish)]

Bjorn Wesen (exo...@sparta.lu.se) wrote:
:
: Allowing pointer arithmetics and casting pointers back and forth is equal

: to begging for crashes. Pointer arithmetics is needed for speed in cores
: etc, not in a highlevel mud extension language.

Speed is really not much of an issue these days. After all
people use windows 95, so they obviously don't care
about speed. Depite that, a lot of stuff done in C is done in c++ these days whic
adds a lot of overhead onto everything anyway. It would seem nicer to
write in a decently protected language instead of the horrible cludge that is c++.

I would also suggest that the number of people writing core kenerla
and stuff these days is extrodinarily small.

Bing well,
David.
[DDT] Shrinking without a clue.

PS Death to visual basic!

[Michael J Wenk]

In article <85065337...@ogham.demon.co.uk>,
<ne...@ogham.demon.co.uk> wrote:

|Can someone explain to me why some people feel that lack of pointers is a
|good thing in a language? IMHO any language without pointers is rather
|crippled. If Java is to be taken seriously as an *all* purpose language as some
|people would have us believe then its going to have to have some transplanted
|into it and fast. Besides which , even if it did have pointers no ones forcing
|you to use them, after all you can write a C program without explicitly
|using them.
|

|As for garbage collection , big deal. Whose to say the garbage collection
|code in the VM isn't broken so it leaks memory anyway? The implementation
|of the JavaScript interpeter in netscape 2 certainly had this problem.
|

|NJR
|

Well you're both wrong.

Java does too have pointers. Ive seen code that uses them, what it lacks natively is pointer arithmetic. But you can do that too.

As for garbage collection, you're talking about two very different puppies. Also, i wouldn't knock a language cuz one of its implementations is buggy.

Mike

--
Michael Wenk
we...@cis.ohio-state.edu http://www.cis.ohio-state.edu/~wenk
System Developer/Engineer, IICF
The Ohio State University

[George Reese]

Michael J Wenk wrote:
>
> In article <85065337...@ogham.demon.co.uk>,
> <ne...@ogham.demon.co.uk> wrote:
>
> |Can someone explain to me why some people feel that lack of pointers is a
> |good thing in a language? IMHO any language without pointers is rather
> |crippled. If Java is to be taken seriously as an *all* purpose language as some
> |people would have us believe then its going to have to have some transplanted
> |into it and fast. Besides which , even if it did have pointers no ones forcing
> |you to use them, after all you can write a C program without explicitly
> |using them.
> |
> |As for garbage collection , big deal. Whose to say the garbage collection
> |code in the VM isn't broken so it leaks memory anyway? The implementation
> |of the JavaScript interpeter in netscape 2 certainly had this problem.
> |
> |NJR
> |
>
> Well you're both wrong.
>
> Java does too have pointers. Ive seen code that uses them, what it lacks natively is pointer arithmetic. But you can do that too.
>

It does not have pointers, it has object references. Which are
basically pointers without things like pointer arithmatic.

[ne...@ogham.demon.co.uk]

George Reese <bo...@imaginary.com> wrote:
>> into it and fast. Besides which , even if it did have pointers no ones forcing
>> you to use them, after all you can write a C program without explicitly
>> using them.
>

>Name one critical thing you can do with pointers that you cannot do in
>Java.

Write operating system type code? If you don't have direct access to memory
you're onto a non-starter. Various companies have been marketing Java as a
language to write a mini OS in for certain PDA type devices. Well sorry , that
ain't gonna happen until it can access the memory and hardware direct. Apart
from that , pointers will always be faster than array access. Admittedly
though, for writing most user level type programs they're not needed (but
then neither is object orientation) however:

Try doing this is java...

accept_packet(ip_packet)
char *ip_packet;
{
struct iphdr *ip=(struct iphdr *)packet;
int hdrlen;
.
.
hdrlen=ip->ihl << 2;
if (hdrlen>20) call_options(packet+20);
call_protocol(ip->protocol,packet+hdrlen,ip->tot_len-hdrlen);
.
.

Here the packet is a direct reference to somewhere in the kernel memory area,
there is no other way to reference it other than via its memory address - a
pointer.

>Pointers only server to introduce errors conditions into programs.

True , but as with most things they have a plus and minus side. Personally
(as you've probably guessed) I rather like them.

>Furthermore, adding them to Java would bring up a serious security
>problem.

Not really. What happens if you get a duff pointer in a user level unix C
program? A: You get a segmentation fault or suchlike, it doesnt bring the OS
down and no security is violated. The wonders of virtual memory. Ok it could
currupt its own files etc but this could happen quite happily without the help
of pointers anyway.

NJR

[ne...@ogham.demon.co.uk]

[ne...@ogham.demon.co.uk]

d...@visi.com (David Bennett (pinkfish)) wrote:
>usuage. With a nice oo language you can use controled memory allocation
>instead: ie create a new object.

So instead of just passing a pointer to an area of memory around the code
you keep creating and destroying objects? Hardly efficiency personified.
Besides , all that does is hide the pointer code with an abstraction layer,
its all still going on underneath.

Why do you think C is used for OS building? Because at some level you *have*
to start using memory addresses whether you like it or not. The only way to
get around this is have a CPU that uses nothing but its internal registers
and its stack (where corresponding memory addresses are resolved by hardware).
* blech *

NJR

[ne...@ogham.demon.co.uk]

"Bjorn Wesen" <exo...@sparta.lu.se> wrote:
>You quoted me out of context. On the line above my quote, there was this
>nice row:
>"Java is good for a mud language because:".
>Hence I don't talk about java as an allpurpose language at all. It's not.

Yeah ok , fair cop :)

>> As for garbage collection , big deal. Whose to say the garbage collection
>> code in the VM isn't broken so it leaks memory anyway? The implementation
>> of the JavaScript interpeter in netscape 2 certainly had this problem.
>

..

>Waving away GC as "big deal" is probably a famous last word. It really is a
>relief to not have to always keep thinking on who's going to delete what,
>like in situations where a method has to return a new object, and has to
>put the (stupid) demand on the caller that the caller disposes of the
>object when it's done.

I don't mind garbage collected languages as long as I can force it to free
certain objects if I have to. Theres nothing more annoying than watching
the dozey interpreter hang on to memory thats not needed any more but keeps
it anyway because the object or whatever it belongs to is still in scope even
though it'll never get used again. Want an example? JavaScript.

NJR

[Bjorn Wesen]

David Bennett (pinkfish) <d...@visi.com> wrote in
<5926t6$p...@darla.visi.com>...

> Speed is really not much of an issue these days. After all
> people use windows 95, so they obviously don't care
> about speed. Depite that, a lot of stuff done in C is done in c++ these
days whic
> adds a lot of overhead onto everything anyway. It would seem nicer to
> write in a decently protected language instead of the horrible cludge
that is c++.

Another pointless post.

There is nothing that makes a win32 program in win95 much slower than
alternative OS'es. Win95 might have bad resource allocation when
multitasking 16 bit programs, floppy access, and stuff like that though.
People do care for speed, but there is no real alternative to win95, if you
depend on the enormous amounts of programs available for windows (a
dedicated mudserver would be much better off running Linux of course). If
someone wants to develop the mud core, at the same time he uses his
well-known graphical debuggers etc for windows, it's a useful choice
however.

C++ doesn't add much overhead at all. You can inline property access
methods, and virtual metod dispatch is faster than the C-equivalent of
switch()'ing through tables.
Java is a nice beginners OO language I think, but it definately lacks many
things that c++ has. Two important omissions: enumerations and
const-declaring arguments.

I suggest not spewing out personal religious beliefs like these without
having any form of real-world facts behind.

[Reine Bergstrom]

David Bennett (pinkfish) wrote:
>
> Bjorn Wesen (exo...@sparta.lu.se) wrote:
>
> [Your point about it being popular therefor good]
>
> One word for you: Microsoft.
>

Aha but that's very much different M$ is popular among economists and
force uss poor developers to use the shit!

> Aparyt from that. Most OO people will agree t hat Eifel is a far
> better interpreted language (in fact a far better oo language)
>
> hy is it not used? Becaise it is not free. Why is java used?
> Because it is free. This does not nessessarily equate to good.
>

That was one of the worst comment about Java i've ever heard. ever
looked at it ? You think that more and more business move to Java cause
it's free ? People started to check out Java cause it was free, but they
don't use it cause it's free. It's not the only language that's free.

I must admit that my knowledge about Eifel is limited, i've only used it
little in school. I do know smalltalk and c++ pretty well and are now
working with Java. And Java is cool, when there get more packages to
java it will be great! We have already decided to do our CD-rom
production in Java (Except the internet stuff ofcourse). And we don't
care if it's free or not!!!!

It's silly to have this debate in a mud group though, but sometime you
can't hold yourself out of a comment.

/Reine - It's nice to be important but more important to be nice!

email : re...@ef.se
phone : +46 5879 3246

[George Reese]

ne...@ogham.demon.co.uk wrote:
>
> George Reese <bo...@imaginary.com> wrote:
> >> into it and fast. Besides which , even if it did have pointers no ones forcing
> >> you to use them, after all you can write a C program without explicitly
> >> using them.
> >
> >Name one critical thing you can do with pointers that you cannot do in
> >Java.
>
> Write operating system type code? If you don't have direct access to memory
> you're onto a non-starter. Various companies have been marketing Java as a
> language to write a mini OS in for certain PDA type devices. Well sorry , that
> ain't gonna happen until it can access the memory and hardware direct. Apart
> from that , pointers will always be faster than array access. Admittedly
> though, for writing most user level type programs they're not needed (but
> then neither is object orientation) however:

They seem to be doing just fine with JavaOS. The Java virtual machine
itself is basically a mini-OS.

> Try doing this is java...
>
> accept_packet(ip_packet)
> char *ip_packet;
> {
> struct iphdr *ip=(struct iphdr *)packet;
> int hdrlen;

That's called a security problem.

[Jon A. Lambert]

David Bennett (pinkfish) <d...@visi.com> wrote in article <5951ks$p...@darla.visi.com>...
> ne...@ogham.demon.co.uk wrote:

> : d...@visi.com (David Bennett (pinkfish)) wrote:
> : >usuage. With a nice oo language you can use controled memory allocation
> : >instead: ie create a new object.
> :
> : So instead of just passing a pointer to an area of memory around the code
> : you keep creating and destroying objects? Hardly efficiency personified.
> : Besides , all that does is hide the pointer code with an abstraction layer,
> : its all still going on underneath.

What do you think you do in C. Malloc some memory. Set a pointer up
to address it and later free it. In C++ you create an object with new and
later delete it. No difference here in efficiency. Actually pointers to objects are
usually passed around much like pointers to structures. Its generally bad form to
pass objects by value in C++, as it is to pass structures by value in C.
C++ as well as other OO languages allow you to pass objects by reference.
C does not allow this syntax. I know nothing of Java BTW, but it does make sense
to me that this is the way they would implement it, and if so it would be just as
efficient as C pointers passed by value. And leaving pointer arithmetic out
of Java really is an advantage, as it would make the language more secure to use.
For some apps this wouldn't be an advantage.
Perhaps a Java expert could clarify this?

>
> Yes. Exactly. What does c++ do? Pretty much the same thing. Thats
> one of the whole points of using an oo language. Oo languages are
> not more efficent, they are far less efficent (in general) so you would
> probably not want to write a kernal in one. Although I think microsoft did...

Xerox wrote an OS totally in C++ and its as fast or faster than many in C.
Sad to say the perception still lingers on that C++ has "significant"
overhead. I have no reason to believe that an OS kernel could not be
written almost entirely in C++ and be as efficient as C. Keep in mind
C++ compilers have come a long way in the last 5 years and your
"free" GNU compiler is by no means cutting edge, it lags behind
some other "pay" compilers by year or so.

>
> : Why do you think C is used for OS building? Because at some level you *have*

> : to start using memory addresses whether you like it or not. The only way to
> : get around this is have a CPU that uses nothing but its internal registers
> : and its stack (where corresponding memory addresses are resolved by hardware).
> : * blech *
>

> Each language has it's place. c/c++ is not good for building
> reliable and robust programns, prescisly because they
> allow and force you to use pointers in an uncontrolled
> fashion. Also because they type chcking is a bit suspect.
>
It would seem C++ has an advantage here with strong type checking.
Other OO languages are even more strongly typed. At some point
you have decide what level of control you really need a language to
have in order to provide reliable, maintainable and robust applications.
Sad to say, C++ because of its roots did not abandon C's level of machine
control and therefore all the disadvantages and failings of C are still
present in C++.

> For instance, you cannot build an os out of a functionlal language iether.
> Because you cannot garantee order of evaluation. Does this
> mean functionlal languages are not at all useful? No... They
> have their place.
>
I know this to be true on parallel operating systems and in fact you can't
guarantee the order of evaluation with assembler either.
Perhaps you are referring to items in the C/C++ standards that allow
certain expressions order of evaluation to be undefined. I guess if
you were writing code that this is imperative, you had better implement
your algorithm differently.

>
> Blue rings around saturn,
> David.
>

[David Bennett (pinkfish)]

ne...@ogham.demon.co.uk wrote:
: d...@visi.com (David Bennett (pinkfish)) wrote:
: >usuage. With a nice oo language you can use controled memory allocation
: >instead: ie create a new object.
:
: So instead of just passing a pointer to an area of memory around the code
: you keep creating and destroying objects? Hardly efficiency personified.
: Besides , all that does is hide the pointer code with an abstraction layer,
: its all still going on underneath.

Yes. Exactly. What does c++ do? Pretty much the same thing. Thats

one of the whole points of using an oo language. Oo languages are
not more efficent, they are far less efficent (in general) so you would
probably not want to write a kernal in one. Although I think microsoft did...

: Why do you think C is used for OS building? Because at some level you *have*

: to start using memory addresses whether you like it or not. The only way to
: get around this is have a CPU that uses nothing but its internal registers
: and its stack (where corresponding memory addresses are resolved by hardware).
: * blech *

Each language has it's place. c/c++ is not good for building
reliable and robust programns, prescisly because they
allow and force you to use pointers in an uncontrolled
fashion. Also because they type chcking is a bit suspect.

For instance, you cannot build an os out of a functionlal language iether.

Because you cannot garantee order of evaluation. Does this
mean functionlal languages are not at all useful? No... They
have their place.

[ne...@ogham.demon.co.uk]

"Bjorn Wesen" <exo...@sparta.lu.se> wrote:
>C++ doesn't add much overhead at all. You can inline property access
>methods, and virtual metod dispatch is faster than the C-equivalent of
>switch()'ing through tables.

Ever heard of function pointers in C?

NJR

[ne...@ogham.demon.co.uk]

George Reese <bo...@imaginary.com> wrote:
>They seem to be doing just fine with JavaOS. The Java virtual machine
>itself is basically a mini-OS.

That would be a good example , except that its not all written in Java.

>> Try doing this is java...
>>
>> accept_packet(ip_packet)
>> char *ip_packet;
>> {
>> struct iphdr *ip=(struct iphdr *)packet;
>> int hdrlen;
>
>That's called a security problem.

No , thats called IP protocol code that sits in the kernel. Unfortunately
something happened to my article and it got chopped off , I reposted it a
2nd time though which had a lot more stuff.

NJR

[Chris Lawrence (Contra)]

Bjorn Wesen (exo...@sparta.lu.se) wrote:

: Win95 might have bad resource allocation when

: multitasking 16 bit programs, floppy access, and stuff like that though.
: People do care for speed, but there is no real alternative to win95, if you
: depend on the enormous amounts of programs available for windows (a
: dedicated mudserver would be much better off running Linux of
: course).

Lets re-word this for clarification:

...there no real alternative to XXXXX, if you depend on the
enourmous amounts of programs available for XXXXX.

Doesn't this seem a little self-fulfilling? Heck, I can say the same
thing about OS/2, Linux, SunOS, MacOS, BeOS, OS/9, MVS, or even good
old CP/M or and not commit myself to *anything* in the process. Its a
wonderfully meaningless piece of
verbiage.

: I suggest not spewing out personal religious beliefs like these without

: having any form of real-world facts behind.

Quite. Facts, that is.

--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

[Abigail]

On 17 Dec 1996 04:51:37 GMT, Jon A. Lambert wrote in rec.games.mud.admin,rec.games.mud.diku,rec.games.mud.lp,rec.games.mud.misc,rec.games.mud.tiny:
++ David Bennett (pinkfish) <d...@visi.com> wrote in article <5951ks$p...@darla.visi.com>...
++
++ > For instance, you cannot build an os out of a functionlal language iether.
++ > Because you cannot garantee order of evaluation. Does this
++ > mean functionlal languages are not at all useful? No... They
++ > have their place.
++ >
++ I know this to be true on parallel operating systems and in fact you can't
++ guarantee the order of evaluation with assembler either.
++ Perhaps you are referring to items in the C/C++ standards that allow
++ certain expressions order of evaluation to be undefined. I guess if
++ you were writing code that this is imperative, you had better implement
++ your algorithm differently.

In almost any program that has side effects (assignment is a side
effect) you want a defined order of evaluation.
If you have something like:

int foo, bar;

foo = 3;
bar = 3 * foo;
foo = 5;

You want bar to be equal to 9, and foo equal to 5.

In a functional language, you don't have assignment. Something *is*
something else, it doesn't become something else at a particular
point of the program. Functional programs are much easier to use
in an environment where programs have to correct in the first place.
Lazy evaluation is possible, something you can't really do in a
language with side-effects. And graph reduction machines have their
charm too.

On the other hand, I/O is a pain in a functional language.
(Could you image a mud which doesn't give output, cause the lazy
evaluator never needs the results of the write statements?)

Abigail -- Infinite number of ones: xs = 1 : xs

[da...@xs4all.nl]

In <5951ks$p...@darla.visi.com> d...@visi.com (David Bennett (pinkfish)) writes:

>For instance, you cannot build an os out of a functionlal language iether.

>Because you cannot garantee order of evaluation. Does this

>mean functionlal languages are not at all useful? No... They

>have their place.

Actually, you can. In the Ancient History section, we have Lisp Machines.
More recently, there's Haskell. Take a fully lazy, fully functional
language and define your program as a function from an infinite list
of input events to an infinite list of output events -- voila. Some
friends and I wrote a small widget lib in Haskell once, with push-buttons
and pull-down menus and everything.

--
Richard Braakman

[Samuel James Holden]

ne...@ogham.demon.co.uk wrote:

> Why do you think C is used for OS building? Because at some level you *have*
> to start using memory addresses whether you like it or not. The only way to
> get around this is have a CPU that uses nothing but its internal registers
> and its stack (where corresponding memory addresses are resolved by hardware).
> * blech *
>

> NJR

Funnily enought he Java Virtual machine is a stack based machine, yes it does use a heap, but all operations are performed on the stack...

Sam Holden

[Andrew Molitor]

In article <85076382...@ogham.demon.co.uk> ne...@ogham.demon.co.uk writes:
> [ ... ] Apart

>from that , pointers will always be faster than array access.

Actually, array access is a huge win. Pointers, or more accurately,
C's pointers, are damn near impossible for the compiler to optimise. If you
have these damn pointers all over, pointing at who knows what, you can't
cache much of anything in registers.

You most definitely CAN write an OS without pointers. At some point,
you have to more or less fake them by treating various chucks of memory as
arrays of various types (a pointer is, in some sense, an array index into a
big array of char, after all. Or, again to be pedantic, that's how C
programmers who 'love pointers' tend to use them). However, your fake
pointers will have real types, and the compiler can assume you're not punning
all over, and can actually use the registers for something other than a buch
of transistors to give the pipeline's company.

Pointers are fine (they're object references). Pointer arithmetic is
a little dubious, it becomes harder to prove stuff about what the damn thing
is pointing at. Pointer arithmetic without bounds checking and without any
sort of sane type checking, that is, C pointers, are abominable. They weren't
a bad idea at the time, but in this day and age, when we have fancy machine
architectures and decent global optimisation technology, they suck.

Andrew

[John Viega]

In article <85076384...@ogham.demon.co.uk> ne...@ogham.demon.co.uk writes:
>
> So instead of just passing a pointer to an area of memory around the code
> you keep creating and destroying objects? Hardly efficiency personified.

Compilers can be far more intelligent than you seem to think. Java is
a much more dynamic language than C, and its speed is approaching that
of C. I even know one vendor who claims that their implementation is
often faster.

> Besides , all that does is hide the pointer code with an abstraction layer,
> its all still going on underneath.

Which is why it is far easier to program.

> Why do you think C is used for OS building? Because at some level you *have*
> to start using memory addresses whether you like it or not.

Bah. There are multiple JavaOS projects going on right now. I'm sure
if their first pass isn't written in Java, the second iteration will
be. Anyway, Sun is making hardware that supports the Java VM. If
speed considerations are an issue now, they probably won't be in the
near future.

BTW, Pinkfish, you sure the OS's to the old LISP machines weren't
written in LISP? You can garuntee order of evaluation in most
implementations of LISP. Now I'd believe that it would be incredibly
difficult to write an OS in Haskell...

[John Viega]

In article <85076382...@ogham.demon.co.uk> ne...@ogham.demon.co.uk writes:

> From: ne...@ogham.demon.co.uk

> >Name one critical thing you can do with pointers that you cannot do in
> >Java.
> Write operating system type code?

I've pointed this out in a previous post, but you are wrong about that.

> >Furthermore, adding them to Java would bring up a serious security
> >problem.
>
> Not really. What happens if you get a duff pointer in a user level unix C
> program? A: You get a segmentation fault or suchlike, it doesnt bring the OS
> down and no security is violated. The wonders of virtual memory. Ok it could
> currupt its own files etc but this could happen quite happily without the help
> of pointers anyway.

There have been many security violations in most Unix operating
systems in the past few years. Often what happens is this: Someone
uses a function, and doesn't bother checking arguments well enough,
and the stack gets overwritten, running an intruder's program. I know
this has happened several times, usually in code using strcpy().
strcpy() is evil, and if you ever have used it w/ a static buffer
where you did not make sure there was going to be a null termination
before the end of the buffer, then you've written a program with a
huge, gaping security hole. Java removes burdens like this from the
programmer's back.

And re-visiting efficiency, C certainly isn't the most efficient
language possible. I could imagine faster Pascal compilers due to a
number of small things Pascal does that C doesn't, such as storing the
length of strings, instead of null-terminating them.

[John Viega]

In article <85076386...@ogham.demon.co.uk> ne...@ogham.demon.co.uk writes:

> though it'll never get used again. Want an example? JavaScript.

Make sure you note that JavaScript currently has nothing in common w/
Java except for the name. It is not implemented in Java, and does not
compile to the Java VM. (Unless something has changed very recently).

[ae...@chillyclay.ny.fnx]

In article <85076384...@ogham.demon.co.uk>,

ne...@ogham.demon.co.uk writes:
> d...@visi.com (David Bennett (pinkfish)) wrote:
>>usuage. With a nice oo language you can use controled memory allocation
>>instead: ie create a new object.
>

> So instead of just passing a pointer to an area of memory around the code
> you keep creating and destroying objects? Hardly efficiency personified.

> Besides , all that does is hide the pointer code with an abstraction layer,
> its all still going on underneath.

Well, you can implement exactly the same techniques as non-object oriented
languages to get much better effiency. What about keeping a free list of
objects which were destroyed and reusing them when you want a create a new
one?

After all, malloc() asks the OS for more memory also (s)brk etc), and usually
keeps it around even after a free() for the next requests.

This technique of caching objects on a free list is worthwhile, definitely in
highly object intensive applications like MUDs.

Aedil

[Emmanuel Turner]

ae...@chillyclay.ny.fnx; Kris Van Hees <com> wrote in article
<E2MD2...@nonexistent.com>...

> Well, you can implement exactly the same techniques as non-object
oriented
> languages to get much better effiency. What about keeping a free list of
> objects which were destroyed and reusing them when you want a create a
new
> one?
>

> This technique of caching objects on a free list is worthwhile,
definitely in
> highly object intensive applications like MUDs.

Yes, but this technique would only be useful if : The time taken to
allocate a completly new object is longer than searching the object cache
and re-initialising/resurrecting the object, and if the likelihood of a
cache hit is reasonably high.

This technique is used by Delphi to cache Device Context Resources, like
pens, brushes etc.

[Abigail]

On Wed, 18 Dec 1996 16:39:53 GMT, John Viega wrote in rec.games.mud.admin,rec.games.mud.diku,rec.games.mud.lp,rec.games.mud.misc,rec.games.mud.tiny:
++ In article <85076382...@ogham.demon.co.uk> ne...@ogham.demon.co.uk writes:
++
++ > From: ne...@ogham.demon.co.uk
++
++ > >Name one critical thing you can do with pointers that you cannot do in
++ > >Java.
++ > Write operating system type code?
++
++ I've pointed this out in a previous post, but you are wrong about that.

There is a simple answer. A Turing machine doesn't have pointers.
All (digital) computers can be simulated on a Turing machine, hence
any language you can implement on a computer (like C, Java, LISP,
Pascal) are at most as powerful as a Turing machine.

++ > >Furthermore, adding them to Java would bring up a serious security
++ > >problem.
++ >
++ > Not really. What happens if you get a duff pointer in a user level unix C
++ > program? A: You get a segmentation fault or suchlike, it doesnt bring the OS
++ > down and no security is violated. The wonders of virtual memory. Ok it could
++ > currupt its own files etc but this could happen quite happily without the help
++ > of pointers anyway.
++
++ There have been many security violations in most Unix operating
++ systems in the past few years. Often what happens is this: Someone
++ uses a function, and doesn't bother checking arguments well enough,
++ and the stack gets overwritten, running an intruder's program. I know
++ this has happened several times, usually in code using strcpy().
++ strcpy() is evil, and if you ever have used it w/ a static buffer
++ where you did not make sure there was going to be a null termination
++ before the end of the buffer, then you've written a program with a
++ huge, gaping security hole. Java removes burdens like this from the
++ programmer's back.

But that's not something new of Java. Many programming languages
do that for you, including LPC, Pascal and Perl. Each in its
own way.

++ And re-visiting efficiency, C certainly isn't the most efficient
++ language possible. I could imagine faster Pascal compilers due to a
++ number of small things Pascal does that C doesn't, such as storing the
++ length of strings, instead of null-terminating them.

How do you measure "efficient" anyway? Take an algorithm, implement it in
various languages and measure the time it takes to run? But that's not
measuring the efficientcy of the language, it's comparing how well
the various compilers are doing.

If you want to measure the efficiency of a language, you might want
to look at how long it takes to program (and debug) a certain
algorithm. But that's very hard. While I can do most things faster
in Perl than in C, the person next to me can do it faster in C than
in Perl.

Abigail

[ne...@ogham.demon.co.uk]

abi...@ny.fnx.com (Abigail) wrote:
>There is a simple answer. A Turing machine doesn't have pointers.
>All (digital) computers can be simulated on a Turing machine, hence
>any language you can implement on a computer (like C, Java, LISP,
>Pascal) are at most as powerful as a Turing machine.

But some are more powerfull than others :) Like it or not C/C++ as it stands
at the moment is more powerfull than Java simply because it can access the
hardware direct with assembly code being the most powerfull language of all
(though also the hardest by far to use) since *anything* that can be done in
*any* other language on a given machine is by definition possible to do in
assembler on the same machine (given 10 years and free psychiatric support if
required :)

Also don't forget that a turing machine is a concept , it has to be turned
into reality via hardware which currently we build using CPU addressable
memory. This memory requires pointers of some sort within the software (of
normal computers, I'm not talking hardware stack machines) even if only at the
BIOS level.

NJR

[Abigail]

On Fri, 20 Dec 1996 11:04:20 GMT, ne...@ogham.demon.co.uk wrote in rec.games.mud.admin,rec.games.mud.lp:
++ abi...@ny.fnx.com (Abigail) wrote:
++ >There is a simple answer. A Turing machine doesn't have pointers.
++ >All (digital) computers can be simulated on a Turing machine, hence
++ >any language you can implement on a computer (like C, Java, LISP,
++ >Pascal) are at most as powerful as a Turing machine.
++
++ But some are more powerfull than others :) Like it or not C/C++ as it stands
++ at the moment is more powerfull than Java simply because it can access the
++ hardware direct with assembly code being the most powerfull language of all
++ (though also the hardest by far to use) since *anything* that can be done in
++ *any* other language on a given machine is by definition possible to do in
++ assembler on the same machine (given 10 years and free psychiatric support if
++ required :)

What if the given machine doesn't have assembler? Unrealistic? Why?
You think your microwave has assembler?

++ Also don't forget that a turing machine is a concept , it has to be turned
++ into reality via hardware which currently we build using CPU addressable
++ memory. This memory requires pointers of some sort within the software (of
++ normal computers, I'm not talking hardware stack machines) even if only at the
++ BIOS level.

Indeed, on a Von Neumann machine, you have "pointers". Which just
means you can access any memory location in constant time. However,
it would perfectly be possible to implement a Turing machine on a
non-Von Neumann machine. :)

Abigail

[Tim Hollebeek]

In article <85065337...@ogham.demon.co.uk>, ne...@ogham.demon.co.uk writes:
>
> As for garbage collection , big deal. Whose to say the garbage collection
> code in the VM isn't broken so it leaks memory anyway? The implementation
> of the JavaScript interpeter in netscape 2 certainly had this problem.

The nice thing about this is it is Someone Else's Problem. If the language
isn't garbage collected, memory allocation is your problem every time you
write a line of code that allocates memory.

That's tons of unnecessary work, IMO.

---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

[Tim Hollebeek]

Sure, if you want to spend hours of your development time maintaining
jumptables by hand, instead of letting the compiler do it for you.
When you succeed, your C code will be able to call functions *as fast
as* C++, not faster. IMO, spending hours of development time for no
practical gain is stupid. YMMV.

One good way to recognize people who don't know C++ well is to ask them
if C++ is slower than C. If they say yes, they really don't understand
C++ at all. Of course, there are plenty of other good reasons to dislike
C++ ...

[afader]

One thing about this thread - one is it doesn't have much to do with
Administration of a mud - so please STOP posting it to .admin! (IMHO, I
doubt it has ANYTHING to do with an LP mud either...)

Abigail wrote:
[Very well put Abigail]

>
> If you want to measure the efficiency of a language, you might want
> to look at how long it takes to program (and debug) a certain
> algorithm. But that's very hard. While I can do most things faster
> in Perl than in C, the person next to me can do it faster in C than
> in Perl.
>
> Abigail

The word "efficiency" is typically applied to an alogrythm - not the
coding of such. (I might be able to code the same algorythm in 68000
faster then both of you - but someone else might be able to do it in
BASIC faster then all of us. There is no information about the
langauges in this analysis.)

If we extend it to a "language" we can say the following: 4GLs are
typicially less efficient then 2GLs or 3GLs. (GL = Generation Language)

Java is a language which is a tokenized interperted language. (IE, you
write java program - build it and then anyone in the world with a Java
"library" (A misnomer) can hit your web page - and have the java code
you built download to them, and their machine interperts the binary
tokens. This makes Java a 4GL.

Sure, Java can do many operations in time close to any 2GL, (the 4GL
simply calls routines which are written in a 2GL.) So one could say
that Java is a fine choice of language for solving PDEs...
However, the "effeciency of the langauge" should be measured on how
well it preforms tasks under its primitave operators.

Java can be thought of being highly effective for communications. But
Java cannot be computationally effecient.

[ne...@ogham.demon.co.uk]

abi...@ny.fnx.com (Abigail) wrote:
>On Fri, 20 Dec 1996 11:04:20 GMT, ne...@ogham.demon.co.uk wrote in rec.games.mud.admin,rec.games.mud.lp:

>++ But some are more powerfull than others :) Like it or not C/C++ as it stands>++ at the moment is more powerfull than Java simply because it can access the
>++ hardware direct with assembly code being the most powerfull language of all
>++ (though also the hardest by far to use) since *anything* that can be done in>++ *any* other language on a given machine is by definition possible to do in
>++ assembler on the same machine (given 10 years and free psychiatric support if
>++ required :)
>
>What if the given machine doesn't have assembler? Unrealistic? Why?
>You think your microwave has assembler?

You'd be surprised how much is programmed these days - god help us if Bills
vision ever see's the light of day when even your average toaster will have
Windows *spit* running on it :) You either program something or its hard
wired, if its programmed it'll require some sort of assembly code to describe
the embedded CPU instructions even if they're only very basic.

>Indeed, on a Von Neumann machine, you have "pointers". Which just

And since thats what we have to work with at the moment pointers are needed
at some stage. QED.

>means you can access any memory location in constant time. However,
>it would perfectly be possible to implement a Turing machine on a
>non-Von Neumann machine. :)

Yup. You could probably do it on an analog computer if you tried hard enough.

NJR

[Tim Hollebeek]

No; managing variable size requests for memory is actually A LOT of
work, unless malloc() uses a very simplistic scheme. If you are
allocating constant size objects on a regular basis, allocating them
from pools and keeping a free list is quite a significant win, since
malloc() decays into a pointer assignment or two, instead of tons
of work (read a typical malloc implementation if you don't believe
me; it isn't a particularly fast call in many cases).

[Tim Hollebeek]

Jon A. Lambert wrote:
>
> Xerox wrote an OS totally in C++ and its as fast or faster than many in C.
> Sad to say the perception still lingers on that C++ has "significant"
> overhead. I have no reason to believe that an OS kernel could not be
> written almost entirely in C++ and be as efficient as C.

Actually, you have a reason *to* believe it, since C is a subset of
C++ (for the most part). As Bjarne likes to point out, every example
in K&R2 is a valid C++ program.

Of course, typically doesn't write C++ like that, but if the bottlenecks
are written in straight C, the speed difference will be neglible.
10% of the OS will be very C like, and the remaining 90% will be
easy to maintain (well, easier :-)).

> Keep in mind
> C++ compilers have come a long way in the last 5 years and your
> "free" GNU compiler is by no means cutting edge, it lags behind
> some other "pay" compilers by year or so.

I think you're being too kind. Two or three is often closer.