Are LPMuds Dead? Or Where to Next?
George Reese
advancements in at least two years (an eternity in the Internet world)
and it seems today even more so than in the past that new muds never
see the light of day. And of those new muds that make it, nothing new
is being done.
I do not think it is any secret that I no longer value LPC as a mud
building environment. It does have some strengths over Java that one
can get around by using a propreitary JVM, but on the whole it seems
to be overwhemingly limiting in where it can let people take muds.
So, what sort of things would make muds more appealing and does LPC
fit anywhere in that picture?
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie."
-Orson Welles
Haderak
George Reese wrote in message ...
>Are LPMuds dead? None of the major drivers have made any real
>advancements in at least two years (an eternity in the Internet world)
>and it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
No I don’t think Lpmuds are dead. A better word might be stagnating. I
disagree that nothing new is being done. One example is the Mud Sound
Protocol. It is supported by three somewhat popular clients, and while some
might consider it pointless or trivial, it is new. If MSP is implemented
well it can be a nice feature.
You also have commercial games modeled after muds. A great example is
Everquest by Sony Interactive/989 Studios. Everquest is only new in that it
uses 3d graphics. The basis of Everquest is still founded in text based
muds.
So are lpmuds dead? No. They are still popular, and individual muds still
add new things. The lack of new features are on the driver side. I have
noticed that new drivers are harder to come by.
> I do not think it is any secret that I no longer value LPC as a mud
> building environment. It does have some strengths over Java that one
> can get around by using a propreitary JVM, but on the whole it seems
> to be overwhemingly limiting in where it can let people take muds.
>
> So, what sort of things would make muds more appealing and does LPC
> fit anywhere in that picture?
Muds are having to start competing with commercial online games. While most
muds are free, they don’t have the support of a commercial game and don’t
have some of the other advantages that games like UO, Merdian 50 and
Everquest have. It’s a tradeoff. So to make muds more appealing would mean
to make muds more avialable to novice users and easier to start out. Also
integrating more functions into a client is a good way to make muds more
appealing to people. Although this has the effect of limiting the mud, it
also allows the mud to add abilities that it otherwise couldn’t do. I don’t
know Java, so I am guessing here, but a java mud/client might be a nice
combo. Coders create java code that is pushed to the client and instead of
having the client developer integrate everything into the client itself, you
push the responsibility to the mud coders. But like I said I don’t know
Java, so I could just be plain wrong of that part.
Tom Schmidt
http://gate.imaginary.com
had...@gatemud.org
Khall
wrote:
>Are LPMuds dead?
[chop]
Yes!!! Long live Diku:)
</troll> Sorry this group only had 4 messages in it...so I decided to
spruce it up a little bit:)
K.
D. B. Brown
>Are LPMuds dead? None of the major drivers have made any real
>advancements in at least two years (an eternity in the Internet world)
>and it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
Er, no.
LPMuds aren't dead. You're just out of touch.
I could go on and on about my mud Jormundgand which is nearing
alpha testing, or the advances made by the administration of Lost
Souls over the past several years. I'm sure my colleague Mr.
Sheahan will have something to add to this, but the simple fact
that you have closed your eyes to legitimate LPMud advancement
does not make it cease to exist.
> I do not think it is any secret that I no longer value LPC as a mud
> building environment. It does have some strengths over Java that one
> can get around by using a propreitary JVM, but on the whole it seems
> to be overwhemingly limiting in where it can let people take muds.
Please explain this. I don't see how LPC is any more limiting than
Java when it comes to an ultimately text-based system. Writing
graphical muds (and hence mud-clients) is something totally different
however, and something that Java is significantly better than LPC at
(well, at least, until someone writes OpenGL bindings for LPC :), but
still not the core of mud development.
If anything, Java's lack of multiple inheritance would be limiting to
the design of a LP-like mud. Perhaps I am due flamage for stating that
MI is anything besides evil, but it has its uses in a simulation.
> So, what sort of things would make muds more appealing and does LPC
> fit anywhere in that picture?
Personally, I think the next steps in mud evolution are going to
happen largely on the client end. And since most of the whiz-bang
will be going on on the client end, it doesn't especially matter
what the server is written in, so long as it adequately communicates
to the client. And socket bindings exist for most languages -- even
LPC.
D. B. Brown
"There's just a trace of pride upon our fixed grins
for there is no business like the show we're in"
-Jethro Tull
Haderak
perspective. LPC allows you to style your mud virtually anyway you want, but
as far as a player goes, do they really care if its MudOS, Circle, Nightmare
or any of the other's? Not really.
Lack of driver support is different then a dying breed of muds. Some muds
like ours uses a modified driver or may plan to develop thier own that isnt
released to the general public.
I do see a lack of driver options though for LPMuds. I wont discuss the
merit of one language over the other like the others did. The only comment
on my part is that in the future I expect to see more and more handled by
the client.
George Reese wrote in message ...
>Haderak <had...@gatemud.org> wrote:
>
>: George Reese wrote in message ...
>:>Are LPMuds dead? None of the major drivers have made any real
>:>advancements in at least two years (an eternity in the Internet world)
>:>and it seems today even more so than in the past that new muds never
>:>see the light of day. And of those new muds that make it, nothing new
>:>is being done.
>
>: No I don’t think Lpmuds are dead. A better word might be stagnating. I
>: disagree that nothing new is being done. One example is the Mud Sound
>: Protocol. It is supported by three somewhat popular clients, and while
some
>: might consider it pointless or trivial, it is new. If MSP is implemented
>: well it can be a nice feature.
>
>: You also have commercial games modeled after muds. A great example is
>: Everquest by Sony Interactive/989 Studios. Everquest is only new in that
it
>: uses 3d graphics. The basis of Everquest is still founded in text based
>: muds.
>
>: So are lpmuds dead? No. They are still popular, and individual muds still
>: add new things. The lack of new features are on the driver side. I have
>: noticed that new drivers are harder to come by.
>
>You are referencing things that are NOT LPMuds :)
>
>My comments were specifically regarding LPMuds, not muds in general.
John Adelsberger
: I do not think it is any secret that I no longer value LPC as a mud
: building environment. It does have some strengths over Java that one
: can get around by using a propreitary JVM, but on the whole it seems
: to be overwhemingly limiting in where it can let people take muds.
The fact that you think Java is the alternative is amusing; Java is
inherently more difficult to learn and code in than LPC, and so the
main edge of LP muds(lots of developers, even if most of them are area
coders) is lost outright. The only weaknesses of LPC can be fixed
relatively easily(I'm working on some of this for my project) without
destroying that ease of use.
: So, what sort of things would make muds more appealing and does LPC
: fit anywhere in that picture?
Frankly, the reason you haven't seen much _new_ stuff is that we're
rapidly reaching the pinnacle in text-based mudding and nobody has
come close to making anything as enjoyable as a text game out of
a graphical game(including those lame commercial hacks that aren't
even as fun as "Bard's Tale.") Lots of neat tech there, but no
worthwhile games.
IMHO, the two things to look at in LPC are threading/distribution
and the graphics end of things. The former cannot be a threaded LPC
because this destroys ease of use(*). Truthfully, though, I'm not
yet interested in either of those, because nobody has proposed a
game to build on them that I consider to be worth a rat's ass.
(*) I'm working on a way to provide limited threading that might not
impact any code except the sections which utilize it, but this
is really dodgy so far... the best that can be said for it is
that it would clean up some things that need cleaning up.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Burntnjall
George Reese wrote in message ...
>Are LPMuds dead? None of the major drivers have made any real
Dead? As in unpopular or stagnating? Yes, to a degree, but not because of a
lack of driver or low-level mudlib feature developments. I mean, just look at
the proliferation and popularity of simplistic Diku-type muds. Not to get into
the issue of stockmuds or the merits of the diku codebase, one cant deny that
even many simple-minded STOCK dikus attract a great number of players. And
these muds lack many of the features available to lpmuds.
I think the real problem stems from what was originally an lpmud strength, that
is the greater degree of mudlib customization that lpmuds afford. Over the
years, mudlibs have been customized to the point where almost every single
lpmud has unique major object code. The emphasis shifted a long time ago from
GAME developement, meaning creating unique areas and items using a common code
base, to coding and re-coding the mudlib code base itself.
>it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
Many new admins and coders want to add mudlib features to the point that they
never get around to coding a GAME that uses those features, as you have pointed
out. As for the lack of originality in the muds that do make it to opening,
well, I agree. Basically, I think people have overfixated on codebase
developement to the exclusion of game design and game developement.
People used to claim that diku's proliferated simply because they were so
stock, offering new admins instant-muds-in-a-box. That may have been true. But
more and more dikus are coming out now with all unique areas, even adding some
unique features. BUT they retained enough uniformity to let builders easily
create games. I think that the lpmud codebase has simply become too fragmented
and has lost the critical mass it once had that gave it vitality.
Lpmuds have more than enough features to code games new and interesting to
play. The real problem is a question of what we are all focusing on doing.
regards,
Njall.
George Reese
: George Reese wrote in message ...
:>Are LPMuds dead? None of the major drivers have made any real
:>see the light of day. And of those new muds that make it, nothing new
:>is being done.
: Er, no.
: LPMuds aren't dead. You're just out of touch.
: I could go on and on about my mud Jormundgand which is nearing
: alpha testing, or the advances made by the administration of Lost
: Souls over the past several years. I'm sure my colleague Mr.
: Sheahan will have something to add to this, but the simple fact
: that you have closed your eyes to legitimate LPMud advancement
: does not make it cease to exist.
I would appreciate it if you could answer an honest question with
examples to back up your beliefs instead of personal attacks on me.
:> I do not think it is any secret that I no longer value LPC as a mud
:> building environment. It does have some strengths over Java that one
:> can get around by using a propreitary JVM, but on the whole it seems
:> to be overwhemingly limiting in where it can let people take muds.
: Please explain this. I don't see how LPC is any more limiting than
: Java when it comes to an ultimately text-based system.
You just limited yourself right there.
: Writing
: graphical muds (and hence mud-clients) is something totally different
: however, and something that Java is significantly better than LPC at
: (well, at least, until someone writes OpenGL bindings for LPC :), but
: still not the core of mud development.
Why? Java has much stronger server-end support. Built in distributed
computing, for example, makes it possible to build huge muds that PC
can only dream of.
: If anything, Java's lack of multiple inheritance would be limiting to
: the design of a LP-like mud. Perhaps I am due flamage for stating that
: MI is anything besides evil, but it has its uses in a simulation.
The lack of MI is annoying in a mud world, but nothing more than
annoying.
:> So, what sort of things would make muds more appealing and does LPC
:> fit anywhere in that picture?
: Personally, I think the next steps in mud evolution are going to
: happen largely on the client end. And since most of the whiz-bang
: will be going on on the client end, it doesn't especially matter
: what the server is written in, so long as it adequately communicates
: to the client. And socket bindings exist for most languages -- even
: LPC.
I believe socket bindings (in terms of writing socket code) to be an
antiquated manner of communication. The distributed computing of RMI
in Java makes the client and server interaction more seamless. In
addition, it provides a degree of locational transparency of server
objects that would be really hard to achieve with direct socket
programming.
George Reese
: George Reese wrote in message ...
:>Are LPMuds dead? None of the major drivers have made any real
:>advancements in at least two years (an eternity in the Internet world)
:>and it seems today even more so than in the past that new muds never
:>see the light of day. And of those new muds that make it, nothing new
:>is being done.
: No I don’t think Lpmuds are dead. A better word might be stagnating. I
: disagree that nothing new is being done. One example is the Mud Sound
: Protocol. It is supported by three somewhat popular clients, and while some
: might consider it pointless or trivial, it is new. If MSP is implemented
: well it can be a nice feature.
: You also have commercial games modeled after muds. A great example is
: Everquest by Sony Interactive/989 Studios. Everquest is only new in that it
: uses 3d graphics. The basis of Everquest is still founded in text based
: muds.
: So are lpmuds dead? No. They are still popular, and individual muds still
: add new things. The lack of new features are on the driver side. I have
: noticed that new drivers are harder to come by.
You are referencing things that are NOT LPMuds :)
My comments were specifically regarding LPMuds, not muds in general.
--
George Reese
: George Reese <bo...@imaginary.com> wrote:
: : I do not think it is any secret that I no longer value LPC as a mud
: : building environment. It does have some strengths over Java that one
: : can get around by using a propreitary JVM, but on the whole it seems
: : to be overwhemingly limiting in where it can let people take muds.
: The fact that you think Java is the alternative is amusing; Java is
: inherently more difficult to learn and code in than LPC, and so the
: main edge of LP muds(lots of developers, even if most of them are area
: coders) is lost outright. The only weaknesses of LPC can be fixed
: relatively easily(I'm working on some of this for my project) without
: destroying that ease of use.
I would like to hear a defense of why anyone would think
single-threaded, non-distributed Java programming is any harder than
LPC programming. IMHO, the languages are so much a like it is scarey.
Furthermore, Java tends to catch errors much quicker with much less
debuggging.
And did you really need to insert the obviously inflammatory comment
"The fact that you think Java is the alternative is amusing"?
: : So, what sort of things would make muds more appealing and does LPC
: : fit anywhere in that picture?
: Frankly, the reason you haven't seen much _new_ stuff is that we're
: rapidly reaching the pinnacle in text-based mudding and nobody has
: come close to making anything as enjoyable as a text game out of
: a graphical game(including those lame commercial hacks that aren't
: even as fun as "Bard's Tale.") Lots of neat tech there, but no
: worthwhile games.
Why is it the pinnacle? I think it is simply that there is a lack of
vision as to where to go next. Certainly, since I am part of the
LPMud world and I do not have an answer, I am part of that problem.
The question is, how do we get beyond that?
: IMHO, the two things to look at in LPC are threading/distribution
: and the graphics end of things. The former cannot be a threaded LPC
: because this destroys ease of use(*). Truthfully, though, I'm not
: yet interested in either of those, because nobody has proposed a
: game to build on them that I consider to be worth a rat's ass.
Given you think this is the way to go, why did you so readily
dismiss a serious proposal I put forth to add support for
distributed computing to LPC?
John Adelsberger
: John Adelsberger <j...@umr.edu> wrote:
: : The fact that you think Java is the alternative is amusing; Java is
: : inherently more difficult to learn and code in than LPC, and so the
: : main edge of LP muds(lots of developers, even if most of them are area
: : coders) is lost outright. The only weaknesses of LPC can be fixed
: : relatively easily(I'm working on some of this for my project) without
: : destroying that ease of use.
: I would like to hear a defense of why anyone would think
: single-threaded, non-distributed Java programming is any harder than
: LPC programming. IMHO, the languages are so much a like it is scarey.
: Furthermore, Java tends to catch errors much quicker with much less
: debuggging.
I admit, I've never had problems debugging LPC... but then, I'm used to
debugging C, which is so much harder than debugging ANYTHING for which
you have a reasonably instrumented interpreter that it just isn't funny.
As for a defense of why anyone would think that Java is harder than LPC,
for starters, LPC has fewer things a new area coder has to learn; he
has to know to put an inherit line at the top of his file, and then
things just seem to magically work. He'll need to know more than that
to make Java work for him. For starters, he's going to run afoul of
the Java type system if he isn't instructed in what it does and how...
: And did you really need to insert the obviously inflammatory comment
: "The fact that you think Java is the alternative is amusing"?
I like to follow suit. You rarely reply to me without referring to me
as a 'complete idiot' or something to that effect, but I thought I'd
be a bit more subtle. Anyway, since this exchange seems rather
cordial thus far, I'll cease and desist and assume you actually care:)
: : Frankly, the reason you haven't seen much _new_ stuff is that we're
: : rapidly reaching the pinnacle in text-based mudding and nobody has
: : come close to making anything as enjoyable as a text game out of
: : a graphical game(including those lame commercial hacks that aren't
: : even as fun as "Bard's Tale.") Lots of neat tech there, but no
: : worthwhile games.
: Why is it the pinnacle? I think it is simply that there is a lack of
: vision as to where to go next. Certainly, since I am part of the
: LPMud world and I do not have an answer, I am part of that problem.
: The question is, how do we get beyond that?
I'm focusing on technical improvements and a game with a new theme
twist(for muds, anyway.) I'm also focusing on absolute standards of
quality in English, consistency in command parsing and other interface
issues, and eventually a fancy client. None of this is revolutionary,
and all of it takes lots of time, but the result, if there ever is one,
should be a text based mud beyond which one can't go without redefining
what it means to be a text game(ie, without joining the ranks of such
as JC Lawrence and Nathan Yospe.)
Honestly, I suspect the next leap will be when people finally figure
out what to do with graphics and muds, but none of what I've seen so
far is even remotely impressive save as a technical demonstration.
It looks snazzy, it shows talent, but it plays like crap.
: : IMHO, the two things to look at in LPC are threading/distribution
: : and the graphics end of things. The former cannot be a threaded LPC
: : because this destroys ease of use(*). Truthfully, though, I'm not
: : yet interested in either of those, because nobody has proposed a
: : game to build on them that I consider to be worth a rat's ass.
: Given you think this is the way to go, why did you so readily
: dismiss a serious proposal I put forth to add support for
: distributed computing to LPC?
I didn't dismiss it. I thought you were going about it the wrong way.
I think it's a great idea, but since we already have a nonstandard
language, it makes sense to do whatever we can to allow integration
with other tools, and my proposed solution, while more involved, would
provide that seamlessly. There are certainly enough of us to do it,
too... it isn't like it has to be the work of one or two people.
John Adelsberger
: I think it's a great idea, but since we already have a nonstandard
: language, it makes sense to do whatever we can to allow integration
: with other tools, and my proposed solution, while more involved, would
: provide that seamlessly. There are certainly enough of us to do it,
: too... it isn't like it has to be the work of one or two people.
This John guy is cool... hehe... anyway, I should also have pointed out
that if we did this, you could have your Java, too. I'm all for doing
things in the languages which suit them best, and for some things that
could be useful in a mud(interfaces to an Oracle database come to mind
as one possibility:) Java would rock ass. I just don't see dropping
the LPC for area coders, though...
George Reese
: : single-threaded, non-distributed Java programming is any harder than
: : LPC programming. IMHO, the languages are so much a like it is scarey.
: : Furthermore, Java tends to catch errors much quicker with much less
: : debuggging.
: I admit, I've never had problems debugging LPC... but then, I'm used to
: debugging C, which is so much harder than debugging ANYTHING for which
: you have a reasonably instrumented interpreter that it just isn't funny.
Yes, LPC is easier to debug than C. But, as I have stated before,
Java is much easier than LPC. Java's compiler catches so much at
compile time that an LPC compiler simply cannot catch.
: As for a defense of why anyone would think that Java is harder than LPC,
: for starters, LPC has fewer things a new area coder has to learn; he
: has to know to put an inherit line at the top of his file, and then
: things just seem to magically work. He'll need to know more than that
: to make Java work for him. For starters, he's going to run afoul of
: the Java type system if he isn't instructed in what it does and how...
There is no reason for an area coder to know this:
***
#include <lib.h>
inherit LIB_ROOM;
static void create() {
::create();
set_short("a small room");
set_long("This is a really small room.");
add_item("rose", "It is a red rose.");
add_exit("north", "/realms/bozo/workroom");
}
***
***
import mudlib.Room;
public class MyRoom extends Room {
public MyRoom() {
super();
setShort("a small room");
setLong("This is a really small room.");
addItem("rose", "It is a red rose.");
addExit("north", "realms.bozo.Workroom");
}
}
***
You do have to have some concept of types to work in LPC. But for
basic room coding in either language, you really don't need to get it.
Merlan
George Reese wrote in message ...
>Are LPMuds dead? None of the major drivers have made any real
>advancements in at least two years (an eternity in the Internet world)
>and it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
I think the problem here is not that LPC is dead/dying, more it is a
multitude of other reasons. Personally I see the main reason most
muds dont make it is because of, not in any order...
- Lack of mudlibs bases.
Most of the mudlib bases available, are throwbacks from someone
elses attempts and as such are full of inherant bugs, that it means
you'd be better off writing your own from scratch. Which leads
nicely on to the next...
- Time. Most people who attempt to start a new mud, think it's just
a matter of coding a few areas and letting it loose. This is not the
case. To make your mud appealing, you have to have something
different than the last mud. There are only so many ideas for areas,
after a while they get boring. So what happens is that someone
decides for what ever reason to build a mud and they find, they
cant do it all alone, they dont have the knowledge to do the mudlib
themselves, the coders they did start with loose patience and leave.
- Sites. Now more than ever, if you want to host a mud, you need to
pay more for the site. Back in the early life of muds, sites were a lot
more easily come by. You could put it on your college server and such.
Now with the net revolution in full swing, colleges cant afford the
space,
and the bandwidth it all requires. So people are forced to pay for their
site. Age would probably be an important factor here too. Most of the
mud population are school/college going people. They can not afford
to host muds on pay sites.
- Speed. Again the net revolution, although great for a multitude of
purposes, it is all getting very slow. Too often the muds I once played
are now so lagged they are becomming unplayable. Lets face it, if
you play muds to advance in level, it is not nice to be killing a big
monstie, suddenly to see your screen freeze, to come back in 3 minutes
and see yourself in the deat sequence. Again, this goes back to sites.
How many can afford the charges for a fast site?
>
>I do not think it is any secret that I no longer value LPC as a mud
>building environment. It does have some strengths over Java that one
>can get around by using a propreitary JVM, but on the whole it seems
>to be overwhemingly limiting in where it can let people take muds.
>
I refer back to my "Speed" issue, no matter what language you use, your
limited to the speed of the net. You can write it in pure C, will it be any
faster for the player? No, the player is limited by his modem, his ISP,
the inet backbone. How many times, has the main router on the east
coast of america gone down? Enough times for me to die and slam
my keyboard in pure frustration.
>So, what sort of things would make muds more appealing and does LPC
>fit anywhere in that picture?
This is a double barreled question :) Does it refer to muds in general, or
to LPC? On the issue of muds, what would make them more appealing
is speed. Muds are by their very nature appealing, the question the admin
have to ask themeselves is what would make their mud more appealing
to a player than the miriad of other muds. Areas are not enough, you
require an interesting mixture of classes, guilds, clans, abilities to
keep your audience interested. Take Nightmare for instance, it had a
great combat system a thing a lot of the available mudlib dont. To put this
in perspective, look atthe number of muds there were on the NM base..
A lot more than there are now on all the available LPC bases put together.
Another very important factor is what do players on your mud do after they
have reached maximum level in all classes/races??
One of the biggest problems facing any would be mud maker, is the choice
of what lib to use. I know this, as half the mud comunity knows. I've tried
each at this stage, I've hammered on lots of doors, I've driven some
people mad, with questions, which I thought were reasonable but which
others saw as idiotic. It's all a learning process, me, I can afford to
surf to each libbase support site and ask un-ending questions but a
lot more cant. This bring me onto lib support, a thing which is hugely
lacking. From one side I can understand it, people who once supported
libs now have had their fill of it all. But, if your going to code a base
and
offer it to the masses then you have to support it. If you dont, no-one
is going to use it. On a personal side, I have recently chosen to
commit myself to the CD lib. My over-riding reason for this is the
fantastic support I got from every single person involved with it. for
instance, I am not a linux guru, in fact I know very little about it. I
could not get the driver to install on the version of linux on my
site. What happened? A nice chap came and installed it for me.
Now I am not saying that every driver/mudlib base coder has to
do this, but it's nice to know that there is help at hand. Too often
I have visited a support site to see the site full of ego trippers
rather than people who want to see their base used.
In closing, No, LPC is not dead/dying. By far I would think it would
be the base of choice. I'm all for advancement in any facet of the
IT industry, whether it be commercial or home based. But you
have to remember, what ever you code is absolutely useless if
people cant/wont use it.
Merlan
Mystic Realms
Tim Blommerde
>Are LPMuds dead? None of the major drivers have made any real
>advancements in at least two years (an eternity in the Internet world)
>and it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
Well, Mr. Reese indeed raised an interesting question, one I've asked myself
a couple of times before. But, for as far as I can see, contrary to the
honourable Mr. Reese, I don't think LP Muds are dead. I'm no lpmud guru and
don't know the facts, but I guess there are nowadays just as much, if not
more, players and muds than there were say two years ago. So, aslong as
there are lpmuds and players I don't think you can say lpmuds are dead -
Unless people think somebody who's 40 years old and hasn't changed job,
moved to another house or taken another woman/man should be declared dead.
What I do think and where I partly agree with Mr. Reese, is that the
DEVELOPMENT of LPmud DRIVERS has slumbered into a sort of coma. Mr. Reese
is right that there are no recent major driver releases, atleast no recent
releases of the known and mostly used drivers. This might be made a bit
more understandable by a few of the following arguments:
The people that are mudding and thus part of the development and
evolution of (lp)muds are, as from old, a combination of
net-and-computer-freaks - people that spend a lot, if not all, spare time
behind their beloved machines - and students. These were and still are the
people that have the time (or are able to make time), the knowledge, the
love and devotion to create/code Muds. But, if you compare the present with
the older days, there are a lot more things to do. While hacking, cracking
and coding was their business in the 'old' days, web surfing, html-coding
and online games are now also consuming a lot of their time. Besides that,
the gifted part now can actually make some easy money with making web pages
for companies, while in the older days they'd probably have been coding. So
because of the growth of the net and the push and pull from the commercial
side as well as from the graphical side, (would be) mud developers are drawn
away from the always hard and most often unrewarded mud coding.
The people that have been busy with the driver development of the
drivers as we know them, have in most cases lost interest and time. And
there haven't been much people eager to take up there jobs and continue
their work. For this I think the lack of time and other, more rewarding
coding can be blamed. But maybe the main reason why nobody has been eager
to continue where the former driver coders have left, is that it's always
hard to continue/complete somebody else's coding project. And the larger
the projects, the harder it is. And because of that and ofcourse the new
possibilities and new coding languages, the idea of starting from scratch
and do it all your own way, quickly enters the head. Which in most cases
results in another worthless and unused driver or in a non-lpmud. (For as
far as I know there's but one man who's actually succeeded and that's the
honourable Mr. Dworkin with his DGD driver).
Another reason for the lack in driver development is that the current
drivers and the current state of LPC are able to handle nearly all wishes of
the lib coders. As you look into the evolution of other languages (Java, C,
Pascal etc.) the main evolution nowadays is in the support for graphics and
all kinda internet related things. LPmuds are textbased, so no need to
follow to latest graphical protocols and LPC doesn't really need internet
related libraries.
Then there are ofcourse other reasons too. The switch a lot of mudders
made from Unix/Linux to Windows machines might be a reason. The lowering of
the average age of coders might be one and the increase in costs of a site
might be one too.
All reasons that, in my humble opinion are to 'blame' for the lack of driver
development. There are probably a lot of other reasons too that at the
writing of this post kinda escape my mind. But all in all, I don't think
lpmuds are dead, but that the development of the major drivers has indeed
fallen into a sort of coma. The statement that new lpmuds offer little to
no new things I must refute. More and more mudders start their own lpmud
and but few of those ever reach a phase of being open and having players,
but if you look at some of the new open lpmuds, there are some who are more
or less related to older muds and only offer a new world to explore (Note
the word 'new') and there are also muds that offer new things like
roleplaying gods, fully player run economical system, self evolving area's,
ai-npc's etc. etc. And though these things have been thought about also in
the old days, the actually implementation is but something of late.
>I do not think it is any secret that I no longer value LPC as a mud
>building environment. It does have some strengths over Java that one
>can get around by using a propreitary JVM, but on the whole it seems
>to be overwhemingly limiting in where it can let people take muds.
Well, LPC is indeed more or less limited to being a text oriented online
game, so limited it is. Besides that LPC doesn't support any database
structure, another limitation. But even with this limitation people,
throughout the years, have been able to make brilliant games that, as former
posters already said, are far more fun to play than the commercial graphical
cousins of the lpmud. In my humble opinion I think a good LPC coder can
create nearly everything his/her hearth desires even with the limitations of
LPC. Maybe a better net support package for the most familiar drivers would
be nice, so the lib can open and close connections to other ports, but
besides that, I think the limitations LPC has is one that is inherent to a
text-oriented game driver and one people can live with.
>So, what sort of things would make muds more appealing and does LPC
>fit anywhere in that picture?
Hmm, good question. I think, as I stated before, database support and an
addition to LPC, so ports and connections can be handled a bit better in the
lib, might be nice. And I certainly think LPC fits in the mud-world of the
future. From your posts I read you think Java would be far better, but
though I must admit I know very little of Java, I think LPC still had some
advances above Java. One of the major ones is ofcourse that LPC is more
simple than Java (as LPC is also more simple than C/C++). But another major
reason is that nearly all technical students have to follow some C/C++
course. C/C++ still is the most used and known coding language and as LPC
is much like C/C++, muds and thus also lpmuds, only benefit by the fact that
they use C/C++ or a dialect thereof.
Hopefully all the above makes some sence and wasn't too boring. As a
conclusion to this story I'd like to add two things. First of all a thing
I've stated before and that is that the DGD driver, the driver coded by the
honourable Mr. Dworkin, _IS_ a LPmud driver that still get patched every so
often. It's a stable driver and, though it misses a lot of familiar efuns
when you're used to the Amylaar or Mudos driver, it also offers a lot of
other things. It ofcourse uses LPC as a coding language and as Mr. Dworkin
himself says, it can be used as a driver for nearly everything you want. He
even says and I'm tended to believe him, that the DGD driver can be used to
run online games like Ultima Online. Before people start to laugh and say
that can't be, note that with DGD it's pretty easy to make your mud a fully
functional FTP server (this I know by experience) and that the driver can
also be used to code it into a server for nearly every internet protocol you
want. So for those who're looking for a lpmud driver that still gets better
and who's coder still code's for it, I'd advise to check out DGD.
ftp://ftp.imaginary.com/pub/LPC/servers/DGD/
The other thing I'd like to mention is not really lpmud related, but more a
general mud thing. There's a group of people out there that is constantly
busy with the development and evolution of mud like games. They are known
as the MUD-Dev group and they discuss all kinda online game related things
from pure driver related topics to pure lib related topics, from threading
to non-room/coordinate based worlds, from multi-server games to artificial
npc's and spell systems where players can make/invent there own spells and
spells aren't just commands. Their archives are full of great knowledge and
wonderful new ideas. They are the people who're on the top of the mud
evolution and for everybody who's interested to know what all is possible
and what might be awesome to put in their mud, it might be advisable to
check out their archives and/or join their mailing list.
http://www.kanga.nu/~petidomo/lists/mud-dev/
Well, thanks for reading and have a good weekend,
Tim Blommerde
aka Puck Al'Rakham
aka Arvhatté, Sage of Dragg'ba, the Realms of the silvery mists
Lars Duening
> Are LPMuds dead? None of the major drivers have made any real
> advancements in at least two years (an eternity in the Internet world)
> and it seems today even more so than in the past that new muds never
> see the light of day. And of those new muds that make it, nothing new
> is being done.
I can imagine that there is a point from which on improvements on the
driver need more work to implement than the improvements later save you
in building your mud. That, and that working on gamedriver is a hard,
time-consuming and unglamorous work only few appreciate to do.
I can't say anything about modern muds - I don't have enough time to
play them :-(
> I do not think it is any secret that I no longer value LPC as a mud
> building environment. It does have some strengths over Java that one
> can get around by using a propreitary JVM, but on the whole it seems
> to be overwhemingly limiting in where it can let people take muds.
Please elaborate.
--
Lars Duening; la...@cableinet.co.uk
John Adelsberger
: There is no reason for an area coder to know this:
: ***
: #include <lib.h>
Note that this line is only necessary if you're a 'polluted namespaces'
freak, as if you're not, you can easily use the global include file to
provide a static object location service.
: inherit LIB_ROOM;
This makes sense to almost everyone who reads it and realizes what he's
doing insofar as to know that his file 'is' a room...
: static void create() {
This makes sense.
: ::create();
This _may_ be necessary. You can get around it, if you try hard.
: set_short("a small room");
: set_long("This is a really small room.");
: add_item("rose", "It is a red rose.");
: add_exit("north", "/realms/bozo/workroom");
: }
This all makes good sense.
: ***
: ***
: import mudlib.Room;
Again, this will make sense to anyone reading it.
: public class MyRoom extends Room {
Perhaps a bit verbose, but I suppose people can just learn the magic
formula:-)
: public MyRoom() {
: super();
You'll have trouble with this one, and there's no easy way around it in
Java.
: setShort("a small room");
: setLong("This is a really small room.");
: addItem("rose", "It is a red rose.");
: addExit("north", "realms.bozo.Workroom");
: }
: }
This is all identical.
: ***
: You do have to have some concept of types to work in LPC. But for
: basic room coding in either language, you really don't need to get it.
As soon as Joe Loser wants any functionality you didn't put in the room
inherit, he's screwed without knowledge of Java types. LPC will make him
declare a type, but it is remarkably unpicky about dealing with them once
declared. Just try 'string1 + string2' in Java sometime; it makes perfect
sense to nontechie types who read it, but not to a Java compiler:)
Burntnjall
Just out of curiosity, is there a Java driver and/or mudlib available?
regards,
Njall.
George Reese
: : super();
: You'll have trouble with this one, and there's no easy way around it in
: Java.
Why? It is completely optional. Constructors in Java are ALWAYS
extended and NEVER overriden. I always explicitly put the call to
super() in my code because I hate implicitness in programming.
: : You do have to have some concept of types to work in LPC. But for
: : basic room coding in either language, you really don't need to get it.
: As soon as Joe Loser wants any functionality you didn't put in the room
: inherit, he's screwed without knowledge of Java types. LPC will make him
: declare a type, but it is remarkably unpicky about dealing with them once
: declared. Just try 'string1 + string2' in Java sometime; it makes perfect
: sense to nontechie types who read it, but not to a Java compiler:)
It doesn't make sense to a Java compiler?
str3 = str1 + str2;
This is the same in both Java and LPC.
I have provided an example of the most common LPC code and shown how
the Java version is damn near identical. Yet you still claim Java is
not only harder, but significantly harder enough to matter. So please
provide an example of something that is really easy in LPC that would
be hard in Java.
George Reese
: Just out of curiosity, is there a Java driver and/or mudlib available?
I have been working on it off and on :)
John Adelsberger
: Why? Java has much stronger server-end support. Built in distributed
: computing, for example, makes it possible to build huge muds that PC
: can only dream of.
Java's overglorified RPC system is no more a distribution mechanism
than is present in the C programming language. If that's all we
expect from a distribution mechanism, we can just write RPC bindings
for LPC; this isn't even interesting, much less difficult.
: I believe socket bindings (in terms of writing socket code) to be an
: antiquated manner of communication. The distributed computing of RMI
: in Java makes the client and server interaction more seamless.
RMI is just a bunch of wrappers. It would be simple to implement such
functionality in LPC, although it would take a small bit of time. I
don't know how much you know about implementation of RPC, but it is
easy, and all Java adds to ordinary RPC is a form of distributed
namespace caching, which certainly isn't difficult either.
: In
: addition, it provides a degree of locational transparency of server
: objects that would be really hard to achieve with direct socket
: programming.
Mmm... layer of abstraction... probably in the driver. Sometimes you
seem to forget that the fancy toys you play with are nothing but
facades built on older facilities such as sockets in order to simplify
their use. Sure, they're nifty and great and save time and effort,
and that's worthwhile and I don't mean to denigrate it, but writing
such facades is hardly so difficult that their lack is a real flaw in
a given system; just write them and be done with it.
Geoff Wong
>Are LPMuds dead? None of the major drivers have made any real
>advancements in at least two years (an eternity in the Internet world)
>and it seems today even more so than in the past that new muds never
>see the light of day. And of those new muds that make it, nothing new
>is being done.
>I do not think it is any secret that I no longer value LPC as a mud
>building environment. It does have some strengths over Java that one
>can get around by using a propreitary JVM, but on the whole it seems
>to be overwhemingly limiting in where it can let people take muds.
>So, what sort of things would make muds more appealing and does LPC
>fit anywhere in that picture?
An interesting question in rgm.lp (after far more than 2 years
of stagnation ...)! Having messed around with LPC(s) for 8 years,
lectured computer programming (C, C++, Java, Ada, et al) and having also
programmed Java (et al) commercially I feel the urge to waffle a bit :-)
The question is unfortunately a very open ended one and multi-barrelled
(as someone else has pointed out) with no real
criteria for comparison except citing "real advancements".
There are so many ways to approach such an open question.
I'll deal with the question from a number of perspectives:
1. Does one language provide technical possibilities
the other doesn't?
2. Does one language provide better quality support
in terms of performance, reliability, maintainability,
security or robustness?
3. Legacy issues.
1. Technical and Language Issues.
Both LPC and Java are Turing complete languages and hence whatever
you do in one you can do in the other, with an appropriate
amount of support work, more on that later. George may believe Java
can take us to places that LPC can't but I see no reason they can't
both take us to the same place. It is 's likely that one will get their
more quickly and more efficiently than the other.
Indeed I see no reason someone couldn't do a little work and have
LPC compiling onto the JVM (instead of the custom VM(s) that LPmuds
have). This would provide a legacy path for moving your LPmud into
a Java environment. A number of other language already compile to
the JVM (including Ada), these may provide even better languages for
mud-building (but that wasn't the question).
Java provides in-language support for handling concurrency.
LPC does not; here Java is technically superior. Although
some extensions to the LPC language and a support library
could provide concurrency support, these aren't trivial.
It should be noted that concurrency is a two-edged sword that
many wizards, who aren't programmers, would cut themselves upon.
Nevertheless I regard it as a significant deficiency in LPC.
Flaws exist in both languages. Object-orientedness
was really a tack-on to LPC (I remember when there was no inheritance)
and it really shows. Both languages type systems leave something
to be desired. LPC is (very) loosely dynamically typed with
no type checking available on objects. Java provides a more
mature complex type system that has a few subtle problems
(which I won't go into, needless to say some of the method
dispatching and dynamic casting is odd). Both share the peculiarity of
passing basic types by value and objects and array by reference.
Java is a more clearly thought out language.
Using either language requires an understanding of their
static namespace organisation and their runtime support
libraries (objects, etc). LPC namespace organisation is
pretty simple (with classes mapping directly to filenames).
Java is more complicated with packages (relating to directories),
files and classes inside files. Compiled code also hangs around
in the directories. Both have numerous runtime support systems,
Java neatly encapsulates them into class interfaces. LPC
runtime support is usually buried away in the driver as a bunch
of efuns in a flat namespace. Basically both require
some learning overhead to really get going on larger projects.
Dynamic code replacement is an interesting issue. One of
the big strengths of LPC is that you can easily and readily
replace broken code (in the dynamic namespace) and have new
objects created from the code. Java provides for easy loading
of new code but it's not so easy to replace existing code
already linked with other code. Certainly an edge to LP here.
Java has a huge library of support code but it's mostly general
programming stuff. LPmud provides extensive existing libraries
for actual MUDs. Nevertheless class libraries can be developed easily
in either language. It's not really a language issue as such but
it is time to start issue. The only issue of particular importance
in this domain is that of strings. Strings and string handling
are a really important aspect of any mud (assuming we're not talking
graphical muds). Java's string handling is fundamentally irritating
requiring the use of two classes to do any really interesting manipulations.
Whereas LPC has always been aimed at convenient string handling.
Certainly an edge to LPC in this important mud-development aspect.
2. Quality and Software Development Issues.
LPC has a strictly limited number of software development support
tools (profilers, debuggers, metrics tools, etc). And it
is unlikely to get many either (most mud people are more interested
in actually getting a mud up!). Java is streets ahead here
in the availability and quality of software development and
maintenance tools.
LPmuds are by and large reasonably stable runtime environments
with know problems. Java is still quite an unstable beast
(especially the browsers), many JVMs have significant garbage
collection problems. An existing edge in reliability to LPC,
but it's quickly being addressed.
LPC has been specifically tailored to perform well
in the mud domain (lots of strings and smallish memory objects and
long uptimes). Java really hasn't been applied widely in
these circumstances. I haven't done any benchmarking
but on similar hardware I'd expect LPC to do a better
job providing mud-service in a similar mud domain. Having
said that server performance and memory usage are far lesser
issues than they were a few years ago. If you've got a
performance problem then through more hardware at it.
Bottlenecks are now more likely to be network ones than server ones.
Most LPmud drivers are a maintainability burden. With Java
the runtime support and compilers are maintained by the wider
software community and cease to be issues. Standardisation will
also eventually occur.
Because of the strict type system, the packaging system and the
availability of process control tools large code bases will be
easier to maintain in Java. Providing Java and its libraries don't keep
getting changed as significantly and regularly as they have in
the recent past.
3. Legacy Issues.
Many millions of lines of dedicated mud code already exists
in LPC. Very limited amounts of mud-oriented Java code exist.
A lot of people would be quite unhappy to abandon
their existing muds and begin again. This issue alone will
ensure the continued existence of LPC as a language and LPmud as
a development environment.
4. Concluding Thoughts.
Java is the buzz-language of the moment; it's over rated
as a programming language because of the intense marketing behind.
Plenty of similar alternatives exist (including Inferno, Erlang,
Ada (to JVM)). Nevertheless heavy marketing means market-wide support
and development of tools and libraries which are unavailable in a
LPC environment.
In years gone by LPmud was the only really flexible mud driver,
this is certainly no longer the case. Unless you're already
familiar with LPmud there isn't that many compelling reasons
to start one up.
In conclusion I don't think LPC is dead yet, but without
significant injections of highly quality energy it is certainly
on the decline. If you have a good one running it's much easier
to maintain and build on it than it is to switch. If you're looking
to start from scratch then Java is one of the many reasonable
alternatives available.
Geoff
--
Shattered World.
telnet://gecko.serc.rmit.edu.au 23
George Reese
: George Reese <bo...@imaginary.com> wrote:
: : Why? Java has much stronger server-end support. Built in distributed
: : computing, for example, makes it possible to build huge muds that PC
: : can only dream of.
: Java's overglorified RPC system is no more a distribution mechanism
: than is present in the C programming language. If that's all we
: expect from a distribution mechanism, we can just write RPC bindings
: for LPC; this isn't even interesting, much less difficult.
This is totally false, unless your view of all distributed systems is
overglorified RPC systems. Do you care to explain this bizarre
assertion?
: : I believe socket bindings (in terms of writing socket code) to be an
: : antiquated manner of communication. The distributed computing of RMI
: : in Java makes the client and server interaction more seamless.
: RMI is just a bunch of wrappers. It would be simple to implement such
: functionality in LPC, although it would take a small bit of time. I
: don't know how much you know about implementation of RPC, but it is
: easy, and all Java adds to ordinary RPC is a form of distributed
: namespace caching, which certainly isn't difficult either.
Distributed namespace caching? If this is your view of RMI, you are
obviously unfamiliar with it. As its designer (and one of the
designers of CORBA), Jim Waldo, stated, it is what CORBA would be if
the world were all Java. It enables people to do distributed
computing under a single paradigm: the Java/OO paradigm. It supports
pass by reference and pass by value of real Java objects and the
making of true method calls. As it evolves, the distributed services
are now coming along. I myself have written transaction, naming,
logging and security services for RMI.
This is a hell of a lot more powerful than straight RPC.
: : In
: : addition, it provides a degree of locational transparency of server
: : objects that would be really hard to achieve with direct socket
: : programming.
: Mmm... layer of abstraction... probably in the driver.
Yes, if you were to do that, it would be in the driver.
: Sometimes you
: seem to forget that the fancy toys you play with are nothing but
: facades built on older facilities such as sockets in order to simplify
: their use. Sure, they're nifty and great and save time and effort,
: and that's worthwhile and I don't mean to denigrate it, but writing
: such facades is hardly so difficult that their lack is a real flaw in
: a given system; just write them and be done with it.
Who says I forgot that? The fact is Java has them and LPC will likely
never have them. As I pointed out in another post, I tried to offer
up a proposal to provide this sort of functionality of the LPC
paradigm and you used it as an opportunity to engage in a litany of
personal attacks against me. So, if that is how anyone who puts forth
such a proposal is to be greeted, I cannot conceive off any such
system being put into place.
George Reese
: George Reese <bo...@imaginary.com> writes:
:> I have provided an example of the most common LPC code and shown how
:> the Java version is damn near identical. Yet you still claim Java is
:> not only harder, but significantly harder enough to matter. So please
:> provide an example of something that is really easy in LPC that would
:> be hard in Java.
: LPC provides a limited environment that creators can log into -
: limited in that you can only interact with the driver using efuns and
: applies (more or less I think). Can this be done with Java, or does the
: ability to write in code that the driver equivalent is written in (and
: the code would get dynamically loaded into I assume) mean that the code has
: access to the entire Java runtime environment?
This point does not so much relate to the ease of Java v LPC, but it
is an important point in discussing the ability of Java at least to
mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
it cannot by default be dynamically unloaded. There are VM's however
that do support dynamic unloading. I personally would recommend
staying away from proprietary VMs and change the manner in which
development is done in LPMuds. In other words, give each developer a
jar and let them work at home to develop.
John Adelsberger
: This is totally false, unless your view of all distributed systems is
: overglorified RPC systems.
Most are, but some(such as CORBA) provide significantly more.
: : RMI is just a bunch of wrappers. It would be simple to implement such
: : functionality in LPC, although it would take a small bit of time. I
: : don't know how much you know about implementation of RPC, but it is
: : easy, and all Java adds to ordinary RPC is a form of distributed
: : namespace caching, which certainly isn't difficult either.
: Distributed namespace caching? If this is your view of RMI, you are
: obviously unfamiliar with it.
No. The difference between you and me is that I look at what it IS, and
you look at what people USE it for. It allows you to treat remote Java
objects as though they were local, with certain constraints. By any
definition of transparency I ever saw, it does NOT provide the location
transparency you talked about, because you have to know where an object
is in the first place before you can treat it as though it were local.
In other words, it is RPC and a namespace cache.
: As its designer (and one of the
: designers of CORBA), Jim Waldo, stated, it is what CORBA would be if
: the world were all Java.
He may have said that, but if he did, he obviously wasn't thinking
very hard; CORBA will TELL you where to find remote resources. RMI
just lets you pretend they're local after you tell IT where they are.
This is just the beginning of the differences.
: It enables people to do distributed
: computing under a single paradigm: the Java/OO paradigm.
Yes, and this is _all_ that it does. When you realize that the world
really ISN'T all Java and never WILL be, you'll know why I prefer
CORBA.
: It supports
: pass by reference and pass by value of real Java objects and the
: making of true method calls.
Ok, so it has an OO RPC mechanism... this isn't news...
: As it evolves, the distributed services
: are now coming along. I myself have written transaction, naming,
: logging and security services for RMI.
And if you wrote a hundred more services, it would begin to approach
what CORBA already is, but it would STILL only work for Java.
: This is a hell of a lot more powerful than straight RPC.
Yes, but your software sitting on top of RMI is not a part of RMI or the
Java environment any more than is any other. If we restrict the
discussion to what RMI actually IS as a product in itself, it is an
overglorified RPC mechanism with OO extensions whose implementation is
perhaps a bit time consuming but very, very simple.
: : : In
: : : addition, it provides a degree of locational transparency of server
: : : objects that would be really hard to achieve with direct socket
: : : programming.
: : Mmm... layer of abstraction... probably in the driver.
: Yes, if you were to do that, it would be in the driver.
It wouldn't _have_ to be... but it would make more sense there.
George Reese
: : This is totally false, unless your view of all distributed systems is
: : overglorified RPC systems.
: Most are, but some(such as CORBA) provide significantly more.
Because of its services? In this sense, CORBA is nothing more than a
spec. And it took a lone time to get CORBA where it is today.
: : : RMI is just a bunch of wrappers. It would be simple to implement such
: : : functionality in LPC, although it would take a small bit of time. I
: : : don't know how much you know about implementation of RPC, but it is
: : : easy, and all Java adds to ordinary RPC is a form of distributed
: : : namespace caching, which certainly isn't difficult either.
: : Distributed namespace caching? If this is your view of RMI, you are
: : obviously unfamiliar with it.
: No. The difference between you and me is that I look at what it IS, and
: you look at what people USE it for.
There are a lot of differences between you and I, but let's try to
focus on the topic of discussion and not personal nonsense.
: It allows you to treat remote Java
: objects as though they were local, with certain constraints.
Yes.
: By any
: definition of transparency I ever saw, it does NOT provide the location
: transparency you talked about, because you have to know where an object
: is in the first place before you can treat it as though it were
: local.
No.
: In other words, it is RPC and a namespace cache.
No.
: : As its designer (and one of the
: : designers of CORBA), Jim Waldo, stated, it is what CORBA would be if
: : the world were all Java.
: He may have said that, but if he did, he obviously wasn't thinking
: very hard;
It looks foolish for you to sit here and insult someone with his
credentials. You would be better served by stating why CORBA would be
significantl different from RMI if the world were all Java.
: CORBA will TELL you where to find remote resources. RMI
: just lets you pretend they're local after you tell IT where they are.
: This is just the beginning of the differences.
The CORBA spec provides distributed naming services. How well
individual ORBs implement this is up for grabs.
An official JNDI distributed naming service is coming for RMI.
Nevertheless, like I said, I and some companies have developed
distributed naming services for RMI.
This is not an architectural issue. It is a toolset issue.
: : It enables people to do distributed
: : computing under a single paradigm: the Java/OO paradigm.
: Yes, and this is _all_ that it does. When you realize that the world
: really ISN'T all Java and never WILL be, you'll know why I prefer
: CORBA.
Again, you resort to personal attacks instead of attempting to make a
point. I am obviously very well aware of what the world really is
since I have been developing professional, real world software for
close to 6 years. Saying you wwould only ever use CORBA or saying you
would only use RMI is a blanket statement that no one can ever make.
For some people, RMI makes sense. For others, CORBA makes sense.
Getting back to the world of muds, however, none of this is relevant
to mud development. The point about RMI is how easy it is to deliver
distributed muds in the Java environment. The only point you have
tangentially made is that "in the real world", some people might want
to use CORBA. In a JavaMud environment, however, RMI is the leading
choice.
: : It supports
: : pass by reference and pass by value of real Java objects and the
: : making of true method calls.
: Ok, so it has an OO RPC mechanism... this isn't news...
No, that is not simple OO RPC. Things like pass by value and
distributed garbage collecting are things CORBA has not even managed
to touch yet.
Those ARE architectural issues.
: : As it evolves, the distributed services
: : are now coming along. I myself have written transaction, naming,
: : logging and security services for RMI.
: And if you wrote a hundred more services, it would begin to approach
: what CORBA already is, but it would STILL only work for Java.
CORBA does not have a hundred services. So, please explain what it is
beyond having a bunch of services built on top of it makes CORBA so
wonderful that you would use it in a pure Java environment?
: : This is a hell of a lot more powerful than straight RPC.
: Yes, but your software sitting on top of RMI is not a part of RMI or the
: Java environment any more than is any other. If we restrict the
: discussion to what RMI actually IS as a product in itself, it is an
: overglorified RPC mechanism with OO extensions whose implementation is
: perhaps a bit time consuming but very, very simple.
If we restrict the discussion of what CORBA is, it is nothing more
than a specification. There is no software that is CORBA.
And as far as the services go, they exist today. There is no reason
why someone has to write them on their own for RMI.
John Adelsberger
: that do support dynamic unloading. I personally would recommend
: staying away from proprietary VMs and change the manner in which
: development is done in LPMuds. In other words, give each developer a
: jar and let them work at home to develop.
There are lots of problems with this, not the least of which is that
teaching new area people will be nigh on impossible if they can't
work on a setup into which is logged someone who can teach... mostly,
such people don't live near each other and so forth, so being able
to converse, examine code, and reload it rapidly after changes are
made is essential to learning. It is unreasonable to expect area
coders to learn Java in the same way that a professional developer
would.
John Adelsberger
: An official JNDI distributed naming service is coming for RMI.
Ah, so they really ARE trying to produce an all-Java CORBA. One wonders
why they bother... their efforts would be better spent supporting an
existing standard than trying to convince people to adopt yet another
incompatible technology that will later limit their flexibility.
: to use CORBA. In a JavaMud environment, however, RMI is the leading
: choice.
You've yet to explain why I'd want a 'JavaMud environment.' In order to
justify the huge amount of new development this would require, you're
going to need more than 'it can be done, and I like Java.' You're going
to need more than 'I say LPC is limiting.' And you're going to need more
than 'look at all this stuff that exists for Java' too, because in the
time it would take to write a real mud server in Java, including the
probable needed custom VM, you could easily add dozens of features to
an LP driver AND go on vacation.
That said, yes, if you want to do a mud exclusively in Java, RMI probably
makes sense for it. So does CORBA, since there are CORBA bindings either
finished or in the works(I don't bother to keep up with the progress of
Java too closely, because I decided early on that unless someone wanted
to pay me to care, I just couldn't make myself. Too much bark, not enough
bite.)
: : : It supports
: : : pass by reference and pass by value of real Java objects and the
: : : making of true method calls.
: : Ok, so it has an OO RPC mechanism... this isn't news...
: No, that is not simple OO RPC. Things like pass by value and
: distributed garbage collecting are things CORBA has not even managed
: to touch yet.
Garbage collection doesn't belong in CORBA; it would imply imposing a
single memory architecture on object resources so diverse that there
isn't and cannot be a listing of all of them. In Java, garbage
collection for RMI is almost trivial, because you have one environment
that already solved the garbage collection problem(sort of; the Java
garbage collector sucks nads, but it does work, after a fashion.)
As for pass by value, depending on what you intend to pass by value,
it may or may not be possible; no, you cannot pass a raw Oracle
table to an object providing a hash service and expect anything
meaningful to come out of it, but CORBA does in fact efficiently
support transfer of such data as is actually universally recognizable.
: CORBA does not have a hundred services. So, please explain what it is
: beyond having a bunch of services built on top of it makes CORBA so
: wonderful that you would use it in a pure Java environment?
You mistake me. I wouldn't USE a pure Java environment unless someone
was paying me good money to do so or could demonstrate a real advantage
to doing so, and you propose neither.
: : Yes, but your software sitting on top of RMI is not a part of RMI or the
: : Java environment any more than is any other. If we restrict the
: : discussion to what RMI actually IS as a product in itself, it is an
: : overglorified RPC mechanism with OO extensions whose implementation is
: : perhaps a bit time consuming but very, very simple.
: If we restrict the discussion of what CORBA is, it is nothing more
: than a specification. There is no software that is CORBA.
The reference implementation of RMI doesn't make it any more 'real' than
CORBA.
Alan Pennington
I had was a class in GW-BASIC. I don't know if that is still the case in
schools around the country but it doesn't seem to be the best introduction
to programming with the nature of today's world. I was in college when I
discovered muds and LPC was my first exposure to structured programming.
While I have never used LPC for anything other than muds the C structure and
requirements for writing code that other people may use and modify helped
prepare me for "real" programming.
To the point, I like the idea of a JAVAmud. While JAVA may be over
hyped, it is a language used professionally and a mud written with JAVA
could be used as an educational tool. This has been a great thread so far
with very little in the way of flaming and mostly constructive criticism.
Anyone want to extend my comments?
Alan
===---===---===---===---===---===---===---===---===
check out a cool rpg
threshold-rpg.com 23
===---===---===---===---===---===---===---===---===
Richard
> I have provided an example of the most common LPC code and shown how
> the Java version is damn near identical. Yet you still claim Java is
> not only harder, but significantly harder enough to matter. So please
> provide an example of something that is really easy in LPC that would
> be hard in Java.
LPC provides a limited environment that creators can log into -
limited in that you can only interact with the driver using efuns and
applies (more or less I think). Can this be done with Java, or does the
ability to write in code that the driver equivalent is written in (and
the code would get dynamically loaded into I assume) mean that the code has
access to the entire Java runtime environment?
--
Richard Tew (above spudent -> student, lame spam avoidance thingy)
Richard
# Sites. Now more than ever, if you want to host a mud, you need to
# pay more for the site. Back in the early life of muds, sites were a lot
# more easily come by. You could put it on your college server and such.
# Now with the net revolution in full swing, colleges cant afford the space,
# and the bandwidth it all requires. So people are forced to pay for their
# site. Age would probably be an important factor here too. Most of the
# mud population are school/college going people. They can not afford
# to host muds on pay sites.
There will always be free sites, as with most other things in life - what
you put in is what you get out. Someone won't offer you a free site when
you advertise? Go out and e-mail all the ISP admins whose e-mail address
you can find in a Altavista search.. you wouldn't be the first person its
worked for.
# lot more cant. This bring me onto lib support, a thing which is hugely
# lacking. From one side I can understand it, people who once supported
# libs now have had their fill of it all. But, if your going to code a base
# and
# offer it to the masses then you have to support it. If you dont, no-one
# is going to use it. On a personal side, I have recently chosen to
Aren't you contradicting yourself here? George doesn't support Nightmare,
yet it is the most commonly used lib or something - would quote you but
I think I already cut that bit.
What I didn't like with CD was that rather than separate functionality, it
IMO tried to do a Diku type thing with objects. It included commands (for
example) in every object with add_action (or something), to update a command
globally you'd practically have to reboot. It was like what the
distribution Discworld mudlib is like, only complete - functionality
needs to be separated IMO, not all lumped together.
# commit myself to the CD lib. My over-riding reason for this is the
# fantastic support I got from every single person involved with it. for
Isn't CD a school project or something? I think I rember something about
that when I looked at it last.
# instance, I am not a linux guru, in fact I know very little about it. I
# could not get the driver to install on the version of linux on my
# site. What happened? A nice chap came and installed it for me.
I used to do this, what can I say - its a sign of someone with a lot of
time on their hands :P Every mud I did it for died and no longer exists
today.. I believe George is of the opinion that they should only be able
to use Lost Souls if they can get it going, I agree with him whole-heartedly.
Unlike the beatles, I don't want to hold your hand.
# In closing, No, LPC is not dead/dying. By far I would think it would
# be the base of choice. I'm all for advancement in any facet of the
# IT industry, whether it be commercial or home based. But you
# have to remember, what ever you code is absolutely useless if
# people cant/wont use it.
I would say at least a good number of the libs that are released for
LPC drivers are used by the creators in their own muds.
Nightmare (Lost Souls?)
FR
Discworld
.. i'm sure theres more ..
Whether people use the code or not, doesn't mean it isn't good for
reference to - for example understand driver parsing. I would never use
Lima, but it is a good point of reference for how to do some things.
George Reese
r: George Reese <bo...@imaginary.com> wrote:
: : An official JNDI distributed naming service is coming for RMI.
: Ah, so they really ARE trying to produce an all-Java CORBA. One wonders
: why they bother... their efforts would be better spent supporting an
: existing standard than trying to convince people to adopt yet another
: incompatible technology that will later limit their flexibility.
They bother because there are inherent benefits in providing a single
distributed object paradigm.
: : to use CORBA. In a JavaMud environment, however, RMI is the leading
: : choice.
: You've yet to explain why I'd want a 'JavaMud environment.' In order to
: justify the huge amount of new development this would require, you're
: going to need more than 'it can be done, and I like Java.' You're going
: to need more than 'I say LPC is limiting.'
I have done that. Native support for multi-threading, a clean,
built-in distributed object framework, a larger developer base, a
simpler language to program in, a framework of APIs that far outstrips
what LPMud has been able to accomplish in 10 years, etc.
Also, don't forget that it is easier with Java to provide a much
tighter coupling between client and server, thus enhancing what can be
done on the client end.
: And you're going to need more
: than 'look at all this stuff that exists for Java' too, because in the
: time it would take to write a real mud server in Java, including the
: probable needed custom VM, you could easily add dozens of features to
: an LP driver AND go on vacation.
These are all very vacuous claims. Let's not play name that tune. I
am certain I could write a real mud server and mudlib in a much lesser
amount of time than you could add those features to LPMud. But it
means nothing for me to state that--except of course this audience is
familiar with my ability to deliver mud applications.
: That said, yes, if you want to do a mud exclusively in Java, RMI probably
: makes sense for it. So does CORBA, since there are CORBA bindings either
: finished or in the works(I don't bother to keep up with the progress of
: Java too closely, because I decided early on that unless someone wanted
: to pay me to care, I just couldn't make myself. Too much bark, not enough
: bite.)
Actually, if you are intending to be 100% Java, going with CORBA is
idiotic. Also, those of us who do work in the real world have found
that as a language, Java works just fine.
: : : : It supports
: : : : pass by reference and pass by value of real Java objects and the
: : : : making of true method calls.
: : : Ok, so it has an OO RPC mechanism... this isn't news...
: : No, that is not simple OO RPC. Things like pass by value and
: : distributed garbage collecting are things CORBA has not even managed
: : to touch yet.
: Garbage collection doesn't belong in CORBA; it would imply imposing a
: single memory architecture on object resources so diverse that there
: isn't and cannot be a listing of all of them. In Java, garbage
: collection for RMI is almost trivial, because you have one environment
: that already solved the garbage collection problem(sort of; the Java
: garbage collector sucks nads, but it does work, after a fashion.)
: As for pass by value, depending on what you intend to pass by value,
: it may or may not be possible; no, you cannot pass a raw Oracle
: table to an object providing a hash service and expect anything
: meaningful to come out of it, but CORBA does in fact efficiently
: support transfer of such data as is actually universally recognizable.
These are two major and well-recognized problems with CORBA. You are
right. Garbage collection does not belong in CORBA--because CORBA is
an LCD specification. You cannot rely on distributed garbage
collection for a tool that must support languages without garbage
collection. This is good for CORBA because having a language
independent distributed object specification is a good thing.
However, if you can make the assumption of a parrticular language, it
is much better to be able to do so and get distributed garbage
collection.
: : CORBA does not have a hundred services. So, please explain what it is
: : beyond having a bunch of services built on top of it makes CORBA so
: : wonderful that you would use it in a pure Java environment?
: You mistake me. I wouldn't USE a pure Java environment unless someone
: was paying me good money to do so or could demonstrate a real advantage
: to doing so, and you propose neither.
I gave you several above.
: : : Yes, but your software sitting on top of RMI is not a part of RMI or the
: : : Java environment any more than is any other. If we restrict the
: : : discussion to what RMI actually IS as a product in itself, it is an
: : : overglorified RPC mechanism with OO extensions whose implementation is
: : : perhaps a bit time consuming but very, very simple.
: : If we restrict the discussion of what CORBA is, it is nothing more
: : than a specification. There is no software that is CORBA.
: The reference implementation of RMI doesn't make it any more 'real' than
: CORBA.
Yes, it does. RMI is not simply a specification, it is an
implementation. And there is no fucking around with incompatible ORB vendors.
George Reese
: George Reese <bo...@imaginary.com> wrote:
: : that do support dynamic unloading. I personally would recommend
: : staying away from proprietary VMs and change the manner in which
: : development is done in LPMuds. In other words, give each developer a
: : jar and let them work at home to develop.
: There are lots of problems with this, not the least of which is that
: teaching new area people will be nigh on impossible if they can't
: work on a setup into which is logged someone who can teach... mostly,
: such people don't live near each other and so forth, so being able
: to converse, examine code, and reload it rapidly after changes are
: made is essential to learning. It is unreasonable to expect area
: coders to learn Java in the same way that a professional developer
: would.
Who said this implies you could not cooperate real time with other
developers on the mud?
John Adelsberger
: They bother because there are inherent benefits in providing a single
: distributed object paradigm.
There already IS one - they're just fragmenting the support for it.
: I have done that. Native support for multi-threading, a clean,
: built-in distributed object framework, a larger developer base, a
: simpler language to program in, a framework of APIs that far outstrips
: what LPMud has been able to accomplish in 10 years, etc.
Multi-threading - done the way Java does it, this is a hindrance. It
adds too much complexity for most mud developers to handle.
Clean object framework - let's just say we disagree on what 'clean' means
and leave it at that; I despise what Java has in this regard.
Clean object framework - let's just say we disagree on what 'clean' means
and leave it at that; I despise what Java has in this regard.
Larger developer base - yeah, right. I'm sure all those Javaheads are
just dying to work on muds. Guess what? MUD people care about muds,
not Java people. There isn't much overlap, aside from you and a
handful of others, and you're the only one who shows any sign of being
able to produce what he talks about.
Simpler language? Well, yes... monosyllabic grunts are simpler than
English, too...
APIs - hey, thanks for the hot tip, Columbo. I'm glad to know that you
find it interesting that tens of thousands of people with corporate
funding can outstrip a relative handful of volunteers. Are those APIs
useful for a mud? I personally am finding it hard to justify any claim
that I need SSL in my mud, for instance:)
: Also, don't forget that it is easier with Java to provide a much
: tighter coupling between client and server, thus enhancing what can be
: done on the client end.
I question how much easier this really is, but why argue, since we can't
prove anything?
: Actually, if you are intending to be 100% Java, going with CORBA is
: idiotic. Also, those of us who do work in the real world have found
: that as a language, Java works just fine.
Yeah, except that the so-called GUI strengths don't exist(nothing looks
the same on two different platforms in Java,) most of the existing VMs
are so slow they're useless for anything but toy demos, and all you do
is I/O intensive in nature. Try using it for anything that actually
wants speed.
: : The reference implementation of RMI doesn't make it any more 'real' than
: : CORBA.
: Yes, it does. RMI is not simply a specification, it is an
: implementation. And there is no fucking around with incompatible ORB vendors.
Half the stuff you tout about Java doesn't really exist yet(their official
naming service, for instance, or the HotSpot stuff that runs on 2 platforms
out of dozens that are useful, but you then go off on CORBA because it isn't
fully mature yet. You can have it one way or the other, but not both.
George Reese
: : They bother because there are inherent benefits in providing a single
: : distributed object paradigm.
: There already IS one - they're just fragmenting the support for it.
You misunderstand what I was getting at. By making the assumption of
Java and choosing RMI, you are choosing a single paradigm in which to
do both distributed and non-distributed computing. By choosing
language independence and choosing CORBA, you are actually choosing
two paradigms-one for distributed computing and one for
non-distributed computing.
: : I have done that. Native support for multi-threading, a clean,
: : built-in distributed object framework, a larger developer base, a
: : simpler language to program in, a framework of APIs that far outstrips
: : what LPMud has been able to accomplish in 10 years, etc.
: Multi-threading - done the way Java does it, this is a hindrance. It
: adds too much complexity for most mud developers to handle.
If you expect mud developers to manage the threading issues. I would
assume that a good lib would hide this stuff. But this is not even
possible with LPC as it is now.
: Larger developer base - yeah, right. I'm sure all those Javaheads are
: just dying to work on muds. Guess what? MUD people care about muds,
: not Java people. There isn't much overlap, aside from you and a
: handful of others, and you're the only one who shows any sign of being
: able to produce what he talks about.
Actually, it seems a lot of people are interested in the idea.
Furthermore, wouldn't it be nice to be able to point your new creators
to the book store to get them started on area building instead of
holding their hands?
: Simpler language? Well, yes... monosyllabic grunts are simpler than
: English, too...
That is a non-sequitur.
: APIs - hey, thanks for the hot tip, Columbo. I'm glad to know that you
: find it interesting that tens of thousands of people with corporate
: funding can outstrip a relative handful of volunteers. Are those APIs
: useful for a mud? I personally am finding it hard to justify any claim
: that I need SSL in my mud, for instance:)
Besides being rudely formatted, this reply is illogical. And the
proper conclusion is that this is a serious Java advantage.
First off all, just because you may not use some of those libraries
does not mean that the wide availability of libraries (and greater
stability thereof) is not a bonus. In fact, I imagine you could come
up with some uses for an SSL library. Finally, SSL is not one of the
things that comes with the Java Platform.
At any rate, one would think the fact that a lot of corporate
development is going into Java is certainly an advantage over LPC.
: : Also, don't forget that it is easier with Java to provide a much
: : tighter coupling between client and server, thus enhancing what can be
: : done on the client end.
: I question how much easier this really is, but why argue, since we can't
: prove anything?
This is largely based on the idea of being able to load executable
content across the network and the distributed object paradigm that is
inherent in Java. I think those go a bit of the way to underlining my
point. Do you actually have some objections to base your questioning
on?
: : Actually, if you are intending to be 100% Java, going with CORBA is
: : idiotic. Also, those of us who do work in the real world have found
: : that as a language, Java works just fine.
: Yeah, except that the so-called GUI strengths don't exist(nothing looks
: the same on two different platforms in Java,)
This is definitely a weakness of Java. It is going to take time to
get it right. It is not a trivial problem to solve.
: most of the existing VMs
: are so slow they're useless for anything but toy demos, and all you do
: is I/O intensive in nature. Try using it for anything that actually
: wants speed.
This is completely false. The only problem with most applicatin VMs
is the garbage collection. The effect this issue will have on a
distributed mud is negligible.
: : : The reference implementation of RMI doesn't make it any more 'real' than
: : : CORBA.
: : Yes, it does. RMI is not simply a specification, it is an
: : implementation. And there is no fucking around with incompatible ORB vendors.
: Half the stuff you tout about Java doesn't really exist yet(their official
: naming service, for instance, or the HotSpot stuff that runs on 2 platforms
: out of dozens that are useful, but you then go off on CORBA because it isn't
: fully mature yet. You can have it one way or the other, but not both.
You are still comparing apples and oranges. CORBA has been around for
years and has had the time to mature. It has failed because it is way
too complex a specification. Given this complexity and the lack of a
reference implementation, it is no wonder that all the ORBs have
varying degrees of incompatibility and it will be amazing if they are
ever actually trule interopable.
Merlan
Richard wrote in message ...
>"Merlan" <sol...@indigo.ie> writes:
># Sites. Now more than ever, if you want to host a mud, you need to
># pay more for the site. Back in the early life of muds, sites were a lot
># more easily come by. You could put it on your college server and such.
># Now with the net revolution in full swing, colleges cant afford the
space,
># and the bandwidth it all requires. So people are forced to pay for their
># site. Age would probably be an important factor here too. Most of the
># mud population are school/college going people. They can not afford
># to host muds on pay sites.
>
>There will always be free sites, as with most other things in life - what
>you put in is what you get out. Someone won't offer you a free site when
>you advertise? Go out and e-mail all the ISP admins whose e-mail address
>you can find in a Altavista search.. you wouldn't be the first person its
>worked for.
>
># lot more cant. This bring me onto lib support, a thing which is hugely
># lacking. From one side I can understand it, people who once supported
># libs now have had their fill of it all. But, if your going to code a base
># and
># offer it to the masses then you have to support it. If you dont, no-one
># is going to use it. On a personal side, I have recently chosen to
>
>Aren't you contradicting yourself here? George doesn't support Nightmare,
>yet it is the most commonly used lib or something - would quote you but
>I think I already cut that bit.
If I did'nt say it, I meant to say NM _was_ the more common..
>
>What I didn't like with CD was that rather than separate functionality, it
>IMO tried to do a Diku type thing with objects. It included commands (for
>example) in every object with add_action (or something), to update a
command
>globally you'd practically have to reboot. It was like what the
>distribution Discworld mudlib is like, only complete - functionality
>needs to be separated IMO, not all lumped together.
I'm not too sure of what your saying here. It is my understanding that
the reason for add_action is to add commands to the player when
he/she encounters this object. It also my understanding that this is
how it is done in all LPC muds. Feel free to correct me if I'm wrong.
>
># commit myself to the CD lib. My over-riding reason for this is the
># fantastic support I got from every single person involved with it. for
>
>Isn't CD a school project or something? I think I rember something about
>that when I looked at it last.
Are'nt they all ? I don't ever remember seing a commercial one.
>
># instance, I am not a linux guru, in fact I know very little about it. I
># could not get the driver to install on the version of linux on my
># site. What happened? A nice chap came and installed it for me.
>
>I used to do this, what can I say - its a sign of someone with a lot of
>time on their hands :P Every mud I did it for died and no longer exists
>today.. I believe George is of the opinion that they should only be able
>to use Lost Souls if they can get it going, I agree with him
whole-heartedly.
>Unlike the beatles, I don't want to hold your hand.
I accept your first point, in that if everyone visited wouldbe sites to get
drivers/libs working it'd be a whole waste of time in some regards..
As for the second point Re: George and his opinions.. I have to say
I find that attitude pretty hard to take. How did you learn to install
drivers? Did'nt you ever ask questions? And now that you have the
info, your not going to tell anyone else?
IMPHO, George's attitude sucks, I don't care how much he knows,
what he did and did'nt code. It seems to me, that if you don't know
exactly what you want to ask, don't ask George. That's fine with
me. I've been coding professionally for nearly 15 years, but it is
still my understanding that if someone leaves college and asks me
for information and I have it, I give it. It's not like I "own" the
information or anything. And more, if I realise they don't know
exactly waht they want, I help them out. If George does'nt want
to do that, then fine. His attitude and opinons are his, he's
entitled to them, that don't mean I have to respect them.
Let's say someone wants to start a mud. How do they get the info
they require? The attitude I got from George is that if you don't know
then you don't deserve to have a mud.. Now unless I'm vastly
mistaken, owning or building a mud is not something you do or
do not deserve. To my knowledge, most people who play and setup
muds do it as a hobby. So to say "they should only be able to use
Lost Souls if they get it going" reeks to me of "if you cant get it going
yourself, get lost". An attitude I detest.
And now, after reading more of the posts in this thread, It appears to
me like the whole thread is becoming a flame war for George. If
people don't like what he has to say, or their knowledge of OO
design, Java, CORBA is less than his, he jumps on their every word.
It's like he wants to prove he is right that Java is the way to go. Well
George, if you want to design a driver in Java, go do it. We're not
paying you. It's your hobby.
So much for the precious charter of this group. If these people were
anyone else bar George, we'd have a thread telling them to read
the charter. I mean, the first post was fine, ask a question, get the
opinions. But this is now verging on the insane.
>
># In closing, No, LPC is not dead/dying. By far I would think it would
># be the base of choice. I'm all for advancement in any facet of the
># IT industry, whether it be commercial or home based. But you
># have to remember, what ever you code is absolutely useless if
># people cant/wont use it.
>
>I would say at least a good number of the libs that are released for
>LPC drivers are used by the creators in their own muds.
>
The point I was trying to make was this. If George wants to code a
Java driver then fine. Is he going to support it ? If he's only going
to use the driver for his own mud, then why bother asking our
opinions in the first place?
>Nightmare (Lost Souls?)
>FR
>Discworld
>.. i'm sure theres more ..
>
>Whether people use the code or not, doesn't mean it isn't good for
>reference to - for example understand driver parsing. I would never use
>Lima, but it is a good point of reference for how to do some things.
>
I agree totally.
George Reese
: I'm not too sure of what your saying here. It is my understanding that
: the reason for add_action is to add commands to the player when
: he/she encounters this object. It also my understanding that this is
: how it is done in all LPC muds. Feel free to correct me if I'm wrong.
This is not the case. Lima, Dead Souls, and later Nightmare muds all
do not use add_action().
:># instance, I am not a linux guru, in fact I know very little about it. I
:># could not get the driver to install on the version of linux on my
:># site. What happened? A nice chap came and installed it for me.
:>
:>I used to do this, what can I say - its a sign of someone with a lot of
:>time on their hands :P Every mud I did it for died and no longer exists
:>today.. I believe George is of the opinion that they should only be able
:>to use Lost Souls if they can get it going, I agree with him
: whole-heartedly.
:>Unlike the beatles, I don't want to hold your hand.
: I accept your first point, in that if everyone visited wouldbe sites to get
: drivers/libs working it'd be a whole waste of time in some regards..
: As for the second point Re: George and his opinions.. I have to say
: I find that attitude pretty hard to take. How did you learn to install
: drivers? Did'nt you ever ask questions? And now that you have the
: info, your not going to tell anyone else?
To install drivers? I read the directions.
: IMPHO, George's attitude sucks, I don't care how much he knows,
: what he did and did'nt code.
Aha. No matter how much I give you, I still owe you more?
: It seems to me, that if you don't know
: exactly what you want to ask, don't ask George. That's fine with
: me.
A person who does not know what they want to ask has a problem. I
cannot possibly answer a question if you cannot ask it.
: I've been coding professionally for nearly 15 years, but it is
: still my understanding that if someone leaves college and asks me
: for information and I have it, I give it.
What exactly are you referring to? My declaration that I will not
support Dead Souls?
If so, you have no idea what sort of time commitment that entails. It
is really easy for you who has not supported any public software to
sit and pass judgments on what I should and should not do.
The fact is that even though I do not support Dead Souls, I do support
several freely available software projects for which people are
allowed to ask me questions and do in fact ask me questions. Dead
Souls is a place where I have drawn the line.
: It's not like I "own" the
: information or anything. And more, if I realise they don't know
: exactly waht they want, I help them out.
Again, until you have spent any amount of time supporting software
that you have given out for free, you have no business pontificating
on this subject.
: If George does'nt want
: to do that, then fine. His attitude and opinons are his, he's
: entitled to them, that don't mean I have to respect them.
You don't have to, but you should. It is not like I am some person
with all this knowledge who has done nothing for this community. I
have done a lot. At some point, I have to draw the line. But at
least I have done enough that drawing the line is necessary.
Let me put it another way, your complaints sound like those of someone
who would complain of a billionaire not giving to a specific charity
when as a rule he gives away 50% of his annual income.
: Let's say someone wants to start a mud. How do they get the info
: they require?
Rule number 1: You sure as hell better have had some experience
coding on a mud. Otherwise, you have no business running one.
: The attitude I got from George is that if you don't know
: then you don't deserve to have a mud..
The info is in the FAQ. Then each of the drivers come with directions
on how to install them. It is a really easy process and an inability
to follow it should be taken as a sign you have no business running a
mud.
: Now unless I'm vastly
: mistaken, owning or building a mud is not something you do or
: do not deserve.
Someone who hasn't the basic knowledge for starting a mud and who is
not willing to get that knowledge except by having me do it for them
is valuing THEIR time over MY time. And I find that terribly rude.
: To my knowledge, most people who play and setup
: muds do it as a hobby. So to say "they should only be able to use
: Lost Souls if they get it going" reeks to me of "if you cant get it going
: yourself, get lost". An attitude I detest.
You detest the idea that I do not have time to support that lib? I
guess you could say I do to. But I also happen to think that everyone
being able to start up their own muds has been a really bad thing for
the mud world as it has led to tons of little useless go-nowhere
muds. For the sake of mudding, those people starting muds should have
some sort of clue before they go on.
: And now, after reading more of the posts in this thread, It appears to
: me like the whole thread is becoming a flame war for George. If
: people don't like what he has to say, or their knowledge of OO
: design, Java, CORBA is less than his, he jumps on their every word.
: It's like he wants to prove he is right that Java is the way to go. Well
: George, if you want to design a driver in Java, go do it. We're not
: paying you. It's your hobby.
You have misread this thread. Except for one other post and a few
occasional rude remarks from John, yours has been the only flame.
Basically, the above paragraph has no basis in fact.
The question is about LPMuds and their future. I am of the opinion
LPMuds have no future, that Java is the future of muds. You may or
may not agree, but it is a valid opinion and it is very much relevant
to the subject at hand.
: So much for the precious charter of this group. If these people were
: anyone else bar George, we'd have a thread telling them to read
: the charter. I mean, the first post was fine, ask a question, get the
: opinions. But this is now verging on the insane.
Can you please explain what this is based on?
: The point I was trying to make was this. If George wants to code a
: Java driver then fine. Is he going to support it ? If he's only going
: to use the driver for his own mud, then why bother asking our
: opinions in the first place?
I am not asking your opinions about any driver or mudlib. I have
attempted to start a serious thread of dicussion so as to raise the
amount of serious LPMud-related content in this newsgroup.
Thanks for bringing this thread down.
John Adelsberger
: Richard wrote in message ...
: >"Merlan" <sol...@indigo.ie> writes:
: I'm not too sure of what your saying here. It is my understanding that
: the reason for add_action is to add commands to the player when
: he/she encounters this object. It also my understanding that this is
: how it is done in all LPC muds. Feel free to correct me if I'm wrong.
You're wrong. There are at least two or three other systems out there.
: As for the second point Re: George and his opinions.. I have to say
: I find that attitude pretty hard to take. How did you learn to install
: drivers? Did'nt you ever ask questions? And now that you have the
: info, your not going to tell anyone else?
I learned the way I think everyone should learn; I became competent
enough in the general field of configuring, compiling, and installing
software that MudOS was 'just another package.' If you can't handle
this task without help, why do you think you can run a mud? By
comparison, installing a driver is easy.
: IMPHO, George's attitude sucks, I don't care how much he knows,
George, while he and I have our disagreements, certainly is not a man
with the time to hold the hand of every high school kid who thinks he
wants to run a mud. He is not an organization. He is one man, and
he isn't paid to do _anything_ related to muds. When I release the
Voxter, I intend to release it with a solid license, as is, no
support, no questions answered, use it or don't. I'm GIVING you
something. You have no claim on ME; the reverse WOULD be true, but
I'm giving up that claim. Get this straight: you are being given
something for free, and beggars can't be choosers.
: Let's say someone wants to start a mud. How do they get the info
: they require? The attitude I got from George is that if you don't know
: then you don't deserve to have a mud.. Now unless I'm vastly
: mistaken, owning or building a mud is not something you do or
: do not deserve. To my knowledge, most people who play and setup
: muds do it as a hobby. So to say "they should only be able to use
: Lost Souls if they get it going" reeks to me of "if you cant get it going
: yourself, get lost". An attitude I detest.
You may detest it, but it is the only attitude those of us who have real
lives have time for; if you can't learn what you need to know on your
own, either you're stupid or you're lazy. Sure, specialized knowledge
such as the functioning of weird efuns might make for good questions,
but if you can't install the driver, write LPC code, and debug problems,
you CANNOT run a mud, whether anyone wants to help you or not. You might
let someone ELSE run it FOR you, but that isn't the same thing.
: And now, after reading more of the posts in this thread, It appears to
: me like the whole thread is becoming a flame war for George. If
: people don't like what he has to say, or their knowledge of OO
: design, Java, CORBA is less than his, he jumps on their every word.
: It's like he wants to prove he is right that Java is the way to go.
I don't think there's enough momentum amongst serious developers who'll
commit time to the project to make a Java mud happen, but if George can
do it, why do you care?
: So much for the precious charter of this group. If these people were
: anyone else bar George, we'd have a thread telling them to read
: the charter. I mean, the first post was fine, ask a question, get the
: opinions. But this is now verging on the insane.
Hey, wanker, go read the charter:) Hehe...
: The point I was trying to make was this. If George wants to code a
: Java driver then fine. Is he going to support it ? If he's only going
: to use the driver for his own mud, then why bother asking our
: opinions in the first place?
What if he just releases it without support?
Johan Andersson
>
>While I have never used LPC for anything other than muds the C structure and
>requirements for writing code that other people may use and modify helped
>prepare me for "real" programming.
>
can be useful there is one even more important issue, one I did not realize
when I did mud-driver and mudlib development some 7-8 years ago. This did not
come until much later when I realised what I took for granted, was so alien to
some others that Bertrand Meyer compares it to 16th century man acknowledging
the earth circling around the sun and not the reverse.
The issue is Object-Oriented design and analysis.
Mr Meyer says: 'Ask not what the system does, ask what it does it to'. For a
MUD-programmer this comes naturally. Almost everything coded in a mud is an
object, not an abstract concept like a workflow process or some such, but a
very concrete axe, knife, shield, rose, beercan.
Programming in a mud domain promotes OO thinking. It does so in such a strong
way that for a mud programmer the old school of structured design, aka
top-down-functional-decomposition, seems just as ridiculous as the idea that
the earth is the center of the universe.
For all you mud-programmers out there, this might be your most valuable asset
when you go out for "real" programming :-)
/Johan
(aka Commander@Genesis)
--
________________________________________________________________________
| >>> The opinions herein are mine and not neccessarily my employers <<< |
| Johan Andersson, Msc CSE j...@carmenta.se |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lars Duning
> I believe socket bindings (in terms of writing socket code) to be an
> antiquated manner of communication. The distributed computing of RMI
> addition, it provides a degree of locational transparency of server
> objects that would be really hard to achieve with direct socket
> programming.
What kind of computation do you want to put into the client? And of
course this implies that the user is able to run the client code,
which is not guaranteed (not even with Java).
--
Lars Duening; la...@cableinet.co.uk (Home)
Lars Duning
> This point does not so much relate to the ease of Java v LPC, but it
> is an important point in discussing the ability of Java at least to
> mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
> it cannot by default be dynamically unloaded. There are VM's however
> staying away from proprietary VMs and change the manner in which
> development is done in LPMuds. In other words, give each developer a
> jar and let them work at home to develop.
Some of our better people know just enough to do small code tweaks
online, because it's so easy to do and because they can see the results
immediately. Forcing them to take a jar home would just scare them away.
And again, you imply that everybody has the ability to run the
development environment at home.
Lars Duning
> Programming in a mud domain promotes OO thinking. It does so in such a strong
> way that for a mud programmer the old school of structured design, aka
> top-down-functional-decomposition, seems just as ridiculous as the idea that
> the earth is the center of the universe.
>
> For all you mud-programmers out there, this might be your most valuable asset
> when you go out for "real" programming :-)
I second that. Writing code for a mud is one of the best ways to learn the
basics of OO programming.
Lars Duning
[ Lots of good points ]
> In conclusion I don't think LPC is dead yet, but without
> significant injections of highly quality energy it is certainly
> on the decline. If you have a good one running it's much easier
> to maintain and build on it than it is to switch. If you're looking
> to start from scratch then Java is one of the many reasonable
> alternatives available.
Personally, if I would want to start from 'scratch', I'd either
start with Pike as environment and go from there, or take one
of the existing LP drivers and improve that one (inclusive replacing
LPC with something better).
But I don't think that Java (neither the language nor the environment)
is the way to go, at least not in the long run. It has a couple of
nice ideas which should be kept, but all in all the language is not
_that_ good. Just a lot better than C as far as user-level applications
are concerned.
Merlan
George Reese wrote in message ...
>Merlan <sol...@indigo.ie> wrote:
>: I'm not too sure of what your saying here. It is my understanding that
>: the reason for add_action is to add commands to the player when
>: he/she encounters this object. It also my understanding that this is
>: how it is done in all LPC muds. Feel free to correct me if I'm wrong.
>
>This is not the case. Lima, Dead Souls, and later Nightmare muds all
>do not use add_action().
I stand corrected.
>: As for the second point Re: George and his opinions.. I have to say
>: I find that attitude pretty hard to take. How did you learn to install
>: drivers? Did'nt you ever ask questions? And now that you have the
>: info, your not going to tell anyone else?
>
>To install drivers? I read the directions.
What if those directions don't cover your version of linux? I go learn
linux before I can build a mud? As it turned out, the problem I was
having was to do with memory allocation, and the way it was
compiled.
>
>: IMPHO, George's attitude sucks, I don't care how much he knows,
>: what he did and did'nt code.
>
>Aha. No matter how much I give you, I still owe you more?
Untrue, you owe me nothing. What I was pointing out was
your attitude to me, was a "get lost" attitude.
>
>: It seems to me, that if you don't know
>: exactly what you want to ask, don't ask George. That's fine with
>: me.
>
>A person who does not know what they want to ask has a problem. I
>cannot possibly answer a question if you cannot ask it.
To get the right answers, you have to know the questions True. But
not everyone is sure of what the right question is.
>
>: I've been coding professionally for nearly 15 years, but it is
>: still my understanding that if someone leaves college and asks me
>: for information and I have it, I give it.
>
>What exactly are you referring to? My declaration that I will not
>support Dead Souls?
Exactly what I said above. Not everyone knows the exact problem,
therefore they do not necessarily know the right questions. Not
everyone is as up in installing drivers on an alien platform as you.
Dismissing them out of hand is rude. I'd sooner you politely told
me to go else where than shout "WHAT THE FUCK IS YOUR
QUESTION".
>
>: Let's say someone wants to start a mud. How do they get the info
>: they require?
>
>Rule number 1: You sure as hell better have had some experience
>coding on a mud. Otherwise, you have no business running one.
Agree.
>The info is in the FAQ. Then each of the drivers come with directions
>on how to install them. It is a really easy process and an inability
>to follow it should be taken as a sign you have no business running a
>mud.
The installation notes are fine, to a point. But there does come a stage
where someone tries to install it on some system that is not covered
in the documentation. If that person, me for example does not
know a lot about the system, then we're shagged.
>
>: Now unless I'm vastly
>: mistaken, owning or building a mud is not something you do or
>: do not deserve.
>
>Someone who hasn't the basic knowledge for starting a mud and who is
>not willing to get that knowledge except by having me do it for them
>is valuing THEIR time over MY time. And I find that terribly rude.
Ok.
>
>: To my knowledge, most people who play and setup
>: muds do it as a hobby. So to say "they should only be able to use
>: Lost Souls if they get it going" reeks to me of "if you cant get it going
>: yourself, get lost". An attitude I detest.
>
>You detest the idea that I do not have time to support that lib? I
>guess you could say I do to. But I also happen to think that everyone
>being able to start up their own muds has been a really bad thing for
>the mud world as it has led to tons of little useless go-nowhere
>muds.
Whats wrong with people trying? Is it all not just a hobby?
>: And now, after reading more of the posts in this thread, It appears to
>: me like the whole thread is becoming a flame war for George. If
>: people don't like what he has to say, or their knowledge of OO
>: design, Java, CORBA is less than his, he jumps on their every word.
>: It's like he wants to prove he is right that Java is the way to go. Well
>: George, if you want to design a driver in Java, go do it. We're not
>: paying you. It's your hobby.
>
>You have misread this thread. Except for one other post and a few
>occasional rude remarks from John, yours has been the only flame.
>Basically, the above paragraph has no basis in fact.
If you consider my opinion a flame, even if it misguided in parts then
you are wrong. I replied to someone agreeing with your opinion, an
opinion I disagree with.
<**>
A war of words regarding CORBA, JAVA, OO and such in something
like 12 posts is relevant to LPC only in that it started out in context. It
now appears to me to be a OO and IT design and implementation
discussion rather than LPC. The point was, a few weeks ago,
someone asked about their LPC mud status and received something
over 20 posts telling them to read the charter.
>
>The question is about LPMuds and their future. I am of the opinion
>LPMuds have no future, that Java is the future of muds. You may or
>may not agree, but it is a valid opinion and it is very much relevant
>to the subject at hand.
As long as there are LPMud drivers available, people will use/attempt
to use them. Therefore it is not dead. I personally think the future
of LPMuds has nothing to do with Java, CORBA, C, or any
other language. I think that if you do write a Java driver and
people use it, and find it better than MudOS or some other driver
then the issue has a solid fountation.
I have no doubt that you know how, and could/can design and
code a Java driver. I also respect that you have such knowledge
to hand. It's a bit like the release of Delphi a few years back,
most journalists were of the opinion that Visual Basic 3 as it was
then was finished as an RAD system. How wrong they were.
I would guess that VB is by far a more popular system for
development, in the same way I think LPC is at the present
a far easier system to design muds in than a Java driver which
is not here yet. If you code and design one, then we shall see.
>
>: So much for the precious charter of this group. If these people were
>: anyone else bar George, we'd have a thread telling them to read
>: the charter. I mean, the first post was fine, ask a question, get the
>: opinions. But this is now verging on the insane.
>
>Can you please explain what this is based on?
See: <**> I know it says in the charter that you not "supposed" to
ask about the status of muds. And, I agree with the reasons
presented. Stating an opinion and asking for feedback is allowed.
But when that feedback turns into a debate of double figure posts
for just 2 people, and 90% of the discussion is about information
technology advances, OO design issues, CORBA, RMI, etc etc
I wonder should the discussion not be in some other group.
The groups is called rec.games.mud.lp not rec.games.mud.java
or rec.games.mud.CORBA.
If this is how it continues, then it appears it will be fine for me to
post a note entitled "Are LPMuds Dead? Is DIKU the way
to go?" Then we'll have every DIKU fan posting here too.
>Thanks for bringing this thread down.
If your opinion is that me saying my opinion rightly or wrongly is
"bringing this thread down" then I think you are mistaken.
It was never my intention to bring anything down. Rather I was
saying _my_ opinion. If you don't like then I accept that. Everyone
reading this newsgroup's topics is entitled to their opinion.
Finally, my apologies if it appears my past post was a flame, it
was not meant to be.
Merlan
Thomas Lundquist
> This point does not so much relate to the ease of Java v LPC, but it
> is an important point in discussing the ability of Java at least to
> mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
> it cannot by default be dynamically unloaded. There are VM's however
> that do support dynamic unloading. I personally would recommend
> staying away from proprietary VMs and change the manner in which
> development is done in LPMuds. In other words, give each developer a
> jar and let them work at home to develop.
sounds like Lisp may be an option.
at least Allegro Common Lisp has dynamic loading and unloading.
B.
--
Baldrick@Final Realms.
telnet://fr.imaginary.com:4001/
http://fr.imaginary.com/
George Reese
: George Reese wrote:
:> I believe socket bindings (in terms of writing socket code) to be an
:> antiquated manner of communication. The distributed computing of RMI
:> addition, it provides a degree of locational transparency of server
:> objects that would be really hard to achieve with direct socket
:> programming.
: What kind of computation do you want to put into the client? And of
: course this implies that the user is able to run the client code,
: which is not guaranteed (not even with Java).
As things stand today, I would use a minimal applet for a user
interface and even support telnet and mud clients. I would design it
to support the overall direction I am talking about so it is easy to
migrate where I am talking about when the client VM's are up to the task.
As to what kind of processing I would do, I would start with a focus
on UI issues. Then I would provide support for JavaSpaces, thus
allowing any computation intensive work to be picked off by clients
for processing. In my experience though, there is not a lot of mud
processing that falls into this category.
George Reese
:> is an important point in discussing the ability of Java at least to
:> mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
:> it cannot by default be dynamically unloaded. There are VM's however
:> that do support dynamic unloading. I personally would recommend
:> staying away from proprietary VMs and change the manner in which
:> development is done in LPMuds. In other words, give each developer a
:> jar and let them work at home to develop.
: Some of our better people know just enough to do small code tweaks
: online, because it's so easy to do and because they can see the results
: immediately. Forcing them to take a jar home would just scare them away.
: And again, you imply that everybody has the ability to run the
: development environment at home.
Pretty much everyone on the Internet does. You don't need a good
browser to run it. Just *some* VM. And forcing them to take a jar
home would scare them away only because that is not the way they are
used to doing it. Remember, getting the jar and doing uploads but
developing at home can in fact be made to look almost as if it were
online and also be done entirely transparently. The only problem is
that once you upload your changes, they will not take place until the
next reboot.
In fact, I would not even recommend that model. I would recommend all
changes be uploaded to a test mud where they await some sort of QC
process which then migrates changes to the production mud on a regular
basis.
George Reese
: Geoff Wong wrote:
: [ Lots of good points ]
If you don't like the syntax, use JPython. The point is not the
language, but the tools that come with the language.
George Reese
: George Reese wrote in message ...
:>Merlan <sol...@indigo.ie> wrote:
:>: As for the second point Re: George and his opinions.. I have to say
:>: I find that attitude pretty hard to take. How did you learn to install
:>: drivers? Did'nt you ever ask questions? And now that you have the
:>: info, your not going to tell anyone else?
:>
:>To install drivers? I read the directions.
: What if those directions don't cover your version of linux? I go learn
: linux before I can build a mud? As it turned out, the problem I was
: having was to do with memory allocation, and the way it was
: compiled.
First, yes, you should know your OS.
Second, asking questions about a compile for a specific platform when
those questions are not covered by the installation document is fine
so long as the product is supported. And none of that has anything to
do with me since I do not support the driver anyways.
:>
:>: IMPHO, George's attitude sucks, I don't care how much he knows,
:>: what he did and did'nt code.
:>
:>Aha. No matter how much I give you, I still owe you more?
: Untrue, you owe me nothing. What I was pointing out was
: your attitude to me, was a "get lost" attitude.
When the README for Dead Souls says don't ask me questions, I think
the 'get lost' attitude is quite appropriate. Anyone who would ask me
questions about Dead Souls is an asshole either because a) they did
not read the directions or b) they chose to ignore the directions.
:>: It seems to me, that if you don't know
:>: exactly what you want to ask, don't ask George. That's fine with
:>: me.
:>
:>A person who does not know what they want to ask has a problem. I
:>cannot possibly answer a question if you cannot ask it.
: To get the right answers, you have to know the questions True. But
: not everyone is sure of what the right question is.
Then they are not yet qualified to run a mud.
:>: I've been coding professionally for nearly 15 years, but it is
:>: still my understanding that if someone leaves college and asks me
:>: for information and I have it, I give it.
:>
:>What exactly are you referring to? My declaration that I will not
:>support Dead Souls?
: Exactly what I said above. Not everyone knows the exact problem,
: therefore they do not necessarily know the right questions. Not
: everyone is as up in installing drivers on an alien platform as you.
: Dismissing them out of hand is rude. I'd sooner you politely told
: me to go else where than shout "WHAT THE FUCK IS YOUR
: QUESTION".
This is a poorly worded critique. I am certain I have never responded
to someone with "WHAT THE FUCK IS YOUR QUESTION" unless it was for a
good reason. Since you provide no context, it is impossible to judge
what you are talking about. The above would be a proper response for
some situations. Politely telling someone to go soomewhere else would
be proper for others.
:>The info is in the FAQ. Then each of the drivers come with directions
:>on how to install them. It is a really easy process and an inability
:>to follow it should be taken as a sign you have no business running a
:>mud.
: The installation notes are fine, to a point. But there does come a stage
: where someone tries to install it on some system that is not covered
: in the documentation. If that person, me for example does not
: know a lot about the system, then we're shagged.
I already covered this situation above. That is not a question that
me or any other of the more senior mud people worry about. It is more
along the lines of questions like "I downloaded MudOS and typed make
but it did not compile." Those people should be shot. Why? Because
they did not read the directions.
:>: To my knowledge, most people who play and setup
:>: muds do it as a hobby. So to say "they should only be able to use
:>: Lost Souls if they get it going" reeks to me of "if you cant get it going
:>: yourself, get lost". An attitude I detest.
:>
:>You detest the idea that I do not have time to support that lib? I
:>guess you could say I do to. But I also happen to think that everyone
:>being able to start up their own muds has been a really bad thing for
:>the mud world as it has led to tons of little useless go-nowhere
:>muds.
: Whats wrong with people trying? Is it all not just a hobby?
Because if everyone is running their own muds, there is no one to play
on or build on muds.
:>: And now, after reading more of the posts in this thread, It appears to
:>: me like the whole thread is becoming a flame war for George. If
:>: people don't like what he has to say, or their knowledge of OO
:>: design, Java, CORBA is less than his, he jumps on their every word.
:>: It's like he wants to prove he is right that Java is the way to go. Well
:>: George, if you want to design a driver in Java, go do it. We're not
:>: paying you. It's your hobby.
:>
:>You have misread this thread. Except for one other post and a few
:>occasional rude remarks from John, yours has been the only flame.
:>Basically, the above paragraph has no basis in fact.
: If you consider my opinion a flame, even if it misguided in parts then
: you are wrong. I replied to someone agreeing with your opinion, an
: opinion I disagree with.
No, I consider your personal attacks a flame.
: <**>
: A war of words regarding CORBA, JAVA, OO and such in something
: like 12 posts is relevant to LPC only in that it started out in context. It
: now appears to me to be a OO and IT design and implementation
: discussion rather than LPC. The point was, a few weeks ago,
: someone asked about their LPC mud status and received something
: over 20 posts telling them to read the charter.
You need to go read the charter. The former discussion belongs in
this newsgroup. The latter does not.
:>: So much for the precious charter of this group. If these people were
:>: anyone else bar George, we'd have a thread telling them to read
:>: the charter. I mean, the first post was fine, ask a question, get the
:>: opinions. But this is now verging on the insane.
:>
:>Can you please explain what this is based on?
: See: <**> I know it says in the charter that you not "supposed" to
: ask about the status of muds. And, I agree with the reasons
: presented. Stating an opinion and asking for feedback is allowed.
: But when that feedback turns into a debate of double figure posts
: for just 2 people, and 90% of the discussion is about information
: technology advances, OO design issues, CORBA, RMI, etc etc
: I wonder should the discussion not be in some other group.
: The groups is called rec.games.mud.lp not rec.games.mud.java
: or rec.games.mud.CORBA.
You are wrong. This discussion belongs in this newsgroup.
:>Thanks for bringing this thread down.
: If your opinion is that me saying my opinion rightly or wrongly is
: "bringing this thread down" then I think you are mistaken.
: It was never my intention to bring anything down. Rather I was
: saying _my_ opinion. If you don't like then I accept that. Everyone
: reading this newsgroup's topics is entitled to their opinion.
: Finally, my apologies if it appears my past post was a flame, it
: was not meant to be.
By bringing it to the level of personal attacks, yes, you did bring it
George Reese
: George Reese <bo...@imaginary.com> writes:
:> This point does not so much relate to the ease of Java v LPC, but it
:> is an important point in discussing the ability of Java at least to
:> mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
:> it cannot by default be dynamically unloaded. There are VM's however
:> that do support dynamic unloading. I personally would recommend
:> staying away from proprietary VMs and change the manner in which
:> development is done in LPMuds. In other words, give each developer a
:> jar and let them work at home to develop.
: sounds like Lisp may be an option.
: at least Allegro Common Lisp has dynamic loading and unloading.
What else does it have that would make it useful for mud programming?
Tim Blommerde
This thread has been going on for quite a while now and lot of interesting
points have been raised along a lot of less interesting things. But the
general attitude, if I may be so bold, is to say that LPmuds aren't dead,
but that the current state of the major LP drivers hasn't grown with the
demand of modern mudder/mudcoder and the possibilities of the present-day
internet. Mr. George Reese raises a good idea and one that's been heard for
a while now throughout the whole mud society. Java is, though everybody is
ofcourse entitled to their own opinion, probably the coding language of the
future, even though it's still in its childhood. Therefore coding a mud
driver and the corresponding tools in java is indeed a good idea, long as
that may take.
A java coded mud driver though would probably not be a new LP mud, but just
a new mud driver (GR - mud ??). So in my humble opinion, java ain't the
future for lpmuds, but maybe a new, more modern, way for coding muds. Why
code a java mud driver and go through a lot of trouble emulating LPC,
instead of just let the wizards on such a mud code in java (or GRjava). So,
if all you lpmud freaks out there really wanne advance the lpmud drivers to
another level, and give them a more modern style and possibilities, it might
be wise to start thinking on what would be necessary in such a new
generation of lpmud drivers.
No offence meant, but a lot of posts in this thread have quite an unfriendly
tone in it and shouldn't we lpmudders atleast stick together instead of
slating eachother? We live in a democratic world, atleast the internet
should be like that, so everybody is entitled to his/her own opinion. If
such a opinion is based on wrong facts, according to you, please enlighten
the writer, but this can/should be done in a friendly way, instead of
telling him/her he/she is stupid and shouldn't post notes with such
ignorence. So instead of picking on people, you might take interest in
his/her opinion and start thinking about it yourself. I myself am not
really interested in a java mud driver, but Mr. George Reese's post and a
lot of posts by him and Mr. John Adelsberger have some good ideas in it and
might be a good foundation to start thinking on creating a next generation
lpmud drivers. So, my question to you all is:
"Wouldn't if be nice to start thinking and raising ideas for a next
generation lpmud drivers ?"
Instead of a sole person responsible for every branch of lpmud driver, we
might try and get a team of people together to (re)code a new lpmud driver
that lives up to the modern standards and has everything a mud coder could
wish for, but still being compatible with the former drivers, so current
muds shouldn't have too much trouble retweaking their lib to such a new
driver if it is finished.
Thanks for the reading and hope to hear from you all soon,
Tim Blommerde,
aka Puck Al'Rakham
aka Arvhatté, Sage of Dragg'ba, the Realms of the silvery mists
(http://elektron.et.tudelft.nl/~blom)
Ps. As I stated in a previous post. For those interested in a more modern
lpmud driver than the current major drivers, check out DGD.
Tim Blommerde
The Wildman
If anyone asks where I went, I'm going to Hell. I hear the skiing is going
to be GREAT!
Merlan, you blew it.
--
The Wildman
PLEASE do NOT reply to this post! If you MUST email me, please use wildman at
microserve dot net, but a followup is preferred. If you DO reply to the
wrong address, I'll still read it but don't expect a reply. Unless you are a
spammer, in which case I will reply to your ISP.
Fight spam - http://www.cauce.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/MU d- s: a- C++ UL+ P+ L+++ !E W-- N+++ o !K w--- !O !M V-- PS PE Y+ PGP?
t+ 5+ X R tv b++ DI+ D++ G e h---- r++++ y++++
------END GEEK CODE BLOCK------
Lars Duning
> :> is an important point in discussing the ability of Java at least to
> :> mimic LPMud behaviour. Yes, Java code can be dynamically loaded, but
> :> it cannot by default be dynamically unloaded. There are VM's however
> :> that do support dynamic unloading. I personally would recommend
> :> staying away from proprietary VMs and change the manner in which
> :> development is done in LPMuds. In other words, give each developer a
> :> jar and let them work at home to develop.
>
> : online, because it's so easy to do and because they can see the results
> : immediately. Forcing them to take a jar home would just scare them away.
>
> : And again, you imply that everybody has the ability to run the
> : development environment at home.
>
> Pretty much everyone on the Internet does. You don't need a good
> browser to run it. Just *some* VM.
Well, there is no VM for my machine. Maybe in the future, but I don't
count on it.
> And forcing them to take a jar home would scare them away only
> because that is not the way they are used to doing it.
You missed the point: I am talking about the non-geeks, for which a jar
is something to store jam in. Changing code online is not much
different from playing - downloading jars, compiler, runtime
environment, editor, learning to use them, upload your changes again
is very different.
And besides: considering from how many locations I log into my main
mud, I am glad that I can edit code online. It is one of the biggest
assets of LPMud.
> The only problem is that once you upload your changes, they will
> not take place until the next reboot.
Which in my opinion is a big step backwards.
Lars Duning
> : But I don't think that Java (neither the language nor the environment)
> : is the way to go, at least not in the long run. It has a couple of
> : nice ideas which should be kept, but all in all the language is not
> : _that_ good. Just a lot better than C as far as user-level applications
> : are concerned.
>
> If you don't like the syntax, use JPython. The point is not the
> language, but the tools that come with the language.
If these tools also work for other source languages but Java.
But leave the arena at this point: I simply don't know enough (good)
tools for Java, especially none which would be useful in a Mud
environment.
The Wildman
>What if those directions don't cover your version of linux? I go learn
>linux before I can build a mud? As it turned out, the problem I was
>having was to do with memory allocation, and the way it was
>compiled.
If you can't be bothered to learn the OS you will be using, how can you
expect to deal with the issues that come up regarding your OS and how the
driver interacts with it? What would you do if you discovered a memory leak?
How would you even go about fixing it?
>Exactly what I said above. Not everyone knows the exact problem,
>therefore they do not necessarily know the right questions. Not
>everyone is as up in installing drivers on an alien platform as you.
I can't speak for others, but I have never installed any software on an
alien platform - I have the sense to learn the OS first. I had Linux two
months before installed anything that needed compiling and configuring.
>The installation notes are fine, to a point. But there does come a stage
>where someone tries to install it on some system that is not covered
>in the documentation. If that person, me for example does not
>know a lot about the system, then we're shagged.
Part of the idea of distributing source code is so that the end user can
port the software to their particular system. If that person does not know
enough about their system to do this, it is their own fault.
>Whats wrong with people trying? Is it all not just a hobby?
Running a MUD is a pseudo-hobby. You do it for your own personal enjoyment,
but it isn't very enjoyable when you have no players because:
Bob asked you for help because he couldn't be bothered to learn on his own;
You taught Bob everything;
Bob couldn't be bothered to develop a quality MUD;
New players go to Bob's MUD, thinks it is representative of all MUDs, and
give up mudding because Bob's MUD sucks
>If this is how it continues, then it appears it will be fine for me to
>post a note entitled "Are LPMuds Dead? Is DIKU the way
>to go?" Then we'll have every DIKU fan posting here too.
Well, that will only be a problem if you crosspost to r.g.m.diku. Then it's
trolling and you will hit the bottom of many killfiles.
George Reese
: Well, there is no VM for my machine. Maybe in the future, but I don't
: count on it.
I hate to say it, but you are such a vast majority I would be willing
to discount you.
:> And forcing them to take a jar home would scare them away only
:> because that is not the way they are used to doing it.
: You missed the point: I am talking about the non-geeks, for which a jar
: is something to store jam in. Changing code online is not much
: different from playing - downloading jars, compiler, runtime
: environment, editor, learning to use them, upload your changes again
: is very different.
: And besides: considering from how many locations I log into my main
: mud, I am glad that I can edit code online. It is one of the biggest
: assets of LPMud.
You are missing the point of what I am saying--to the end user, it is
no different from coding online. They do not download the jar--it
just happens automatically. They do not upload changes, it happens
automatically. No matter what you do, however, you cannot get around
the need to learn the editor.
:> The only problem is that once you upload your changes, they will
:> not take place until the next reboot.
: Which in my opinion is a big step backwards.
I think it is a big step forwards :) I suppose we can just disagree
on that.
George Reese
Well, I had mentioned the APIs. But in terms of the tools, using
JBuilder instead of ed, I think, would rock.
Stig Hemmer
> Thomas Lundquist <er...@zelow.no> wrote:
> : sounds like Lisp may be an option.
> : at least Allegro Common Lisp has dynamic loading and unloading.
> What else does it have that would make it useful for mud programming?
Common Lisp + CL Object System(CLOS) has:
A flexible object model.
Easy syntax.
Function objects/closures.
Native code compilers.
Libraries for lots and lots of stuff.
It lacks security though. CL/CLOS is _very_ open. Adding security
would mean fiddling with the basic language definition and would
probably mean a lot of work.
On the other hand, one can easily write a Lisp interpreter in Lisp,
and this second-lever interpreter could have all the security you
want. With a bit of ingenuity I guess you could also compile the
second-level code. (Essentially by picking the code apart to see if
it consists of 'allowed' operations before giving it to the
first-level system)
Stig Hemmer,
Jack of a Few Trades.
George Reese
: A java coded mud driver though would probably not be a new LP mud, but just
: a new mud driver (GR - mud ??). So in my humble opinion, java ain't the
: future for lpmuds, but maybe a new, more modern, way for coding
: muds.
A JavaMud would naturally not be an LPMud since the defining property
of LPMud is the base language, LPC. My thesis is not that Java is
the future of LPs, but that LPs have come to the end of what they will
be capable of doing.
: lpmud drivers. So, my question to you all is:
: "Wouldn't if be nice to start thinking and raising ideas for a next
: generation lpmud drivers ?"
Some ideas have been put forth. I am of the opinion that they are not
worth the time in the face of the advancement of Java in the mud
world. Even still, in the last two years, people have mostly not
bothered implementing any driver advancements along the lines that
have been discussed.
Thomas Lundquist
> : at least Allegro Common Lisp has dynamic loading and unloading.
>
> What else does it have that would make it useful for mud programming?
not too sure yet, since I haven't started programming Lisp. just had a
discussion off-net with some Lips programmers.
the OO sounds good, dynamic loading, dynamic typing.
I'll be happy to tell you my experience with it, in a year.. :=)
Holly Sommer
Does George Reese have a job, and if so, how fast does
he type? (OK, two things).
To answer the question of the subject line:
I hope not, I'm just getting started with them!
-Holly
George Reese
: This whole thread has me wondering one thing:
: Does George Reese have a job, and if so, how fast does
: he type? (OK, two things).
Yes, I have a job and I have no idea how fast I type.
John Adelsberger
: John Adelsberger <j...@umr.edu> wrote:
: : George Reese <bo...@imaginary.com> wrote:
: : : John Adelsberger <j...@umr.edu> wrote:
: : : r: George Reese <bo...@imaginary.com> wrote:
: You misunderstand what I was getting at. By making the assumption of
: Java and choosing RMI, you are choosing a single paradigm in which to
: do both distributed and non-distributed computing. By choosing
: language independence and choosing CORBA, you are actually choosing
: two paradigms-one for distributed computing and one for
: non-distributed computing.
This, for the moment, is unfortunately true.
: : Multi-threading - done the way Java does it, this is a hindrance. It
: : adds too much complexity for most mud developers to handle.
: If you expect mud developers to manage the threading issues. I would
: assume that a good lib would hide this stuff. But this is not even
: possible with LPC as it is now.
I question whether it is possible to do this completely; it requires
keeping all data and references to data which might ever be changed by
_any_ of the multithreaded parts of the lib away from the parts of the
lib in which this complexity is hidden, which essentially means you're
going to disallow doing anything interesting without knowledge of locks.
All the things which are worthwhile to thread are things that need some
degree of exposure...(timers, etc.)
: Actually, it seems a lot of people are interested in the idea.
: Furthermore, wouldn't it be nice to be able to point your new creators
: to the book store to get them started on area building instead of
: holding their hands?
I question whether they'd be able to do much without further help or
documentation. My reasons are these:
1) I've yet to see a good book on Java written for nontechnical people
who don't yet know how to program.
2) Even if there is one, it won't tell them what has to be done IN the
language to produce an area, an npc, and so on.
3) Coding style is usually poorly taught by books, no matter how they try.
As such, you'd need, at a _minimum,_ two other documents. One on coding
style, which you'd also have to coach people on(much like grammar, you
give them rules, but do they follow them?) and one on the interface you've
provided for mud entity creation of various sorts. You'd also want some
sample code. Given that there are LPC tutorials(you wrote a set, for one:)
I question whether there's any real difference here; the reason peoples'
hands get held isn't that they NEED it, but because it is easier and most
people are fairly lazy.
: First off all, just because you may not use some of those libraries
: does not mean that the wide availability of libraries (and greater
: stability thereof) is not a bonus.
Whether I'd use _any_ of them is in question, but if I did, then you'd
be right.
: In fact, I imagine you could come up with some uses for an SSL library.
Good ones? Not unless I decided to go commercial. There's just no need
to secure a free game from outside snooping. I could come up with a good
use for a better authentication scheme than we presently use in the mud
world, but SSL isn't it.
: Finally, SSL is not one of the
: things that comes with the Java Platform.
I thought we were talking about the variety of stuff _available_ for the
platform. If you just mean things included, that isn't nearly so much,
nor is it nearly so interesting.
: At any rate, one would think the fact that a lot of corporate
: development is going into Java is certainly an advantage over LPC.
By this logic, we should all be running muds on Windows 98. Corporate
development is no sign of suitability to any given task.
: : Yeah, except that the so-called GUI strengths don't exist(nothing looks
: : the same on two different platforms in Java,)
: This is definitely a weakness of Java. It is going to take time to
: get it right. It is not a trivial problem to solve.
Odd, then, that, assuming you're using real tools, X looks the same on
everything from Sun workstations to Amigas. Sure, it has a bit more
history, but not _much_ more, and for most of that history, it was
developed by a handful of people working for universities and small
computer companies. Java is, counting the prerelease time, around
six years old now(it was called Oak at one time; don't let them fool
you) which gives it about half the age of X(a bit less, I think, but
not much) and it isn't even CLOSE despite the fact that X was never
meant to run on anything BUT Unixish machines and Java was bragged
about as the run-anywhere GUI language of the future from the
_beginning._ My conclusion is that they tried, got it _wrong,_ and
now have to hack the right solution on top.
: You are still comparing apples and oranges. CORBA has been around for
: years and has had the time to mature. It has failed because it is way
: too complex a specification.
CORBA hasn't really been usable until the last couple of years. In
addition, the M$ DCOM strategy has been 'derail CORBA' from the
beginning, for no better reason than that M$ knows they can't control
CORBA. The upshot of these two is that until recently, there just
wasn't much momentum behind it. Now, however, with everyone BUT
M$ realizing that yes, DCOM really does bite as much ass as it appears
to and the only real alternative is CORBA, I think you'll see the
rate of corporate development increase quite a bit. DCOM+ is supposed
to be all things to all people, but already it is being panned by the
people who were supposed to love it... and the current corp efforts are
almost _all_ aimed at security and interoperability.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
John Adelsberger
: Plenty of similar alternatives exist (including Inferno, Erlang,
Actually, this is an excellent point. Everything Java has, Inferno has
more of, better, and usually faster... hehe.
: In conclusion I don't think LPC is dead yet, but without
: significant injections of highly quality energy it is certainly
: on the decline. If you have a good one running it's much easier
: to maintain and build on it than it is to switch. If you're looking
: to start from scratch then Java is one of the many reasonable
: alternatives available.
I think that the suggestions(recently) of adding a distribution
mechanism(not as hard as it sounds, but it would take time) and
OpenGL bindings to MudOS are quite good; there are a few other
minor issues that would be nice to address, some of which would
very quickly lead to a significant performance advantage over
most other alternatives on good hardware(thread out the compiler,
in particular,) and some of which would just make good lib
design easier and less kludgy(the IO interface could use a bit
of work.) It would be nice to improve the type system a bit,
but I question the feasibility of this project while retaining
any kind of backwards compatibility. One thing that _could_
be added(you can simulate it in LPC anyway, but much nicer to
have it as a language feature) is object aspects, aka(for the C++
lusers:) pure virtual classes:) Having these explicitly allows
for a really nifty way of getting around the lack of object
typing...(we already simulate this, using inheritance tests, but
it just isn't the same...)
John Adelsberger
: George Reese wrote in message ...
: What if those directions don't cover your version of linux? I go learn
: linux before I can build a mud? As it turned out, the problem I was
: having was to do with memory allocation, and the way it was
: compiled.
If you don't know your operating system well enough to install software,
you cannot run a mud. Period. Not with help, not without help, not if
little green men put implants in your head. End of story.
: The installation notes are fine, to a point. But there does come a stage
: where someone tries to install it on some system that is not covered
: in the documentation. If that person, me for example does not
: know a lot about the system, then we're shagged.
You are correct, sir. This, however, is a personal problem.
: Whats wrong with people trying? Is it all not just a hobby?
Nothing wrong with trying. Expecting other people to support your
experiments? That's different.
: As long as there are LPMud drivers available, people will use/attempt
: to use them. Therefore it is not dead. I personally think the future
: of LPMuds has nothing to do with Java, CORBA, C, or any
CORBA isn't a language. CORBA is an object distribution mechanism. It
or something similar is vital if LPC is to continue as a viable mud
platform. Since obviously M$ specific crap such as DCOM isn't
appropriate, and since the only alternatives to CORBA that exist other
than that are language specific, this boils down to 'CORBA or a
homebrew.' The argument(an old one) about CORBA is over this choice,
with me supporting an existing standard. It is muddled somewhat by
the new discussion, which involves Java, and to which the appropriate
conclusion does in fact appear to be: if you write it, we'll look, but
what else is there to say?
t...@wfn-shop.princeton.edu
In article <6uin7n$eig$1...@news.indigo.ie>, "Merlan" <sol...@indigo.ie> writes:
>
> - Sites. Now more than ever, if you want to host a mud, you need to
> pay more for the site. Back in the early life of muds, sites were a lot
> more easily come by. You could put it on your college server and such.
> Now with the net revolution in full swing, colleges cant afford the
> space,
> and the bandwidth it all requires. So people are forced to pay for their
> site. Age would probably be an important factor here too. Most of the
> mud population are school/college going people. They can not afford
> to host muds on pay sites.
This one is completely backwards. The price of the hardware needed to run
a decent sized MUD has dropped to a few thousand dollars; previously you
needed to convince a university to use the spare cycles of one of their
workstations.
> - Speed. Again the net revolution, although great for a multitude of
> purposes, it is all getting very slow. Too often the muds I once played
> are now so lagged they are becomming unplayable. Lets face it, if
> you play muds to advance in level, it is not nice to be killing a big
> monstie, suddenly to see your screen freeze, to come back in 3 minutes
> and see yourself in the deat sequence. Again, this goes back to sites.
> How many can afford the charges for a fast site?
The young'uns these days! When I started playing MUDs, we *dreamed* of
sites that occasionally only froze for 3 minutes! :-)
---------------------------------------------------------------------------
Tim Hollebeek | "Everything above is a true
email: t...@wfn-shop.princeton.edu | statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim | false values of true."
t...@wfn-shop.princeton.edu
In article <6uljpu$aaj$1...@emu.cs.rmit.edu.au>, Geoff Wong <ge...@cs.eatspam.rmit.edu.au> writes:
It is a much tougher technical problem than it appears (in fact, I
looked into it, hmm, 4 years ago now?). The VMs have very few
similarities. LPC VM's are way off on the CISCish end, while JVMs are
very RISCish. In fact, the JVM opcodes look very much like generic
platform independent RISC opcodes. The LPC opcodes look like high
level LPC constructs. For example, something like a foreach loop, or
constructing a function pointer, or *any* addition (mapping, array,
etc) are all single opcodes.
This means that a LPC->JVM compiler would have to implement a
substantial fraction of the LPC driver in Java as a "support" library
for the generated JVM code. The effort that much different from
implementing a similar Java-based MUD server.
> Java provides in-language support for handling concurrency.
> LPC does not; here Java is technically superior.
For MUDs, I actually consider this an inferiority. Unless you are
trying to leverage the capabilities of a multiple CPU machine, which
is really overkill for even fairly decent sized MUDs, you don't gain
anything.
George Reese
: : assume that a good lib would hide this stuff. But this is not even
: : possible with LPC as it is now.
: I question whether it is possible to do this completely; it requires
: keeping all data and references to data which might ever be changed by
: _any_ of the multithreaded parts of the lib away from the parts of the
: lib in which this complexity is hidden, which essentially means you're
: going to disallow doing anything interesting without knowledge of locks.
: All the things which are worthwhile to thread are things that need some
: degree of exposure...(timers, etc.)
I do think it is possible, but as Ellery said to me in private, it is
kinda a cheat. Nevertheless, it is all blowing smoke until I actually
do it.
: : Actually, it seems a lot of people are interested in the idea.
: : Furthermore, wouldn't it be nice to be able to point your new creators
: : to the book store to get them started on area building instead of
: : holding their hands?
: I question whether they'd be able to do much without further help or
: documentation. My reasons are these:
: 1) I've yet to see a good book on Java written for nontechnical people
: who don't yet know how to program.
: 2) Even if there is one, it won't tell them what has to be done IN the
: language to produce an area, an npc, and so on.
: 3) Coding style is usually poorly taught by books, no matter how they try.
: As such, you'd need, at a _minimum,_ two other documents. One on coding
: style, which you'd also have to coach people on(much like grammar, you
: give them rules, but do they follow them?) and one on the interface you've
: provided for mud entity creation of various sorts. You'd also want some
: sample code. Given that there are LPC tutorials(you wrote a set, for one:)
: I question whether there's any real difference here; the reason peoples'
: hands get held isn't that they NEED it, but because it is easier and most
: people are fairly lazy.
I think "Exploring Java" or "Just Java" are so infinitely better texts
than my LPC manuals. For LPC or Java, there is no getting around the
need for documentation specific to your code base. But you also need
basic language documentation and I think Java has LPC hands down on
that count. And, since I am the author of the most widely used LPC
documents, I am either being extremely modest (rather unlikely) or
brutally honest.
: : In fact, I imagine you could come up with some uses for an SSL library.
: Good ones? Not unless I decided to go commercial. There's just no need
: to secure a free game from outside snooping. I could come up with a good
: use for a better authentication scheme than we presently use in the mud
: world, but SSL isn't it.
I guess I do not limit the mud server concept to simply playing games
which is why I think SSL support is a good thing. It is certainly not
the most important thing. Probably not even a mildly important
thing. But since there is a potential use for it in a mud world,
having that support is good.
I guess that gets to my point. There are tons of things you might add
to a mud if the support were there already but that you would not
bother with coding the support for if you had to do it yourself.
Using Java or any other widely supported language takes the burden off
of doing yourself.
: : Finally, SSL is not one of the
: : things that comes with the Java Platform.
: I thought we were talking about the variety of stuff _available_ for the
: platform. If you just mean things included, that isn't nearly so much,
: nor is it nearly so interesting.
It is actually quite a bit. Tkae internationalization, for instance.
I think the lack of internationalization for LPMuds really sucks.
With Java, you get it for free.
: : At any rate, one would think the fact that a lot of corporate
: : development is going into Java is certainly an advantage over LPC.
: By this logic, we should all be running muds on Windows 98. Corporate
: development is no sign of suitability to any given task.
Corporate development "is certainly an advantage". It is not a
determining factor. I have not perceived any disagreement on whether
Java or LPC are suitable for developing muds in. I think it would be
odd to try and argue Java is not suitable for muds. Given that it is
suitable, corporate support is an argument in its favour.
: : : Yeah, except that the so-called GUI strengths don't exist(nothing looks
: : : the same on two different platforms in Java,)
: : This is definitely a weakness of Java. It is going to take time to
: : get it right. It is not a trivial problem to solve.
: Odd, then, that, assuming you're using real tools, X looks the same on
: everything from Sun workstations to Amigas. Sure, it has a bit more
: history, but not _much_ more, and for most of that history, it was
: developed by a handful of people working for universities and small
: computer companies. Java is, counting the prerelease time, around
: six years old now(it was called Oak at one time; don't let them fool
: you) which gives it about half the age of X(a bit less, I think, but
: not much) and it isn't even CLOSE despite the fact that X was never
: meant to run on anything BUT Unixish machines and Java was bragged
: about as the run-anywhere GUI language of the future from the
: _beginning._ My conclusion is that they tried, got it _wrong,_ and
: now have to hack the right solution on top.
They tried, and Netscape screwed everything up. They are getting it
right this time. Swing rocks.
The Wildman
>Holly Sommer <hso...@micro.ti.com> wrote:
>: This whole thread has me wondering one thing:
>
>: Does George Reese have a job, and if so, how fast does
>: he type? (OK, two things).
>
>Yes, I have a job and I have no idea how fast I type.
It isn't that you type fast, George, it's that you don't sleep. ;)
Craig S Dohmen
Merlan wrote in message <6un1ge$e5q$1...@news.indigo.ie>...
>I'm not too sure of what your saying here. It is my understanding
that
>the reason for add_action is to add commands to the player when
>he/she encounters this object. It also my understanding that this is
>how it is done in all LPC muds. Feel free to correct me if I'm wrong.
Nah, Pinkfish will jump up and down on you if you use add_action now.
:)
--Craig
John Adelsberger
: Nah, Pinkfish will jump up and down on you if you use add_action now.
: :)
I always wondered where that annoying soul came from:-)
Scatter ///oo/\)
>This thread has been going on for quite a while now and lot of interesting
>points have been raised along a lot of less interesting things. But the
>general attitude, if I may be so bold, is to say that LPmuds aren't dead,
>but that the current state of the major LP drivers hasn't grown with the
>demand of modern mudder/mudcoder and the possibilities of the present-day
>internet.
I don't think I agree with that. Perhaps the reason that driver development
has slowed to a virtual halt is that apart from bug-fixes there is no real
demand for new features? Perhaps MudOS has reached the point where
it does everything that people need from it and more?
The last releases of MudOS seem more and more geared to taking the
game related code out of the driver and enhancing the LPC language
instead - the focus has changed from it being a game-driver to being
a language/development environment provider.
As a language-driver, once it provides a good enough language (which
IMO it does) there is nothing really that needs to be done to it. Language
improvements are all very well, but I can't see many people being willing
to rewrite their mudlibs every three months to take advantage of the
latest new language feature. Hence little demand for new language
features. All that is really needed after this point is bug-fixes and these
will become fewer and more inconsequential as time goes by.
Perhaps it's just a case of "if it ain't broke, don't fix it"?
--
Scatter ///\oo/\\\
[Due to Hurricane George my normal email address may not be working.
In this case, email replies can be send to big_s...@hotmail.com]
ne...@derwent.co.uk
>Tim Blommerde <T.Blo...@et.tudelft.nl> wrote:
>: A java coded mud driver though would probably not be a new LP mud, but just
>: a new mud driver (GR - mud ??). So in my humble opinion, java ain't the
>: future for lpmuds, but maybe a new, more modern, way for coding
>: muds.
>
>A JavaMud would naturally not be an LPMud since the defining property
>of LPMud is the base language, LPC. My thesis is not that Java is
>the future of LPs, but that LPs have come to the end of what they will
>be capable of doing.
Why? Is Java any more of a turing complete language than LPC? The only barrier
I can see with LPMuds or any mud really is imagination. Too many muds these
days are too derivative. My own personal bugbear is braindead NPCs who merely
hang around and do sweet FA, adding nothing to the game world other than being
a convenient way for players to gain exp. A bit of limited AI in MUDs wouldn't
go amiss.
NJR
Tim Blommerde
Scatter ///oo/\) wrote in post <6uq5nm$13hk$1...@news.uk.ibm.com>...
>In <6uobo9$9vp$1...@sun4000.casema.net>, "Tim Blommerde"
<T.Blo...@et.tudelft.nl> writes:
>
>>This thread has been going on for quite a while now and lot of interesting
>>points have been raised along a lot of less interesting things. But the
>>general attitude, if I may be so bold, is to say that LPmuds aren't dead,
>>but that the current state of the major LP drivers hasn't grown with the
>>demand of modern mudder/mudcoder and the possibilities of the present-day
>>internet.
>
>I don't think I agree with that. Perhaps the reason that driver
development
>has slowed to a virtual halt is that apart from bug-fixes there is no real
>demand for new features? Perhaps MudOS has reached the point where
>it does everything that people need from it and more?
Hmm, well I ain't as familiar with the most recent versions of the MudOS
driver, but for as far as I know there's no database support, not network
functions (like opening and closing of ports etc.) and no support for
running the mud on multiple servers. These are just three things that
spring to my mind that would be very nice to see implemented in lpmud
drivers. Especially the first two can be really handy. So, if I am not the
only one that would like to see such things implemented, the current lpmud
drivers have not yet reached the point where it does everything coders want
and need.
>The last releases of MudOS seem more and more geared to taking the
>game related code out of the driver and enhancing the LPC language
>instead - the focus has changed from it being a game-driver to being
>a language/development environment provider.
True and I'm very pleased with that.
>As a language-driver, once it provides a good enough language (which
>IMO it does) there is nothing really that needs to be done to it. Language
>improvements are all very well, but I can't see many people being willing
>to rewrite their mudlibs every three months to take advantage of the
>latest new language feature. Hence little demand for new language
>features. All that is really needed after this point is bug-fixes and these
>will become fewer and more inconsequential as time goes by.
Well, as I stated above, there's atleast one lpmud coder who would like to
see some additions. And remember, additions, in most cases, don't mean you
have to change previous code. They are additions and allow you, the coder,
to do things another (better ??) way or add new things to enhance the game.
>Perhaps it's just a case of "if it ain't broke, don't fix it"?
Very true statement.
>--
>Scatter ///\oo/\\\
>[Due to Hurricane George my normal email address may not be working.
>In this case, email replies can be send to big_s...@hotmail.com]
>
Thanks for sharing your thoughts,
Lars Duning
> : count on it.
>
> I hate to say it, but you are such a vast majority I would be willing
> to discount you.
Well, if you put it that way...
> :> And forcing them to take a jar home would scare them away only
> :> because that is not the way they are used to doing it.
>
> : You missed the point: I am talking about the non-geeks, for which a jar
> : is something to store jam in. Changing code online is not much
> : different from playing - downloading jars, compiler, runtime
> : environment, editor, learning to use them, upload your changes again
> : is very different.
>
> : And besides: considering from how many locations I log into my main
> : mud, I am glad that I can edit code online. It is one of the biggest
> : assets of LPMud.
>
> You are missing the point of what I am saying--to the end user, it is
> no different from coding online. They do not download the jar--it
> just happens automatically. They do not upload changes, it happens
> automatically. No matter what you do, however, you cannot get around
> the need to learn the editor.
Ok, point taken, and yes, it'd be nice to have. Just not as the only
method. Guess I'm just burnt - machine hopping, slow links and a dumb
terminals as the only way of access are still reality here.
Lars Duning
> : tools for Java, especially none which would be useful in a Mud
> : environment.
>
> Well, I had mentioned the APIs.
I'm afraid I need a semi-concrete example in order to understand why
the APIs are so useful for creating a mud :-)
> But in terms of the tools, using
> JBuilder instead of ed, I think, would rock.
Better than ed, yes, and it has its good points, but still I wish
I could ditch JBuilder in exchange for a decent editor/compiler combo.
But that's probably just me (as usual).
Lars Duning
> Some ideas have been put forth.
This reminds me: maybe you or someone else directly involved
could summarize these ideas, for easier reference/archival?
Scatter ///oo/\)
>Scatter ///oo/\) wrote in post <6uq5nm$13hk$1...@news.uk.ibm.com>...
>>has slowed to a virtual halt is that apart from bug-fixes there is no real
>>demand for new features? Perhaps MudOS has reached the point where
>>it does everything that people need from it and more?
>
>Hmm, well I ain't as familiar with the most recent versions of the MudOS
>driver, but for as far as I know there's no database support,
I've never tried to use it, but I'm sure I've seen database and SQL
package options in MudOS's options.h file?
>not network functions (like opening and closing of ports etc.)
My ftpd manages to open and close port 5023 and my httpd opens and
closes port 5080 - MudOS provides enough socket calls to handle UDP
and TCP/IP network connections.
>and no support for running the mud on multiple servers.
Not specifically - there's nothing stopping you using MudOS's calls to
open a UDP or TCP/IP connection to another server (intermud3 does
this) and implementing through it some remote procedure call and object
passing mechanism in LPC. Assuming the same object library on both
servers, you only need actually transmit data that differs from the
defaults. Of course this will be more work than simply using a
system the driver provides. :)
>These are just three things that
>spring to my mind that would be very nice to see implemented in lpmud
>drivers. Especially the first two can be really handy. So, if I am not the
>only one that would like to see such things implemented, the current lpmud
>drivers have not yet reached the point where it does everything coders want
>and need.
The first two are already in MudOS, I think. I agree that the third would
be best implemented in the driver rather than LPC but I don't see many
muds growing large enough to need to be split across servers anyway
(though there may be valid design reasons for splitting the world).
>>As a language-driver, once it provides a good enough language (which
>>IMO it does) there is nothing really that needs to be done to it. Language
>>improvements are all very well, but I can't see many people being willing
>>to rewrite their mudlibs every three months to take advantage of the
>>latest new language feature. Hence little demand for new language
>>features. All that is really needed after this point is bug-fixes and these
>>will become fewer and more inconsequential as time goes by.
>Well, as I stated above, there's atleast one lpmud coder who would like to
>see some additions. And remember, additions, in most cases, don't mean you
>have to change previous code. They are additions and allow you, the coder,
>to do things another (better ??) way or add new things to enhance the game.
Two additions I was thinking of in MudOS's case are the newer kind of
function pointer, and classes. To use both to the full would mean rewriting
large parts of the mudlib, otherwise only new code can benefit from the
additions.
Personally, the lack of new driver versions will only start to bother
me if I find problems with the driver that impact my mudlib and that
I can't easily work around or prevent from occurring. Otherwise the
language and services provided by the driver are more than adequate
for building my mud. They are probably good enough for building
almost anything mud related with - potentially graphic muds too.
Certainly my LPC webserver has no problem serving graphics...
--
Scatter ///\oo/\\\
Tim Blommerde
>>Hmm, well I ain't as familiar with the most recent versions of the MudOS
>>driver, but for as far as I know there's no database support,
>
>I've never tried to use it, but I'm sure I've seen database and SQL
>package options in MudOS's options.h file?
Well, as I stated, I am not familiar with the latest Mudos drivers, so I
didn't know that. But good to hear people have indeed taken the time to
support such things.
>>not network functions (like opening and closing of ports etc.)
>
>My ftpd manages to open and close port 5023 and my httpd opens and
>closes port 5080 - MudOS provides enough socket calls to handle UDP
>and TCP/IP network connections.
Hmm are these daemons inside the mud or outside the mud ?
>>and no support for running the mud on multiple servers.
>
>Not specifically - there's nothing stopping you using MudOS's calls to
>open a UDP or TCP/IP connection to another server (intermud3 does
>this) and implementing through it some remote procedure call and object
>passing mechanism in LPC. Assuming the same object library on both
>servers, you only need actually transmit data that differs from the
>defaults. Of course this will be more work than simply using a
>system the driver provides. :)
I agree (*happy smile*).
>>These are just three things that
>>spring to my mind that would be very nice to see implemented in lpmud
>>drivers. Especially the first two can be really handy. So, if I am not
the
>>only one that would like to see such things implemented, the current lpmud
>>drivers have not yet reached the point where it does everything coders
want
>>and need.
>
>The first two are already in MudOS, I think. I agree that the third would
>be best implemented in the driver rather than LPC but I don't see many
>muds growing large enough to need to be split across servers anyway
>(though there may be valid design reasons for splitting the world).
Nop, I agree that there are but few muds that are so big they need to be run
on more than one server, or atleast none that I know. Though it might be an
interesting thing to do if people from a certain part of the world all
experience a substantial amount of lag. Then enabling a second driver
placed on a machine they don't experience lag on to interact with the same
lib would solve their problem.
>Two additions I was thinking of in MudOS's case are the newer kind of
>function pointer, and classes. To use both to the full would mean rewriting
>large parts of the mudlib, otherwise only new code can benefit from the
>additions.
(*nods agreeingly*)
>Personally, the lack of new driver versions will only start to bother
>me if I find problems with the driver that impact my mudlib and that
>I can't easily work around or prevent from occurring. Otherwise the
>language and services provided by the driver are more than adequate
>for building my mud. They are probably good enough for building
>almost anything mud related with - potentially graphic muds too.
>Certainly my LPC webserver has no problem serving graphics...
Well, so far I haven't run into things I couldn't code because the driver
couldn't do it. So I fully agree with you. Though I guess that some of my
code might be faster/better if I had indeed classes support and (m)SQL
support in the driver I use.
Lots of good luck and enjoy every nanosecond,
George Reese
: George Reese wrote:
:> Lars Duning <ldu...@mdisystems.com> wrote:
:> : But leave the arena at this point: I simply don't know enough (good)
:> : tools for Java, especially none which would be useful in a Mud
:> : environment.
:>
:> Well, I had mentioned the APIs.
: I'm afraid I need a semi-concrete example in order to understand why
: the APIs are so useful for creating a mud :-)
Built in database access, internationalization, simple socket API,
security, and so on.
George Reese
: George Reese wrote:
:> Some ideas have been put forth.
: This reminds me: maybe you or someone else directly involved
: could summarize these ideas, for easier reference/archival?
Multi-threadeding--preferably a simpler model than Java. Distributed
LPC. Stronger typing. Better ease for client integration.
Internationalization. Database access.
James Pietan
> #> that when I looked at it last.
> #
> # Are'nt they all ? I don't ever remember seing a commercial one.
>
> When I said school in this instance, I did mean school - not generically
> non-commercial. I believe that the C in CD stands for Chalmers or
> something and CD is a project done by students of CD school or CD
> University or something. Not a typical hobbiest project. And so my
> point here was that you were more likely to get support because of this.
>
> I am not going to reply to the rest of this post as it has already been
> more than commented on by others.
>
> Also, someone asked whether CD comes with a driver, yes it does I believe.
CD (Lib) was the project put forth by Lars Pengl (sp?) as an upgraded
version
to 2.4.5. This was also the same time as MudOS was coming into play.
My understanding is, and I may be wrong, that at the time MudOS was
being
developed, it was discussed with Lar (LP) and asked if there would be a
collaberation(sp?). Things were said at that time, between the two
groups
on how things would be done and who would do them. A rift appeared and
sucked both groups to either end of the spectrum (As far as the east is
from
the west, if memory serves me correctly, then again it may not).
Anyway,
both MudOs and CD (Lib) offer benefits and pitfalls.
Just my $0.02 worth in trying to keep the record straight.
Elwe
#define Old_Mudder set("oldest_version_worked_on", 1.4.1)
--
CONGRESS.SYS Corrupted: Re-Boot WASHINGTON D.C. (Y/n) ?
Richard
#Richard wrote in message ...
#> What I didn't like with CD was that rather than separate functionality,
#> it IMO tried to do a Diku type thing with objects. It included
#> commands (for example) in every object with add_action (or something),
#> to update a # command globally you'd practically have to reboot. It
#> was like what the distribution Discworld mudlib is like, only complete
#> - functionality #>needs to be separated IMO, not all lumped together.
#
# I'm not too sure of what your saying here. It is my understanding that
# the reason for add_action is to add commands to the player when
# he/she encounters this object. It also my understanding that this is
# how it is done in all LPC muds. Feel free to correct me if I'm wrong.
My point was that CD lumps everything into an object, add_action is the
way it is done yes. But, a better way IMO is to have all commands as
external objects and add a wildcard add_action that checks to see if the
verb is the name of a command and if so, calls the command object.
This way, if you update the 'look' command, the functionality of the look
command is updated for all objects that use it. Where as, if you add it
internally with add_action, then when you update the object it is in you
are only updating that object not all the instances inherited into all the
objects inheriting that object. Heh.
So, actually my point is CD uses what I consider to be outdated methods of
design - and I do not consider myself to be an expert in mud design.
This was just the first outdated method that came to mind. These days, I
use a combination of driver parsing and commands as above, but without any
add_action usage.
Merlan
>Merlan, you blew it.
I said what I wanted to say. I'm happy :)
Merlan
Merlan
t...@wfn-shop.princeton.edu wrote in message
<6uokiu$538$2...@cnn.Princeton.EDU>...
>a decent sized MUD has dropped to a few thousand dollars; previously you
>needed to convince a university to use the spare cycles of one of their
>workstations.
True, but who hosts it? I live in Ireland, when I looked to have my site
hosted at an ISP here, I was quoted 4000 punts maybe 6500$ per annum
plus in addition a bandwidth charge.
>
>The young'uns these days! When I started playing MUDs, we *dreamed* of
>sites that occasionally only froze for 3 minutes! :-)
Sounds like the old VMS system I worked on <:-)
regards
Merlan
The Wildman
>I said what I wanted to say. I'm happy :)
If you can be happy being wrong...
John Adelsberger
: Hmm, well I ain't as familiar with the most recent versions of the MudOS
: driver, but for as far as I know there's no database support, not network
: functions (like opening and closing of ports etc.) and no support for
: running the mud on multiple servers.
LPC socket bindings have been around for at least three or four years, and
I'm thinking longer. You're way out of date. There is rudimentary
database support as well(MiniSQL, if I recall.) Distributed is the current
discussion; the argument isn't whether, but how.
: These are just three things that
: spring to my mind that would be very nice to see implemented in lpmud
: drivers. Especially the first two can be really handy. So, if I am not the
: only one that would like to see such things implemented, the current lpmud
: drivers have not yet reached the point where it does everything coders want
: and need.
The only thing you've mentioned that isn't there is distribution. That's
a current topic of discussion, although I don't know if Beek knows or
cares about the discussion:)
: >The last releases of MudOS seem more and more geared to taking the
: >game related code out of the driver and enhancing the LPC language
: >instead - the focus has changed from it being a game-driver to being
: >a language/development environment provider.
: True and I'm very pleased with that.
How would you even be aware of it? The oldest version of MudOS I ever
compiled had features you didn't even know existed TODAY!
: Well, as I stated above, there's atleast one lpmud coder who would like to
: see some additions. And remember, additions, in most cases, don't mean you
: have to change previous code. They are additions and allow you, the coder,
: to do things another (better ??) way or add new things to enhance the game.
Distribution, one way or another, is going to change quite a few things.
Face it; you can't distribute a mud without providing some means of
synchronization, and LPC doesn't have any such concept right now... it
doesn't have to be typical mp synch, but _something_ will be needed, and
it _will_ change things.
John Adelsberger
: sounds like Lisp may be an option.
: at least Allegro Common Lisp has dynamic loading and unloading.
If lisp is the answer, it was a stupid question, or else you asked an
aging CS prof.
Merlan
Touche!
Continueing this would be pointless.
Yours in mudding, whatever it's facets..
Merlan
Matthew R. Sheahan
> Are LPMuds dead?
as a body, i think so.
1) when they were distinctly non-dead, it was because they were doing
things commercial games didn't even think about touching. this is no
longer the case, and that simple fact has sucked the magic right out of
the whole culture. somewhere along the line, the rush, the feeling that
we were pushing the envelope, just evaporated.
2) a few years ago, it seemed like there was a revolutionary development
every few days. now the revolutions are basically over. some of this
is probably jadedness, but i suspect the rest has to do with the available
hobbyist labor being largely inadequate to the projects that are still
worth doing. this has to do with good design being a lot more work than
slap-happy grab-ass design, and therefore producing delayed gratification.
delayed gratification is pure death to anything that relies on the average
hobbyist's attention span.
3) the (don't kid yourselves, boys and girls) much easier availability of
sites, and the result of everyone running off and starting their own place
has created massive diffusion and duplication of effort. this contributes
to the above.
that said, i think that there are many LPmuds which individually have
bright futures and will continue to do great things. the unwashed masses,
though, are dead as a doornail, they just haven't figured out to lie down
yet.
i think it's significant to note that many of the things i said above apply
to MUDs at large as much as LPmuds specifically, though obviously if DIKU
people ever thought they were pushing the envelope it was because they'd
been dropped on their heads too many times as toddlers.
chiaroscuro
Johan van Selst
] My point was that CD lumps everything into an object, add_action is the
] way it is done yes. But, a better way IMO is to have all commands as
] external objects and add a wildcard add_action that checks to see if the
] verb is the name of a command and if so, calls the command object.
]
] This way, if you update the 'look' command, the functionality of the look
] command is updated for all objects that use it. Where as, if you add it
] internally with add_action, then when you update the object it is in you
] are only updating that object not all the instances inherited into all the
] objects inheriting that object. Heh.
Actually all standard functions (like look) go in a central soul, not in
seperate objects. So when you change the behaviour of the look command,
then you can just reload the one soul it is defined in, and it instantly
works the new way for everybody in the mud.
CD only uses add_action to get specialized commands that do not appear in
normal objects or that can be handled differently by the object that
defines it. e.g. 'open door' can be defined by /std/door.c and
'open container' by /std/container.c.
] When I said school in this instance, I did mean school - not generically
] non-commercial. I believe that the C in CD stands for Chalmers or
] something and CD is a project done by students of CD school or CD
] University or something. Not a typical hobbiest project. And so my
] point here was that you were more likely to get support because of this.
The CD driver was developed by Chalmers Datorf\"orening (the computer
society of the Chalmers University in G\"otenborg (www.cd.chalmers.se).
But current development is mostly taken over by the admins of leading
CD muds.
] Also, someone asked whether CD comes with a driver, yes it does I believe.
Indeed, and even though driver and mudlib are being developed seperately,
they still very much depend on each other.
Greetings,
Johan van Selst
Stig Hemmer
> If lisp is the answer, it was a stupid question, or else you asked an
> aging CS prof.
Could you please provide some support for this opinion?
Stig Hemmer,
Jack of a Few Trades.
Bryan Williams
L_ots of I_rritating S_tupid P_arenthesises
Bryan
Both politicians and diapers should be changed
regularly, and for the same reasons.
John Adelsberger
: George Reese <bo...@imaginary.com> writes:
: > : at least Allegro Common Lisp has dynamic loading and unloading.
: >
: > What else does it have that would make it useful for mud programming?
: not too sure yet, since I haven't started programming Lisp. just had a
: discussion off-net with some Lips programmers.
: the OO sounds good, dynamic loading, dynamic typing.
Yeah, too bad about that dynamic scoping, though... a true pain in the
ass:-)
For those of us who realize that recursion is rarely the right answer,
Lisp just seems somewhat like a sick joke, but I know that in so saying,
I'll alienate thousands of devoted Lisp lusers:)
((((((()()(()))(())()))
Hehe...
John Adelsberger
: John Adelsberger <j...@umr.edu> writes:
: > If lisp is the answer, it was a stupid question, or else you asked an
: > aging CS prof.
: Could you please provide some support for this opinion?
1. Functional languages are dead outside academia. Even IN academia,
they're fading away quickly.
2. (1) is a goodly part of the salvation of mankind.
3. Lisp causes the early retirement of the parentheses on a keyboard.
4. Dynamic scoping is for chumps writing their first interpreters by
hand, and if the chumps have any talent, even THEY won't use it.
5. Perl, Python, and a dozen other interpreted languages are far more
expressive, have far more development done for/with them, and are
far more widely known, and are likely to exist in 20 years.
6. Aging CS profs love Lisp because they were a part of the doomed
minority who swore up and down that functional programming was
the wave of the future.
7. Recursion is good for quicksort. This does not mean that recursion
should be an integral part of every algorithm used on a computer.
I'm reminded of Larry Wall's response to a major Lisp freak who was
bitching about how Perl had stolen what he regarded as Lisp's rightful
glory. He said something to the effect of: 'You've wasted a 25 year
head start. Whose fault is that?' What he didn't say, but should
have appended to his comment, is: 'on a language nobody wants.'
:-)
Jacob Hallen
>
>You've yet to explain why I'd want a 'JavaMud environment.' In order to
>justify the huge amount of new development this would require, you're
>going to need more than 'it can be done, and I like Java.' You're going
>to need more than 'I say LPC is limiting.' And you're going to need more
>than 'look at all this stuff that exists for Java' too, because in the
>time it would take to write a real mud server in Java, including the
>probable needed custom VM, you could easily add dozens of features to
>an LP driver AND go on vacation.
Coder training, tool availibility, books, installed base, ready made code,
better language, brighter future...
The list of reasons one would like a JavaMud environment is long. The most
compelling reasons for sticking with LPC are large installed base,
thoroughly tested paradigm and the fact that the LPC setup is specially
geared towards muds.
Which way you want to go depends on if you are a conservative or a radical.
LPC gives you better value now while Java wins in the long run.
Jacob Hallen
Stig Hemmer
> Stig Hemmer <st...@pvv.ntnu.no> wrote:
[>> Lisp bad]
> >Could you please provide some support for this opinion?
L_ots of I_ntelligent S_piffy P_arentheses
Has either of us proven anything? No.
Thomas Lundquist
> Actually all standard functions (like look) go in a central soul, not in
> seperate objects. So when you change the behaviour of the look command,
> then you can just reload the one soul it is defined in, and it instantly
> works the new way for everybody in the mud.
you get basically the same functions on most of the MudOS-based muds I
have been looking at.
altho it is separate objects they can be updated once and the new version
is used by everyone.
but still, at least FR, is using add_actions for some stuff altho it is
less every day.
B.
--
Baldrick@Final Realms.
telnet://fr.imaginary.com:4001/
http://fr.imaginary.com/
Jacob Hallen
>If you don't know your operating system well enough to install software,
>you cannot run a mud. Period. Not with help, not without help, not if
>little green men put implants in your head. End of story.
Bah! If you get a little help getting the mud up and running, you don't
need to know all that much about the operating system. The important traits
for running a successful mud are organisational skills, entrepreneurial
spirit and creative ideas. A bit of coding skill helps as well, but isn't
really necessary.
I decided to help Merlan because he seemed to have the necessary traits.
I think he will succeed, which makes him worth a little investment in the
form of some help and a few prods in the right direction.
There is a lesson to be learned in this.
Jacob Hallen