DLPC: A proposal for distributed LPC

[George Reese]

I would like to initiate discussion on a *standard* for distributed LPC.
While a standard for LPC is not necessary, I do think one for
distributed LPC would be for the following reasons:
* there is no architectural reason why DLPC would need to be anchored to
a specific driver
* there are plenty of reasons (migration, integration of muds, etc) why
it would be useful

I think a distributed LPC is important for LPC as a language. It is not
needed for today's muds IMHO. But I do think it will be needed for
tomorrow's.

This is extremely rough and is certainly missing in a few areas. Among
the design goals is that the local developer be completely ignorant of
any features of the remote system (or, even that there is a remote
system). This means no access to remote efuns/simuls/kfuns/driver
features. Ideally, the remote end could be in other languages such as
Java or C++.

Please use this as a topic to start discussion and not a platform for
flamage or ad hominem attacks.

***************

* Naming
DLPC requires a distributed naming convention. I suggest
(mud#)file(#clone_id). For security reasons, each mud should handle its
own mud name to host name resolution in a centralized location. But
using mud name as part of the object ID allows for a certain level of
locational transparency (i.e. when I do a
find_object("Nightmare#/realms/descartes/workroom") I do not care where
Nightmare is... however, my mudlib will take care of that mapping to
prevent spoofing.

Anything without the mud# is implied as localmud#. Muds should be able
to handle object names with and without a mud# prefix.

* Concurrency (the hard part)
Remote method calls in DLPC are blocking *for both muds* and both muds
LPC processes are assumed single threaded. The drivers themselves are
assumed to be multi-threaded. Muds may define multiple DLPC sockets so
that callbacks may be made. Thus, while blocking, a driver is still
checking for callbacks and ready to process those callbacks while it is
still technically waiting on a return value from the initial call.

For example:

A#room1 B#womble
B#womble->move(A#room2)
A#room2->receive(B#womble)

>From this interaction diagram, you can see that processing starts on mud
A, moves to mud B, and then back to mud A before returning from the
initial call. All of this should happen synchronously on both muds.

*Note* This means it is not a good idea to have a distributed system
that is separated by unreliable networks.

* Marshalling
All data types except for the object data types are passed by value.
Objects are passed by reference. The DLPC datatypes are:
int
string
array
mapping (assumed to have unique keys)
(should float be in here?)
object

Objects within mappings or arrays are still passed as references. The
mappings an arrays themselves are still passed as values. Note that
this contrasts with typical mapping and array behaviour on a mud.

obref->foo(), if a remote call, is understood by the driver as a *stub*
call. That is the driver will marshal the parameters and send the call,
parameters, and call stack across the network to be unmarshalled and
turned into the proper local data with the method foo() being called.
The return value is then marshalled, sent across the network,
unmarshalled, and returned as the value to the original caller.

* Security
Connections should be maintained as long as the network allows and
automatically reconnected when lost. The mudlib should have control
over validating incoming connections (this is all the mudlib sees of the
socket underbelly). I would love to hear ideas on what this protocol
should be.

Again, this is just a start. Please, let's talk about this in detail.

--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal

[Timothy Philip Vernum]

George Reese <bo...@imaginary.com> writes:

>I would like to initiate discussion on a *standard* for distributed LPC.

>***************

>* Naming
>DLPC requires a distributed naming convention. I suggest
>(mud#)file(#clone_id). For security reasons, each mud should handle its
>own mud name to host name resolution in a centralized location. But
>using mud name as part of the object ID allows for a certain level of
>locational transparency (i.e. when I do a
>find_object("Nightmare#/realms/descartes/workroom") I do not care where
>Nightmare is... however, my mudlib will take care of that mapping to
>prevent spoofing.

>Anything without the mud# is implied as localmud#. Muds should be able
>to handle object names with and without a mud# prefix.

I can imagine a possible scenario where a filename would possibly be
ambiguous with this method.

It is techincally possible (although presumably senseless) to have an object
(either virtual or real) with a filename entirely made of digits.

Although I haven't actually tested that it loads, I don't see why a file
"/123.c" (ie in the root dir) won't load.

Then find_object( "Nightmare#123" ) would be ambiguous. Logic would suggest it
to be a local file with clone_id of 123.

Although such a situation seems far-fetched and even utterly ridiculous, it
is a legal filename.

Perhaps prepending the mudname iwth a '#' would work.
ie
#Nightmare#123
vs
Nightmare#123

[Adam Helps]

George Reese wrote:
>
> I would like to initiate discussion on a *standard* for distributed LPC.

> While a standard for LPC is not necessary, I do think one for
> distributed LPC would be for the following reasons:
> * there is no architectural reason why DLPC would need to be anchored to
> a specific driver
> * there are plenty of reasons (migration, integration of muds, etc) why
> it would be useful

I've snipped out most of your comments, so anyone wondering what I'm
talking about should backtrack on the thread.

First a couple ideas about 'Distributed LPC' ... in true World Wide Web
tradition, you could work out a format for a 'virtual MUD' made up of
networked drivers. It's a pretty neat idea theoretically, and has some
pretty obvious practical applications (imagine the player base!). In
this case, though, I think the drawbacks outweigh the benefits.

For one, what MUDs are connected to this 'network of MUDs'? MUDs are
unlike web pages in that objects on a MUD have a great deal of power
over other objects, and can thus do a great deal of damage. I can easily
imagine 'pirate' MUDs connecting to the network with objects mainly
designed to mess things up -- randomly destructing players, etc.

Also, the bandwidth required to maintain these MUD connections would be
very large -- The objects in a MUD communicate mainly through function
calls, and every function call would have to be routed through the
Internet if the objects in question are not local to one other. And what
if the function call requires some kind of result? (for example a return
value). As long as the MUDs are connected together over a reliable
connection, this is not so much of a problem, but one of the words which
I have never used to describe the net is 'reliable.' How would this
system handle an object which goes off the network while you're waiting
for a return value?

Perhaps a true DLPC, similar to the one described above, can be made
practical through a bit of work (registering MUDs as safe, and special
techniques to drop the bandwidth requirement and necessity of
connection, etc). Maybe a bit more limited system would be more
practical, though.

One feature of the limited system could be 'passing' an object to
another MUD. The only real problem is in the nature of passing -- you
probably shouldn't send source code (or compiled object code) from MUD
to MUD, since that would bring back the above mentioned problem of
'pirate' MUDs. However you could pass the object's statistics from place
to place, and simply convert the object to the local equivalent (i.e. to
pass a weapon, send a dump of the variables and some properties which
show that it is a weapon. The MUD receiving the pass would clone its
local weapon object and try to apply the statistics). At the moment this
is impractical, since many MUDs would have such incompatible statistics
that the object would be badly garbled, or lose some important
properties, by the time it reaches the opposite MUD. MUDs with similar
or identical libs would not have this problem so much.

It would actually be possible just to pass the source along with the
object data if MUD drivers were a little more aggressive in protecting
the MUD from foreign objects ... for example, a valid_destruct command.
You'd still have to have similar enough interfaces that the object can
function in the new environment in the same way that it did in the old.

Another feature of a limited system could be some kind of inter-MUD
messaging. The driver would provide a command to send a message to an
object address (a use for that naming convention). The object could
define a method to receive that information, something like
catch_message(str). This would allow for inter-MUD chats, widespread
MUD-magazines, and you could even use a specialized version of this
system to handle the object passing completely in the MUD-lib.

One obvious application of object passing is to hand off players from
MUD to MUD -- you could journey through several different MUDs with the
same character (with perhaps a few conversions to avoid theme problems).
MUDs connected in this way could have a very fluid player base, with
players moving from MUD to MUD with just a little more difficulty than
going from room to room (with, perhaps, a hefty fee to keep it from
being TOO easy :). You'd still have to route the connection through the
MUD which the player originally logged on to.

Other ideas? It's too late at night for me to be incredibly coherent.

-=-=-=-=-=-=-=-=-=-=-=-=-
,.~*~% |\ __ o. . __ ,.~*~%
~,....~~$&$& -- |_\| || |`--, ~,....~~$&$&
*~~..~~**&$@#% | \-- ``--'`--' *~~..~~**&$@#%
~~~****&$#@@#$ -=-=-=-=-=-=-=-=-=-=-=-=- ~~~****&$#@@#$
$&$$&&$@@##$$$ aka Adam Helps $&$$&&$@@##$$$
$&$#@@#$$$$% -=-=-=-=-=-=-=-=-=-=-=-=- $&$#@@#$$$$%
$%$$$% hel...@slkc.uswest.net $%$$$%
-=-=-=-=-=-=-=-=-=-=-=-=-

[John Adelsberger]

A friend of mine sent me a copy of this, and even though I promised I
would not bother replying to Reese foolishness any more, because he
herein lays the groundwork for a colossally bad idea that would probably
be the end of LPC as a serious distributed platform, as opposed to the
beginning, I really have to. But, this is all I have to say; those
clever enough to know why I say what I say can do as they please, and
those, such as Reese, not so fortunate can flame me as they please,
and either way, I tried.

George Reese <bo...@imaginary.com> wrote:
: I would like to initiate discussion on a *standard* for distributed LPC.

: This is extremely rough and is certainly missing in a few areas. Among

Just write CORBA hooks for LPC and be done with it. Reinventing the
wheel here would be both foolish and overly difficult, and CORBA
already does every single thing you want, whereas your 'design' is
not rough or incomplete; it is just bad.

: * Concurrency (the hard part)

: Remote method calls in DLPC are blocking *for both muds* and both muds

Why? What a fantastically bad idea. Can you say 'pathetic performance?'
I suspect you are advocating this 'maximal lock' strategy because you
don't know better; suffice it to say that minimal lock strategies
provide vastly greater performance at high load and on networks where
tranmission delay is significant, and are really not that hard to
implement.

: LPC processes are assumed single threaded. The drivers themselves are

Since at lesat one LPC interpreter already supports LPC bindings to a
pthread library, this won't work, probably:)

: assumed to be multi-threaded. Muds may define multiple DLPC sockets so

: that callbacks may be made. Thus, while blocking, a driver is still
: checking for callbacks and ready to process those callbacks while it is
: still technically waiting on a return value from the initial call.

And while it sits around with all the players saying 'damn this lag
sucks' because some moron decided to do router maintenance.

<simple RPC example snipped>

: >From this interaction diagram, you can see that processing starts on mud

: A, moves to mud B, and then back to mud A before returning from the
: initial call. All of this should happen synchronously on both muds.

You intend to run this on dedicated OC-48 links, right?

: *Note* This means it is not a good idea to have a distributed system

: that is separated by unreliable networks.

No kidding. A better way to put it is that it means that unless by
distributed you mean in someone's basement, it won't work worth a
damn.

: * Marshalling

: All data types except for the object data types are passed by value.
: Objects are passed by reference. The DLPC datatypes are:
: int
: string
: array
: mapping (assumed to have unique keys)
: (should float be in here?)
: object

You just suggested passing arrays and mappings by value across a network
every time they are asked for. Do you in fact have any knowledge of
any distributed object system theory whatsoever, or are you blubbering
as usual about something you know nothing about?

: Objects within mappings or arrays are still passed as references. The

: mappings an arrays themselves are still passed as values. Note that
: this contrasts with typical mapping and array behaviour on a mud.

Very badly, yes.

: obref->foo(), if a remote call, is understood by the driver as a *stub*

: call. That is the driver will marshal the parameters and send the call,
: parameters, and call stack across the network to be unmarshalled and
: turned into the proper local data with the method foo() being called.
: The return value is then marshalled, sent across the network,
: unmarshalled, and returned as the value to the original caller.

I see you got through the first chapter of the O'Reilly book on RPC.
Congratulations.

: * Security

: Connections should be maintained as long as the network allows and
: automatically reconnected when lost. The mudlib should have control
: over validating incoming connections (this is all the mudlib sees of the
: socket underbelly). I would love to hear ideas on what this protocol
: should be.

You're suggesting implementing RPC using bad semantics on persistent
channels, and ignoring the people(CORBA) who've already done all of
this correctly and whose work would make this project much cleaner.
Other than distributing a mud, is there a single good idea in here?

: Again, this is just a start. Please, let's talk about this in detail.

www.omg.org is your friend.

--
John J. Adelsberger III
j...@umr.edu

"There are none so blind as those who will not see." - Kansas

[Corey Brenner]

George Reese <bo...@imaginary.com> wrote:
: Again, this is just a start. Please, let's talk about this in detail.

Assuming that, say, the two MUDs will be running on dissimilar hardware
(for instance, a PC and an UltraSPARC), it would be necessary to avoid
host->network->host data translation problems. It might be a good idea
to send all the data across as a stream of ASCII.

That would make the decoding, etc. of the data on each end a bit more
intensive, but it would serve to make the communication work reliably.

I would suggest, before taking an idea like distributed LPC any farther,
however, that someone begin work on a threaded server. In this way,
the two ends of the connection can block for data, but game play on either
end will not suffer as badly if, say, one of the links suffers a bit of
temporary lag.

--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
============================================================================
Corey D. Brenner -- (bre...@umr.edu) | #include<standard_disclaimer.h>
----------------------------------------------------------------------------
Our savior, who art in hard disk, |
Unix be thy name. | This .signature is in
Thy daemons run, thy work be done, | [=] FEEL-AROUND [=]
On localhost, even as in network. |
============================================================================
"I yam Popeye of Borg. Resistinks is futile. You will be askimilgrated."

[Kris Van Hees]

On 28 Jul at 17:58:39, Corey Brenner wrote <5rimj7$14u$1...@news.cc.umr.edu> which contained:

> Assuming that, say, the two MUDs will be running on dissimilar hardware
> (for instance, a PC and an UltraSPARC), it would be necessary to avoid
> host->network->host data translation problems. It might be a good idea
> to send all the data across as a stream of ASCII.

That's what network byte order can be used for, to save bandwidth. After all,
maxint on a 32bit machine is 10 digits, so a 4/10 ratio).

>
> I would suggest, before taking an idea like distributed LPC any farther,
> however, that someone begin work on a threaded server. In this way,
> the two ends of the connection can block for data, but game play on either
> end will not suffer as badly if, say, one of the links suffers a bit of
> temporary lag.

Work on threaded programming environments based on LPC in some way is in
progress, however I found that using LPC the way it is now is more of a
limitation and bad idea than anything else. There are too many historic
mistakes in the language to make it worthwhile trying to extend it with
advanced features such as multithreading, I believe. Starting from a more
pure and clean language helps alot.

Then again, I do not care about backwards compatibility.

Aedil

[Jody Byrd]

Questions:

1) If playerA in MudA calls for a room in MudB, would playerAs connection
be moved to MudB?

If not,
2) Where would the object be compilied, on MudA or B?

Possible Answers:
1) I guess not since a new telnet session would have to be established.
1) The player object may not match the remote mud.
2) I guess B since the object will be in that mudlib.

[Corey Brenner]

Kris Van Hees <ae...@ny.fnx.com> wrote:
: On 28 Jul at 17:58:39, Corey Brenner wrote <5rimj7$14u$1...@news.cc.umr.edu> which contained:

: > Assuming that, say, the two MUDs will be running on dissimilar hardware
: > (for instance, a PC and an UltraSPARC), it would be necessary to avoid
: > host->network->host data translation problems. It might be a good idea
: > to send all the data across as a stream of ASCII.

: That's what network byte order can be used for, to save bandwidth. After all,
: maxint on a 32bit machine is 10 digits, so a 4/10 ratio).

Indeed, but sending, say, a mapping across via a strict binary packet
will be rather a bitch, wouldn't you agree? the thing would have to
be run-length encoded somehow, and you have several such data items on
an object like, say, a player.

: Work on threaded programming environments based on LPC in some way is in

: progress, however I found that using LPC the way it is now is more of a
: limitation and bad idea than anything else. There are too many historic
: mistakes in the language to make it worthwhile trying to extend it with
: advanced features such as multithreading, I believe. Starting from a more
: pure and clean language helps alot.

This is true. I think that threads could be implemented in the server and
for server and lib operations alright, and transparently to the vast majority
of area-type coders, but it would take a bit more thought to the design
of the lib.

: Then again, I do not care about backwards compatibility.

Nor do I.

[John Adelsberger]

Kris Van Hees <ae...@ny.fnx.com> wrote:
: limitation and bad idea than anything else. There are too many historic
: mistakes in the language to make it worthwhile trying to extend it with
: advanced features such as multithreading, I believe. Starting from a more
: pure and clean language helps alot.

: Then again, I do not care about backwards compatibility.

I don't care about backwards compatibility, either, but I do care about
two things:

1) LPC is known by a huge number of people.
2) Since there is no standard, 'fixing' LPC would be an easy task.

Most of the 'errors' in it are syntactic uglinesses that can be
remedied readily if one is willing to give up the use of old code.
Besides, it has the overwhelming advantage of not being so
incredibly ugly as most other C-like interpreted scripting languages,
like, say, ColdC, which, sorry if you like it, is syntactic garbage.

You _could_ start over trying to keep all of LPC's advantages, but
you'd just end up making LPC over again the hard way with a few
changes. It _is_ ironic, however, that LPC is not alone in this
regard; most of the stuff in use in computing in general that is
of any merit whatsoever is also kinda ugly in some ways; it would
seem that principles of design are screamed at 'newbie coders'
and roundly ignored by people who ought to know better.

[John Adelsberger]

Corey Brenner <bre...@umr.edu> wrote:
: Kris Van Hees <ae...@ny.fnx.com> wrote:

: : That's what network byte order can be used for, to save bandwidth. After all,

: : maxint on a 32bit machine is 10 digits, so a 4/10 ratio).

: Indeed, but sending, say, a mapping across via a strict binary packet
: will be rather a bitch, wouldn't you agree? the thing would have to
: be run-length encoded somehow, and you have several such data items on
: an object like, say, a player.

Not only that, I insist, just to be a bastage, on sending you a mapping
of mappings of arrays of mappings. Have a nice day:) No, sorry, but
while I can't prove it just yet, no successful server that intends to
be distributed across a network bigger than a house geographically will
pass mappings or arrays by value for long... unless of course we can
all get T-3 or better as the minimum speed of a link, which just isn't
happening.

: This is true. I think that threads could be implemented in the server and

: for server and lib operations alright, and transparently to the vast majority
: of area-type coders, but it would take a bit more thought to the design
: of the lib.

Actually, outside the socket related stuff, probably nobody would even
use threads in most muds; you just end up having to synchronize everything
again anyway every time you interact with any other object in the system
if you try to put each connection completely on its own thread... you could
thread some background stuff and use it as a way to implement hbs and
call_out in LPC instead of in the driver, but that's probably about it.

(Yes, I know you could do more, but I'm just guessing that you'd see no
real benefit performancewise, and it'd be a lot of work.)

Oh, hey, you could integrate the nameserver thingie by threading it out,
too:)

[George Reese]

Timothy Philip Vernum <tp...@uow.edu.au> wrote:
: George Reese <bo...@imaginary.com> writes:

: >I would like to initiate discussion on a *standard* for distributed LPC.

: >***************

Yeah... or object://Nightmare#123

But that is a good point. I went with # as a delimiter since most LPC
systems are designed to prevent spoofing on that aleady.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: A friend of mine sent me a copy of this, and even though I promised I

: would not bother replying to Reese foolishness any more, because he
: herein lays the groundwork for a colossally bad idea that would probably
: be the end of LPC as a serious distributed platform, as opposed to the
: beginning, I really have to. But, this is all I have to say; those
: clever enough to know why I say what I say can do as they please, and
: those, such as Reese, not so fortunate can flame me as they please,
: and either way, I tried.

: George Reese <bo...@imaginary.com> wrote:
: : I would like to initiate discussion on a *standard* for distributed LPC.
: : This is extremely rough and is certainly missing in a few areas. Among

: Just write CORBA hooks for LPC and be done with it. Reinventing the
: wheel here would be both foolish and overly difficult, and CORBA
: already does every single thing you want, whereas your 'design' is
: not rough or incomplete; it is just bad.

Doing CORBA in LPC is immensely stupid. My mechanism allows you to add
CORBA hooks into LPC without all of the overhead required by CORBA.
First, do you think writing a CORBA compliant ORB is so simple that
every mud admin who wants the advantages of scaling across multiple
CPUs will run out and write an LPC ORB?
Second, most mud admins have a hard enough time getting the computer
literate to write LPC code. Now you suggest they should learn IDL and
understand distributed computing principles?

You have got to be kidding me.

Then there is the issue of generating CORBA stubs and skeletons. The
DLPC of which I am talking requires no extra compile process... it
basically creates virtual skeletons and stubs within the driver.
CORBA compliance will have you generating stubs and skeletons from IDL
source. Yuck.

: : * Concurrency (the hard part)

: : Remote method calls in DLPC are blocking *for both muds* and both muds

: Why? What a fantastically bad idea. Can you say 'pathetic performance?'
: I suspect you are advocating this 'maximal lock' strategy because you
: don't know better; suffice it to say that minimal lock strategies
: provide vastly greater performance at high load and on networks where
: tranmission delay is significant, and are really not that hard to
: implement.

Let me know when you have any idea you are talking about.

: : LPC processes are assumed single threaded. The drivers themselves are

: Since at lesat one LPC interpreter already supports LPC bindings to a
: pthread library, this won't work, probably:)

Then it would not support DLPC, would it? DUH.

: : assumed to be multi-threaded. Muds may define multiple DLPC sockets so

: : that callbacks may be made. Thus, while blocking, a driver is still
: : checking for callbacks and ready to process those callbacks while it is
: : still technically waiting on a return value from the initial call.

: And while it sits around with all the players saying 'damn this lag
: sucks' because some moron decided to do router maintenance.

: <simple RPC example snipped>

: : >From this interaction diagram, you can see that processing starts on mud
: : A, moves to mud B, and then back to mud A before returning from the
: : initial call. All of this should happen synchronously on both muds.

: You intend to run this on dedicated OC-48 links, right?

: : *Note* This means it is not a good idea to have a distributed system
: : that is separated by unreliable networks.

: No kidding. A better way to put it is that it means that unless by
: distributed you mean in someone's basement, it won't work worth a
: damn.

Same with CORBA right now. Distributed computing over the Internet is
simply not there yet. Best IMHO to deal with the problems we have today.

: : * Marshalling

: : All data types except for the object data types are passed by value.
: : Objects are passed by reference. The DLPC datatypes are:
: : int
: : string
: : array
: : mapping (assumed to have unique keys)
: : (should float be in here?)
: : object

: You just suggested passing arrays and mappings by value across a network
: every time they are asked for. Do you in fact have any knowledge of
: any distributed object system theory whatsoever, or are you blubbering
: as usual about something you know nothing about?

I told you before, I wrote a book on distributed client/server in
Java. What are your credentials? I also happen to understand LPC
pretty damn well.

: : Objects within mappings or arrays are still passed as references. The

: : mappings an arrays themselves are still passed as values. Note that
: : this contrasts with typical mapping and array behaviour on a mud.

: Very badly, yes.

Whatever.

: : obref->foo(), if a remote call, is understood by the driver as a *stub*

: : call. That is the driver will marshal the parameters and send the call,
: : parameters, and call stack across the network to be unmarshalled and
: : turned into the proper local data with the method foo() being called.
: : The return value is then marshalled, sent across the network,
: : unmarshalled, and returned as the value to the original caller.

: I see you got through the first chapter of the O'Reilly book on RPC.
: Congratulations.

While you are checking that out, check out the O'Reilly book on JDBC
and RMI (RMI being the IIOP compliant distributed computing API for
Java). Guess who wrote it?

: : * Security

: : Connections should be maintained as long as the network allows and
: : automatically reconnected when lost. The mudlib should have control
: : over validating incoming connections (this is all the mudlib sees of the
: : socket underbelly). I would love to hear ideas on what this protocol
: : should be.

: You're suggesting implementing RPC using bad semantics on persistent
: channels, and ignoring the people(CORBA) who've already done all of
: this correctly and whose work would make this project much cleaner.
: Other than distributing a mud, is there a single good idea in here?

I am not suggesting RCP. I am suggesting about a distributed
computing mechanism that maintains LPC symantics without burdening LPC
developers with the complexity of distributed computing. In addition,
I want potential CORBA and RMI interoperability, but I do not want to
force it on people who do not need it.

Are these concepts so alien to you?

Why do you have to be a complete asshole to someone trying to start
honest discussion?

: : Again, this is just a start. Please, let's talk about this in detail.

: www.omg.org is your friend.

Thanks, question is, do you have any friends?

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:

: On 28 Jul at 17:58:39, Corey Brenner wrote <5rimj7$14u$1...@news.cc.umr.edu> which contained:
: > Assuming that, say, the two MUDs will be running on dissimilar hardware
: > (for instance, a PC and an UltraSPARC), it would be necessary to avoid
: > host->network->host data translation problems. It might be a good idea
: > to send all the data across as a stream of ASCII.

: That's what network byte order can be used for, to save bandwidth. After all,

: maxint on a 32bit machine is 10 digits, so a 4/10 ratio).
: >

: > I would suggest, before taking an idea like distributed LPC any farther,

: > however, that someone begin work on a threaded server. In this way,
: > the two ends of the connection can block for data, but game play on either
: > end will not suffer as badly if, say, one of the links suffers a bit of
: > temporary lag.

: Work on threaded programming environments based on LPC in some way is in

: progress, however I found that using LPC the way it is now is more of a

: limitation and bad idea than anything else. There are too many historic
: mistakes in the language to make it worthwhile trying to extend it with
: advanced features such as multithreading, I believe. Starting from a more
: pure and clean language helps alot.

: Then again, I do not care about backwards compatibility.

: Aedil

I agree. And in this situation, I am interested in backwards
compatibility. Distributed computing for LPC could be no other way.
More specifically, I personally am interested in scaling issues I
foresee for my mud. I do not want to have to by a Cray to scale to
500 or 1000 users.

[George Reese]

Jody Byrd <jlb...@smart1.net> wrote:
: Questions:

: 1) If playerA in MudA calls for a room in MudB, would playerAs connection
: be moved to MudB?

No.

: If not,

: 2) Where would the object be compilied, on MudA or B?

MudB.

: Possible Answers:

: 1) I guess not since a new telnet session would have to be established.
: 1) The player object may not match the remote mud.
: 2) I guess B since the object will be in that mudlib.

There is no player object on the remote mud, just a reference to one.

[George Reese]

I think you missed some key points in my post. I will discuss in
detail below. The most obvious is that I *do not think* it is a good
idea to have a mud distributed across a physically troublesome network.

Adam Helps <hel...@slkc.uswest.net> wrote:

: George Reese wrote:
: >
: > I would like to initiate discussion on a *standard* for distributed LPC.
: > While a standard for LPC is not necessary, I do think one for
: > distributed LPC would be for the following reasons:
: > * there is no architectural reason why DLPC would need to be anchored to
: > a specific driver
: > * there are plenty of reasons (migration, integration of muds, etc) why
: > it would be useful

: I've snipped out most of your comments, so anyone wondering what I'm
: talking about should backtrack on the thread.

: First a couple ideas about 'Distributed LPC' ... in true World Wide Web
: tradition, you could work out a format for a 'virtual MUD' made up of
: networked drivers. It's a pretty neat idea theoretically, and has some
: pretty obvious practical applications (imagine the player base!). In
: this case, though, I think the drawbacks outweigh the benefits.

: For one, what MUDs are connected to this 'network of MUDs'? MUDs are
: unlike web pages in that objects on a MUD have a great deal of power
: over other objects, and can thus do a great deal of damage. I can easily
: imagine 'pirate' MUDs connecting to the network with objects mainly
: designed to mess things up -- randomly destructing players, etc.

People are doing this with all kinds of systems. The security
problems are certainly solvable and are not a drawback.

: Also, the bandwidth required to maintain these MUD connections would be

: very large -- The objects in a MUD communicate mainly through function
: calls, and every function call would have to be routed through the
: Internet if the objects in question are not local to one other. And what
: if the function call requires some kind of result? (for example a return
: value). As long as the MUDs are connected together over a reliable
: connection, this is not so much of a problem, but one of the words which
: I have never used to describe the net is 'reliable.' How would this
: system handle an object which goes off the network while you're waiting
: for a return value?

Again, I am not suggesting using the Net for connectivity. A
distributed mud should be one where all the components are on a common
LAN.

: Perhaps a true DLPC, similar to the one described above, can be made

: practical through a bit of work (registering MUDs as safe, and special
: techniques to drop the bandwidth requirement and necessity of
: connection, etc). Maybe a bit more limited system would be more
: practical, though.

No reason for a more limited system.

: One feature of the limited system could be 'passing' an object to

: another MUD. The only real problem is in the nature of passing -- you
: probably shouldn't send source code (or compiled object code) from MUD
: to MUD, since that would bring back the above mentioned problem of
: 'pirate' MUDs.

That has nothing to do with pirate muds :) Few muds encrypt sensitive
data to begin with. Plus, I am not talking about passing around
objects. I am talking about passing around object refgerences.

: However you could pass the object's statistics from place

: to place, and simply convert the object to the local equivalent (i.e. to
: pass a weapon, send a dump of the variables and some properties which
: show that it is a weapon. The MUD receiving the pass would clone its
: local weapon object and try to apply the statistics). At the moment this
: is impractical, since many MUDs would have such incompatible statistics
: that the object would be badly garbled, or lose some important
: properties, by the time it reaches the opposite MUD. MUDs with similar
: or identical libs would not have this problem so much.

I think you should take a look back at my proposal. It does not sound
like you are understanding the stub/skeleton mechanism (which I stole
straight from CORBA) which I am proposing.

: It would actually be possible just to pass the source along with the

: object data if MUD drivers were a little more aggressive in protecting
: the MUD from foreign objects ... for example, a valid_destruct command.
: You'd still have to have similar enough interfaces that the object can
: function in the new environment in the same way that it did in the old.

Again, you do not want this (at least not at this time).

: Another feature of a limited system could be some kind of inter-MUD

: messaging. The driver would provide a command to send a message to an
: object address (a use for that naming convention). The object could
: define a method to receive that information, something like
: catch_message(str). This would allow for inter-MUD chats, widespread
: MUD-magazines, and you could even use a specialized version of this
: system to handle the object passing completely in the MUD-lib.

: One obvious application of object passing is to hand off players from
: MUD to MUD -- you could journey through several different MUDs with the
: same character (with perhaps a few conversions to avoid theme problems).
: MUDs connected in this way could have a very fluid player base, with
: players moving from MUD to MUD with just a little more difficulty than
: going from room to room (with, perhaps, a hefty fee to keep it from
: being TOO easy :). You'd still have to route the connection through the
: MUD which the player originally logged on to.

: Other ideas? It's too late at night for me to be incredibly coherent.

I appreciate the discussion... I just think you missed specifically
where I dealt with all these concerns (or I stated them poorly).

[Kris Van Hees]

On 30 Jul at 01:35:19, George Reese wrote <5rm5nn$4v8$4...@darla.visi.com> which contained:

> Kris Van Hees <ae...@ny.fnx.com> wrote:
>: Work on threaded programming environments based on LPC in some way is in
>: progress, however I found that using LPC the way it is now is more of a
>: limitation and bad idea than anything else. There are too many historic
>: mistakes in the language to make it worthwhile trying to extend it with
>: advanced features such as multithreading, I believe. Starting from a more
>: pure and clean language helps alot.
>
>: Then again, I do not care about backwards compatibility.
>

> I agree. And in this situation, I am interested in backwards
> compatibility. Distributed computing for LPC could be no other way.
> More specifically, I personally am interested in scaling issues I
> foresee for my mud. I do not want to have to by a Cray to scale to
> 500 or 1000 users.

Distributed computing for LPC could be no other way? That's a weird
statement to make. Of course it can be other ways. All depends on
what you want, what your requirements are.

You look at it (from your posting here and on the mailing list) from the
perspective of wanting to make your own mud more scalable. That is an
area where distribution may work, but that's a very specific case. Any
form of DLPC which is successful should support a pretty generic way of
doing distributed processing so that other MUDs, and perhaps future more
serious LPC-based projects can benifit from it.

Limiting a design to just LANs and very much MUD based cut off the way once
again for LPC to move towards more general usage. Granted, without some
uniform LPC language (or unless a derived language is made which solves the
many problems/nuisances) the usefulness of any design is doubtful. The
way LPC dialects exist now, making a DLPC standard which covers them all is
going to be tricky. E.g. differences in datatypes. Then again, since you
are only considering LANs right now, I guess you can stick to one single
driver implementation (like MudOS or DGD), and not worry about cross-driver
issues. And exactly that is I think where the more interesting issues lie.

Aedil

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:

: On 30 Jul at 01:35:19, George Reese wrote <5rm5nn$4v8$4...@darla.visi.com> which contained:

: > Kris Van Hees <ae...@ny.fnx.com> wrote:
: >: Work on threaded programming environments based on LPC in some way is in
: >: progress, however I found that using LPC the way it is now is more of a
: >: limitation and bad idea than anything else. There are too many historic
: >: mistakes in the language to make it worthwhile trying to extend it with
: >: advanced features such as multithreading, I believe. Starting from a more
: >: pure and clean language helps alot.
: >
: >: Then again, I do not care about backwards compatibility.
: >
: > I agree. And in this situation, I am interested in backwards
: > compatibility. Distributed computing for LPC could be no other way.
: > More specifically, I personally am interested in scaling issues I
: > foresee for my mud. I do not want to have to by a Cray to scale to
: > 500 or 1000 users.

: Distributed computing for LPC could be no other way? That's a weird
: statement to make. Of course it can be other ways. All depends on
: what you want, what your requirements are.

: You look at it (from your posting here and on the mailing list) from the
: perspective of wanting to make your own mud more scalable. That is an
: area where distribution may work, but that's a very specific case. Any
: form of DLPC which is successful should support a pretty generic way of
: doing distributed processing so that other MUDs, and perhaps future more
: serious LPC-based projects can benifit from it.

Do you have a proposal for a more generic, non-LAN distributed LPC?
If so, please let's discuss it. This issue has not been solved
reasonably for either DCOM or CORBA. I do not think I personally am
ready to tackle that issue. And, scalability, IMHO, is the one use
that is not based on coolness.

: Limiting a design to just LANs and very much MUD based cut off the way once

: again for LPC to move towards more general usage. Granted, without some
: uniform LPC language (or unless a derived language is made which solves the
: many problems/nuisances) the usefulness of any design is doubtful. The
: way LPC dialects exist now, making a DLPC standard which covers them all is
: going to be tricky. E.g. differences in datatypes. Then again, since you
: are only considering LANs right now, I guess you can stick to one single
: driver implementation (like MudOS or DGD), and not worry about cross-driver
: issues. And exactly that is I think where the more interesting issues lie.

: Aedil

I do not think there are any real issues with cross-driver
portability. The biggest issue are floats.

[Scott Goehring]

"Jody" == Jody Byrd <jlb...@smart1.net> writes:

Jody> Questions: 1) If playerA in MudA calls for a room in MudB, would
Jody> playerAs connection be moved to MudB?

In the experimental UnterMUD system developed by Marcus Ranum back in,
um, 1990, this is what happened. There was a server/client protocol
to signify when a client should connect to a new server, and a
server/server protocol for handing off objects between MUDs. There
was no inter-server communication except for object handoff, if I
recall correctly (which, given the fact that this was seven years ago,
I might very well not).

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: Corey Brenner <bre...@umr.edu> wrote:
: : Kris Van Hees <ae...@ny.fnx.com> wrote:

: : : That's what network byte order can be used for, to save bandwidth. After all,

: : : maxint on a 32bit machine is 10 digits, so a 4/10 ratio).

: : Indeed, but sending, say, a mapping across via a strict binary packet

: : will be rather a bitch, wouldn't you agree? the thing would have to
: : be run-length encoded somehow, and you have several such data items on
: : an object like, say, a player.

: Not only that, I insist, just to be a bastage, on sending you a mapping
: of mappings of arrays of mappings. Have a nice day:) No, sorry, but
: while I can't prove it just yet, no successful server that intends to
: be distributed across a network bigger than a house geographically will
: pass mappings or arrays by value for long... unless of course we can
: all get T-3 or better as the minimum speed of a link, which just isn't
: happening.

Ya moron, 100+ muds are already doing it via Intermud 3.

: : This is true. I think that threads could be implemented in the server and

: : for server and lib operations alright, and transparently to the vast majority
: : of area-type coders, but it would take a bit more thought to the design
: : of the lib.

: Actually, outside the socket related stuff, probably nobody would even
: use threads in most muds; you just end up having to synchronize everything
: again anyway every time you interact with any other object in the system
: if you try to put each connection completely on its own thread... you could
: thread some background stuff and use it as a way to implement hbs and
: call_out in LPC instead of in the driver, but that's probably about it.

: (Yes, I know you could do more, but I'm just guessing that you'd see no
: real benefit performancewise, and it'd be a lot of work.)

: Oh, hey, you could integrate the nameserver thingie by threading it out,
: too:)

Been there, done that. That is the way the Nightmare release of
MudOS/Win32 works.

[John Adelsberger]

Jody Byrd <jlb...@smart1.net> wrote:
: Questions:

: 1) If playerA in MudA calls for a room in MudB, would playerAs connection
: be moved to MudB?

The proposal would simply give playerA a reference to the room on MudB,
which it could treat as though it were a reference to a local object,
the translation across the network being handled by the drivers.

: If not,
: 2) Where would the object be compilied, on MudA or B?

No object would be moved.

By the way, like I said, the proposal should just be replaced with
a proposal for CORBA hooks for LPC. No need to reinvent the wheel,
especially since the wheel in the proposal isn't even round:)

[Christer Borang]

In <EE1t2...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees) writes:
>On 28 Jul at 17:58:39, Corey Brenner wrote <5rimj7$14u$1...@news.cc.umr.edu> which contained:

>> I would suggest, before taking an idea like distributed LPC any farther,
>> however, that someone begin work on a threaded server. In this way,
>> the two ends of the connection can block for data, but game play on either
>> end will not suffer as badly if, say, one of the links suffers a bit of
>> temporary lag.

>Work on threaded programming environments based on LPC in some way is in
>progress, however I found that using LPC the way it is now is more of a
>limitation and bad idea than anything else. There are too many historic
>mistakes in the language to make it worthwhile trying to extend it with
>advanced features such as multithreading, I believe. Starting from a more
>pure and clean language helps alot.

I do know that the latest version of Pike (formerly uLPC) has
threading, at least on some platforms. As far as I know, there's only
one Mud running with Pike, and I'm not sure that they use the threaded
version. Is DGD getting threads as well?

>Then again, I do not care about backwards compatibility.

Backwards schmackwards. :-)

//Christer aka Mort
--
| Fyrklöverg 110 | Phone: Home +46 (0)31 235576, CTH +46 (0)31 7723445 |
| S-417 21 Goteborg | WWW: http://www.cd.chalmers.se/~mort/ |
| Sweden | Email: mo...@cd.chalmers.se |

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:
: Doing CORBA in LPC is immensely stupid. My mechanism allows you to add

: CORBA hooks into LPC without all of the overhead required by CORBA.
: First, do you think writing a CORBA compliant ORB is so simple that
: every mud admin who wants the advantages of scaling across multiple
: CPUs will run out and write an LPC ORB?

You obviously know _nothing_ about CORBA. You could use an ORB off
the shelf. OmniORB is free, and there are others. You don't need
an LPC orb. Thank you for playing, please don't play again, please
go stick your head up your ass and fight for air.

: Second, most mud admins have a hard enough time getting the computer

: literate to write LPC code. Now you suggest they should learn IDL and
: understand distributed computing principles?

No. I suggest such functionality be mostly implemented in the driver,
and if and when it is necessary to let it be visible in LPC, it should
go in lib inherits. Also, once you have IDL mappings for LPC, you can
write a translator that will produce IDL from the LPC prototypes for an
object.

: You have got to be kidding me.

Nope; you just know nothing about CORBA but like to pretend you do.

: Then there is the issue of generating CORBA stubs and skeletons. The

: DLPC of which I am talking requires no extra compile process... it
: basically creates virtual skeletons and stubs within the driver.
: CORBA compliance will have you generating stubs and skeletons from IDL
: source. Yuck.

Can you say 'a thread in the driver that nobody ever sees?' I thought
you could. Moron. Also, in dynamic languages such as LPC, you can use
DII and DSI to automagically do the stubs and skeletons for you at
runtime. Oops, again, you are a clueless moron.

: : : * Concurrency (the hard part)

: : : Remote method calls in DLPC are blocking *for both muds* and both muds

: : Why? What a fantastically bad idea. Can you say 'pathetic performance?'
: : I suspect you are advocating this 'maximal lock' strategy because you
: : don't know better; suffice it to say that minimal lock strategies
: : provide vastly greater performance at high load and on networks where
: : tranmission delay is significant, and are really not that hard to
: : implement.

: Let me know when you have any idea you are talking about.

What a response. Go read a book on distributed design; it may well
be termed 'modern operating systems,' but either way, you'll find
that while I do in fact know what I'm talking about, you don't.

: : : LPC processes are assumed single threaded. The drivers themselves are

: : Since at lesat one LPC interpreter already supports LPC bindings to a
: : pthread library, this won't work, probably:)

: Then it would not support DLPC, would it? DUH.

Oh, that's brilliant. "If your LPC isn't a crusty old design, we don't
want you." Sorry, but threads are going to be a part of practically
any new LP server, and if you want to create a meaningless joke of a
standard, I suppose nobody would really try hard to stop you... heh.

: : : *Note* This means it is not a good idea to have a distributed system

: : : that is separated by unreliable networks.

: : No kidding. A better way to put it is that it means that unless by
: : distributed you mean in someone's basement, it won't work worth a
: : damn.

: Same with CORBA right now. Distributed computing over the Internet is
: simply not there yet. Best IMHO to deal with the problems we have today.

Excuse me? Netscape? CORBA hooks? Internet? Oh, yeah. Moron.

: : You just suggested passing arrays and mappings by value across a network

: : every time they are asked for. Do you in fact have any knowledge of
: : any distributed object system theory whatsoever, or are you blubbering
: : as usual about something you know nothing about?

: I told you before, I wrote a book on distributed client/server in
: Java. What are your credentials? I also happen to understand LPC
: pretty damn well.

There are a _lot_ of bad books about Java. What is your point?
You deliberately avoid the meat of my reply, which is that mappings
and arrays are really bad things to pass by value over a network.
The reason is that you know you are wrong. Only a complete moron
would even suggest it. My credentials? Mmm... ad hominem... if
my ideas are logically sound, which you have yet to even start in
on, it doesn't really matter who I am, does it? Hey, whilst I'm
at it, the whole 'book' bit strikes me as an argument from
authority. Why is it that you refuse to discuss content and insist
on engaging in attempts to make yourself look like you can't possibly
be wrong? Oh, it would be because you _are_ wrong.

: : I see you got through the first chapter of the O'Reilly book on RPC.
: : Congratulations.

: While you are checking that out, check out the O'Reilly book on JDBC
: and RMI (RMI being the IIOP compliant distributed computing API for
: Java). Guess who wrote it?

I'll look. A friend has a copy. BTW, RMI is not yet IIOP compliant;
apparently you don't nkow your own subject very well. As usual, a
moron. Continuation of your silly argument from authority... what
nonsense. If you can't deal in facts, why are you bothering?

: : You're suggesting implementing RPC using bad semantics on persistent

: : channels, and ignoring the people(CORBA) who've already done all of
: : this correctly and whose work would make this project much cleaner.
: : Other than distributing a mud, is there a single good idea in here?

: I am not suggesting RCP. I am suggesting about a distributed
: computing mechanism that maintains LPC symantics without burdening LPC
: developers with the complexity of distributed computing. In addition,

I'm glad you aren't suggesting RCP, because that's a protocol for copying
files between Unix machines that has nothing to do with the discussion
at hand. RPC, on the other hand, is exactly what lies at the core of
what you are discussing. By the way, your DLPC does not maintain LPC
semantics; passing arrays and mappings by value will cause inconsistencies
right away, because locally they are always references. If you can't
see the problem, you aren't thinking.

: I want potential CORBA and RMI interoperability, but I do not want to

: force it on people who do not need it.
: Are these concepts so alien to you?

Reinventing the wheel is indeed alien to me. BTW, when are you going
to propose doing this with DCOM?:)

: Why do you have to be a complete asshole to someone trying to start
: honest discussion?

Because he's full of it. Honest discussion does not include ad hominems,
arguments from authority, or completely wrong statements.

: : www.omg.org is your friend.

: Thanks, question is, do you have any friends?

None whatsoever, George, because as you well know, everyone on the
planet is afraid of offending you by admitting to knowing me. Get
over yourself.

[George Reese]

I thought you had me killfiled? This really disappoints me, because I
thought I was done having to respond to your complete ignorance.

John, you have not made one salient point that has been substantiated
by anyone in any of the mud newsgroups. Consider that these people
probably know more than you about these things, because you clearly
don't know jack shit about LPMuds or distributed computing.

John Adelsberger <j...@umr.edu> wrote:

: George Reese <bo...@imaginary.com> wrote:
: : Doing CORBA in LPC is immensely stupid. My mechanism allows you to add
: : CORBA hooks into LPC without all of the overhead required by CORBA.
: : First, do you think writing a CORBA compliant ORB is so simple that
: : every mud admin who wants the advantages of scaling across multiple
: : CPUs will run out and write an LPC ORB?

: You obviously know _nothing_ about CORBA. You could use an ORB off
: the shelf. OmniORB is free, and there are others. You don't need
: an LPC orb. Thank you for playing, please don't play again, please
: go stick your head up your ass and fight for air.

And this gets you what? You need to be able to bind *LPC* objects
remotely. Binding internal driver code gets you zippo.

: : Second, most mud admins have a hard enough time getting the computer

: : literate to write LPC code. Now you suggest they should learn IDL and
: : understand distributed computing principles?

: No. I suggest such functionality be mostly implemented in the driver,
: and if and when it is necessary to let it be visible in LPC, it should
: go in lib inherits. Also, once you have IDL mappings for LPC, you can
: write a translator that will produce IDL from the LPC prototypes for an
: object.

: : You have got to be kidding me.

: Nope; you just know nothing about CORBA but like to pretend you do.

Uh-huh. And you base this on what?

: : Then there is the issue of generating CORBA stubs and skeletons. The

: : DLPC of which I am talking requires no extra compile process... it
: : basically creates virtual skeletons and stubs within the driver.
: : CORBA compliance will have you generating stubs and skeletons from IDL
: : source. Yuck.

: Can you say 'a thread in the driver that nobody ever sees?' I thought
: you could. Moron. Also, in dynamic languages such as LPC, you can use
: DII and DSI to automagically do the stubs and skeletons for you at
: runtime. Oops, again, you are a clueless moron.

Whatever. What you state above so whimsically is not at all trivial,
and it certainly does not get you a lot. It is needed for CORBA
compliance, WHICH I HAVE ADVOCATED ALL ALONG, but doing CORBA from the
start is way too much trouble.

: : : : * Concurrency (the hard part)

: : : : Remote method calls in DLPC are blocking *for both muds* and both muds

: : : Why? What a fantastically bad idea. Can you say 'pathetic performance?'
: : : I suspect you are advocating this 'maximal lock' strategy because you
: : : don't know better; suffice it to say that minimal lock strategies
: : : provide vastly greater performance at high load and on networks where
: : : tranmission delay is significant, and are really not that hard to
: : : implement.

: : Let me know when you have any idea you are talking about.

: What a response. Go read a book on distributed design; it may well
: be termed 'modern operating systems,' but either way, you'll find
: that while I do in fact know what I'm talking about, you don't.

I said this before, but you seem to ignore it conveniently. I wrote a
book on the subject for O'Reilly and Associates.

By the way, do you ever intend to respond to the challenge I put to
you in another thread (before you supposedly killfiled me) to back up
any of your claims?

: : : : LPC processes are assumed single threaded. The drivers themselves are

: : : Since at lesat one LPC interpreter already supports LPC bindings to a
: : : pthread library, this won't work, probably:)

: : Then it would not support DLPC, would it? DUH.

: Oh, that's brilliant. "If your LPC isn't a crusty old design, we don't
: want you." Sorry, but threads are going to be a part of practically
: any new LP server, and if you want to create a meaningless joke of a
: standard, I suppose nobody would really try hard to stop you... heh.

What the hell do you know about what is going on? And if it turns out
that there is a lot of multi-threaded LPC work going on, then perhaps
it should be discussed.

BUT LISTEN TO THIS DIPSHIT:
This was something to begin discussion, not the final word. If what I
have suggested is not feasible, then it should be discussed. So far,
you have done nothing to suggest otherwise or to even provide a
reasonable course of action.

Instead, you have managed to tell someone who knows quite a bit about
distributed computing that he knows nothing about distributed
computing and then fuck all this, use CORBA. Not too fucking
productive if you ask me.

: : : : *Note* This means it is not a good idea to have a distributed system

: : : : that is separated by unreliable networks.

: : : No kidding. A better way to put it is that it means that unless by
: : : distributed you mean in someone's basement, it won't work worth a
: : : damn.

: : Same with CORBA right now. Distributed computing over the Internet is
: : simply not there yet. Best IMHO to deal with the problems we have today.

: Excuse me? Netscape? CORBA hooks? Internet? Oh, yeah. Moron.

Just because Netscape has a CORBA ORB does not mean that programming
against it is a good idea. I could go into detail on the proper
application profiles for distributed internet applications, but you
are clearly too fucking stupid to even understand the concept.

Suffice it to say, for most client/server type applications (such as a
mud) DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE YET.

: : : You just suggested passing arrays and mappings by value across a network

: : : every time they are asked for. Do you in fact have any knowledge of
: : : any distributed object system theory whatsoever, or are you blubbering
: : : as usual about something you know nothing about?

: : I told you before, I wrote a book on distributed client/server in
: : Java. What are your credentials? I also happen to understand LPC
: : pretty damn well.

: There are a _lot_ of bad books about Java. What is your point?

Yes, but mine is backed up by a publisher known for quality books
(O'Reilly and Associates) and is a book that has been getting
excellent feedback.

: You deliberately avoid the meat of my reply, which is that mappings

: and arrays are really bad things to pass by value over a network.
: The reason is that you know you are wrong. Only a complete moron
: would even suggest it.

I don't ignore it in the least. THERE IS ABSOLUTELY NOTHING WRONG
WITH PASSING MAPPINGS AND ARRAYS OVER A NETWORK. They do not
inherently take up significantly more bandwidth. And, as I stated in
another thread, almost all Nightmare, Lima, TMI-2, and Discworld muds
are doing it TODAY in the form of the I3 network.

Who exactly is the complete moron here?

: My credentials? Mmm... ad hominem... if

: my ideas are logically sound, which you have yet to even start in
: on, it doesn't really matter who I am, does it?

There is no logic to them. You have just made personal attacks on me
and blanket statements that are supposed be self-evident. Statements
such as 'only a complete moron would even suggest it (passing mappings
and arrays over a network)'.

: Hey, whilst I'm

: at it, the whole 'book' bit strikes me as an argument from
: authority. Why is it that you refuse to discuss content and insist
: on engaging in attempts to make yourself look like you can't possibly
: be wrong? Oh, it would be because you _are_ wrong.

I have made arguments. But when your arguments come down to saying I
am a moron who knows nothing about distributed computing, I think the
fact that I wrote a book on the subject does call into question your
judgment.

: : : I see you got through the first chapter of the O'Reilly book on RPC.
: : : Congratulations.

: : While you are checking that out, check out the O'Reilly book on JDBC
: : and RMI (RMI being the IIOP compliant distributed computing API for
: : Java). Guess who wrote it?

: I'll look. A friend has a copy. BTW, RMI is not yet IIOP compliant;
: apparently you don't nkow your own subject very well. As usual, a
: moron. Continuation of your silly argument from authority... what
: nonsense. If you can't deal in facts, why are you bothering?

Do you really think I don't know what the status of the RMI IIOP
binding? Where in the above can you derive that I don't know it?
This is a prime example of how much of a complete asshole you are. If
someone does not say X, then clearly they do not know X.

: : : You're suggesting implementing RPC using bad semantics on persistent

: : : channels, and ignoring the people(CORBA) who've already done all of
: : : this correctly and whose work would make this project much cleaner.
: : : Other than distributing a mud, is there a single good idea in here?

: : I am not suggesting RCP. I am suggesting about a distributed
: : computing mechanism that maintains LPC symantics without burdening LPC
: : developers with the complexity of distributed computing. In addition,

: I'm glad you aren't suggesting RCP, because that's a protocol for copying
: files between Unix machines that has nothing to do with the discussion
: at hand. RPC, on the other hand, is exactly what lies at the core of
: what you are discussing. By the way, your DLPC does not maintain LPC
: semantics; passing arrays and mappings by value will cause inconsistencies
: right away, because locally they are always references. If you can't
: see the problem, you aren't thinking.

No, you simply do not understand the way muds are written. It is VERY
BAD PRACTICE to write LPC code that relies on mapping/array data from
an external source not being a copy. Anything else means you probably
have a mud full of security holes.

: : I want potential CORBA and RMI interoperability, but I do not want to

: : force it on people who do not need it.
: : Are these concepts so alien to you?

: Reinventing the wheel is indeed alien to me. BTW, when are you going
: to propose doing this with DCOM?:)

Rhetorical nonsense.

: : Why do you have to be a complete asshole to someone trying to start
: : honest discussion?

: Because he's full of it. Honest discussion does not include ad hominems,
: arguments from authority, or completely wrong statements.

Show any place in the original post that had any of the above.

: : : www.omg.org is your friend.

: : Thanks, question is, do you have any friends?

: None whatsoever, George, because as you well know, everyone on the
: planet is afraid of offending you by admitting to knowing me. Get
: over yourself.

You must be kidding. This sentence above all else shows what kind of
fool you are.

[Kris Van Hees]

I reply to only one small aspect of the posting, mostly since the rest is
so offensive and brutal, it's not something I even want to get involved
with.

John Adelsberger <j...@umr.edu> wrote:

: By the way, your DLPC does not maintain LPC

: semantics; passing arrays and mappings by value will cause inconsistencies
: right away, because locally they are always references. If you can't
: see the problem, you aren't thinking.

This is stated wrong. Having local handling done through references and
remote through value passing isn't a particularly semantic inconsistency.
By making array and mapping passing through unter-object function calls a
pass-by-value operation, you get back on track.

Since the data portion of the state of an object is supposed to be well
encapsulated (and hidden) from other objects, passing arrays and mappings
by reference between objects in itself is doubtful practise. In DGD, this
was changed after many discussions between Dworkin and myself while doing
work for my thesis, without really changing the mechanisms much. Arrays
and mapppings get passed as references over all function calls, but at the
end of an execution thread, all references to arrays and mappings in other
objects (the state of one object containing a reference to data in another
object) are turned into local copies.

It is a hybrid solution, but defendable and it works very well.

Yet, making all inter-object (and remote) function calls use pass-by-value
is the most clean semantical view.

Aedil

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:

<Referring to passing arrays/mappings by value across a network>

: Ya moron, 100+ muds are already doing it via Intermud 3.

Intermud is little used even on muds where it exists. Rarely does it
involve passing arrays or mappings of any size whatosever. Even so,
it is _way_ too slow. I think you just made my point. Thanks.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: George Reese <bo...@imaginary.com> wrote:

: <Referring to passing arrays/mappings by value across a network>

: : Ya moron, 100+ muds are already doing it via Intermud 3.

: Intermud is little used even on muds where it exists. Rarely does it
: involve passing arrays or mappings of any size whatosever. Even so,
: it is _way_ too slow. I think you just made my point. Thanks.

Please provide proof of ANY of the following:
a) Intermud is not widely used
b) It rarely involves passing arrays or mappings
c) It is slow (I am not even gonna hold you to _way_ too slow)

FYI:
a) There is constant traffic of multiple packet types (used by over
100 muds)
b) ALL INTERMUD DATA is in the form of an array or mapping
c) It is very fast.

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:

: Again, I am not suggesting using the Net for connectivity. A

: distributed mud should be one where all the components are on a common
: LAN.

Then it is so limited that standardizing it is pointless. You only
need a standard if said distributed mud will be run on a variety of
drivers; why would admins at one site run more than one different
driver? Moreover, it is so limited as to be nigh on useless. And,
hey, if you're running NT(yech) Solaris, or Digital Unix(or any of
the free Unixes, before long now) you don't need this sort of thing
to do what you want; just use a clustering package on your machines.

Only across such a network as the Internet is a standard needed and
only across such a network is the application layer the appropriate
place to put the distribution logic.

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:

<although not to me>

: Do you have a proposal for a more generic, non-LAN distributed LPC?

: If so, please let's discuss it. This issue has not been solved
: reasonably for either DCOM or CORBA. I do not think I personally am
: ready to tackle that issue. And, scalability, IMHO, is the one use
: that is not based on coolness.

When you say reasonably, the only thing I can figure that you mean is
speed of remote object access. The problem is similar to one I am
_very_ familiar with, but actually a bit nastier. In distributed
filesystems, the answer is to cache directories and commonly accessed
files. However, caching data that can change at any time isn't much of
an advantage unless it is faster to send timestamps than the data, which
is questionable, given IPV4, and certainly bs given IPV6, unless the
data in question is farking huge for an LPC datum. One possibility
would be to compress the data if it _is_ farking huge, but as far as
latency goes, there _is_ no solution; it will be slow until the network
is faster. Of course, IPV6 will or at least should reduce latency and
other delays a bit through things like resource reservation, but it
won't really be in common use for a few more years, and you won't be
assured of an end to end v6 connection for probably a decade now...

: : way LPC dialects exist now, making a DLPC standard which covers them all is

: : going to be tricky. E.g. differences in datatypes. Then again, since you

: I do not think there are any real issues with cross-driver

: portability. The biggest issue are floats.

Mmm... IEEE standard fp... mmm... CORBA... It works across languages
as diverse as C and Smalltalk; it'll work for LPC:)

[John Viega]

In article <5s5tfj$37q$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:
> John Adelsberger <j...@umr.edu> wrote:
> : George Reese <bo...@imaginary.com> wrote:
>
> : <Referring to passing arrays/mappings by value across a network>
>
> : : Ya moron, 100+ muds are already doing it via Intermud 3.
>
> : Intermud is little used even on muds where it exists. Rarely does it
> : involve passing arrays or mappings of any size whatosever. Even so,
> : it is _way_ too slow. I think you just made my point. Thanks.
>
> Please provide proof of ANY of the following:
> a) Intermud is not widely used
> b) It rarely involves passing arrays or mappings
> c) It is slow (I am not even gonna hold you to _way_ too slow)
>
> FYI:
> a) There is constant traffic of multiple packet types (used by over
> 100 muds)
> b) ALL INTERMUD DATA is in the form of an array or mapping
> c) It is very fast.
>

John, I'm sorry, but George is 100% right here. First of all, I3 is
only passing small ammounts of data between muds, and it's all done
over a TCP connection using arrays and a couple of mappings. None of
it is slow in the slightest.

Your statement that no one would want to pass mappings and/or arrays
over a network by value is *completely* befuddling. First of all,
it's usually the case for I3 that you probably want to use all data in
the structure you're getting. What good is a reference to some remote
structure going to do you? The remote mud has to hold on to it until
you tell it to go away, plus you'd potentially incur a lot of delay
from latency by requesting each field seperately. Here's an example:
spudboy@Lima sends you a tell. Your mud gets a reference to it in
time X. You could have had all the info associated w/ that tell in
time pretty close to X, but NO, you have to go and request all the
data fields, because all you have is a bleeding reference to a remote
structure, and you end up spending 300% more time on the network than
you needed to, minimum.

There are very few times where you don't want most if not all of the
information in a packet as it's coming in w/ I3. You might not need
the entire mudlist at once, but why not cache it locally anyway,
instead of incuring the delay of dereferencing the whole thing over a
network, and then processing it, when someone asks for a mudlist?

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: George Reese <bo...@imaginary.com> wrote:

: <although not to me>

: : Do you have a proposal for a more generic, non-LAN distributed LPC?
: : If so, please let's discuss it. This issue has not been solved
: : reasonably for either DCOM or CORBA. I do not think I personally am
: : ready to tackle that issue. And, scalability, IMHO, is the one use
: : that is not based on coolness.

: When you say reasonably, the only thing I can figure that you mean is
: speed of remote object access. The problem is similar to one I am
: _very_ familiar with, but actually a bit nastier. In distributed
: filesystems, the answer is to cache directories and commonly accessed
: files. However, caching data that can change at any time isn't much of
: an advantage unless it is faster to send timestamps than the data, which
: is questionable, given IPV4, and certainly bs given IPV6, unless the
: data in question is farking huge for an LPC datum. One possibility
: would be to compress the data if it _is_ farking huge, but as far as
: latency goes, there _is_ no solution; it will be slow until the network
: is faster. Of course, IPV6 will or at least should reduce latency and
: other delays a bit through things like resource reservation, but it
: won't really be in common use for a few more years, and you won't be
: assured of an end to end v6 connection for probably a decade now...

WTF does this have to do with anything? These issues have absolutely
nothing to do with one another.

How long are you going to continue yammering your nonsense?

: : : way LPC dialects exist now, making a DLPC standard which covers them all is

: : : going to be tricky. E.g. differences in datatypes. Then again, since you

: : I do not think there are any real issues with cross-driver
: : portability. The biggest issue are floats.

: Mmm... IEEE standard fp... mmm... CORBA... It works across languages
: as diverse as C and Smalltalk; it'll work for LPC:)

I count on it working with LPC. If you were not hellbent on being an
idiot, you might remember me saying I *want* CORBA compatibility. The
fact remains that CORBA is simply way too much to be the solution for
most mud scalability issues.

[John Adelsberger]

Distribution:

George Reese <bo...@imaginary.com> wrote:
: John Adelsberger <j...@umr.edu> wrote:

<about distributed fs, distributed object systems, and IP>

: WTF does this have to do with anything? These issues have absolutely

: nothing to do with one another.

If you can't see the interrelationship between the network protocol and
performance, or the similarity of the design problems in dist fs and
dist obj sys, you aren't worth the oxygen your body uses.

: I count on it working with LPC. If you were not hellbent on being an

: idiot, you might remember me saying I *want* CORBA compatibility. The
: fact remains that CORBA is simply way too much to be the solution for
: most mud scalability issues.

Yeah, why go with an open standard that already works and for which all
the work could be complete in a couple of weeks when you can invent your
own standard, gateway it to the real standard, and do so much more work
and look like a bigshot? Luser.

(For those who don't know CORBA, it does _exactly_ what Reese wants to
do, but he didn't invent it, so it isn't good enough.)

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:
: I thought you had me killfiled? This really disappoints me, because I

: thought I was done having to respond to your complete ignorance.

Since you actually replied, and not every reply consisted of the kind
of rubbish represented by the above two sentences, I removed the killfile
until either you decide to ignore me or I get sick of arguing with you
on this subject or until I actually decide to just go and write CORBA
bindings for LPC and be done with it.

: John, you have not made one salient point that has been substantiated

: by anyone in any of the mud newsgroups. Consider that these people
: probably know more than you about these things, because you clearly
: don't know jack shit about LPMuds or distributed computing.

You keep saying this(that I don't know jack shit.) Nevertheless, while
I can point to substantial education in distributed computing and
several muds and mudlibs that bear my mark and one that is entirely
mine, you have one pisspoor mudlib, a book on database stuff that
happens to include several forms of the word 'distribute,'
and a big mouth. You have yet to counter a single of my points in a
logical and non-ad-hominem manner, excepting a few to the responses
to which I have already replied in a similar fact oriented fashion.
What is wrong with you?

: John Adelsberger <j...@umr.edu> wrote:

: : You obviously know _nothing_ about CORBA. You could use an ORB off

: : the shelf. OmniORB is free, and there are others. You don't need
: : an LPC orb. Thank you for playing, please don't play again, please
: : go stick your head up your ass and fight for air.

: And this gets you what? You need to be able to bind *LPC* objects
: remotely. Binding internal driver code gets you zippo.

Here, I'll speak loudly for clarity:

YOU CAN USE A FREE ORB WRITTEN IN WHATEVER, WRITE LPC BINDINGS AND AN
IDL->LPC TRANSLATOR, AND BIND LPC OBJECTS REMOTELY. YOU DO NOT NEED
AN ORB WRITTEN IN LPC. YOU _WOULD_ NEED SOME DRIVER SUPPORT.

Did you get it that time? If not, go and read more about CORBA,
because if that didn't clarify, you don't know CORBA at all.

: : : Second, most mud admins have a hard enough time getting the computer

: : : literate to write LPC code. Now you suggest they should learn IDL and
: : : understand distributed computing principles?

: : No. I suggest such functionality be mostly implemented in the driver,
: : and if and when it is necessary to let it be visible in LPC, it should
: : go in lib inherits. Also, once you have IDL mappings for LPC, you can
: : write a translator that will produce IDL from the LPC prototypes for an
: : object.

: : : You have got to be kidding me.

It's been done for Python, C, C++, Ada, it's being done for Perl, and there
are about half a dozen others. Do you in fact know anything about CORBA
at all, or is it just a buzzword to you?

: : Nope; you just know nothing about CORBA but like to pretend you do.

: Uh-huh. And you base this on what?

You repeatedly making claims about CORBA that are false.

: : : Then there is the issue of generating CORBA stubs and skeletons. The

: : : DLPC of which I am talking requires no extra compile process... it
: : : basically creates virtual skeletons and stubs within the driver.
: : : CORBA compliance will have you generating stubs and skeletons from IDL
: : : source. Yuck.

: : Can you say 'a thread in the driver that nobody ever sees?' I thought
: : you could. Moron. Also, in dynamic languages such as LPC, you can use
: : DII and DSI to automagically do the stubs and skeletons for you at
: : runtime. Oops, again, you are a clueless moron.

: Whatever. What you state above so whimsically is not at all trivial,
: and it certainly does not get you a lot. It is needed for CORBA
: compliance, WHICH I HAVE ADVOCATED ALL ALONG, but doing CORBA from the
: start is way too much trouble.

Excuse me. Until I mentioned CORBA, you never said the word in this
newsgroup, and certainly not in the DLPC thread. When you did mention
it, it was to attack it as a bad idea. There are archives; you can't
lie about this.

As for trivial, no, it isn't trivial; neither is the existing MudOS
driver. It isn't _that_ hard if you build it in steps; the Python
stuff was done in an amazing hurry. Automatic stub and skeleton
generation, btw, is not required for compliance; to my knowledge,
only the more dynamic languages(as opposed to C++, C, and Ada, for
instance) actually support doing it.

: : : Let me know when you have any idea you are talking about.

: : What a response. Go read a book on distributed design; it may well
: : be termed 'modern operating systems,' but either way, you'll find
: : that while I do in fact know what I'm talking about, you don't.

: I said this before, but you seem to ignore it conveniently. I wrote a
: book on the subject for O'Reilly and Associates.

That book is on JDBC, which is a database connectivity library. It has
only peripheral connection to distributed design, and in fact, Java's
RMI and related stuff are designed specifically so that most of the
distributed design knowledge out there isn't needed by users of Java.
Perhaps if you'd just be honest?

: By the way, do you ever intend to respond to the challenge I put to

: you in another thread (before you supposedly killfiled me) to back up
: any of your claims?

The OMG website does so nicely for this thread. Do you really expect
me ot quote them when you can use your favorite web browser?

: : Oh, that's brilliant. "If your LPC isn't a crusty old design, we don't

: : want you." Sorry, but threads are going to be a part of practically
: : any new LP server, and if you want to create a meaningless joke of a
: : standard, I suppose nobody would really try hard to stop you... heh.

: What the hell do you know about what is going on? And if it turns out
: that there is a lot of multi-threaded LPC work going on, then perhaps
: it should be discussed.

The only new LPC server in the last couple of years is threaded. The
only other one that I know of that is getting underway(a project of mine)
is also threaded. That's 100% of new development, as opposed to
improvements in old stuff(which old stuff is unlikely to get threaded
since it requires such major changes.) Yes, I may have missed somone's
new driver; if so, I apologize, but you must be hiding it fairly well:)

: BUT LISTEN TO THIS DIPSHIT:

: This was something to begin discussion, not the final word. If what I
: have suggested is not feasible, then it should be discussed. So far,
: you have done nothing to suggest otherwise or to even provide a
: reasonable course of action.

You keep saying this.

: Instead, you have managed to tell someone who knows quite a bit about

: distributed computing that he knows nothing about distributed
: computing and then fuck all this, use CORBA. Not too fucking
: productive if you ask me.

Since CORBA does in fact do everything you want your DLPC to do, and
then some, and since a 'more than good enough' implementation isn't
even an overlarge project for, say, a couple of dedicated codefreaks
and a few months, I'd say the only productive step left to take is
to grab the CORBA standards documents, example stuff(python would
be good to look at) and some free CORBA software and get moving.
If nobody else does, sooner or later, I will, I imagine.

: Suffice it to say, for most client/server type applications (such as a

: mud) DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE YET.

Only because of latency and bandwidth. The latter is being solved by
infusion of money, the former by IPV6, ATM, and a couple of other
technologies. Designing standards now for IPV4 and today's bandwidth
is a joke; by the time they'd get widely used, they'd be outdated.

: I don't ignore it in the least. THERE IS ABSOLUTELY NOTHING WRONG

: WITH PASSING MAPPINGS AND ARRAYS OVER A NETWORK. They do not
: inherently take up significantly more bandwidth. And, as I stated in
: another thread, almost all Nightmare, Lima, TMI-2, and Discworld muds
: are doing it TODAY in the form of the I3 network.

Those are tiny arrays and mappings. Besides, the biggest problem I
have with it, as I've said before, is that it makes LPC procedure
call semantics different for local and remote calls, which you, as
a distributed computing guru, should know is a very bad idea.

: Who exactly is the complete moron here?

Probably neither of us, but your world seems awfully small to me.

: : I'll look. A friend has a copy. BTW, RMI is not yet IIOP compliant;

: : apparently you don't nkow your own subject very well. As usual, a
: : moron. Continuation of your silly argument from authority... what
: : nonsense. If you can't deal in facts, why are you bothering?

: Do you really think I don't know what the status of the RMI IIOP
: binding? Where in the above can you derive that I don't know it?

Well, you said it was IIOP compliant; in fact it is not. This would
imply either that you are lying or that you are ignorant. Which is
it?

: This is a prime example of how much of a complete asshole you are. If
: someone does not say X, then clearly they do not know X.

Saying 'RMI is IIOP compliant' when it is not so is not the same as
omitting information.

: No, you simply do not understand the way muds are written. It is VERY

: BAD PRACTICE to write LPC code that relies on mapping/array data from
: an external source not being a copy. Anything else means you probably
: have a mud full of security holes.

I'm not arguing about how muds are written. I'm arguing about how
RPC is implemented. Even if the language allows you to do bad things,
if you intend to write RPC hooks for it, they should be consistent in
those bad things; otherwise, you have semantic and syntactic garbage.

Of course, you could always just change LPC, but that's a different
can of worms.

[Kris Van Hees]

-----BEGIN PGP SIGNED MESSAGE-----

George Reese <bo...@imaginary.com> wrote:
: John Adelsberger <j...@umr.edu> wrote:

: : The only new LPC server in the last couple of years is threaded. The

: : only other one that I know of that is getting underway(a project of mine)
: : is also threaded. That's 100% of new development, as opposed to
: : improvements in old stuff(which old stuff is unlikely to get threaded
: : since it requires such major changes.) Yes, I may have missed somone's
: : new driver; if so, I apologize, but you must be hiding it fairly well:)

: First, IMHO, anyone writing a new LPMud driver is wasting their time.
: DOH! That would be you! Someone who has produces zilcho and yet talks
: up a storm. Wake us all up when you actually have something.

Yes, writing an LP-MUD driver is a bit pointless these days, though writing
one for a derived language, or at least based on LPC, isn't that pointless.
Pike is a nice example, and I believe it is threaded. Abyss will be another
example (though not developed for MUD use in mind). Then again, Abyss will
at first provide concurrency on the LPC level rather than at the driver
level.

I don't consider writing Abyss as wasting my time. Java for example isn't
sufficient for what I want; actually Alef and Limbo are about the closest
in concept.

: Second, DGD, the most recent driver publically available, is becoming
: multi-threaded.

It is, however there is no known timeframe on when this will happen, as
far as I have seen. Hopefully in the very near future.

: Pointless. LPC needs to die.

Perhaps, perhaps not. It serves quite nicely as basis for other
languages, such as Pike and Abyss.

Aedil

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBM/B9++ph1XpRBQ6dAQGQGAP+P2kJa/CdJVLkVCjQEHjxRolZurmzv55I
t4NwB62UBxV46ZvQDTpZlNdWELC76bSOebvIWCn5VftfWo8g18chSjUqloLUHA5o
MU8R5xdskT6MbX2bA1ztWhCrzL6gRcqCCj/vnvy28rL7UxL9jgZyi1S0sBvwwPNt
9Wqkz4ZpyJk=
=wGE7
-----END PGP SIGNATURE-----

[George Reese]

John Adelsberger <j...@umr.edu> wrote:

: George Reese <bo...@imaginary.com> wrote:
: : I thought you had me killfiled? This really disappoints me, because I
: : thought I was done having to respond to your complete ignorance.

: Since you actually replied, and not every reply consisted of the kind
: of rubbish represented by the above two sentences, I removed the killfile
: until either you decide to ignore me or I get sick of arguing with you
: on this subject or until I actually decide to just go and write CORBA
: bindings for LPC and be done with it.

Oh please do. It would be about time you actually did something.

: : John, you have not made one salient point that has been substantiated

: : by anyone in any of the mud newsgroups. Consider that these people
: : probably know more than you about these things, because you clearly
: : don't know jack shit about LPMuds or distributed computing.

: You keep saying this(that I don't know jack shit.) Nevertheless, while
: I can point to substantial education in distributed computing and
: several muds and mudlibs that bear my mark and one that is entirely
: mine,

Why does no one in the LP community know who the hell you are then?

: you have one pisspoor mudlib,

You keep saying that, but most people completely disagree. If you are
going to keep saying this, you better back it up.

: a book on database stuff that

: happens to include several forms of the word 'distribute,'

Evidently you did not read it. The book is about building three-tier
distributed applications that use JDBC and RMI. I know what it is
about since I wrote it.

Please let me know how this compares to your little 'education in
distributed computing'.

Uh, write a book or read one... which do you think is the more
comprehensive background?

: and a big mouth.

Last I checked, having a big mouth was neither a crime nor did it mean
you were not right.

: You have yet to counter a single of my points in a

: logical and non-ad-hominem manner, excepting a few to the responses
: to which I have already replied in a similar fact oriented fashion.
: What is wrong with you?

Actually, I have several times. And you have chosen several times to
ignore any direct arguments I make. Instead you go for intentional
misreadings of my words or worse, you are just a perfect example of
how a little knowledge can be dangerous.

If your news server sucks, go back and read deja news. There was one
major post in which I asked you directly three questions. And that
was before you ostensibly killfiled me.

: : John Adelsberger <j...@umr.edu> wrote:

: : : You obviously know _nothing_ about CORBA. You could use an ORB off
: : : the shelf. OmniORB is free, and there are others. You don't need
: : : an LPC orb. Thank you for playing, please don't play again, please
: : : go stick your head up your ass and fight for air.

: : And this gets you what? You need to be able to bind *LPC* objects
: : remotely. Binding internal driver code gets you zippo.

: Here, I'll speak loudly for clarity:

: YOU CAN USE A FREE ORB WRITTEN IN WHATEVER, WRITE LPC BINDINGS AND AN
: IDL->LPC TRANSLATOR, AND BIND LPC OBJECTS REMOTELY. YOU DO NOT NEED
: AN ORB WRITTEN IN LPC. YOU _WOULD_ NEED SOME DRIVER SUPPORT.

: Did you get it that time? If not, go and read more about CORBA,
: because if that didn't clarify, you don't know CORBA at all.

Hey, dipshit, where did I say the ORB had to be written in LPC. An
LPC ORB is an ORB that *supports* LPC objects: i.e. some driver
support.

: : : : Second, most mud admins have a hard enough time getting the computer

: : : : literate to write LPC code. Now you suggest they should learn IDL and
: : : : understand distributed computing principles?

: : : No. I suggest such functionality be mostly implemented in the driver,
: : : and if and when it is necessary to let it be visible in LPC, it should
: : : go in lib inherits. Also, once you have IDL mappings for LPC, you can
: : : write a translator that will produce IDL from the LPC prototypes for an
: : : object.

: : : : You have got to be kidding me.

: It's been done for Python, C, C++, Ada, it's being done for Perl, and there
: are about half a dozen others. Do you in fact know anything about CORBA
: at all, or is it just a buzzword to you?

All those languages are not designed to make mud building simple. LPC
is. CORBA is non-trivial for the programmer. What I suggest is. Why
do you think JavaSoft came up with RMI in the first place?

: : : Nope; you just know nothing about CORBA but like to pretend you do.

: : Uh-huh. And you base this on what?

: You repeatedly making claims about CORBA that are false.

No, you make claims for me and then disprove them. Woo woo. That
only proves you like to argue with yourself like a buffoon before the
world.

: : : : Then there is the issue of generating CORBA stubs and skeletons. The

: : : : DLPC of which I am talking requires no extra compile process... it
: : : : basically creates virtual skeletons and stubs within the driver.
: : : : CORBA compliance will have you generating stubs and skeletons from IDL
: : : : source. Yuck.

: : : Can you say 'a thread in the driver that nobody ever sees?' I thought
: : : you could. Moron. Also, in dynamic languages such as LPC, you can use
: : : DII and DSI to automagically do the stubs and skeletons for you at
: : : runtime. Oops, again, you are a clueless moron.

: : Whatever. What you state above so whimsically is not at all trivial,
: : and it certainly does not get you a lot. It is needed for CORBA
: : compliance, WHICH I HAVE ADVOCATED ALL ALONG, but doing CORBA from the
: : start is way too much trouble.

: Excuse me. Until I mentioned CORBA, you never said the word in this
: newsgroup, and certainly not in the DLPC thread. When you did mention
: it, it was to attack it as a bad idea. There are archives; you can't
: lie about this.

From the first time you mentioned it, I stated that is what I wanted.
In fact, MY PERSONAL REASONING is to scale my own mud, which means
long term moving away from LPC to Java. There for I *need* IIOP
bindings. Just because I did not say it in my first post does not
mean I was not thinking it. This is another perfect example of you
taking things I don't say as proof I do not know/have never thought
them. John, YOUR LOGIC IS WANTING.

: As for trivial, no, it isn't trivial; neither is the existing MudOS

: driver. It isn't _that_ hard if you build it in steps; the Python
: stuff was done in an amazing hurry. Automatic stub and skeleton
: generation, btw, is not required for compliance; to my knowledge,
: only the more dynamic languages(as opposed to C++, C, and Ada, for
: instance) actually support doing it.

So what?

: : : : Let me know when you have any idea you are talking about.

: : : What a response. Go read a book on distributed design; it may well
: : : be termed 'modern operating systems,' but either way, you'll find
: : : that while I do in fact know what I'm talking about, you don't.

: : I said this before, but you seem to ignore it conveniently. I wrote a
: : book on the subject for O'Reilly and Associates.

: That book is on JDBC, which is a database connectivity library. It has
: only peripheral connection to distributed design, and in fact, Java's
: RMI and related stuff are designed specifically so that most of the
: distributed design knowledge out there isn't needed by users of Java.
: Perhaps if you'd just be honest?

Perhaps if you actually read the book. It is on distributed
three-tier computing. JDBC is one part of it, RMI is the other part.
And you evidently don't know jack about RMI as well. RMI is designed
to preserve the Java semantics in distributed computing. It is not
designed to hide distributed design knowldge. In fact, it exposes
distributed design *more* than CORBA because it draws a much clearly
distinction between local objects and remote objects than CORBA.

What RMI does not have is an IDL. It also supports some things CORBA
does not, such as distributed garbage collection and full object
semantics (more important, full Java semantics).

: : By the way, do you ever intend to respond to the challenge I put to

: : you in another thread (before you supposedly killfiled me) to back up
: : any of your claims?

: The OMG website does so nicely for this thread. Do you really expect
: me ot quote them when you can use your favorite web browser?

So you ignore an unrelated challenge based on some quote on some web
site? I really don't give a damn.

: : : Oh, that's brilliant. "If your LPC isn't a crusty old design, we don't

: : : want you." Sorry, but threads are going to be a part of practically
: : : any new LP server, and if you want to create a meaningless joke of a
: : : standard, I suppose nobody would really try hard to stop you... heh.

: : What the hell do you know about what is going on? And if it turns out
: : that there is a lot of multi-threaded LPC work going on, then perhaps
: : it should be discussed.

: The only new LPC server in the last couple of years is threaded. The
: only other one that I know of that is getting underway(a project of mine)
: is also threaded. That's 100% of new development, as opposed to
: improvements in old stuff(which old stuff is unlikely to get threaded
: since it requires such major changes.) Yes, I may have missed somone's
: new driver; if so, I apologize, but you must be hiding it fairly well:)

First, IMHO, anyone writing a new LPMud driver is wasting their time.

DOH! That would be you! Someone who has produces zilcho and yet talks
up a storm. Wake us all up when you actually have something.

Second, DGD, the most recent driver publically available, is becoming
multi-threaded.

: : BUT LISTEN TO THIS DIPSHIT:

: : This was something to begin discussion, not the final word. If what I
: : have suggested is not feasible, then it should be discussed. So far,
: : you have done nothing to suggest otherwise or to even provide a
: : reasonable course of action.

: You keep saying this.

Because you keep saying nothing.

: : Instead, you have managed to tell someone who knows quite a bit about

: : distributed computing that he knows nothing about distributed
: : computing and then fuck all this, use CORBA. Not too fucking
: : productive if you ask me.

: Since CORBA does in fact do everything you want your DLPC to do, and
: then some, and since a 'more than good enough' implementation isn't
: even an overlarge project for, say, a couple of dedicated codefreaks
: and a few months, I'd say the only productive step left to take is
: to grab the CORBA standards documents, example stuff(python would
: be good to look at) and some free CORBA software and get moving.
: If nobody else does, sooner or later, I will, I imagine.

And, as I said, the implementation is a lot less trivial than you
think and the overhead for mud developers is way too high to be
worthwhile as a starting point.

Now you may disagree with that fact, but if this is our point of
contention, then your original post in this thread was more than pure
crap as this point of contention does not merit the venom you have put
forth.

: : Suffice it to say, for most client/server type applications (such as a

: : mud) DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE YET.

: Only because of latency and bandwidth. The latter is being solved by
: infusion of money, the former by IPV6, ATM, and a couple of other
: technologies. Designing standards now for IPV4 and today's bandwidth
: is a joke; by the time they'd get widely used, they'd be outdated.

Which means: DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE
YET. So do you finally get it?

: : I don't ignore it in the least. THERE IS ABSOLUTELY NOTHING WRONG

: : WITH PASSING MAPPINGS AND ARRAYS OVER A NETWORK. They do not
: : inherently take up significantly more bandwidth. And, as I stated in
: : another thread, almost all Nightmare, Lima, TMI-2, and Discworld muds
: : are doing it TODAY in the form of the I3 network.

: Those are tiny arrays and mappings. Besides, the biggest problem I
: have with it, as I've said before, is that it makes LPC procedure
: call semantics different for local and remote calls, which you, as
: a distributed computing guru, should know is a very bad idea.

It does not change the semantics. In LPC, you should never treat
mappings or arrars as references. Furthermore, what the hell do you
know about I3? I3 mappings are representative of the type of
mappings, if any, you would be passing through remote method calls.

Who the hell uses large mappings as arguments or return values?

: : Who exactly is the complete moron here?

: Probably neither of us, but your world seems awfully small to me.

Oh, but you started in on me and have been making 'moron' claims of me
from day one. Should we look at this as an admission that you are
full of shit?

: : : I'll look. A friend has a copy. BTW, RMI is not yet IIOP compliant;

: : : apparently you don't nkow your own subject very well. As usual, a
: : : moron. Continuation of your silly argument from authority... what
: : : nonsense. If you can't deal in facts, why are you bothering?

: : Do you really think I don't know what the status of the RMI IIOP
: : binding? Where in the above can you derive that I don't know it?

: Well, you said it was IIOP compliant; in fact it is not. This would
: imply either that you are lying or that you are ignorant. Which is
: it?

It means that the standard for Java computing is IIOP compliant. The
current implementation is not. I am therefore neither lying nor being
ignorant.

: : This is a prime example of how much of a complete asshole you are. If

: : someone does not say X, then clearly they do not know X.

: Saying 'RMI is IIOP compliant' when it is not so is not the same as
: omitting information.

RMI is a standard for Java distributed objects. The standard is IIOP
compliant. That the current implementation is not is completely
irrelecant to my point.

: : No, you simply do not understand the way muds are written. It is VERY

: : BAD PRACTICE to write LPC code that relies on mapping/array data from
: : an external source not being a copy. Anything else means you probably
: : have a mud full of security holes.

: I'm not arguing about how muds are written. I'm arguing about how
: RPC is implemented. Even if the language allows you to do bad things,
: if you intend to write RPC hooks for it, they should be consistent in
: those bad things; otherwise, you have semantic and syntactic garbage.

And since LPC is not a true object language, you are left with some
useless ugliness in the name of 'semantic consistency'. No one else
seems to support your zealotry for semantic consistency either.

: Of course, you could always just change LPC, but that's a different
: can of worms.

Pointless. LPC needs to die.

--

[Felix A. Croes]

George Reese <bo...@imaginary.com> wrote:
> John Adelsberger <j...@umr.edu> wrote:

>[...]

> In fact, MY PERSONAL REASONING is to scale my own mud, which means
> long term moving away from LPC to Java. There for I *need* IIOP
> bindings.

This is interesting. Are you saying that you've given up on the idea of
"Distributed LPC" as a way to scale your mud?

>[...]

> : The only new LPC server in the last couple of years is threaded. The
> : only other one that I know of that is getting underway(a project of mine)
> : is also threaded. That's 100% of new development, as opposed to
> : improvements in old stuff(which old stuff is unlikely to get threaded
> : since it requires such major changes.) Yes, I may have missed somone's
> : new driver; if so, I apologize, but you must be hiding it fairly well:)

The only new LPC server that was released in the last few years is Pike,
which never was a genuine MUD server to begin with and which is evolving
further and further away from it. Pike's rudimentary thread support (with
a mutex lock in the interpreter, smirk) could be added to any of the other
LPC servers without much difficulty.

> First, IMHO, anyone writing a new LPMud driver is wasting their time.
> DOH! That would be you! Someone who has produces zilcho and yet talks
> up a storm. Wake us all up when you actually have something.

> Second, DGD, the most recent driver publically available, is becoming
> multi-threaded.

But not in any way that is visible from within the mud; merely as a
speedup on a multiprocessor platform.

>[...]

> And since LPC is not a true object language, you are left with some
> useless ugliness in the name of 'semantic consistency'. No one else
> seems to support your zealotry for semantic consistency either.

What, then, is a true object language?

> : Of course, you could always just change LPC, but that's a different
> : can of worms.

> Pointless. LPC needs to die.

A queer conclusion in a thread about "Distributed LPC", started by you.
Would you care to elaborate?

Dworkin

[George Reese]

Felix A. Croes <dwo...@visi.com> wrote:
: George Reese <bo...@imaginary.com> wrote:

: > John Adelsberger <j...@umr.edu> wrote:
: >[...]

: > In fact, MY PERSONAL REASONING is to scale my own mud, which means

: > long term moving away from LPC to Java. There for I *need* IIOP
: > bindings.

: This is interesting. Are you saying that you've given up on the idea of

: "Distributed LPC" as a way to scale your mud?

No, this is part of the scaling plan.

Specifically, I never had any actual belief anyone would do this today
or in the near future :) Given my personal desires to a) scale mud
mud and b) migrate to Java, this posting I made fits those needs.
Certainly a full CORBA binding would have worked as well, but I
assumed my b) would be to most people dubious and tried to focus on
common needs, which is a). In other words, I treated b) as a personal
bonus if it could be done while meeting needs most people would have.

: >[...]
: > : The only new LPC server in the last couple of years is threaded. The

: > : only other one that I know of that is getting underway(a project of mine)
: > : is also threaded. That's 100% of new development, as opposed to
: > : improvements in old stuff(which old stuff is unlikely to get threaded
: > : since it requires such major changes.) Yes, I may have missed somone's
: > : new driver; if so, I apologize, but you must be hiding it fairly well:)

: The only new LPC server that was released in the last few years is Pike,

: which never was a genuine MUD server to begin with and which is evolving
: further and further away from it. Pike's rudimentary thread support (with
: a mutex lock in the interpreter, smirk) could be added to any of the other
: LPC servers without much difficulty.

: > First, IMHO, anyone writing a new LPMud driver is wasting their time.

: > DOH! That would be you! Someone who has produces zilcho and yet talks
: > up a storm. Wake us all up when you actually have something.

: > Second, DGD, the most recent driver publically available, is becoming
: > multi-threaded.

: But not in any way that is visible from within the mud; merely as a

: speedup on a multiprocessor platform.

: >[...]
: > And since LPC is not a true object language, you are left with some

: > useless ugliness in the name of 'semantic consistency'. No one else
: > seems to support your zealotry for semantic consistency either.

: What, then, is a true object language?

One that supports full data abstraction, inheritance, polymorphism,
and encapsulation.

: > : Of course, you could always just change LPC, but that's a different
: > : can of worms.

: > Pointless. LPC needs to die.

: A queer conclusion in a thread about "Distributed LPC", started by you.

: Would you care to elaborate?

Oh, I am being overly dramatic is all :)

Less dramatic, I don't see the point in building *new* LPMud servers.

[Kris Van Hees]

On 13 Aug at 17:30:59, George Reese wrote <5ssqvr$40p$1...@darla.visi.com> which contained:

> Felix A. Croes <dwo...@visi.com> wrote:
>
>: What, then, is a true object language?
>
> One that supports full data abstraction, inheritance, polymorphism,
> and encapsulation.

That's a fairly subjective answer (as it will always be, as there is no full
conclusive definition of object orientation). Also, a "true object language"
would cover both object based and object oriented languages, which are two
quite different groups.

Literature on object orientation is very far from conclusive on what the
definition should be, unfortunately. Booch's "Object-Oriented Analysis And
Design With Applications" gives a very good start at some language
classification using his 4 main criteria (and 3 sub-criteria).

Aedil

[Tim Hollebeek]

In article <5sslrq$1aa$1...@darla.visi.com>, Felix A. Croes <dwo...@visi.com> writes:
>
> The only new LPC server that was released in the last few years is Pike,
> which never was a genuine MUD server to begin with and which is evolving
> further and further away from it. Pike's rudimentary thread support (with
> a mutex lock in the interpreter, smirk) could be added to any of the other
> LPC servers without much difficulty.

Uhoh, we're going in circles :-) Interested people should search Deja News
for a discussion of all the points related to this; there was an excellent
thread on it a few months ago.

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

spamming idiots please email sp...@franck.princeton.edu so I know who you are.
Thanks for being stupid and doing this automatically.

[John Adelsberger]

Distribution:

George Reese <bo...@imaginary.com> wrote:

<defining 'true object language'>

: One that supports full data abstraction, inheritance, polymorphism,
: and encapsulation.

encapsulation - better than C++, so you can't complain there
inheritance - the implementation could be a bit cleaner, but it works well
data abstraction - requires a bit of thought, but look at my new lib when
I release it and tell me it isn't possible then.
polymorphism - you can 'overload' fns as you've pointed out using varargs
and mixed types. The object type enhances the effect, as
do function pointers and the evaluate efun(in MudOS.) The
only thing it doesn't do that might be useful that I can
think of in this regard is overloading operators, but that
is just a bad idea, as C++ is proving daily.

: Less dramatic, I don't see the point in building *new* LPMud servers.

Because you don't want one that does something the current ones don't.
I do. Others do. Granted, we could just write something completely
different, but if we choose not to, who are you to say there's no
point in our efforts?

[John Adelsberger]

George Reese <bo...@imaginary.com> wrote:

: Oh please do. It would be about time you actually did something.

I've been working rather steadily for the last few weeks in preparation
for a project that will likely subsume this issue. I doubt I'll have
anything to show for it for quite a while, since for the moment I'm
working alone, but time will tell:)

: : You keep saying this(that I don't know jack shit.) Nevertheless, while

: : I can point to substantial education in distributed computing and
: : several muds and mudlibs that bear my mark and one that is entirely
: : mine,

: Why does no one in the LP community know who the hell you are then?

No one seems to equal you and Beek and a few others who all chat daily.
I've spent too much time coding to waste time yabbering on Idea Exchange,
or even these ngs until recently. The mudlibs I've modified are mostly
only running one site, and my mods aren't the only ones there, and the
one that is entirely mine is a work in progress, albeit a working work
in progress. Before too long, the first public release version will be
available, although I have no ftp site to put it on(it may end up on a
web page, much though I dislike the idea.)

: : you have one pisspoor mudlib,

: You keep saying that, but most people completely disagree. If you are
: going to keep saying this, you better back it up.

Most being whom? You, your coders, and maybe a few of your friends. Even
when it was available, almost nobody else used it. It'd be hard to back
up my claims, though, since the lib itself is no longer available for
my perusal and I didn't memorize your sources. To be fair, you may have
improved it a lot since I saw it, but when I saw it, which was about a
year and a half ago or so, I readily admit, it was disgusting.

: : a book on database stuff that

: : happens to include several forms of the word 'distribute,'

: Evidently you did not read it. The book is about building three-tier
: distributed applications that use JDBC and RMI. I know what it is
: about since I wrote it.

You're right; I didn't and won't read it - not because you wrote it, but
because the topic of doing anything using Java is utterly uninteresting
to me. Toy languages tacked on top of mediocre virtual machines aren't
my idea of distributed computing. It's ironic that the serious attempts
int that field(virtual machines and so forth) such as Inferno, which
are technically excellent, are also ignored.

: Please let me know how this compares to your little 'education in

: distributed computing'.
: Uh, write a book or read one... which do you think is the more
: comprehensive background?

You wrote a book about putting distribution logic into applications. My
knowledge spans some of that and a lot more. Since you have so far
derided the notion of distributed operating systems, I can only assume
you know nothing about them and their implementation, whereas I'll
before long have more of one written than there is of your book. I
hate sitting here in this stupid dick and a ruler contest; will you
please just accept that neither of us is a complete idiot, and agree
that it isn't worth arguing over who knows more? One of us does, the
other does not, and nothing either of us says is going to prove a damn
thing.

: : YOU CAN USE A FREE ORB WRITTEN IN WHATEVER, WRITE LPC BINDINGS AND AN

: : IDL->LPC TRANSLATOR, AND BIND LPC OBJECTS REMOTELY. YOU DO NOT NEED
: : AN ORB WRITTEN IN LPC. YOU _WOULD_ NEED SOME DRIVER SUPPORT.

: : Did you get it that time? If not, go and read more about CORBA,
: : because if that didn't clarify, you don't know CORBA at all.

: Hey, dipshit, where did I say the ORB had to be written in LPC. An
: LPC ORB is an ORB that *supports* LPC objects: i.e. some driver
: support.

You don't need an entire ORB for this; not even _CLOSE._ Granted, you
could do it that way, but you're right: that _would_ suck.

: : It's been done for Python, C, C++, Ada, it's being done for Perl, and there

: : are about half a dozen others. Do you in fact know anything about CORBA
: : at all, or is it just a buzzword to you?

: All those languages are not designed to make mud building simple. LPC
: is. CORBA is non-trivial for the programmer. What I suggest is. Why
: do you think JavaSoft came up with RMI in the first place?

RMI is a good idea tacked onto a lousy programming language tacked onto
a vm whose performance can only be described as mediocre. CORBA is
nontrivial for the programmer in static languages; using it effectively
in a language with support for it in the interpreter _could_ be made
simple. A matter of design.

: No, you make claims for me and then disprove them. Woo woo. That

: only proves you like to argue with yourself like a buffoon before the
: world.

The fact that I misunderstood what you meant by 'LPC ORB' does not
constitute inventing arguments for you.

: From the first time you mentioned it, I stated that is what I wanted.

: In fact, MY PERSONAL REASONING is to scale my own mud, which means
: long term moving away from LPC to Java. There for I *need* IIOP
: bindings. Just because I did not say it in my first post does not
: mean I was not thinking it. This is another perfect example of you
: taking things I don't say as proof I do not know/have never thought
: them. John, YOUR LOGIC IS WANTING.

You propose to establish a standard that you say would eventually have
incorporated CORBA, but which didn't mention CORBA, IIOP, or anything
similar, and then say that my logic in saying you didn't mention it
and slammed it as a bad idea when I did, which statements are facts,
is wanting? What logic is there to be wanting? Moreover, if you had
thought about it so much, why didn't you say so two weeks ago, instead
of waiting until now, when even on the remote chance that you're telling
the truth, nobody but your friends will believe you?

: : As for trivial, no, it isn't trivial; neither is the existing MudOS

: : driver. It isn't _that_ hard if you build it in steps; the Python
: : stuff was done in an amazing hurry. Automatic stub and skeleton
: : generation, btw, is not required for compliance; to my knowledge,
: : only the more dynamic languages(as opposed to C++, C, and Ada, for
: : instance) actually support doing it.

: So what?

Each of the statements in the paragraph above countered something you
said in a previous post which has been snipped. The only one worth
even trying to remember, though, was the last: you implied that CORBA
compliance required automatic stub and skeleton generation, and this
is not so, although those are features I personally want.

: Perhaps if you actually read the book. It is on distributed

: three-tier computing. JDBC is one part of it, RMI is the other part.
: And you evidently don't know jack about RMI as well. RMI is designed
: to preserve the Java semantics in distributed computing. It is not
: designed to hide distributed design knowldge. In fact, it exposes
: distributed design *more* than CORBA because it draws a much clearly
: distinction between local objects and remote objects than CORBA.

It is, to be specific, on the use of Java in distributed three-tier
computing, which is a subject which interests me precisely not at all,
for the reasons I give earlier in this post. Yes, it does in fact
draw a distinction between local and remote objects; this isn't a
design feature so much as a lack of design and or scope. As for
preserving Java semantics, it does not. Firstly because it doesn't
provide location transparency, as you just said, and secondly because
you have to use a special language feature at all to do it.

: What RMI does not have is an IDL. It also supports some things CORBA

: does not, such as distributed garbage collection and full object
: semantics (more important, full Java semantics).

One can build, and in fact should build, if one intends to use CORBA,
such support on top of it. It isn't exactly difficult, even if it isn't
a small job. CORBA is primarily, when you get down to it, an object
directory and interconnectivity standard.

: : The only new LPC server in the last couple of years is threaded. The

: : only other one that I know of that is getting underway(a project of mine)
: : is also threaded. That's 100% of new development, as opposed to
: : improvements in old stuff(which old stuff is unlikely to get threaded
: : since it requires such major changes.) Yes, I may have missed somone's
: : new driver; if so, I apologize, but you must be hiding it fairly well:)

: First, IMHO, anyone writing a new LPMud driver is wasting their time.
: DOH! That would be you! Someone who has produces zilcho and yet talks
: up a storm. Wake us all up when you actually have something.

I'm not writing a new LPMud driver. I'm writing what essentially is going
to be a VM for LPC; the vm itself is likely to look little like existing
ones, because LPC isn't its primary and long range goal. As for having
something, you've probably just offended most of the people who actually
write code in this group, whose projects are yet incomplete, if in fact
they've bothered to read this far.

: Second, DGD, the most recent driver publically available, is becoming
: multi-threaded.

Thanks for doing my legwork for me:) Ok, now we have the following:

1) Of two existing drivers worth a 2nd glance, one is going to be mt
sooner or later, and the other could be, but there are no announced
plans for it.

2) There are two(one mentioned in another response, and mine) which will
be mt, in development.

3) Your so called standard ignores, therefore, 3 of the 4 drivers that
may/will be worth using in the next 5 years or so.

: And, as I said, the implementation is a lot less trivial than you

: think and the overhead for mud developers is way too high to be
: worthwhile as a starting point.

I've read a lot of the standards docs, and while the commercial stuff
is huge(and, IMHO, bloated) the standard doesn't specify most of the
gunk they throw in. A clean and simple implementation really just isn't
going to be that bad, even though it isn't a small project.

: Now you may disagree with that fact, but if this is our point of

: contention, then your original post in this thread was more than pure
: crap as this point of contention does not merit the venom you have put
: forth.

If this is our only disagreement, I agree, but going back and looking
at some of your replies, I don't know if I believe the premise here...

: : Only because of latency and bandwidth. The latter is being solved by

: : infusion of money, the former by IPV6, ATM, and a couple of other
: : technologies. Designing standards now for IPV4 and today's bandwidth
: : is a joke; by the time they'd get widely used, they'd be outdated.

: Which means: DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE
: YET. So do you finally get it?

I get what you said; nevertheless, I wouldn't be designing standards
around what we have today. Before you even get them implemented, it
will be tomorrow.

: It does not change the semantics. In LPC, you should never treat

: mappings or arrars as references. Furthermore, what the hell do you

Should and can are two entirely different things.

: : I'm not arguing about how muds are written. I'm arguing about how

: : RPC is implemented. Even if the language allows you to do bad things,
: : if you intend to write RPC hooks for it, they should be consistent in
: : those bad things; otherwise, you have semantic and syntactic garbage.

: And since LPC is not a true object language, you are left with some
: useless ugliness in the name of 'semantic consistency'. No one else
: seems to support your zealotry for semantic consistency either.

An interesting claim, that LPC is not a true object language. Objects
are a concept; support for them does not imply doing things just like
some other language. All the core concepts of OOP are available to
the LPC programmer, and in fact, some of them have far cleaner
implementations than they do in, say, C++, or Java. Ada I'm only now
beginning to look at, so I can't say anything about it.

: : Of course, you could always just change LPC, but that's a different
: : can of worms.

: Pointless. LPC needs to die.

To be replaced by Java? Please. LPC contains many, many features which
are far and away superior to the so called industry standards. The only
languages I've yet really looked at that are similarly innovative in
certain areas are Perl5 and Python, and nobody who knows them well would
suggest them for a serious secured multiuser environment in which users
can modify the source code of said environment, unless he had not
seriously considered the implications of such a project.

Now, if you propose to design an entirely _new_ system and language based
on what has been learned from LP and maybe some other things, that might
be interesting, but that isn't what you said.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: : Why does no one in the LP community know who the hell you are then?

: No one seems to equal you and Beek and a few others who all chat daily.
: I've spent too much time coding to waste time yabbering on Idea Exchange,
: or even these ngs until recently. The mudlibs I've modified are mostly
: only running one site, and my mods aren't the only ones there, and the
: one that is entirely mine is a work in progress, albeit a working work
: in progress. Before too long, the first public release version will be
: available, although I have no ftp site to put it on(it may end up on a
: web page, much though I dislike the idea.)

Just let me know. ftp.imaginary.com is open to anyone, even people
like yourself.

: : : you have one pisspoor mudlib,

: : You keep saying that, but most people completely disagree. If you are
: : going to keep saying this, you better back it up.

: Most being whom? You, your coders, and maybe a few of your friends. Even
: when it was available, almost nobody else used it.

You wanna try backing this up? It made up at least HALF the MudOS
starts.

This group has already gone through the hard numbers to back this one
up. Check deja news if you failed to catch it.

: It'd be hard to back
: up my claims, though, since the lib itself is no longer available for
: my perusal and I didn't memorize your sources. To be fair, you may have
: improved it a lot since I saw it, but when I saw it, which was about a
: year and a half ago or so, I readily admit, it was disgusting.

*rofl* 1 1/2 years ago NM IV was in its first EXTREMELY alpha
release. It said so on any document you could have possibly read.
Even the last release of it was a beta. It never made it into final
release before I removed it.

: : : a book on database stuff that

: : : happens to include several forms of the word 'distribute,'

: : Evidently you did not read it. The book is about building three-tier
: : distributed applications that use JDBC and RMI. I know what it is
: : about since I wrote it.

: You're right; I didn't and won't read it - not because you wrote it, but
: because the topic of doing anything using Java is utterly uninteresting
: to me. Toy languages tacked on top of mediocre virtual machines aren't
: my idea of distributed computing. It's ironic that the serious attempts
: int that field(virtual machines and so forth) such as Inferno, which
: are technically excellent, are also ignored.

You made judgments based on my book, which you have not read.

You make judgments about a language, which you admittedly have read
nothing on.

Doesn't this define talking out your ass?

: : Please let me know how this compares to your little 'education in

: : distributed computing'.
: : Uh, write a book or read one... which do you think is the more
: : comprehensive background?

: You wrote a book about putting distribution logic into applications. My
: knowledge spans some of that and a lot more. Since you have so far
: derided the notion of distributed operating systems, I can only assume
: you know nothing about them and their implementation, whereas I'll
: before long have more of one written than there is of your book.

I never derided the idea of a distributed operating system. I said
that the specific issues involved in distributed operating systems
were not relevant to issues in DLPC. Big difference.

: I

: hate sitting here in this stupid dick and a ruler contest; will you
: please just accept that neither of us is a complete idiot, and agree
: that it isn't worth arguing over who knows more? One of us does, the
: other does not, and nothing either of us says is going to prove a damn
: thing.

I cannot accept that you are not a complete idiot, no. Everything in
my experience here suggests otherwise.

: : : YOU CAN USE A FREE ORB WRITTEN IN WHATEVER, WRITE LPC BINDINGS AND AN

: : : IDL->LPC TRANSLATOR, AND BIND LPC OBJECTS REMOTELY. YOU DO NOT NEED
: : : AN ORB WRITTEN IN LPC. YOU _WOULD_ NEED SOME DRIVER SUPPORT.

: : : Did you get it that time? If not, go and read more about CORBA,
: : : because if that didn't clarify, you don't know CORBA at all.

: : Hey, dipshit, where did I say the ORB had to be written in LPC. An
: : LPC ORB is an ORB that *supports* LPC objects: i.e. some driver
: : support.

: You don't need an entire ORB for this; not even _CLOSE._ Granted, you
: could do it that way, but you're right: that _would_ suck.

Guess what... DLPC is an incomplete ORB.

: : : It's been done for Python, C, C++, Ada, it's being done for Perl, and there

: : : are about half a dozen others. Do you in fact know anything about CORBA
: : : at all, or is it just a buzzword to you?

: : All those languages are not designed to make mud building simple. LPC
: : is. CORBA is non-trivial for the programmer. What I suggest is. Why
: : do you think JavaSoft came up with RMI in the first place?

: RMI is a good idea tacked onto a lousy programming language tacked onto
: a vm whose performance can only be described as mediocre. CORBA is
: nontrivial for the programmer in static languages; using it effectively
: in a language with support for it in the interpreter _could_ be made
: simple. A matter of design.

I fail to see why RMI for Java is a good idea and DLPC for LPC is a
bad idea.

: : No, you make claims for me and then disprove them. Woo woo. That

: : only proves you like to argue with yourself like a buffoon before the
: : world.

: The fact that I misunderstood what you meant by 'LPC ORB' does not
: constitute inventing arguments for you.

You have done it time and time again.

: : From the first time you mentioned it, I stated that is what I wanted.

: : In fact, MY PERSONAL REASONING is to scale my own mud, which means
: : long term moving away from LPC to Java. There for I *need* IIOP
: : bindings. Just because I did not say it in my first post does not
: : mean I was not thinking it. This is another perfect example of you
: : taking things I don't say as proof I do not know/have never thought
: : them. John, YOUR LOGIC IS WANTING.

: You propose to establish a standard that you say would eventually have
: incorporated CORBA, but which didn't mention CORBA, IIOP, or anything
: similar, and then say that my logic in saying you didn't mention it
: and slammed it as a bad idea when I did, which statements are facts,
: is wanting? What logic is there to be wanting? Moreover, if you had
: thought about it so much, why didn't you say so two weeks ago, instead
: of waiting until now, when even on the remote chance that you're telling
: the truth, nobody but your friends will believe you?

I said it two weeks ago when you brought up the cncept of CORBA.
Furthermore, whether or not you believe I am telling the truth does
not matter. I mentioned my assumptions as well in the initial
statement, which clearly corroborate my reasons for not wanting full
CORBA compliance.

: : : As for trivial, no, it isn't trivial; neither is the existing MudOS

: : : driver. It isn't _that_ hard if you build it in steps; the Python
: : : stuff was done in an amazing hurry. Automatic stub and skeleton
: : : generation, btw, is not required for compliance; to my knowledge,
: : : only the more dynamic languages(as opposed to C++, C, and Ada, for
: : : instance) actually support doing it.

: : So what?

: Each of the statements in the paragraph above countered something you
: said in a previous post which has been snipped. The only one worth
: even trying to remember, though, was the last: you implied that CORBA
: compliance required automatic stub and skeleton generation, and this
: is not so, although those are features I personally want.

They counter nothing I have said. I do not even recall where I
*implied* CORBA requires automatic stub generation. Perhaps you could
enlighten me?

: : Perhaps if you actually read the book. It is on distributed

: : three-tier computing. JDBC is one part of it, RMI is the other part.
: : And you evidently don't know jack about RMI as well. RMI is designed
: : to preserve the Java semantics in distributed computing. It is not
: : designed to hide distributed design knowldge. In fact, it exposes
: : distributed design *more* than CORBA because it draws a much clearly
: : distinction between local objects and remote objects than CORBA.

: It is, to be specific, on the use of Java in distributed three-tier
: computing, which is a subject which interests me precisely not at all,
: for the reasons I give earlier in this post. Yes, it does in fact
: draw a distinction between local and remote objects; this isn't a
: design feature so much as a lack of design and or scope. As for
: preserving Java semantics, it does not. Firstly because it doesn't
: provide location transparency, as you just said, and secondly because
: you have to use a special language feature at all to do it.

Ugh, read something about RMI first. It does provide location
transparency to the developer and requires no special language
features. There is no location transparency for the *designer*. This
is a good thing.

: : What RMI does not have is an IDL. It also supports some things CORBA

: : does not, such as distributed garbage collection and full object
: : semantics (more important, full Java semantics).

: One can build, and in fact should build, if one intends to use CORBA,
: such support on top of it. It isn't exactly difficult, even if it isn't
: a small job. CORBA is primarily, when you get down to it, an object
: directory and interconnectivity standard.

CORBA cannot support these thigns since it is heterogeneous in nature.

: : : The only new LPC server in the last couple of years is threaded. The

: : : only other one that I know of that is getting underway(a project of mine)
: : : is also threaded. That's 100% of new development, as opposed to
: : : improvements in old stuff(which old stuff is unlikely to get threaded
: : : since it requires such major changes.) Yes, I may have missed somone's
: : : new driver; if so, I apologize, but you must be hiding it fairly well:)

: : First, IMHO, anyone writing a new LPMud driver is wasting their time.
: : DOH! That would be you! Someone who has produces zilcho and yet talks
: : up a storm. Wake us all up when you actually have something.

: I'm not writing a new LPMud driver. I'm writing what essentially is going
: to be a VM for LPC; the vm itself is likely to look little like existing
: ones, because LPC isn't its primary and long range goal. As for having
: something, you've probably just offended most of the people who actually
: write code in this group, whose projects are yet incomplete, if in fact
: they've bothered to read this far.

I think the only person I have remotely insulted in this group is
Aedil. And quite honestly, he has been working on his LPC
implementation for a long, long time; he does not really fall into
that category.

: : Second, DGD, the most recent driver publically available, is becoming
: : multi-threaded.

: Thanks for doing my legwork for me:) Ok, now we have the following:

: 1) Of two existing drivers worth a 2nd glance, one is going to be mt
: sooner or later, and the other could be, but there are no announced
: plans for it.

As Dworkin stated, later rather than sooner.

: 2) There are two(one mentioned in another response, and mine) which will
: be mt, in development.

Yes, Aedil's.

: 3) Your so called standard ignores, therefore, 3 of the 4 drivers that

: may/will be worth using in the next 5 years or so.

No, it does not. As Dworkin pointed out, the LPC will not be MT in
DGD; just the backend systems in the driver. I quite honestly mostly
care about DGD and MudOS since that accounts for almost all of new mud
development. 100% of all new LPC development using an existing VM is
using a non-MT LPC.

: : And, as I said, the implementation is a lot less trivial than you

: : think and the overhead for mud developers is way too high to be
: : worthwhile as a starting point.

: I've read a lot of the standards docs, and while the commercial stuff
: is huge(and, IMHO, bloated) the standard doesn't specify most of the
: gunk they throw in. A clean and simple implementation really just isn't
: going to be that bad, even though it isn't a small project.

Then do it.

: : Now you may disagree with that fact, but if this is our point of

: : contention, then your original post in this thread was more than pure
: : crap as this point of contention does not merit the venom you have put
: : forth.

: If this is our only disagreement, I agree, but going back and looking
: at some of your replies, I don't know if I believe the premise here...

Whatever.

: : : Only because of latency and bandwidth. The latter is being solved by

: : : infusion of money, the former by IPV6, ATM, and a couple of other
: : : technologies. Designing standards now for IPV4 and today's bandwidth
: : : is a joke; by the time they'd get widely used, they'd be outdated.

: : Which means: DISTRIBUTED COMPUTING OVER THE INTERNET IS NOT THERE
: : YET. So do you finally get it?

: I get what you said; nevertheless, I wouldn't be designing standards
: around what we have today. Before you even get them implemented, it
: will be tomorrow.

And my standard supports an Internet without such latencies. Duh. If
the Internet were the way you suggest it will be tomorrow, then this
DLPC design works fine across the Internet.

: : It does not change the semantics. In LPC, you should never treat

: : mappings or arrars as references. Furthermore, what the hell do you

: Should and can are two entirely different things.

: : : I'm not arguing about how muds are written. I'm arguing about how
: : : RPC is implemented. Even if the language allows you to do bad things,
: : : if you intend to write RPC hooks for it, they should be consistent in
: : : those bad things; otherwise, you have semantic and syntactic garbage.

: : And since LPC is not a true object language, you are left with some
: : useless ugliness in the name of 'semantic consistency'. No one else
: : seems to support your zealotry for semantic consistency either.

: An interesting claim, that LPC is not a true object language. Objects
: are a concept; support for them does not imply doing things just like
: some other language. All the core concepts of OOP are available to
: the LPC programmer, and in fact, some of them have far cleaner
: implementations than they do in, say, C++, or Java. Ada I'm only now
: beginning to look at, so I can't say anything about it.

Name one that has a cleaner implementation than Java.

And this paragraph did nothing to address the issue of symantic
consistency.

: : : Of course, you could always just change LPC, but that's a different
: : : can of worms.

: : Pointless. LPC needs to die.

: To be replaced by Java? Please. LPC contains many, many features which
: are far and away superior to the so called industry standards. The only
: languages I've yet really looked at that are similarly innovative in
: certain areas are Perl5 and Python, and nobody who knows them well would
: suggest them for a serious secured multiuser environment in which users
: can modify the source code of said environment, unless he had not
: seriously considered the implications of such a project.

Java is a much better language than LPC in every single respect.

: Now, if you propose to design an entirely _new_ system and language based

: on what has been learned from LP and maybe some other things, that might
: be interesting, but that isn't what you said.

I would propose Java with Python syntax. I would not propose anything
from LPC.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: Distribution:

: George Reese <bo...@imaginary.com> wrote:

: <defining 'true object language'>

: : One that supports full data abstraction, inheritance, polymorphism,
: : and encapsulation.

: encapsulation - better than C++, so you can't complain there
: inheritance - the implementation could be a bit cleaner, but it works well
: data abstraction - requires a bit of thought, but look at my new lib when
: I release it and tell me it isn't possible then.

I have been doing this a wee longer than you and I *think* I
understand the issues involved. Data abstraction is impossible to
rely upon in LPC since any such abstraction:
* has no automatic garbage collection
* fails to maintain type semantics

Yes, you can do it; but the only places it is useful is under the
covers where no one can see it. And it is still not full data abstraction.

: polymorphism - you can 'overload' fns as you've pointed out using varargs

: and mixed types. The object type enhances the effect, as
: do function pointers and the evaluate efun(in MudOS.) The

: only thing it doesn't do that might be useful that I can
: think of in this regard is overloading operators, but that

: is just a bad idea, as C++ is proving daily.

: : Less dramatic, I don't see the point in building *new* LPMud servers.

: Because you don't want one that does something the current ones don't.
: I do. Others do. Granted, we could just write something completely
: different, but if we choose not to, who are you to say there's no
: point in our efforts?

There are better tools out there.

[John Adelsberger]

Distribution:

George Reese <bo...@imaginary.com> wrote:

(I wrote):
: : encapsulation - better than C++, so you can't complain there

: : inheritance - the implementation could be a bit cleaner, but it works well
: : data abstraction - requires a bit of thought, but look at my new lib when
: : I release it and tell me it isn't possible then.

: I have been doing this a wee longer than you and I *think* I
: understand the issues involved. Data abstraction is impossible to
: rely upon in LPC since any such abstraction:
: * has no automatic garbage collection
: * fails to maintain type semantics

If you think data abstraction requires garbage collection, you are wrong
about thinking you understand the issues involved. Such a view says that
Ada, C++, and earlier versions of Smalltalk even aren't OO - surely you
aren't this obtuse?

I'm not even sure whwat you mean by type semantics, but if you mean
you can't overload operators, this is a _GOOD THING._ Operator
overloading is the most easily misused feature around, even if you
count variable aliasing, and is the number one source of bad C++
code that I've encountered.

As for your statement that it is impossible to rely on: what do you mean
by rely? I use and rely on the use of data abstraction in LPC on a daily
basis.

: Yes, you can do it; but the only places it is useful is under the

: covers where no one can see it. And it is still not full data abstraction.

You seem to have lost sight of the purpose of data abstraction. Data
abstraction makes programs easier to read, easier to write(somewhat) and
as a result of those improvements, adds _somewhat_ to reliability. It is
nothing more, does nothing more, and that is that. Quite frankly, if to
you no language is truly OO unless user defined types are _exactly_ like
internal types, then your beloved Java isn't even close. Neither are
Smalltalk, C++, Ada, or _any_ other language yet invented. Clearly your
absolutism is unwarranted here.

And again, you engage in silly argment from authority and character
negation by trying to sound more experienced than me. Cut the shit.

: : : Less dramatic, I don't see the point in building *new* LPMud servers.

: : Because you don't want one that does something the current ones don't.
: : I do. Others do. Granted, we could just write something completely
: : different, but if we choose not to, who are you to say there's no
: : point in our efforts?

: There are better tools out there.

That's a pretty bold statement, given that you have absolutely no idea
what my goals are.

[John Adelsberger]

Distribution:

George Reese <bo...@imaginary.com> wrote:
: John Adelsberger <j...@umr.edu> wrote:

: Just let me know. ftp.imaginary.com is open to anyone, even people
: like yourself.

Thank you.

: : Most being whom? You, your coders, and maybe a few of your friends. Even

: : when it was available, almost nobody else used it.

: You wanna try backing this up? It made up at least HALF the MudOS
: starts.

Before I knew enough to write real lib code, I wrote for a lot of startup
MudOS setups; almost all of them were DW.

: This group has already gone through the hard numbers to back this one

: up. Check deja news if you failed to catch it.

This group isn't even _read_ by most admins of MudOS startups. Sorry,
but while there's no way to prove it, DW is by far the most popular
MudOS lib in history.

: *rofl* 1 1/2 years ago NM IV was in its first EXTREMELY alpha

: release. It said so on any document you could have possibly read.
: Even the last release of it was a beta. It never made it into final
: release before I removed it.

I write code neatly the first time. If you think being alpha is an
excuse for poor indenting, poor variable naming, lack of commenting
of non-obvious or context dependent functionality, and so on, you
and I disagree hopelessly.

: : You're right; I didn't and won't read it - not because you wrote it, but

: : because the topic of doing anything using Java is utterly uninteresting
: : to me. Toy languages tacked on top of mediocre virtual machines aren't
: : my idea of distributed computing. It's ironic that the serious attempts
: : int that field(virtual machines and so forth) such as Inferno, which
: : are technically excellent, are also ignored.

: You made judgments based on my book, which you have not read.

No, _you_ made a judgement based on your book: the judgement that you
are better than me in some regard.

: You make judgments about a language, which you admittedly have read
: nothing on.

I've read lots of Java, written just a teeny bit, and seen a friend write
a large software system in it. I've read a bit of the VM spec and compared
the VM to others around. I read part of a book on the subject before
realizing that it was written for VB programmers who don't know memory
from disk. I know enough to know that Java is only a force in the world
because it was the first thing out there that had a VM and was available
for use as an open standard.

: Doesn't this define talking out your ass?

No. Claiming that your opponent in an argument is wrong because you've
written a book on a tangentially similar subject is talking out your
ass.

: I cannot accept that you are not a complete idiot, no. Everything in

: my experience here suggests otherwise.

Your loss.

: : You don't need an entire ORB for this; not even _CLOSE._ Granted, you

: : could do it that way, but you're right: that _would_ suck.

: Guess what... DLPC is an incomplete ORB.

No, it is not. It specifies zero object directory services, zero
object bus services, zero protocols, includes no IIOP support, and
in fact can be said to be little more than just 'incomplete.'

: : RMI is a good idea tacked onto a lousy programming language tacked onto

: : a vm whose performance can only be described as mediocre. CORBA is
: : nontrivial for the programmer in static languages; using it effectively
: : in a language with support for it in the interpreter _could_ be made
: : simple. A matter of design.

: I fail to see why RMI for Java is a good idea and DLPC for LPC is a
: bad idea.

If what you really want is RPC and nothing more, fine, but if you want
a serious mechanism for _object_ distribution that makes it realistic
to write and maintain a large object system independent of the location
of its parts, then you're barking up the wrong tree.

: I said it two weeks ago when you brought up the cncept of CORBA.

: Furthermore, whether or not you believe I am telling the truth does
: not matter. I mentioned my assumptions as well in the initial
: statement, which clearly corroborate my reasons for not wanting full
: CORBA compliance.

Anyone caring to look at your reply to my first posting about CORBA here
will note that you said no such thing, and have now made a liar of yourself
for all to see. You're right; it doesn't matter one bit whether _I_
believe you.

: : Each of the statements in the paragraph above countered something you

: : said in a previous post which has been snipped. The only one worth
: : even trying to remember, though, was the last: you implied that CORBA
: : compliance required automatic stub and skeleton generation, and this
: : is not so, although those are features I personally want.

: They counter nothing I have said. I do not even recall where I
: *implied* CORBA requires automatic stub generation. Perhaps you could
: enlighten me?

You: LPC CORBA use would require coders to make skeletons and stubs.
Me: No, you could do automatic generation of them, ala Python.
You: That's part of the standard.

But it isn't. If you want ref #s, go look at Dejanews; I now can and
have, but I'm not going to do so again right now.

: Ugh, read something about RMI first. It does provide location

: transparency to the developer and requires no special language
: features. There is no location transparency for the *designer*. This
: is a good thing.

Playing semantic games with the word developer is irrelevant. Some
code in RMI doesn't have to know about locations; nevertheless, as
a language feature, it inherently lacks location transparency. Are
you going to deny this?

: : : What RMI does not have is an IDL. It also supports some things CORBA

: : : does not, such as distributed garbage collection and full object
: : : semantics (more important, full Java semantics).

: : One can build, and in fact should build, if one intends to use CORBA,

: : such support on top of it. It isn't exactly difficult, even if it isn't
: : a small job. CORBA is primarily, when you get down to it, an object
: : directory and interconnectivity standard.

: CORBA cannot support these thigns since it is heterogeneous in nature.

CORBA itself does not have to support these things; CORBA is a bus. It
is possible to do distributed garbage collection in a distributed
object system built on CORBA; even you will not, I hope, deny this. As
for Java semantics, I misspoke myself. Nobody in his right mind would
want them anyway.

: : I'm not writing a new LPMud driver. I'm writing what essentially is going

: : to be a VM for LPC; the vm itself is likely to look little like existing
: : ones, because LPC isn't its primary and long range goal. As for having
: : something, you've probably just offended most of the people who actually
: : write code in this group, whose projects are yet incomplete, if in fact
: : they've bothered to read this far.

: I think the only person I have remotely insulted in this group is
: Aedil. And quite honestly, he has been working on his LPC
: implementation for a long, long time; he does not really fall into
: that category.

Since you didn't understand what I meant by 'As for having something,'
I'm not going to further waste time on it.

: : 1) Of two existing drivers worth a 2nd glance, one is going to be mt

: : sooner or later, and the other could be, but there are no announced
: : plans for it.

: As Dworkin stated, later rather than sooner.

What if it takes him five years? It won't if he actually does any work
on it, but what if it does? Do you propose to build a standard around
the next five years only? I hope not.

: : 2) There are two(one mentioned in another response, and mine) which will
: : be mt, in development.

: Yes, Aedil's.

No, another. I don't remember the guys name, unfortunately, but he posted
here. So, mine, the other, and DGD are three, and MudOS is the fourth
worth considering.

: No, it does not. As Dworkin pointed out, the LPC will not be MT in

: DGD; just the backend systems in the driver. I quite honestly mostly
: care about DGD and MudOS since that accounts for almost all of new mud
: development. 100% of all new LPC development using an existing VM is
: using a non-MT LPC.

Actually, if most of new mud development is your concern, you may as well
forget DGD too; it is technically excellent in many ways, but it is also
almost never used for anything, for whatever reason.

: : I've read a lot of the standards docs, and while the commercial stuff

: : is huge(and, IMHO, bloated) the standard doesn't specify most of the
: : gunk they throw in. A clean and simple implementation really just isn't
: : going to be that bad, even though it isn't a small project.

: Then do it.

I probably will, but I've got a lot of other work to do first on this
project of mine before it'll be ready for that. Truth be known, I'm
doing it mainly to get experience building and tweaking a VM and maybe
get some useful code out of it for another much larger project, and
figure I can make a fun game whilst I'm at it.

: : I get what you said; nevertheless, I wouldn't be designing standards

: : around what we have today. Before you even get them implemented, it
: : will be tomorrow.

: And my standard supports an Internet without such latencies. Duh. If
: the Internet were the way you suggest it will be tomorrow, then this
: DLPC design works fine across the Internet.

Works across, yes. Takes advantage of? I think not. Besides, it isn't
what I say that matters on this: go look at ATM(it's an open standard,
you can find it:) and IPV6 if you don't believe it's going to happen.
Of course, ADSL, gigabit ethernet(yuck) and some other stuff will help,
but the most general purpose stuff is ATM and IPV6.

: : An interesting claim, that LPC is not a true object language. Objects

: : are a concept; support for them does not imply doing things just like
: : some other language. All the core concepts of OOP are available to
: : the LPC programmer, and in fact, some of them have far cleaner
: : implementations than they do in, say, C++, or Java. Ada I'm only now
: : beginning to look at, so I can't say anything about it.

: Name one that has a cleaner implementation than Java.

First off, nice change of subject from your foolish claim that LPC is
not an object language. Much easier to ignore your mistakes than
admit them, eh?

Secondly, implementation is irrelevant not only to LPC as an object
language, but also to Java's merits as a language.

Third, if we talk about languages as languages, which _is_ sensible,
Smalltalk, Python, Perl5, Ada, Eiffel, and probably a dozen others
are all better OO languages than Java. Java has _one_ benefit: it
is simple. It sacrifices too much for simplicity, and then they
build data 'abstractions' such as Integer, which look nothing like
real data types(interesting, since you so hate LPC data abstraction
on that same account:) and are tedious to use. Blech.

: And this paragraph did nothing to address the issue of symantic
: consistency.

Or even semantic consistency. Little things like always either passing
something by reference or value as the default, and not making it depend
on things like location:)

: : To be replaced by Java? Please. LPC contains many, many features which

: : are far and away superior to the so called industry standards. The only
: : languages I've yet really looked at that are similarly innovative in
: : certain areas are Perl5 and Python, and nobody who knows them well would
: : suggest them for a serious secured multiuser environment in which users
: : can modify the source code of said environment, unless he had not
: : seriously considered the implications of such a project.

: Java is a much better language than LPC in every single respect.

Speed: no.
Security: nope.
Ease of use: please.
Data abstraction: I refer you to Integer from Java, which cannot even be
added normally, and invite you to compare with what can
be done with creative mixing of the class and object
types in LPC.
Encapsulation: They're similar in capability.
Inheritance: Java's is less flexible, but they are similar in
capability in the way they really get used.
Syntax: Again, I refer you to Integer. Java also has no
foreach, and is lacking in many other areas as far
as control structures go.
Readability: probably similar, but its subjective
Writability: Java might even win, if you don't mind being treated
like a child by your language and don't mind
capitalizing everything and using .intval to get
the 'value' of an integer(as though it has other
meaningful properties.)

Have I missed anything?

: : Now, if you propose to design an entirely _new_ system and language based

: : on what has been learned from LP and maybe some other things, that might
: : be interesting, but that isn't what you said.

: I would propose Java with Python syntax. I would not propose anything
: from LPC.

Java is a language. If it has Python syntax, it's Python. If what you
want is Python compiling to the JVM, fine, but that's Python.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: Distribution:

: George Reese <bo...@imaginary.com> wrote:
: : John Adelsberger <j...@umr.edu> wrote:

: : Just let me know. ftp.imaginary.com is open to anyone, even people
: : like yourself.

: Thank you.

: : : Most being whom? You, your coders, and maybe a few of your friends. Even
: : : when it was available, almost nobody else used it.

: : You wanna try backing this up? It made up at least HALF the MudOS
: : starts.

: Before I knew enough to write real lib code, I wrote for a lot of startup
: MudOS setups; almost all of them were DW.

Please name those; there are in fact very few DW muds.

: : This group has already gone through the hard numbers to back this one

: : up. Check deja news if you failed to catch it.

: This group isn't even _read_ by most admins of MudOS startups. Sorry,
: but while there's no way to prove it, DW is by far the most popular
: MudOS lib in history.

You are hilarious. DW is the single least popular. That is not a
reflection of its quality; it is however a fact.

That startups may or may not read this newsgroup is irrelevant; there
was an actual MudOS lib count done a while ago. To get a quick count,
just check the intermud mudlists--all MudOS libs come with intermud
access by default.

For more detail, check the other mudlists.

: : *rofl* 1 1/2 years ago NM IV was in its first EXTREMELY alpha

: : release. It said so on any document you could have possibly read.
: : Even the last release of it was a beta. It never made it into final
: : release before I removed it.

: I write code neatly the first time. If you think being alpha is an
: excuse for poor indenting, poor variable naming, lack of commenting
: of non-obvious or context dependent functionality, and so on, you
: and I disagree hopelessly.

Nightmare is very well indented, has a consistent naming system, is
well documented, etc. Even in alpha. Please address something
relating to NM.

And more important, it is well-designed.

: : : You're right; I didn't and won't read it - not because you wrote it, but

: : : because the topic of doing anything using Java is utterly uninteresting
: : : to me. Toy languages tacked on top of mediocre virtual machines aren't
: : : my idea of distributed computing. It's ironic that the serious attempts
: : : int that field(virtual machines and so forth) such as Inferno, which
: : : are technically excellent, are also ignored.

: : You made judgments based on my book, which you have not read.

: No, _you_ made a judgement based on your book: the judgement that you
: are better than me in some regard.

You did in fact suggest several things about my book in spite of
having not read it.

The fact that I think that my having written book on the subject is a
major credential in matters on the subject is irrelevant to that
fact. I am a recognized authority on this subject; you are not. That
does mean that when you want to argue a position, you need to do
better than call me a moron.

And to date, you have done nothing other than make various attempts to
call me a moron.

: : You make judgments about a language, which you admittedly have read
: : nothing on.

: I've read lots of Java, written just a teeny bit, and seen a friend write
: a large software system in it. I've read a bit of the VM spec and compared
: the VM to others around. I read part of a book on the subject before
: realizing that it was written for VB programmers who don't know memory
: from disk. I know enough to know that Java is only a force in the world
: because it was the first thing out there that had a VM and was available
: for use as an open standard.

There is a lot more to it.

: : Doesn't this define talking out your ass?

: No. Claiming that your opponent in an argument is wrong because you've
: written a book on a tangentially similar subject is talking out your
: ass.

I never said you were wrong because I wrote a book on the subject.

The issue with the book is this:

You repeatedly say that my software sucks, my proposal is idiotic,
etc, etc without anything to back it up. Clearly, since I am a
recognized expert on the subject matter (because of the book), you
need to do better than bash me with moron labeling; the book means
that without any substantial arguments from you, you are clearly
talking out your ass.

: : I cannot accept that you are not a complete idiot, no. Everything in
: : my experience here suggests otherwise.

: Your loss.

: : : You don't need an entire ORB for this; not even _CLOSE._ Granted, you
: : : could do it that way, but you're right: that _would_ suck.

: : Guess what... DLPC is an incomplete ORB.

: No, it is not. It specifies zero object directory services, zero
: object bus services, zero protocols, includes no IIOP support, and
: in fact can be said to be little more than just 'incomplete.'

That is not the definition of an ORB.

: : : RMI is a good idea tacked onto a lousy programming language tacked onto

: : : a vm whose performance can only be described as mediocre. CORBA is
: : : nontrivial for the programmer in static languages; using it effectively
: : : in a language with support for it in the interpreter _could_ be made
: : : simple. A matter of design.

: : I fail to see why RMI for Java is a good idea and DLPC for LPC is a
: : bad idea.

: If what you really want is RPC and nothing more, fine, but if you want
: a serious mechanism for _object_ distribution that makes it realistic
: to write and maintain a large object system independent of the location
: of its parts, then you're barking up the wrong tree.

Hardly.

: : I said it two weeks ago when you brought up the cncept of CORBA.

: : Furthermore, whether or not you believe I am telling the truth does
: : not matter. I mentioned my assumptions as well in the initial
: : statement, which clearly corroborate my reasons for not wanting full
: : CORBA compliance.

: Anyone caring to look at your reply to my first posting about CORBA here
: will note that you said no such thing, and have now made a liar of yourself
: for all to see. You're right; it doesn't matter one bit whether _I_
: believe you.

Go ahead and look it up. I know what my motivations are :)

: : : Each of the statements in the paragraph above countered something you

: : : said in a previous post which has been snipped. The only one worth
: : : even trying to remember, though, was the last: you implied that CORBA
: : : compliance required automatic stub and skeleton generation, and this
: : : is not so, although those are features I personally want.

: : They counter nothing I have said. I do not even recall where I
: : *implied* CORBA requires automatic stub generation. Perhaps you could
: : enlighten me?

: You: LPC CORBA use would require coders to make skeletons and stubs.
: Me: No, you could do automatic generation of them, ala Python.
: You: That's part of the standard.

: But it isn't. If you want ref #s, go look at Dejanews; I now can and
: have, but I'm not going to do so again right now.

Please do. I have never said that automatic stub generation is part
of the CORBA standard.

: : Ugh, read something about RMI first. It does provide location

: : transparency to the developer and requires no special language
: : features. There is no location transparency for the *designer*. This
: : is a good thing.

: Playing semantic games with the word developer is irrelevant. Some
: code in RMI doesn't have to know about locations; nevertheless, as
: a language feature, it inherently lacks location transparency. Are
: you going to deny this?

I am not playing any semantic games. You simply do not need any
special code tied to specific locations ANYWHERE.

: : : : What RMI does not have is an IDL. It also supports some things CORBA

: : : : does not, such as distributed garbage collection and full object
: : : : semantics (more important, full Java semantics).

: : : One can build, and in fact should build, if one intends to use CORBA,
: : : such support on top of it. It isn't exactly difficult, even if it isn't
: : : a small job. CORBA is primarily, when you get down to it, an object
: : : directory and interconnectivity standard.

: : CORBA cannot support these thigns since it is heterogeneous in nature.

: CORBA itself does not have to support these things; CORBA is a bus. It
: is possible to do distributed garbage collection in a distributed
: object system built on CORBA; even you will not, I hope, deny this. As
: for Java semantics, I misspoke myself. Nobody in his right mind would
: want them anyway.

Of course distributed garbage collection is possible; a heterogeneous
distributed GC system is questionable. If you think you know
otherwise, you are questioning everybody on earth dealign with
RMI/CORBA interoperability.

: : : I'm not writing a new LPMud driver. I'm writing what essentially is going

: : : to be a VM for LPC; the vm itself is likely to look little like existing
: : : ones, because LPC isn't its primary and long range goal. As for having
: : : something, you've probably just offended most of the people who actually
: : : write code in this group, whose projects are yet incomplete, if in fact
: : : they've bothered to read this far.

: : I think the only person I have remotely insulted in this group is
: : Aedil. And quite honestly, he has been working on his LPC
: : implementation for a long, long time; he does not really fall into
: : that category.

: Since you didn't understand what I meant by 'As for having something,'
: I'm not going to further waste time on it.

: : : 1) Of two existing drivers worth a 2nd glance, one is going to be mt
: : : sooner or later, and the other could be, but there are no announced
: : : plans for it.

: : As Dworkin stated, later rather than sooner.

: What if it takes him five years? It won't if he actually does any work
: on it, but what if it does? Do you propose to build a standard around
: the next five years only? I hope not.

It is still irrelevant. His MT additions are not going to have LPC
multi-threading. My proposal does not handle MT LPC.

: : : 2) There are two(one mentioned in another response, and mine) which will
: : : be mt, in development.

: : Yes, Aedil's.

: No, another. I don't remember the guys name, unfortunately, but he posted
: here. So, mine, the other, and DGD are three, and MudOS is the fourth
: worth considering.

MudOS is not likely ever to be MT; and DGD will not be MT in a way that
contradicts with the DLPC spec; in fact, it requires that sort of
multi-threading.

So what is your point?

: : No, it does not. As Dworkin pointed out, the LPC will not be MT in

: : DGD; just the backend systems in the driver. I quite honestly mostly
: : care about DGD and MudOS since that accounts for almost all of new mud
: : development. 100% of all new LPC development using an existing VM is
: : using a non-MT LPC.

: Actually, if most of new mud development is your concern, you may as well
: forget DGD too; it is technically excellent in many ways, but it is also
: almost never used for anything, for whatever reason.

It does not have a major mudlib backing it up. I personally think
Dworkin has also gone overboard on minimalism. But others would like
that. The lack of a major mudlib, IMHO is the kicker.

TMI and Nightmare, on the other hand, made MudOS.

: : : I've read a lot of the standards docs, and while the commercial stuff

: : : is huge(and, IMHO, bloated) the standard doesn't specify most of the
: : : gunk they throw in. A clean and simple implementation really just isn't
: : : going to be that bad, even though it isn't a small project.

: : Then do it.

: I probably will, but I've got a lot of other work to do first on this
: project of mine before it'll be ready for that. Truth be known, I'm
: doing it mainly to get experience building and tweaking a VM and maybe
: get some useful code out of it for another much larger project, and
: figure I can make a fun game whilst I'm at it.

Talk, talk, talk.

: : : I get what you said; nevertheless, I wouldn't be designing standards

: : : around what we have today. Before you even get them implemented, it
: : : will be tomorrow.

: : And my standard supports an Internet without such latencies. Duh. If
: : the Internet were the way you suggest it will be tomorrow, then this
: : DLPC design works fine across the Internet.

: Works across, yes. Takes advantage of? I think not.

It works just like RMI and CORBA, just much simpler. So you are
really missing a point here.

The Internet is just a slower network. There is no such thing as
taking advantage of a slower network.

: Besides, it isn't

: what I say that matters on this: go look at ATM(it's an open standard,
: you can find it:) and IPV6 if you don't believe it's going to happen.
: Of course, ADSL, gigabit ethernet(yuck) and some other stuff will help,
: but the most general purpose stuff is ATM and IPV6.

That has nothing to do with this subject.

: : : An interesting claim, that LPC is not a true object language. Objects

: : : are a concept; support for them does not imply doing things just like
: : : some other language. All the core concepts of OOP are available to
: : : the LPC programmer, and in fact, some of them have far cleaner
: : : implementations than they do in, say, C++, or Java. Ada I'm only now
: : : beginning to look at, so I can't say anything about it.

: : Name one that has a cleaner implementation than Java.

: First off, nice change of subject from your foolish claim that LPC is
: not an object language. Much easier to ignore your mistakes than
: admit them, eh?

I did not back off it. I stated in another post, bozo.

: Secondly, implementation is irrelevant not only to LPC as an object

: language, but also to Java's merits as a language.

Huh? Java is recognized by most of the big OO guys as a perfect
language in which to implement OO design patterns. The only
competition Java has on this front is Eiffel.

: Third, if we talk about languages as languages, which _is_ sensible,

: Smalltalk, Python, Perl5, Ada, Eiffel, and probably a dozen others
: are all better OO languages than Java.

Python, while I love it, is MOST DEFINITELY not a better OO language.

Perl5 OO? *rofl*

So, Mr. OO guru (let's see, you are a mud guru, distributed computing
guru, database guru, threading guru, and now OO guru in spite of the
fact of having nothing out there that anyone has ever seen?), what
exactly is better about these languages in an OO sense than Java.

Ignore Eiffel. Eiffel is a controversial one;

What about Smalltalk, Python, Perl5, Ada make any of them better OO
languages than Java?

: Java has _one_ benefit: it

: is simple. It sacrifices too much for simplicity, and then they
: build data 'abstractions' such as Integer, which look nothing like
: real data types(interesting, since you so hate LPC data abstraction
: on that same account:) and are tedious to use. Blech.

What????

Integer is a real data type and looks like a real data type.

LPC is a shit language for data abstraction (which answers your
question why LPC is not a true object language) for two reasons:
* all abstract data in LPC is of the same type; your stack object is
type object and nothing more, so is your date object or file object or
whatever
* in order to do data abstraction in LPC, you have to step outside the
LPC garbage collection paradigm and do your own memory managemen,
otherwise you end up with serious leaks

What exactly does Java sacrifice for simplicity?

: : And this paragraph did nothing to address the issue of symantic
: : consistency.

: Or even semantic consistency. Little things like always either passing
: something by reference or value as the default, and not making it depend
: on things like location:)

Which is a completely irrelevant issue in the LPC world.

: : : To be replaced by Java? Please. LPC contains many, many features which

: : : are far and away superior to the so called industry standards. The only
: : : languages I've yet really looked at that are similarly innovative in
: : : certain areas are Perl5 and Python, and nobody who knows them well would
: : : suggest them for a serious secured multiuser environment in which users
: : : can modify the source code of said environment, unless he had not
: : : seriously considered the implications of such a project.

: : Java is a much better language than LPC in every single respect.

: Speed: no.

The fastest Java VM is most certainly faster than the fastest LPC VM.

: Security: nope.

LPC and Java are the only two languages I know of with a security
model. Their security models, however, are different. Java's is
better for some things; LPC's for others.

: Ease of use: please.

Java is much easier to use.

In more detail, if Java code compiles, it almost always runs. That is
a tremendous boost over LPC code which rarely runs properly even when
it compiles.

: Data abstraction: I refer you to Integer from Java, which cannot even be

: added normally, and invite you to compare with what can
: be done with creative mixing of the class and object
: types in LPC.

Do you even know what data abstraction is? This ain't it.

First, getting into your little off topic issue, show me an LPC
abstraction of an int that beats Integer.

Second, let's talk about real data abstraction issues, such as how to
build a Data or File object in LPC.

: Encapsulation: They're similar in capability.

Yes.

: Inheritance: Java's is less flexible, but they are similar in

: capability in the way they really get used.

Java's inheritance mechanism with interfaces makes for a more robust
representation of common design patters.

And if multiple inheritance is what you want, let's talk about LPC's
virtual inheritance...

: Syntax: Again, I refer you to Integer. Java also has no

: foreach, and is lacking in many other areas as far
: as control structures go.

Integer is a non-example. I agree foreach() rocks in LPC, but only
MudOS has foreach(). No other driver does. So, on the whole, they
are both syntactically identical languages.

: Readability: probably similar, but its subjective

Java is much easier to read.

: Writability: Java might even win, if you don't mind being treated

: like a child by your language and don't mind
: capitalizing everything and using .intval to get
: the 'value' of an integer(as though it has other
: meaningful properties.)

It is much easier to write for reasons I addressed above.

: Have I missed anything?

The point?

: : : Now, if you propose to design an entirely _new_ system and language based

: : : on what has been learned from LP and maybe some other things, that might
: : : be interesting, but that isn't what you said.

: : I would propose Java with Python syntax. I would not propose anything
: : from LPC.

: Java is a language. If it has Python syntax, it's Python. If what you
: want is Python compiling to the JVM, fine, but that's Python.

You are just a complete buffoon. Java is a platform. It includes the
language plus the VM. Python on the JVM is not Python, it is Python
on the JVM--something completely different. And exactly what I want.

[George Reese]

John Adelsberger <j...@umr.edu> wrote:
: Distribution:

: George Reese <bo...@imaginary.com> wrote:

: (I wrote):

: : : encapsulation - better than C++, so you can't complain there
: : : inheritance - the implementation could be a bit cleaner, but it works well
: : : data abstraction - requires a bit of thought, but look at my new lib when
: : : I release it and tell me it isn't possible then.

: : I have been doing this a wee longer than you and I *think* I
: : understand the issues involved. Data abstraction is impossible to
: : rely upon in LPC since any such abstraction:
: : * has no automatic garbage collection
: : * fails to maintain type semantics

: If you think data abstraction requires garbage collection, you are wrong
: about thinking you understand the issues involved. Such a view says that
: Ada, C++, and earlier versions of Smalltalk even aren't OO - surely you
: aren't this obtuse?

What is LPC's one greatest, most touted feature? YOU DON'T HAVE TO
WORRY ABOUT MEMORY ALLOCATION ISSUES BECAUSE IT PERFORMS YOUR GARBAGE
COLLECTION FOR YOU.

In order to fake data abstraction in LPC, you have to hack it in and
you are left in a realm without GC and thus in a completely
impractical situation in the LPC world.

The fact that you can have data abstraction without GC is 100%
irrelevant.

: I'm not even sure whwat you mean by type semantics, but if you mean

: you can't overload operators, this is a _GOOD THING._ Operator
: overloading is the most easily misused feature around, even if you
: count variable aliasing, and is the number one source of bad C++
: code that I've encountered.

No, I mean that a file is not a file, it is an object. A date is an
object. A stack is an object. That is all they are. A file is type
equivalent to a date.

That is not data abstraction.

: As for your statement that it is impossible to rely on: what do you mean

: by rely? I use and rely on the use of data abstraction in LPC on a daily
: basis.

Oh really? I use it in a couple of VERY guarded circumstances on the
mud. Even still, I lose a lot specifically because of its impleteness
with respect to typing. It is not something you want your area coders doing.

: : Yes, you can do it; but the only places it is useful is under the

: : covers where no one can see it. And it is still not full data abstraction.

: You seem to have lost sight of the purpose of data abstraction. Data
: abstraction makes programs easier to read, easier to write(somewhat) and
: as a result of those improvements, adds _somewhat_ to reliability. It is
: nothing more, does nothing more, and that is that. Quite frankly, if to
: you no language is truly OO unless user defined types are _exactly_ like
: internal types, then your beloved Java isn't even close. Neither are
: Smalltalk, C++, Ada, or _any_ other language yet invented. Clearly your
: absolutism is unwarranted here.

You are babbling.

: And again, you engage in silly argment from authority and character

: negation by trying to sound more experienced than me. Cut the shit.

Well, I am more experienced than you. You think this means nothing?

: : : : Less dramatic, I don't see the point in building *new* LPMud servers.

: : : Because you don't want one that does something the current ones don't.
: : : I do. Others do. Granted, we could just write something completely
: : : different, but if we choose not to, who are you to say there's no
: : : point in our efforts?

: : There are better tools out there.

: That's a pretty bold statement, given that you have absolutely no idea
: what my goals are.

There is no good reason for writing a brand new LPC driver.

[Kris Van Hees]

On 25 Aug at 18:44:19, George Reese wrote <5tsjof$rms$1...@darla.visi.com> which contained:
> Kris Van Hees <ae...@ny.fnx.com> wrote:
>: On 23 Aug at 01:25:09, George Reese wrote <5tle6k$lds$1...@darla.visi.com> which contained:
>
>: Not really true. Actually the more academic and established base of OO
>: experts still looks at Java with alot of reservations as to whether it
>: is really as great as is generally accepted. In fact, several times has
>: the topic been discussed of companies spending tons of money these days on
>: investing in a language (Java) which hasn't even proven it's worth yet.
>
> Who? I have read stuff by the three amigos and talked to Peter Coad
> face to face. In fact, it was Peter Coad who convinced me that the
> lack of MI in Java was a good thing.

Check the thread (in which you actually contributed) on comp.object, "Avoiding
the second historic mistake", started by Bertrand Meyer.

I can't say much for Peter Coad convincing you that lack of MI in Java is a
good thing, but I can't say I agree (nor is there concensus on this subject
in general in the OO world) that lack of MI is ever a good thing, except
for perhaps very specialized cases or for educational purposes.
>
>: What is so controversial about Eiffel, other than that it is one of the
>: main OO language around?
>
> The question is not whether Eiffel is OO. It is definitely one of the
> most OO languages around.
>
> The issue was raised that a list of languages were held up as
> 'more-OO' than Java. Of that list, I dismiss the whole lot EXCEPT
> EIFFEL as being MUCH less OO than Java. Since I agree there are
> arguments for saying Eiffel is more OO than Java (and vice versa), I
> do not think that is nearly as interesting as hearing John try to
> defend something as silly as, say, Perl5 being more OO than Java.

Oki, I misunderstood you here then,
>
>: > question why LPC is not a true object language) for two reasons:

>: > * all abstract data in LPC is of the same type; your stack object is
>: > type object and nothing more, so is your date object or file object or
>: > whatever
>: > * in order to do data abstraction in LPC, you have to step outside the
>: > LPC garbage collection paradigm and do your own memory managemen,
>: > otherwise you end up with serious leaks
>

>: The above is by common standards not a reason to discount LPC as a true
>: object oriented language (again... object language combined object based
>: and object oriented, which are DIFFERENT methodologies - try using the
>: one you mean here, that makes things easier to read).
>
> Huh? I mean true OO. Meaning strong support for the four principles
> I have outlined, one of which is data abstraction.

That's you view. Thanks for clearing up the object based vs object oriented
though, that makes it easier to understand the issue in full. Anyhow, I
simply don't agree with your definition of 'true OO' :-) Or rather, with
the interpretation you give for the four main principles used in OO. First
and for all, the actual main principle is to be "abstraction", not just
"data abstraction". That's a disputable position to take, but I believe
most newer OO language designs have agreed upon the fact that pure functional
objects rather than data objects are indeed useful, and thus data abstraction
on itself is too limiting.

Furthermore, the actual 'abstraction' refers to the object model being an
abstraction of the real world environment is models. In that sense, there is
no real rule on how to implement this. LPC actually fulfils the abstraction
requirement by making it possible to create an abstract model of the real
world you want to implement. I have a prototype of a mudlib which shows that
very clearly.
>
>: Not that a real
>: definition of object orientation exists (as I mentioned in a previous
>: post already).
>
> I do challenge you to find literature that does not support my
> minimalist view of object orientation in a programming language.

Give me a strict definition of 'true object orientation' and I'll consider
looking into it. It is a waste of time anyhow, since lack of accepted
definition automatically means that obviously anyone can have his or her
own definition. All that counts is being close enough to the generally
accepted norm.

Anyhow, the issue is whether LPC is a true OO language or not, which doesn't
have to do with your definition, but how you use that definition to classify
languages.
>
<< About Speed of Java implementations. >>

>: Right now, yes. Doesn't have to be though. As Lucent has shown with
>: Dis (the VM in Inferno), and as has been described in a comparison between
>: Inferno and Java, the stackmachine based VM used for Java is inferior to
>: the memory-to-memory architecture of Dis. Reason is that although the use
>: of a stackmachine is easier to design and extend, when doing Just-In-Time
>: compilation, there is a real advantage to having a VM which is closer to
>: real architectures.
>
> That is not really relevant to the topic at hand.

Neither is Java relevant to DLPC, as far as I can determine :)
>
>: It would be an interesting study though to see whether semantically Java is
>: capable of running straight on another architecture (without using the JVM).
>
>: I don't mean the following as an insult to Java:
>
>: Has anyone noticed how Java and the JVM are relatively similar to
>: the old PASCAL with the P-code machine?
>
> I think that is intentional.

I'm pretty sure it is yes. Then again, the P-code machine implementations
of PASCAL (e.g. using a P-code simulator to run compiled PASCAL code on) has
generally been considered a cute idea, but all sensible implementations (as
far as sensible PASCAL implementations are possible) did away with the step
of having a P-code machine, and generate pure object code.

Aedil

[John Adelsberger]

Kris Van Hees (ae...@ny.fnx.com) wrote:
: On 22 Aug at 23:42:29, John Adelsberger wrote <5tl83i$7f8$1...@news.cc.umr.edu> which contained:
: >

: > I've read lots of Java, written just a teeny bit, and seen a friend write
: > a large software system in it. I've read a bit of the VM spec and compared
: > the VM to others around. I read part of a book on the subject before
: > realizing that it was written for VB programmers who don't know memory
: > from disk. I know enough to know that Java is only a force in the world
: > because it was the first thing out there that had a VM and was available
: > for use as an open standard.

: This is far from true. The concept of Virtual Machines goes back a long time
: in history, with major peaks such as the IBM VM virtual architecture used on
: 360 and 370 family mainframes. And that is merely one example.

Read what I wrote. I didn't say it was the first thing to implement a
virtual machine. I said it was the first language based on a VM, by
which I meant strictly defined VM, that was also an open standard. Do
you care to propose that the VM architecture is/was an open standard?

FYI, I _know_ the history of computing.

: For the small scale programming, Java is indeed about the first (along with
: (the more integrated) Limbo language for Inferno). Alot of the current
: success is also due to the rather large hype, and pushing from Sun to get
: it into the open.

Limbo is far superior to Java, as is its VM. Especially in the performance
department. The Java VM is terribly poor in this category.

: Um, George did point out that my implementation of a LPC-alike language us
: indeed multi-threading, so you 'No' is not correct here. And you really can
: count my implementation (which makes your count up to five), even though it
: is definitely not straight LPC.

He was ignoring someone elses. Yes, you bring it to five.

: Note that I fully disagree that writing something derived from LPC is a Bad
: Thing[tm], as George mentioned in an earlier post. Almost all languages have
: aspects which are actually pretty nice and useful. Borrowing such ideas from
: various language can help to build a better language. As such LPC is a nice
: testcase to build on, because it is so open and easy to use.

LPC as it is evolving in the beta driver for MudOS right now is actually
a much nicer language than Java, and with the LPC->C stuff, it is certainly
faster. Of course, to some extent, language preference is a personal
thing, but Java is demonstrably uglier, demonstrably slower, demonstrably
_less_ OO as defined by the originators of said concept, and carries with
it a large object library whose design is questionable at best. LPC can
certainly be improved upon, but anyone who's tried to get even a simple
thing like a datebook app to run on more than one platform's JVM is
unlikely to have anything nice to say about it. They keep saying that
every new version will fix it, and it keeps not happening. I've got
a friend whose code checks as 'pure Java,' but it only runs on the Sun
implementation(properly, anyway.) He's not amused. Neither am I.

I can understand GUI appearance inconsistencies, but code failing to run?
Please. LP, done to support a game, has done this right from the
beginning. Java is a kiddie toy.

[George Reese]

John Adelsberger <j...@ultra1.cc.umr.edu> wrote:
: George Reese (bo...@imaginary.com) wrote:

: : Who? I have read stuff by the three amigos and talked to Peter Coad

: : face to face. In fact, it was Peter Coad who convinced me that the
: : lack of MI in Java was a good thing.

: You must be a sucker in the extreme.

How so?

: : do not think that is nearly as interesting as hearing John try to

: : defend something as silly as, say, Perl5 being more OO than Java.

: More OO by your idiotic definition, no.

I am still waiting for you to justify that.

: : Huh? I mean true OO. Meaning strong support for the four principles

: : I have outlined, one of which is data abstraction.

: True OO is whatever you say it is, eh? Take a hike, dipshit.

Those are 4 very widely accepted criteria for OO-ness, Aedil not
withstanding.

: : I do challenge you to find literature that does not support my

: : minimalist view of object orientation in a programming language.

: The Smalltalk development papers. Oops, those were written by the guys
: who invented OO. Sorry, you lose, play again sometime, fool.

And???

What specifically do these papers say that define OO?
Who specifically are you referring to as 'the guys who invented OO'?

: : : > You are just a complete buffoon. Java is a platform. It includes the

: : : > language plus the VM. Python on the JVM is not Python, it is Python
: : : > on the JVM--something completely different. And exactly what I want.

: Java is a language. Go look at Sun's definition:)

You want to argue about things that are not the point. Sun's
definition is political and contradicts what it was saying 6 months
ago (because of Microsoft).

Whatever you, Mr. Adelsburger, wish to call it, I would like to see
Java's OO support, Eiffel design by contract, Python syntax, and the
Java VM. If you want to call it Python, you are welcome to do it.
What really matters is the content of what I am aiming at, not your
juvenile attempts to goad me into a flamefest over what is really Java.

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:

: Cite your sources. As I have said before, I have actually talked to
: one of them. That is in addition to other things I have read from
: Booch, Jacobson, and Rumbaugh.

It's called Xerox PARC. They invented Smalltalk. Despite not being the
true originators of the original OO concept, as is widely believed, they
did in fact originate the first usable OO language systems, and developed
much of the modern concept of OO. Their definition of OO, while I admit
I'm interpreting, doesn't even appear to INCLUDE Java and C++, much less
advocate them.

: How is its object library questionable?

Lets see... it is implemented widely differently on different platforms
because parts of it kinda sorta can see the hardware, it uses poor naming
conventions that make code unnecessarily unwieldy, it doesn't include
everything one needs to do platform independent stuff(hence the forthcoming
Java Foundation Classes) and it is buggy. Need anything else?

: : LPC can

: : certainly be improved upon, but anyone who's tried to get even a simple
: : thing like a datebook app to run on more than one platform's JVM is
: : unlikely to have anything nice to say about it. They keep saying that
: : every new version will fix it, and it keeps not happening. I've got
: : a friend whose code checks as 'pure Java,' but it only runs on the Sun
: : implementation(properly, anyway.) He's not amused. Neither am I.

: : I can understand GUI appearance inconsistencies, but code failing to
: : run?

: Code does not fail to run. The only 'portability' issues are GUI
: inconsistencies. Either your friend is on drugs or your friend is
: developing for 1.1 which has no browser support yet.

You are impaired. I said, _IT FAILS TO RUN._ Not 'I think it will' but
rather IT HAS FAILED TO RUN.

: And I have been doing this for 2 years now.

Wow. I've been programming for about 11 years, and in a variety of
languages. Of all I've seen, I even like some variants of BASIC better
than Java. But so what?

: LPC is a nice start, but I have already pointed out its most glaring
: weaknesses.

You have? I must have missed this. If you mean data abstraction, strongly
typed user defined types are a hindrance and a pain anyway; only those too
stupid to understand and use them effectively need them.

[Ralf Engels]

Please, don't bang your heads together.

I think Java is a very nice language and just right to
implement a LPC-like Mud-Server.

To prove this I have begun to implement it.
Anyone how wants to mail some Comments, who wants the
code I have written to this point or who wants to
marry me,

ren...@hydra.informatik.uni-ulm.de

Ralf Engels

[George Reese]

Corey Brenner <bre...@umr.edu> wrote:
: Kris Van Hees <ae...@ny.fnx.com> wrote:
: : On 23 Aug at 01:31:49, George Reese wrote <5tlehm$lds$2...@darla.visi.com> which contained:
: : >
: : > There is no good reason for writing a brand new LPC driver.

: : I am not writing one, but I think that perhaps stability, concurrency, cleaner
: : OO language design, performance, and distribution are all reason for writing a
: : new LPC driver. And there is of course the other one... It could be fun and a
: : very nice exercise.

: Yes, but to paraphrase George, "If your goal is to put up a mud, no." ;-)
: Seriously, though, I think it is time for development on a new LP driver.
: I'd like to see one threaded and the entire [ekl...]fun interface cleaned
: up.

What would you expect to get out of this effort that you cannot find
in Java?

[George Reese]

John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
: George Reese (bo...@imaginary.com) wrote:

: : Cite your sources. As I have said before, I have actually talked to
: : one of them. That is in addition to other things I have read from
: : Booch, Jacobson, and Rumbaugh.

: It's called Xerox PARC. They invented Smalltalk. Despite not being the
: true originators of the original OO concept, as is widely believed, they
: did in fact originate the first usable OO language systems, and developed
: much of the modern concept of OO. Their definition of OO, while I admit
: I'm interpreting, doesn't even appear to INCLUDE Java and C++, much less
: advocate them.

Gosh, neither does mine. Mine has four very simple, well-defined
concepts that have nothing to do with Java or C++.

And the documents you speak of have nothing to do with Java at all.
Not even in a negative sense.

So what exactly is the point you are trying to make?

Again, I challenge you for the 5th or 6th time:
How are Perl5, Python, or LPC more OO than Java?

And related to what you were ostensibly trying to prove above, what
literature out there suggests Java is not OO and why?

: : How is its object library questionable?

: Lets see... it is implemented widely differently on different platforms
: because parts of it kinda sorta can see the hardware,

What object world do you come from? Being OO means you are
implementation independent.

: it uses poor naming

: conventions that make code unnecessarily unwieldy

What poor naming conventions are those? Java's naming conventions are
very well defined and very consistent.

: it doesn't include

: everything one needs to do platform independent stuff(hence the forthcoming
: Java Foundation Classes) and it is buggy. Need anything else?

You have two issues here. First, it has not been out long enough to
have all the platform indepdent stuff it needs. Your judging it
against the impossible is ridiculous.

Second buggy? Not.

: : : LPC can

: : : certainly be improved upon, but anyone who's tried to get even a simple
: : : thing like a datebook app to run on more than one platform's JVM is
: : : unlikely to have anything nice to say about it. They keep saying that
: : : every new version will fix it, and it keeps not happening. I've got
: : : a friend whose code checks as 'pure Java,' but it only runs on the Sun
: : : implementation(properly, anyway.) He's not amused. Neither am I.

: : : I can understand GUI appearance inconsistencies, but code failing to
: : : run?

: : Code does not fail to run. The only 'portability' issues are GUI
: : inconsistencies. Either your friend is on drugs or your friend is
: : developing for 1.1 which has no browser support yet.

: You are impaired. I said, _IT FAILS TO RUN._ Not 'I think it will' but
: rather IT HAS FAILED TO RUN.

That's either bullshit or some really weird circumstances.

: : And I have been doing this for 2 years now.

: Wow. I've been programming for about 11 years, and in a variety of
: languages. Of all I've seen, I even like some variants of BASIC better
: than Java. But so what?

I have been programming longer than 2 years. You are missing the
point, but you seem to do that a lot.

The point is that I have been doing JAVA DEVELOPMENT for two years.
That means I am well aware of what you can or cannot do with it.

: : LPC is a nice start, but I have already pointed out its most glaring
: : weaknesses.

: You have? I must have missed this. If you mean data abstraction, strongly
: typed user defined types are a hindrance and a pain anyway; only those too
: stupid to understand and use them effectively need them.

While your insult is touching, this was not the only problem with it.

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:

: On 27 Aug at 03:48:09, George Reese wrote <5u082o$mib$2...@darla.visi.com> which contained:
: > John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
: >: Lets see... it is implemented widely differently on different platforms

: >: because parts of it kinda sorta can see the hardware,
: >
: > What object world do you come from? Being OO means you are
: > implementation independent.

: Sorry George, but what does OO have to do with implementation independence?
: Looking back at the 4 major principles of object orientation, as they are
: generally accepted as being the main characteristics (and even checking the
: 3 sub-principles as set forward in Booch's classification)... there is no
: implementation independence in there. The only vaguely related issue is that
: of a perfect object design (utopia) being such that every class can be
: replaced by a functionally equivalent class without requiring any other code
: changes.

I was not putting that up as a criteria; I have clearly stated the 4
major principles already.

The point is that implementation independence is a good thing, not a
bad thing.

[Rick J. Irvine]

George Reese wrote:
>
> Whatever you, Mr. Adelsburger, wish to call it, I would like to see
> Java's OO support, Eiffel design by contract, Python syntax, and the
> Java VM. If you want to call it Python, you are welcome to do it.
> What really matters is the content of what I am aiming at, not your
> juvenile attempts to goad me into a flamefest over what is really Java.

Honestly, George. You never required much goading to get into a
flamefest. You were always wanting to bust chops about the dumbest
things. Things which usually didn't have a defined right or wrong
answer, allowing you to argue and list points for hours on end.
Most of what I have seen on here is opinion and flames, not much
else. At first I said 'man, no one else is going to want to join
this conversation simply because they will get eaten alive as soon
as they open their mouths.' Now I think folks won't want to join
simply because there really isn't that much to jump into...

*grin* Nothing's changed.

Cheers,
Alexus

[Greg Foley]

Kris Van Hees wrote:
>
> On 27 Aug at 02:53:09, George Reese wrote <5u04rk$k6i$2...@darla.visi.com> which contained:

> >: John Adelsberger <j...@ultra1.cc.umr.edu> wrote:
> >: : Huh? I mean true OO. Meaning strong support for the four principles
> >: : I have outlined, one of which is data abstraction.
> >
> >: True OO is whatever you say it is, eh? Take a hike, dipshit.
> >
> > Those are 4 very widely accepted criteria for OO-ness, Aedil not
> > withstanding.
>

> That's a cheap shot, and far from true, George. I disagree with your
> interpretation of the 4 main principles (you do not mention the 3 sub
> principles, so I don't know if we agree on those). Saying that I do
> not agree with the generally accepted criteria for object orientation
> is a ridiculous statement. Especially since you have definitely not
> read the main work where I formally state my view on object orientation.
>
> Aedil
Ok can i ask for a recap? after scrolling through over a hundred reposts
back and forth between A.,G., and J....i must ask..
George what are your Four main principles?
Aedil what are your Three subprinciples?
John what are you trying to say?

-looknfor ...enlightenment or something...

[Greg Foley]

Jay A. Carlson wrote:
>
> In article <5tvnd8$4l2$1...@news.cc.umr.edu>,

> John Adelsberger <j...@ultra1.cc.umr.edu> wrote:
> >George Reese (bo...@imaginary.com) wrote:

> >: I do challenge you to find literature that does not support my
> >: minimalist view of object orientation in a programming language.
> >
> > The Smalltalk development papers. Oops, those were written by the guys
> > who invented OO. Sorry, you lose, play again sometime, fool.
>

> I dislike spelling flames, but you appear to have horribly misspelled
> "Simula".

>
> >: : > You are just a complete buffoon. Java is a platform. It includes the
> >: : > language plus the VM. Python on the JVM is not Python, it is Python
> >: : > on the JVM--something completely different. And exactly what I want.
>
> > Java is a language. Go look at Sun's definition:)
>

> There are plenty of fine newsgroups to discuss this. I've certainly
> lost track of any relevance of this discussion to r.g.m.lp. If you
> two want to play last word, you can do that in email much more
> efficiently (although it does deny you the audience you obviously
> crave).
>
...well it was in email for awhile... but that kinda died down..
i am refering to the LPC-Language email list..
-Looknfor

> And you wonder why people want another newsgroup or two in the r.g.m
> hierarchy. Please get this long convo back on topic, or STFU.
> --
> Jay Carlson n...@kagoona.mitre.org n...@nop.com
> The MITRE Corporation, Bedford MA
>
> Flat text is just *never* what you want. ---stephen p spackman

[John Adelsberger]

Kris Van Hees (ae...@ny.fnx.com) wrote:

: John Adelsberger <j...@ultra1.cc.umr.edu> wrote:
: : Kris Van Hees (ae...@ny.fnx.com) wrote:

: I read what you wrote, just interpreted it differently. To me is sounded
: as the open standard part was not included in the 'first thing' part. Sorry
: for the wrong interpretation. Still, as things stand now, the VM arch was
: not much different in open-ness of the standard compared to the JVM. Both
: are owned by a company (unless the JVM became an independent standard lately,
: which I think I'd have noticed). The VM architecture was just a tiny little
: bit (sarcasm implied) more complex :)

The JVM is owned by a company. So are parts of the GNU C compiler, as I
recall, by the copyrights. So what? The fact is, the licencing is what
matters(no, I am not implying that the JVM is GPL:) in determining what
is an open standard and what isn't, and VM certainly isn't. The JVM is
available, and I can implement my own version and do whatever I want with
it, and SunSoft won't give a damn. _That_ is what counts.

: No need to be defensive, I don't doubt your knowledge on this, and as such
: I was merely pointing out a fact which not everyone realizes. I do consider
: newsgroups a forum with many participants, and as such try to write replies
: with that in mind.

Indeed; sorry about that.

: : Limbo is far superior to Java, as is its VM. Especially in the performance

: : department. The Java VM is terribly poor in this category.

: A design issue I believe. The choice of a stackmachine for the JVM seems to
: indicate that it was designed with interpretation in mind, and that the idea
: of actually compiling Java code to machine code for a given platform (and the
: JIT compilers) came as an answer to the performance complaints. Dis was from
: the beginning intended to be compiled directly into machine code.

Probably. Nevertheless, Dis is far superior for the category of software
they both target, and as I recall, there is a Java->Dis compiler. Basically,
the only thing preventing its use is that its licencing isn't quite as nice
and nobody's heard of it.

Just for grins, has anyone considered non-stackmachine implementations of
LPC? The language itself, despite claims to the contrary, is easy to
learn and relatively clean, and well supports(better, than, for instance,
C++) most OO concepts. It could be fun:) (For that matter, the parts
that aren't real clean right now _could_ be in a new implementation:)

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:
: John Adelsberger <j...@umr.edu> wrote:

: What is LPC's one greatest, most touted feature? YOU DON'T HAVE TO

: WORRY ABOUT MEMORY ALLOCATION ISSUES BECAUSE IT PERFORMS YOUR GARBAGE
: COLLECTION FOR YOU.

Wow, it does reference counting. So does every other interpreted language
worth the effort of learning the syntax of. What does this have to do with
data abstraction?

: In order to fake data abstraction in LPC, you have to hack it in and

: you are left in a realm without GC and thus in a completely
: impractical situation in the LPC world.

You've yet to explain how doing data abstraction screws your GC. I think
it is because it is dependent upon your implementation and you don't want
to admit it or believe it is the only implementation and that it is
obvious that that is so. You're wrong, either way.

: The fact that you can have data abstraction without GC is 100%
: irrelevant.

This is precisely correct.

: No, I mean that a file is not a file, it is an object. A date is an

: object. A stack is an object. That is all they are. A file is type
: equivalent to a date.

Only in your pathetic mind. Do you whine that classes in C++ are the same
thing as dates? I would hope not. The class serves the same purpose as
the LPC object, even if their form is somewhat different.

: That is not data abstraction.

Again, precisely correct. Why did you mention it, since the topic _was_
in fact data abstraction?

: Oh really? I use it in a couple of VERY guarded circumstances on the
: mud. Even still, I lose a lot specifically because of its impleteness

: with respect to typing. It is not something you want your area coders doing.

Area coders aren't likely to know what data abstraction _is_ much less be
capable of using it coherently. They don't need to anyway.

: : You seem to have lost sight of the purpose of data abstraction. Data

: : abstraction makes programs easier to read, easier to write(somewhat) and
: : as a result of those improvements, adds _somewhat_ to reliability. It is
: : nothing more, does nothing more, and that is that. Quite frankly, if to
: : you no language is truly OO unless user defined types are _exactly_ like
: : internal types, then your beloved Java isn't even close. Neither are
: : Smalltalk, C++, Ada, or _any_ other language yet invented. Clearly your
: : absolutism is unwarranted here.

: You are babbling.

No, that's not babbling, that's called 'demonstrating that as usual, George
is talking out his small end.' You'll learn the difference someday, maybe.

: : And again, you engage in silly argment from authority and character

: : negation by trying to sound more experienced than me. Cut the shit.

: Well, I am more experienced than you. You think this means nothing?

It means you're older than me. That's about it. Experience can mean
skill and knowledge, but as you routinely demonstrate, it doesn't have to.

: : : There are better tools out there.

: : That's a pretty bold statement, given that you have absolutely no idea
: : what my goals are.

: There is no good reason for writing a brand new LPC driver.

Repeating your overly bold statement may make your simple mind believe it
a bit more firmly, in a fashion similar to chanting religious mantras, but
it will not alter reality.

[Kris Van Hees]

On 01 Sep at 19:00:39, John Adelsberger wrote <5uf3bj$15h$1...@news.cc.umr.edu> which contained:

>
> Just for grins, has anyone considered non-stackmachine implementations of
> LPC? The language itself, despite claims to the contrary, is easy to
> learn and relatively clean, and well supports(better, than, for instance,
> C++) most OO concepts. It could be fun:) (For that matter, the parts
> that aren't real clean right now _could_ be in a new implementation:)

I have condidered such an implementation (and actually have a design for
Abyss using a non-stackmachine approach). However, unless you intend to
do compilation into machine code, there is little or nothing to gain. I
might still do it in the future as very few things in my implementation
of Abyss actually depend on the choice of interpreter engine.

The downside of non-stackmachine implementations is that usually they'll
involve more advanced compiler techniques such as register colouring. I
found those to be too much of a slowdown. With concurrent compilation,
or even if compilation on the fly isn't too much of an issue (or in the
very exotic case that someone writes a JIT compiler for an LPC-based
language) a non-stackmachine implementation would be superior.

Aedil

[Kris Van Hees]

On 30 Aug at 00:39:39, Greg Foley wrote <34076B...@centuryinter.net> which contained:

> Ok can i ask for a recap? after scrolling through over a hundred reposts
> back and forth between A.,G., and J....i must ask..
> George what are your Four main principles?
> Aedil what are your Three subprinciples?

The four main principles and 3 sub-principles of object orientation as set
forward by Grady Booch in "Object-Oriented Analysis and Design with
Applications" (1994) are:

Main: Abstraction
Encapsulation
Modularity
Hierarchy

Sub: Typing
Concurrency
Persistence

Hope that helps you out.

Aedil

[John Viega]

In article <5uk8oh$jvq$1...@news.cc.umr.edu> j...@ultra3.cc.umr.edu (John Adelsberger) writes:

> Multiple inheritance is a _requirement_ if you want to do real work in
> a staticly typed language. If you want, I'll dig up the paper that
> demonstrates it; I think it's available on the web somewhere.

This is absolute complete and utter bullshit. The most obvious
argument here is a Turing completeness argument. More practically,
when there is no multiple inheritance in an OO language, there are 2
common coping strategies. One of them is textual code substitution,
the other is aggregation or delegation.

In fact, MI is rarely used in practice. Of the "design patterns"
described in the seminal book of the same name, I believe only 2 of
them rely on it. However, like I said, there are obvious and well
used coping strategies, that are sometimes FAR less desirable in terms
of the amount of eror prone and tedious easily automated work the
programmer has to do.

> : : : I do challenge you to find literature that does not support my

> : : : minimalist view of object orientation in a programming language.
>
> : : The Smalltalk development papers. Oops, those were written by the guys
> : : who invented OO. Sorry, you lose, play again sometime, fool.
>

> : What specifically do these papers say that define OO?

> : Who specifically are you referring to as 'the guys who invented OO'?

Don't worry, as someone who *really does* know the history and has
read all the papers, I can tell you w/ quite a bit of confidence that
John Adelsberger is blowing smoke up your ass in an attempt to look
credible. But I'm sure you already knew this already. The main goal
of Alan Kay, the guy who coined the term "Object-oriented" in
reference to programming languages was to simplify the task of
programming by having it model real life.

However, OO was not "defined" until Wegner in 1986[SIGPLAN v21 n10
p173]. The definition he gave, which is still taught in most books is
"OO = data abstraction + abstract data types + type inheritance".
Actually, he might have made this definition even earlier in the Dec
'95 ACM Computing Surveys (Cardelli & Wegner) which is a seminal paper
on types and polymorphism, and discusses inheritance in that context
(I'm not in front of my papers, sorry if I don't get more accurate).
This definition is how people classify PL's into OO vs Object Based.
Certainly, there are plenty of other features that are associated only
w/ OO languages. However, that's the core of OO. Anything as to what
is "good OO" depends on the particular methodology... usually people
have in mind what Booch talks about in his OO Analysis book.

Even so, languages without "inheritance" that still support type
inheritance are still considered OO languages. In fact, there are a
whole bunch of languages like that (Actor languages)... they rely
entirely on delegation. For one example, see the paper "Delegation is
Inheritance" be Stein, it's in an '83 SIGPLAN somewhere.

>
> Oh, Xerox PARC's Smalltalk team and the academics who gave them the
> ideas. Nobody special by comparison to _you._ And what they did was
> define OO in a very strict sense that your 'minimalist' defn doesn't
> meet. I'm not going to repeat what they said; either read the damn
> things yourself or quit pretending you know something about OO.

You've said this before (that Smalltalk's ideas all came from
academics outside PARC, they didn't do the research, and they just did
the implementation) , and I didn't get a chance to respond to it due
to a vacation, but now I'm going to call bullshit. The Smalltalk
language team got its ideas from two places. Simula 67 is one. It is
obvious if you know Smalltalk and Simula 67 what concepts stem from
Simula. The second is from Alan Kay, who, in the late 60's, designed
an architecture called Flex, from which he developed the ideals that
went into Smalltalk. Hmm, Alan Kay was at Xerox Parc for the whole
Smalltalk/Dynabook project.

I find it offensive that you are using a history too vague to be
useful in your pitiful attempts to be correct, and emerge the victor
in your little war. I find it even more offensive that you refuse to
present any real evidence when asked to do so. For example, you
mention "Smalltalk Design Papers" to argue your case, without ever
providing a single reference, as if you've read them, which, as
someone who has read most of them, I can say with some certainty you
have not, because you fail to show any degree of knowlege as to their
content. Even after you were directly asked to provide a reference
and some specific content, you revert to personal attacks instead of
throwing around some actual fact.

> as yet. As for "Java's OO support," Eiffel kicks the shit out of Java
> for OO, as does Python(although less so than Eiffel.)

Oh, come on, based on whose notion of OO? As usual, you are so vague
that your statement is essentially vacuous. For example, if you look
in the back of Booch, he discusses Eiffel in relation to his highly
and widely regarded Object Model:

1) While it has instance variables and methods, it fails to have class
variables or methods.

2) It fails to provide persistence primitives.

3) It fails to provide multitasking primitives.

All three of those things are supported by Java, either directly by
the language in the first case, or indirectly through the standard
class libraries for the other two cases.

Of the things Booch uses as critereon, the only one where Java could
even be considered to fall short of Eiffel is in multiple inheritance.
Then again, Java's interfaces cover a little less than 1/2 of the
utility of multiple inheritance in a well designed system.

Now this is just based on the Booch methodology.

Now if we look at Python, I don't know what the hell you are thinking.
As someone else pointed out in another post, Python is 100% devoid of
encapsulation. That's very big in most peoples methodologies.
Interestingly enough, if you look at the works of the people who do
Actor languages, you will find discussions on how inheritance hurts
many peoples notion of OO because it encourages breaking of
encapsulation by allowing dependancies on data from your superclasses.

Of course, I could almost always make arguments that Java is more OO
than X, and that X is more OO than Java. It depends on the particular
methodology, and not some widely held view of what is or isn't an OO
feature. Therefore to me, it's not an interesting thing to argue.
But I do hate watching you slam people with vacuous words that seem
like they might be credible to anyone with only a cursory knowlege of
the material.

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:
: John Adelsberger <j...@umr.edu> wrote:

: : Distribution:

: : Before I knew enough to write real lib code, I wrote for a lot of startup

: : MudOS setups; almost all of them were DW.

: Please name those; there are in fact very few DW muds.

One(right now) is Citadel. I wrote for RoD(not a startup:) for a little
while. I also wrote for a couple that never got off the ground(you've
never heard of them.) As for 'very few DW muds,' anyone who goes and
looks at an intermud listing _knows_ you're lying through your teeth.

: : This group isn't even _read_ by most admins of MudOS startups. Sorry,

: : but while there's no way to prove it, DW is by far the most popular
: : MudOS lib in history.

: You are hilarious. DW is the single least popular. That is not a
: reflection of its quality; it is however a fact.

Lima is more popular recently. But as far as number vs all time, DW
wins hands down.

: That startups may or may not read this newsgroup is irrelevant; there

: was an actual MudOS lib count done a while ago. To get a quick count,
: just check the intermud mudlists--all MudOS libs come with intermud
: access by default.

All MudOS libs come with intermud access by default... that's a good one.
As for a 'lib count,' if it was done via intermud, the list I just took
off of Citadel is almost all DW and Lima. A couple of old Nightmares,
one TMI something or other, one Foundation, and a couple of homebrews,
and then like 3 or 4 2.4.5 knockoffs. Guess what? You're wrong.

: : I write code neatly the first time. If you think being alpha is an

: : excuse for poor indenting, poor variable naming, lack of commenting
: : of non-obvious or context dependent functionality, and so on, you
: : and I disagree hopelessly.

: Nightmare is very well indented, has a consistent naming system, is
: well documented, etc. Even in alpha. Please address something
: relating to NM.

The version I saw 18 months ago was none of the above.

: And more important, it is well-designed.

I couldn't tell; reading the code was such a chore that I gave up after
about 10k worth of it. Stock DW is easier to comprehend.

: : No, _you_ made a judgement based on your book: the judgement that you

: : are better than me in some regard.

: The fact that I think that my having written book on the subject is a

: major credential in matters on the subject is irrelevant to that
: fact. I am a recognized authority on this subject; you are not. That
: does mean that when you want to argue a position, you need to do
: better than call me a moron.

Recognized authority? By whom? For what? And meaning what? More
importantly, I always prepended to the word moron the reason, quite
logical in nature, for my lending to your credits the title of moron.

: And to date, you have done nothing other than make various attempts to
: call me a moron.

Anyone reading my posts knows otherwise. Anyone taking your word instead
is also a moron.

: : I've read lots of Java, written just a teeny bit, and seen a friend write

: : a large software system in it. I've read a bit of the VM spec and compared
: : the VM to others around. I read part of a book on the subject before
: : realizing that it was written for VB programmers who don't know memory
: : from disk. I know enough to know that Java is only a force in the world
: : because it was the first thing out there that had a VM and was available
: : for use as an open standard.

: There is a lot more to it.

As usual, your claim is backed up by evidence and sound logic.

: The issue with the book is this:

: You repeatedly say that my software sucks, my proposal is idiotic,
: etc, etc without anything to back it up. Clearly, since I am a
: recognized expert on the subject matter (because of the book), you
: need to do better than bash me with moron labeling; the book means
: that without any substantial arguments from you, you are clearly
: talking out your ass.

If a book makes one an expert, then all the guys who write about how
OO is a fad are experts. I doubt you would agree with that statement.
More importantly, your proposal _is_ idiotic, and I gave reasons which
I will here recount for the listening audience.

1) By the time you get your limited form of distribution even running,
the net will be capable of doing so much more; this is the time
to be running what you are talking about, not designing it for
the future.

2) You could be writing to a standard; instead, you choose to write a
nonstandard setup, and then hack it later to meet the standard. This
is a bad idea to anyone who knows about things like design, but I'm
sure your reuse religion will let you justify it easily.

3) Your standard is so specialized as to be useless: it is needless if
you only want to use one driver, and useless if you're running on
more than one site. Who wants to run MudOS one one machine, and then
right next to it on the same desk, DGD, and run one game on the two?

I have said this all before, and more. Now tell me I give no reasons,
moron.

: : : Guess what... DLPC is an incomplete ORB.

: : No, it is not. It specifies zero object directory services, zero
: : object bus services, zero protocols, includes no IIOP support, and
: : in fact can be said to be little more than just 'incomplete.'

: That is not the definition of an ORB.

You must be reading different OMG documents than I. Where are they
located, these documents that don't specify that ORBs communicate
using IIOP?

: : If what you really want is RPC and nothing more, fine, but if you want

: : a serious mechanism for _object_ distribution that makes it realistic
: : to write and maintain a large object system independent of the location
: : of its parts, then you're barking up the wrong tree.

: Hardly.

For the third time in two days, and the second in this post, I point out
the truly well argued and supported nature of your position.

: : : I said it two weeks ago when you brought up the cncept of CORBA.

: : : Furthermore, whether or not you believe I am telling the truth does
: : : not matter. I mentioned my assumptions as well in the initial
: : : statement, which clearly corroborate my reasons for not wanting full
: : : CORBA compliance.

: : Anyone caring to look at your reply to my first posting about CORBA here
: : will note that you said no such thing, and have now made a liar of yourself
: : for all to see. You're right; it doesn't matter one bit whether _I_
: : believe you.

: Go ahead and look it up. I know what my motivations are :)

Motivations maybe, but you claim in the quote above that you 'said it two
weeks ago' and it is NOT in your posts. You lied. Admit it. (By the
time you reply to this, you'll be saying 'two weeks ago' in reference
to _this_ post, but anyone reading the thread can figure out the dates,
so just don't bother.)

: : But it isn't. If you want ref #s, go look at Dejanews; I now can and

: : have, but I'm not going to do so again right now.

: Please do. I have never said that automatic stub generation is part
: of the CORBA standard.

Assuming I have more time later today, I will. Class in 5.

: : : Ugh, read something about RMI first. It does provide location

: : : transparency to the developer and requires no special language
: : : features. There is no location transparency for the *designer*. This
: : : is a good thing.

: : Playing semantic games with the word developer is irrelevant. Some
: : code in RMI doesn't have to know about locations; nevertheless, as
: : a language feature, it inherently lacks location transparency. Are
: : you going to deny this?

: I am not playing any semantic games. You simply do not need any
: special code tied to specific locations ANYWHERE.

You have to know where the remote objects are when you first start up.
This is not true of a CORBA setup. Try and tell me how you can do RMI
without knowing the machine on the other end so you can start up a
communication? CORBA directory services, provided by an ORB, let you
do just that; you need only find the ORB(via multicast or broadcast)
and then you don't have to know anything else.

: : CORBA itself does not have to support these things; CORBA is a bus. It

: : is possible to do distributed garbage collection in a distributed
: : object system built on CORBA; even you will not, I hope, deny this. As
: : for Java semantics, I misspoke myself. Nobody in his right mind would
: : want them anyway.

: Of course distributed garbage collection is possible; a heterogeneous
: distributed GC system is questionable. If you think you know
: otherwise, you are questioning everybody on earth dealign with
: RMI/CORBA interoperability.

A heterogeneous distributed GC system? IBM was doing stuff like that years
ago; the fact that the crew of people working on RMI crap doesn't know shit
about history or what's been done before, and insists on reinventing the
wheel, is irrelevant.

: TMI and Nightmare, on the other hand, made MudOS.

Whatever you say. I've seen like 5 TMI muds in all time that weren't just
a kid playing in a lab for a week or so. Nightmare similar. DW, on the
other hand, and its derivatives, I've seen scores of.

: : I probably will, but I've got a lot of other work to do first on this

: : project of mine before it'll be ready for that. Truth be known, I'm
: : doing it mainly to get experience building and tweaking a VM and maybe
: : get some useful code out of it for another much larger project, and
: : figure I can make a fun game whilst I'm at it.

: Talk, talk, talk.

I work about 4-8 hrs a day on it. That's probably more time than you spend
doing anything of this sort, when taken as my consistent average over
months and months of time.

: : : : I get what you said; nevertheless, I wouldn't be designing standards

: : : : around what we have today. Before you even get them implemented, it
: : : : will be tomorrow.

: : : And my standard supports an Internet without such latencies. Duh. If
: : : the Internet were the way you suggest it will be tomorrow, then this
: : : DLPC design works fine across the Internet.

: : Works across, yes. Takes advantage of? I think not.

: It works just like RMI and CORBA, just much simpler. So you are
: really missing a point here.

No, it does not. If you implemented IIOP, it could at least be the
foundation of a CORBA service, but that's the only similarity.

: The Internet is just a slower network. There is no such thing as

: taking advantage of a slower network.

The internet is slower _now._ Years from now, when you actually get your
silly little standard implemented, it will be fast by todays standards,
and your standard will not take advantage of that fact in any meaningful
way.

: : Besides, it isn't

: : what I say that matters on this: go look at ATM(it's an open standard,
: : you can find it:) and IPV6 if you don't believe it's going to happen.
: : Of course, ADSL, gigabit ethernet(yuck) and some other stuff will help,
: : but the most general purpose stuff is ATM and IPV6.

: That has nothing to do with this subject.

Dropping context is not an argument. It _is_ relevant because of the
argument I just have been making about your 'standard's' inherent
impending obsolesence.

: : First off, nice change of subject from your foolish claim that LPC is

: : not an object language. Much easier to ignore your mistakes than
: : admit them, eh?

: I did not back off it. I stated in another post, bozo.

How useful and convenient; that'll let you drop all context while you
argue a point you're doomed to end up losing anyway.

: : Secondly, implementation is irrelevant not only to LPC as an object

: : language, but also to Java's merits as a language.

: Huh? Java is recognized by most of the big OO guys as a perfect
: language in which to implement OO design patterns. The only
: competition Java has on this front is Eiffel.

Most of the big OO guys. Sounds like a clique. Of course, most of
the big OO guys talked about how wonderful C++ is for years, and
that is rapidly being debunked as a complete joke. Eiffel has a
chance, if people can stomach its ugliness, but Java is a bad hack
based off a bad attempt at an OO language.

: : Third, if we talk about languages as languages, which _is_ sensible,

: : Smalltalk, Python, Perl5, Ada, Eiffel, and probably a dozen others
: : are all better OO languages than Java.

: Python, while I love it, is MOST DEFINITELY not a better OO language.

Whatever you say.

: Perl5 OO? *rofl*

Have you used it? Have you read about it? Do you even know that it has
object extensions? I doubt it.

: Ignore Eiffel. Eiffel is a controversial one;

Yeah, ignore the one that proves you wrong incontrovertibly. Moron.

: What about Smalltalk, Python, Perl5, Ada make any of them better OO
: languages than Java?

Smalltalk: it's an object system unto itself, and its design is cleaner.
Ada: it doesn't lack little things like parameterized types.
Python: similar in many ways, but runs faster and is nicer syntactically.
Perl5: This is a weird one, and contrary to your Eiffel bullshit, this
is the controversial one. Nevertheless, if you can get past its
inherent weirdness, the Perl5 OO stuff is incredibly usable, and
incredibly powerful/expressive, neither of which are aspects of
Java.

: : Java has _one_ benefit: it

: : is simple. It sacrifices too much for simplicity, and then they
: : build data 'abstractions' such as Integer, which look nothing like
: : real data types(interesting, since you so hate LPC data abstraction
: : on that same account:) and are tedious to use. Blech.

: Integer is a real data type and looks like a real data type.

Integer.intval? That looks like accessing a regular type to you? You
MUST be a moron.

: LPC is a shit language for data abstraction (which answers your

: question why LPC is not a true object language) for two reasons:

: * all abstract data in LPC is of the same type; your stack object is
: type object and nothing more, so is your date object or file object or
: whatever

Actually, while I'm sure many would disagree, I call this a feature.
Strongly typed UDTs only work if you have multiple inheritance, truly
static typing, overloadable operators, and a bunch of other stuff that
Java generally utterly lacks, and that is undesirable in LPC. Typing
info can be simulated in LPC anyway, your lack of imagination
notwithstanding.

: * in order to do data abstraction in LPC, you have to step outside the

: LPC garbage collection paradigm and do your own memory managemen,
: otherwise you end up with serious leaks

You keep saying this. I do a lot of clean_up stuff, but that's it.

: What exactly does Java sacrifice for simplicity?

Overloadable operators, integral object typing of basic types, multiple
inheritance... that's too much already.

: : Or even semantic consistency. Little things like always either passing

: : something by reference or value as the default, and not making it depend
: : on things like location:)

: Which is a completely irrelevant issue in the LPC world.

You keep saying that. Obviously you will never be a language designer
of any skill. Language designers don't excuse their lack of good design
by saying 'don't do this; its a bad idea' to programmers.

: : : Java is a much better language than LPC in every single respect.

: : Speed: no.

: The fastest Java VM is most certainly faster than the fastest LPC VM.

If you mean pure interpretation, maybe. LPC->C vs anything but MS's
JIT compiler is likely to change the outcome.

: : Security: nope.

: LPC and Java are the only two languages I know of with a security
: model. Their security models, however, are different. Java's is
: better for some things; LPC's for others.

Java's is useless for anything but toys, but they're supposedly fixing
that using digital signature technology. I'll wait and see before I
comment.

: : Ease of use: please.

: In more detail, if Java code compiles, it almost always runs. That is

: a tremendous boost over LPC code which rarely runs properly even when
: it compiles.

I haven't had this problem writing what is currently about 300k of LPC
and growing rapidly. On the other hand, I have found the MudOS compiler
to be incredibly handy in debugging if you have a decent error handler
and all the debugging useful pragmas enabled by default. I've yet to
encounter a bug I couldn't fix in five minutes or so, and I'm writing
from scratch. When I moved to AIX from Linux, there was zero difficulty
beyond getting MudOS to compile on a crusty old version of AIX that has
no dl libraries and so on, which took me about 3 tries.

On the other hand, a good friend has a simple calendar project he co-wrote
with a team for a semester project. It runs flawlessly on Solaris. It
barely even pretends to run elsewhere. But hey, it checks out as
'100% Pure Java.' What a joke.

: : Data abstraction: I refer you to Integer from Java, which cannot even be

: : added normally, and invite you to compare with what can
: : be done with creative mixing of the class and object
: : types in LPC.

: Do you even know what data abstraction is? This ain't it.

No, of course not. The Integer type isn't an attempt at abstracting int
into an object type. Not at all. Do you in fact know your ass from your
elbow?

: First, getting into your little off topic issue, show me an LPC

: abstraction of an int that beats Integer.

I don't need to. The LPC int _is_ an abstraction unto itself; it is
exactly the same, behaves exactly the same, on all platforms. And
you don't have to dereference a member of it to get its value. Imagine
that.

: Second, let's talk about real data abstraction issues, such as how to

: build a Data or File object in LPC.

A Data object? I do believe that's type object. The whole point of objects
is to contain data of all sorts. Precisely what more do you expect?
Maybe this?

class Data
{
string type;
mixed MyData;
}

And then a bunch of simuls like typeof and datap so on?

As for a file, I've never felt the need to do this, because the
persistence primitives(save_object and restore_object) make it too
unimportant to bother with, but if you wanted to, the read and write
family of efuns would make building such fairly easy. You could have
syntax kinda like this in usage:

object my_goddamn_file = new(File);

my_goddamn_file->open("/txt/thingie");
my_goddamn_file->read_bytes(some_bytes);
my_goddamn_file->close();

Would this give you a woody?

: Java's inheritance mechanism with interfaces makes for a more robust

: representation of common design patters.

Such as? And because?

: And if multiple inheritance is what you want, let's talk about LPC's
: virtual inheritance...

You mean MudOS's virtual inheritance. It doesn't have to be that way;
it is not inherent in the language itself.

: : Readability: probably similar, but its subjective

: Java is much easier to read.

I disagree, and as I said, it is subjective. LPC supports some things
that Java falls on its ass for(the fn pointers, the ({}) immediate form
of array notation, etc) that aren't as pretty as one might like, but
can you improve on them?

: It is much easier to write for reasons I addressed above.

Which you won't even reference in enough detail to let us identify them,
thus guaranteeing that your faulty logic won't be countered.

: : Have I missed anything?

: The point?

You always say this. What _is_ the point? Is it that you are a god and
we should all worship you and your desire to make a standard? Is it
anything, as long I don't choose to discuss it? Is it that Java will
rule the world? I'm curious, because I've been arguing within a context
(our discussion up to the point of a given post) and to an end, whereas
you've been making unsupported assertions and saying I was missing the
point, and blabbering about your book and your reuse religion, and then
including just enough pretense at real logic and evidence to avoid even
your friends ridiculing you.

: : Java is a language. If it has Python syntax, it's Python. If what you

: : want is Python compiling to the JVM, fine, but that's Python.

: You are just a complete buffoon. Java is a platform. It includes the
: language plus the VM. Python on the JVM is not Python, it is Python
: on the JVM--something completely different. And exactly what I want.

Buffoon. That's a good one. Have you been travelling with a circus?
That said, Java is a language according to the trademark holder on the
word Java. Python is python, even if you do slow it down by running it
on the JVM.

[John Viega]

In article <EFvy6...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees) writes:

> Newsgroups: rec.games.mud.lp
> From: ae...@ny.fnx.com (Kris Van Hees)
> X-Complaints-To: Email ab...@news2.new-york.net if this posting is inappropriate
> X-Trace: news2.new-york.net 873211344 18069 aedil [165.254.149.16]
> X-Nntp-Posting-Host: chillyclay.ny.fnx.com
> Date: Tue, 2 Sep 1997 14:42:25 GMT

Hmm, Booch refers to the first set as Major, and the second set as
Minor... the distinction being that without a major element, the model
is not object oriented (p. 41) Of course, look in the appendix, and
you'll see that Smalltalk, which he still considers OO, has no kinds
of modules (p. 476). Also note that the notion of a language being
encapsulated for Booch is fairly synonymous with the notion of class,
since languages without any notion of private data members are
considered encapsulated (eg, Object Pascal, see p 480 for its
classification).

In short, his notions of modularity and encapsulation are a bit too
loose to be useful in categorizing languages as OO or not OO. Again,
the generally used metric for what is and what is not OO comes from
Wegner [SIGPLAN Oct 86]:

OO = data abstraction + ADTs + type inheritance.

Which is essentially equivolent to Booch, since Booch's notions of
modularity and encapsulation are embrasingly loose.

[John Viega]

In article <EG179...@nonexistent.com> Kris Van Hees <ae...@ny.fnx.com> writes:

> : In short, his notions of modularity and encapsulation are a bit too

> : loose to be useful in categorizing languages as OO or not OO. Again,
> : the generally used metric for what is and what is not OO comes from
> : Wegner [SIGPLAN Oct 86]:
>
> : OO = data abstraction + ADTs + type inheritance.
>

> One reason why I disagree with this (and fortunately I am far from the only
> one) is that this notion of what is OO fails to include functional objects,
> more precisely objects which do are not an abstraction of any data item.

Actually, Wegner's definition is very all-embrasing. If your language
supports those three things, you've got an OO language under his
definition. It doesn't matter what else your language does or doesn't
have.

> I
> know that not everyone agrees that data-less objects are acceptable, but it
> is a bit too strict to me to be using a definition of OO these days which
> fails to classify well known OO languages as being OO :) Unless you take
> Wegner's definition loosely as saying:
>
> The language must allow data abstraction, ADTs and type inheritance
> but if it allows more, fine.

This is exactly what Wegner is saying. His definition is the metric
for what is an OO language -- a set of minimum entry requirements.

>
> : Which is essentially equivolent to Booch, since Booch's notions of

> : modularity and encapsulation are embrasingly loose.
>

> If you interpret it like I do above (so as to be able to include languages
> which allow non-data abstractions), then you could say Booch is perhaps even
> more strict because he gives more requirements ;)

Well, I feel that Booch's definition does try to be more strict.
However, by allowing Smalltalk OOness despite its lack of modularity,
and by allowing Object pascal despite public only encapsulation, he
waters down those requirements to the point that they are meaningless.
Personally, I would have classified encapsulation as a minor feature.
You don't have to have it, but it sure is nice. I don't think I would
have included modularity at all, for while it is certainly important
in Booch's methodology, it is a completely orthogonal concept from
object oriented-ness.

> Of course, I think the original issue was the OO-ness of LPC :-)

LPC is an OO language. However, it has a few shortcomings as such,
some of which have been pointed out by other people in this thread.

[Rick J. Irvine]

John Adelsberger wrote:
>
> George Reese (bo...@imaginary.com) wrote:
> : John Adelsberger <j...@umr.edu> wrote:
> : : Distribution:
>

> : TMI and Nightmare, on the other hand, made MudOS.

For once, I have to agree with Descartes. *Fear*... :)

> Whatever you say. I've seen like 5 TMI muds in all time that weren't just
> a kid playing in a lab for a week or so. Nightmare similar. DW, on the
> other hand, and its derivatives, I've seen scores of.

Wow, that is amazing to hear nowadays. Back when TMI-2 and NM (3.x)
were being developed, I would say that about 40% of the lps were
TMI-2, 45-50% were NM3, and about 5-10% were Discworld. Most of
the time the people using DW were people who were just really
trying to be different from 'the crowd's that were forming at TMI-2
and NM3. Both were growing in all directions, trying to accomodate
as many ideas as possible. Believe it or not, it was a fun time.
*sigh* Oh well...

I'm not going to comment on the rest of John's amazingly huge response
to Descartes' response to his response to ... you get the point. :)
Guys, may I suggest starting over? Instead of responding to some
big messy thing, write up a file using short, to-the-point logical
arguments that people can once again read? Most of the responses
now are 'you're a moron'. I admit, I love reading these, but it
kind of deflates the validity of the argument.

Now, before you write up this file, both of you need to go out, get
a beer, chill a bit, relax, and remember that this isn't a face-saving
contest, it's a debate of ideas. Or, if you really want to just save
face, just start slinging mud and screw the logical arguments... :)

- Alexus

[George Reese]

John Adelsberger <j...@ultra6.cc.umr.edu> wrote:

: George Reese (bo...@imaginary.com) wrote:
: : John Adelsberger <j...@umr.edu> wrote:
: : : Distribution:

: : : Before I knew enough to write real lib code, I wrote for a lot of startup
: : : MudOS setups; almost all of them were DW.

: : Please name those; there are in fact very few DW muds.

: One(right now) is Citadel. I wrote for RoD(not a startup:) for a little
: while. I also wrote for a couple that never got off the ground(you've
: never heard of them.)

And you have done exactly what for those muds?

: As for 'very few DW muds,' anyone who goes and

: looks at an intermud listing _knows_ you're lying through your teeth.

Here is the count from today:
Lima: 37
Nightmare: 27
Discworld: 22
TMI-2: 16
Other: 13
Foundation: 2

While 22 is not very few as I stated, it appears to mostly have
appeared since December 1996. It is very generous--I counted
anything as Discworld that has even remote Discworld roots (i.e. Nanvaent).

In a thread from December 1996 titled 'List of MudOS muds?', it was
determined that Nightmare muds made up 48% of the muds on that list
(at a total of 38 muds). That was the same time Nightmare was removed
from distribution. Since that time, Nightmare's presence has
decreased by only 11 muds, Limas has significantly increased,
Discworld's has moderately increased, and TMI and Foundation are
roughly the same.

: : : This group isn't even _read_ by most admins of MudOS startups. Sorry,

: : : but while there's no way to prove it, DW is by far the most popular
: : : MudOS lib in history.

: : You are hilarious. DW is the single least popular. That is not a
: : reflection of its quality; it is however a fact.

: Lima is more popular recently. But as far as number vs all time, DW
: wins hands down.

As I showed above, Discworld's popularity is only recent. And clearly
in terms of overall popularity, Discworld has never been most
popular--Nightmare most definitely holds that title of most popular of
all time (MudOS, 2.4.5 is the all-time all-LP) and Lima is currently
the most popular.

Just think about it. Nearly a year after being removed from
distribution, there are still more Nightmare muds than Discworld
muds. Compund that with the fact that in this year, two Discworld
derivative libs were released publically.

: : That startups may or may not read this newsgroup is irrelevant; there

: : was an actual MudOS lib count done a while ago. To get a quick count,
: : just check the intermud mudlists--all MudOS libs come with intermud
: : access by default.

: All MudOS libs come with intermud access by default... that's a good
: one.

What is good about it?

Nightmare, Foundation, Discworld (and derivatives), TMI-2, and Lima
all come with intermud enabled.

: As for a 'lib count,' if it was done via intermud, the list I just took

: off of Citadel is almost all DW and Lima. A couple of old Nightmares,
: one TMI something or other, one Foundation, and a couple of homebrews,
: and then like 3 or 4 2.4.5 knockoffs. Guess what? You're wrong.

Guess what: either you don't know how to count, or you are a total
liar. My detailed count above proves that. And you cannot simply get
a different count on your mud; all muds see the same mudlist on I3.

: : : I write code neatly the first time. If you think being alpha is an

: : : excuse for poor indenting, poor variable naming, lack of commenting
: : : of non-obvious or context dependent functionality, and so on, you
: : : and I disagree hopelessly.

: : Nightmare is very well indented, has a consistent naming system, is
: : well documented, etc. Even in alpha. Please address something
: : relating to NM.

: The version I saw 18 months ago was none of the above.

Then you were not looking at Nightmare. If you want, I can tell you
the naming convention and post some code for indentation style
proof. I challenge you to find anyone who can say another lib is
better documented than NM.

: : And more important, it is well-designed.

: I couldn't tell; reading the code was such a chore that I gave up after
: about 10k worth of it. Stock DW is easier to comprehend.

Yeah, sure.

: : : No, _you_ made a judgement based on your book: the judgement that you

: : : are better than me in some regard.

: : The fact that I think that my having written book on the subject is a
: : major credential in matters on the subject is irrelevant to that
: : fact. I am a recognized authority on this subject; you are not. That
: : does mean that when you want to argue a position, you need to do
: : better than call me a moron.

: Recognized authority? By whom? For what? And meaning what? More
: importantly, I always prepended to the word moron the reason, quite
: logical in nature, for my lending to your credits the title of moron.

I guess I would have to know what you consider an authority. Somehow,
I think your definition of authority contains the caveat: cannot be
George. In which case, this discussion is futile.

: : And to date, you have done nothing other than make various attempts to
: : call me a moron.

: Anyone reading my posts knows otherwise. Anyone taking your word instead
: is also a moron.

Now, I have stated this before, I do not believe that truth is a
democratic issue. However, when you say 'anyone reading my posts
knows otherwise', you are basically suggesting that you have people
who agree with you. Name one person who has posted supporting your
contentions. I can only think of an endless army of people laughing
publically at your posts.

: : : I've read lots of Java, written just a teeny bit, and seen a friend write

: : : a large software system in it. I've read a bit of the VM spec and compared
: : : the VM to others around. I read part of a book on the subject before
: : : realizing that it was written for VB programmers who don't know memory
: : : from disk. I know enough to know that Java is only a force in the world
: : : because it was the first thing out there that had a VM and was available
: : : for use as an open standard.

: : There is a lot more to it.

: As usual, your claim is backed up by evidence and sound logic.

You want me to post an entire book on this subject? Please.

: : The issue with the book is this:

: : You repeatedly say that my software sucks, my proposal is idiotic,
: : etc, etc without anything to back it up. Clearly, since I am a
: : recognized expert on the subject matter (because of the book), you
: : need to do better than bash me with moron labeling; the book means
: : that without any substantial arguments from you, you are clearly
: : talking out your ass.

: If a book makes one an expert, then all the guys who write about how
: OO is a fad are experts. I doubt you would agree with that
: statement.

It means they are probably an expert on something. The question is,
from what point of view were they writing their books? So, yes, I
would agree: they are most likely experts.

: More importantly, your proposal _is_ idiotic, and I gave reasons which

: I will here recount for the listening audience.

: 1) By the time you get your limited form of distribution even running,
: the net will be capable of doing so much more; this is the time
: to be running what you are talking about, not designing it for
: the future.

Why? My proposal works well in a fast Internet.

: 2) You could be writing to a standard; instead, you choose to write a

: nonstandard setup, and then hack it later to meet the standard. This
: is a bad idea to anyone who knows about things like design, but I'm
: sure your reuse religion will let you justify it easily.

To whom? So far, you are the only one harping on this. And Ibelieve
I have given very sound reasons for it. You may not agree with them;
but they are sound and can hardly be passed of as "idiotic".

: 3) Your standard is so specialized as to be useless: it is needless if

: you only want to use one driver, and useless if you're running on
: more than one site. Who wants to run MudOS one one machine, and then
: right next to it on the same desk, DGD, and run one game on the two?

You say it is specialized, but then you give an example of how it is
generalized.

Make up your mind!

: I have said this all before, and more. Now tell me I give no reasons,
: moron.

1 & 3 are complete bullshit. 2, while a good question to raise, I
believe I have answered.

: : : Anyone caring to look at your reply to my first posting about CORBA here

: : : will note that you said no such thing, and have now made a liar of yourself
: : : for all to see. You're right; it doesn't matter one bit whether _I_
: : : believe you.

: : Go ahead and look it up. I know what my motivations are :)

: Motivations maybe, but you claim in the quote above that you 'said it two
: weeks ago' and it is NOT in your posts. You lied. Admit it. (By the
: time you reply to this, you'll be saying 'two weeks ago' in reference
: to _this_ post, but anyone reading the thread can figure out the dates,
: so just don't bother.)

I am not going to admit anything. I had said it prior. And you are
changing your accusations.

: : : But it isn't. If you want ref #s, go look at Dejanews; I now can and

: : : have, but I'm not going to do so again right now.

: : Please do. I have never said that automatic stub generation is part
: : of the CORBA standard.

: Assuming I have more time later today, I will. Class in 5.

Yeehaw.

: : : : Ugh, read something about RMI first. It does provide location

: : : : transparency to the developer and requires no special language
: : : : features. There is no location transparency for the *designer*. This
: : : : is a good thing.

: : : Playing semantic games with the word developer is irrelevant. Some
: : : code in RMI doesn't have to know about locations; nevertheless, as
: : : a language feature, it inherently lacks location transparency. Are
: : : you going to deny this?

: : I am not playing any semantic games. You simply do not need any
: : special code tied to specific locations ANYWHERE.

: You have to know where the remote objects are when you first start up.
: This is not true of a CORBA setup. Try and tell me how you can do RMI
: without knowing the machine on the other end so you can start up a
: communication? CORBA directory services, provided by an ORB, let you
: do just that; you need only find the ORB(via multicast or broadcast)
: and then you don't have to know anything else.

You have one service (kinda like a directory service) that worries
about locational issues. This is not rocket science.

: : : CORBA itself does not have to support these things; CORBA is a bus. It

: : : is possible to do distributed garbage collection in a distributed
: : : object system built on CORBA; even you will not, I hope, deny this. As
: : : for Java semantics, I misspoke myself. Nobody in his right mind would
: : : want them anyway.

: : Of course distributed garbage collection is possible; a heterogeneous
: : distributed GC system is questionable. If you think you know
: : otherwise, you are questioning everybody on earth dealign with
: : RMI/CORBA interoperability.

: A heterogeneous distributed GC system? IBM was doing stuff like that years
: ago; the fact that the crew of people working on RMI crap doesn't know shit
: about history or what's been done before, and insists on reinventing the
: wheel, is irrelevant.

In a CORBA environment, eh?

Then why is it that everyone but you seems to find this issue hard to
deal with.

And as far as the RMI crew, Jim Waldo has to be one of the most
brilliant people I have spoken to. FYI, he is the guy overseeing that
area of Java.

: : TMI and Nightmare, on the other hand, made MudOS.

: Whatever you say. I've seen like 5 TMI muds in all time that weren't just
: a kid playing in a lab for a week or so. Nightmare similar. DW, on the
: other hand, and its derivatives, I've seen scores of.

Then explain the above list.

Explain why MudOS got so popular when, for the longest time, Amylaar
was clearly a better choice.

Explain why DGD has had such a hard time getting equivalent popularity
even though it is a product of similar quality (cleaner, stabler, but
fewer features)?

It was not Discworld.

: : : I probably will, but I've got a lot of other work to do first on this

: : : project of mine before it'll be ready for that. Truth be known, I'm
: : : doing it mainly to get experience building and tweaking a VM and maybe
: : : get some useful code out of it for another much larger project, and
: : : figure I can make a fun game whilst I'm at it.

: : Talk, talk, talk.

: I work about 4-8 hrs a day on it. That's probably more time than you spend
: doing anything of this sort, when taken as my consistent average over
: months and months of time.

What is 'of this sort'? Building muds? Don't make me laugh.

: : : : : I get what you said; nevertheless, I wouldn't be designing standards

: : : : : around what we have today. Before you even get them implemented, it
: : : : : will be tomorrow.

: : : : And my standard supports an Internet without such latencies. Duh. If
: : : : the Internet were the way you suggest it will be tomorrow, then this
: : : : DLPC design works fine across the Internet.

: : : Works across, yes. Takes advantage of? I think not.

: : It works just like RMI and CORBA, just much simpler. So you are
: : really missing a point here.

: No, it does not. If you implemented IIOP, it could at least be the
: foundation of a CORBA service, but that's the only similarity.

Bullshit. I based the damn thing off RMI and CORBA.

: : The Internet is just a slower network. There is no such thing as

: : taking advantage of a slower network.

: The internet is slower _now._ Years from now, when you actually get your
: silly little standard implemented, it will be fast by todays standards,
: and your standard will not take advantage of that fact in any meaningful
: way.

So how does RMI or CORBA take advantage of a faster Internet in a way
that DLPC would not?

: : : Besides, it isn't

: : : what I say that matters on this: go look at ATM(it's an open standard,
: : : you can find it:) and IPV6 if you don't believe it's going to happen.
: : : Of course, ADSL, gigabit ethernet(yuck) and some other stuff will help,
: : : but the most general purpose stuff is ATM and IPV6.

: : That has nothing to do with this subject.

: Dropping context is not an argument. It _is_ relevant because of the
: argument I just have been making about your 'standard's' inherent
: impending obsolesence.

What argument?

: : : First off, nice change of subject from your foolish claim that LPC is

: : : not an object language. Much easier to ignore your mistakes than
: : : admit them, eh?

: : I did not back off it. I stated in another post, bozo.

: How useful and convenient; that'll let you drop all context while you
: argue a point you're doomed to end up losing anyway.

You want me to post it in every single post when you can easily
reference the original?

: : : Secondly, implementation is irrelevant not only to LPC as an object

: : : language, but also to Java's merits as a language.

: : Huh? Java is recognized by most of the big OO guys as a perfect
: : language in which to implement OO design patterns. The only
: : competition Java has on this front is Eiffel.

: Most of the big OO guys. Sounds like a clique. Of course, most of
: the big OO guys talked about how wonderful C++ is for years, and
: that is rapidly being debunked as a complete joke. Eiffel has a
: chance, if people can stomach its ugliness, but Java is a bad hack
: based off a bad attempt at an OO language.

Yes, you keep saying this stuff.

: : : Third, if we talk about languages as languages, which _is_ sensible,

: : : Smalltalk, Python, Perl5, Ada, Eiffel, and probably a dozen others
: : : are all better OO languages than Java.

: : Python, while I love it, is MOST DEFINITELY not a better OO language.

: Whatever you say.

: : Perl5 OO? *rofl*

: Have you used it? Have you read about it? Do you even know that it has
: object extensions? I doubt it.

Yes, I have used it. Its object extensions are a horrible hack on top
of a worthless language.

: : Ignore Eiffel. Eiffel is a controversial one;

: Yeah, ignore the one that proves you wrong incontrovertibly. Moron.

If I make the following claims simultaneously:
1 Bill Clinton was the first president of the USA.
2 Too bad Kurt Cobain's suicide broke up the Beatles.
3 Lowering taxes helps the working poor.
4 Ronald Reagan was the best French leader of the 20th century.

Are you going to waste your time debating #3 when 1, 2, and 4 are so
blatantly wrong?

As I stated before, arguments can be made that Eiffel is more OO than
Java--it is not something I hold to be true. Smalltalk actually falls
into that same class.

The rest, however, are laughable.

: : What about Smalltalk, Python, Perl5, Ada make any of them better OO
: : languages than Java?

: Smalltalk: it's an object system unto itself, and its design is
: cleaner.

How is its design cleaner?

: Ada: it doesn't lack little things like parameterized types.

You name one thing Ada has (that is not core to OO) that Java does not
have TODAY (they will be in the future). This is hardly an argument
to support your claim.

: Python: similar in many ways, but runs faster and is nicer
: syntactically.

Runs faster? Nicer syntactically?

What the hell does that have to do with being OO?

: Perl5: This is a weird one, and contrary to your Eiffel bullshit, this

: is the controversial one. Nevertheless, if you can get past its
: inherent weirdness, the Perl5 OO stuff is incredibly usable, and
: incredibly powerful/expressive, neither of which are aspects of
: Java.

That is not an argument.

: : : Java has _one_ benefit: it

: : : is simple. It sacrifices too much for simplicity, and then they
: : : build data 'abstractions' such as Integer, which look nothing like
: : : real data types(interesting, since you so hate LPC data abstraction
: : : on that same account:) and are tedious to use. Blech.

: : Integer is a real data type and looks like a real data type.

: Integer.intval? That looks like accessing a regular type to you? You
: MUST be a moron.

In Java, an integer is represented by the int primitive data type JUST
LIKE IN LPC.

: : LPC is a shit language for data abstraction (which answers your

: : question why LPC is not a true object language) for two reasons:

: : * all abstract data in LPC is of the same type; your stack object is
: : type object and nothing more, so is your date object or file object or
: : whatever

: Actually, while I'm sure many would disagree, I call this a feature.
: Strongly typed UDTs only work if you have multiple inheritance, truly
: static typing, overloadable operators, and a bunch of other stuff that
: Java generally utterly lacks, and that is undesirable in LPC. Typing
: info can be simulated in LPC anyway, your lack of imagination
: notwithstanding.

This is all doublespeak. Overloadable operators *in any language* is
nothing more than syntactic sugar. The rest of what you are saying is
nonsense.

: : * in order to do data abstraction in LPC, you have to step outside the

: : LPC garbage collection paradigm and do your own memory managemen,
: : otherwise you end up with serious leaks

: You keep saying this. I do a lot of clean_up stuff, but that's it.

Calling destruct(ob); in LPC is the same damn thing as delete ob; in
C++. clean_up() is not a good mechanism since, in a lot of cases, you
do not want ADT instances to be cleaned. Cleaning up is not the same
as reference counting.

: : What exactly does Java sacrifice for simplicity?

: Overloadable operators, integral object typing of basic types, multiple
: inheritance... that's too much already.

Those are all definitely good things that Java has omitted, except the
integral object typing of basic types, which is neither good nor bad.

: : : Or even semantic consistency. Little things like always either passing

: : : something by reference or value as the default, and not making it depend
: : : on things like location:)

: : Which is a completely irrelevant issue in the LPC world.

: You keep saying that. Obviously you will never be a language designer
: of any skill. Language designers don't excuse their lack of good design
: by saying 'don't do this; its a bad idea' to programmers.

Good ones prvent programmers from doing bad things.

: : : Security: nope.

: : LPC and Java are the only two languages I know of with a security
: : model. Their security models, however, are different. Java's is
: : better for some things; LPC's for others.

: Java's is useless for anything but toys, but they're supposedly fixing
: that using digital signature technology. I'll wait and see before I
: comment.

You know nothing about what people are using Java for in the real
world, yet you make this statement? I use it securely for things that
are more than toys, and a lot of other people are as well.

: : : Ease of use: please.

: : In more detail, if Java code compiles, it almost always runs. That is
: : a tremendous boost over LPC code which rarely runs properly even when
: : it compiles.

: I haven't had this problem writing what is currently about 300k of LPC
: and growing rapidly. On the other hand, I have found the MudOS compiler
: to be incredibly handy in debugging if you have a decent error handler
: and all the debugging useful pragmas enabled by default. I've yet to
: encounter a bug I couldn't fix in five minutes or so, and I'm writing
: from scratch. When I moved to AIX from Linux, there was zero difficulty
: beyond getting MudOS to compile on a crusty old version of AIX that has
: no dl libraries and so on, which took me about 3 tries.

You are missing the point. Java requires less debugging. And its
logging information is as good as that MudOS produces.

: On the other hand, a good friend has a simple calendar project he co-wrote

: with a team for a semester project. It runs flawlessly on Solaris. It
: barely even pretends to run elsewhere. But hey, it checks out as
: '100% Pure Java.' What a joke.

You provide one anecdotal piece of information without any reference
to what problems were actually encountered and you expect it to serve
as evidence to damn Java?

: : : Data abstraction: I refer you to Integer from Java, which cannot even be

: : : added normally, and invite you to compare with what can
: : : be done with creative mixing of the class and object
: : : types in LPC.

: : Do you even know what data abstraction is? This ain't it.

: No, of course not. The Integer type isn't an attempt at abstracting int
: into an object type. Not at all. Do you in fact know your ass from your
: elbow?

That is not what you were talking about. You said that it cannot be
added normally (It is value is immutable). That is not an issue of
data abstration.

Furthermore, an abstraction of int in LPC could no more be added to.

: : First, getting into your little off topic issue, show me an LPC

: : abstraction of an int that beats Integer.

: I don't need to. The LPC int _is_ an abstraction unto itself; it is
: exactly the same, behaves exactly the same, on all platforms. And
: you don't have to dereference a member of it to get its value. Imagine
: that.

You mean, just like the Java int type?

: : Second, let's talk about real data abstraction issues, such as how to

: : build a Data or File object in LPC.

: A Data object? I do believe that's type object. The whole point of objects
: is to contain data of all sorts. Precisely what more do you expect?
: Maybe this?

: class Data
: {
: string type;
: mixed MyData;

: }

In LPC, class is a misnomer. This is nothing more than a struct.

: And then a bunch of simuls like typeof and datap so on?

Oh, that is real OO. *rofl*

: As for a file, I've never felt the need to do this, because the

: persistence primitives(save_object and restore_object) make it too
: unimportant to bother with, but if you wanted to, the read and write
: family of efuns would make building such fairly easy. You could have
: syntax kinda like this in usage:

: object my_goddamn_file = new(File);

: my_goddamn_file->open("/txt/thingie");
: my_goddamn_file->read_bytes(some_bytes);
: my_goddamn_file->close();

: Would this give you a woody?

I have such an object, and so does Lima. The problem is that it is
type object and it does not automatically GC.

: : Java's inheritance mechanism with interfaces makes for a more robust

: : representation of common design patters.

: Such as? And because?

Please look at Rust's post for a much better summary of this than I
can give.

: : And if multiple inheritance is what you want, let's talk about LPC's
: : virtual inheritance...

: You mean MudOS's virtual inheritance. It doesn't have to be that way;
: it is not inherent in the language itself.

That is the way it is. Arguing about hypotheticals is silly.

: : : Readability: probably similar, but its subjective

: : Java is much easier to read.

: I disagree, and as I said, it is subjective. LPC supports some things
: that Java falls on its ass for(the fn pointers, the ({}) immediate form
: of array notation, etc) that aren't as pretty as one might like, but
: can you improve on them?

And LPC also has plenty of its own uglies.

Prototyping is my favourite.

: : It is much easier to write for reasons I addressed above.

: Which you won't even reference in enough detail to let us identify them,
: thus guaranteeing that your faulty logic won't be countered.

I did reference them. Sorry you cannot read.

[John Viega]

In article <5upj50$o0m$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

> : Most of the big OO guys. Sounds like a clique. Of course, most of
> : the big OO guys talked about how wonderful C++ is for years, and
> : that is rapidly being debunked as a complete joke. Eiffel has a
> : chance, if people can stomach its ugliness, but Java is a bad hack
> : based off a bad attempt at an OO language.

John, it is now time for you to put your money where your mouth is.
Two things:

First, Come out with examples where "most of the big OO guys talked
about how wonderful C++ is for years". Since it's most of them, and
over a period of years, please present us with enough references from
enough people over a period of years to demonstrate this point. I can
point you at plenty of references with criticisms of C++, and plenty
of OO work that builds off of C++, but I can find few of "the big OO
guys" making such claims. Now plenty of people use C++, mainly
because it is quickly becoming widely standard, and because most
people who know other OO languages can also read C++, not because it
is intrinsicly such a great language. Even Booch cites those two
reasons for switching to all C++ in his second edition of OO Analysis
and Design (p vi-vii). So please prove that you're not spouting
complete BS by providing such references. BTW, Selecting the big names
from the C++ community is hardly appropriate. You said the big OO
guys, not the big C++ guys. So pick the people well known for doing
work or being experts on object orientation in general, since that is
the statement you made.

Second, argue how Java is a back hack, and how it is a bad attempt at
an object oriented language. Give us specific examples as to what is
bad AND hackish about it, and what could be made better, and how.
I've seen you comment on a few things here, mainly features in C++
that Java omitted or attempted to replace. You don't argue
convincingly as to why they are useful features in an object oriented
system, or argue why the reasoning behind omitting those features is
poor. Now, I happen to believe myself that some of Java's omissions
belong in the language, and I believe that some of them do not. But
if I really wanted to discuss it, I would present arguments on the
different features, and the pros and cons from my point of view.
Besides, no programming language is all things to all people, and most
programming languages are excellent at filling at least a small niche.
I find it offensive that you are so cavalier about branding Java as a
piece of crap, when it is obviously an oppinion, and when you are
unwilling to even present evidence to support your oppinion.

> Yes, you keep saying this stuff.
>
> : : : Third, if we talk about languages as languages, which _is_ sensible,
> : : : Smalltalk, Python, Perl5, Ada, Eiffel, and probably a dozen others
> : : : are all better OO languages than Java.

Here is another one where you're going to have to elaborate for anyone
to pay any attention to your oppinion: Better by what metrics??

>
> : : Python, while I love it, is MOST DEFINITELY not a better OO language.
>
> : Whatever you say.

John, George gave reasons why he felt Python is not as OO. You have
neither refuted his examples or provided counter arguments that are on
topic. The only things I have heard you mention (which I keep quoted
below) are that Python has nicer syntax, and that it is faster. First
of all, syntax has nothing to do with object orientedness. Nor does
speed. Second, Python isn't faster, anyway, when compared to any Java
implementation I've ever seen! Are you out of your gourd?? In
general, Python is a pretty slow language. First of all, very little
effort has been put into optimization. Second of all, Python is not
statically typed at all, and makes no attempts in the implementation
to gain any static type information about variables at all, which
pretty much garuntees that you will not have an overly speedy
language.

So please argue convincingly with lots of examples as to why Python is
more OO, and by whoose notion of OO.

> : Python: similar in many ways, but runs faster and is nicer
> : syntactically.
>
> Runs faster? Nicer syntactically?

See my comments above.

> : Integer.intval? That looks like accessing a regular type to you? You
> : MUST be a moron.
>
> In Java, an integer is represented by the int primitive data type JUST
> LIKE IN LPC.

Just like practically every other language except for the most pure
(an inefficient) OO languages, eg, Smalltalk. So if you don't have
an Integer "wrapper" type in your language, John, where are you going
to put the operations in that class? Are you going to make the
primitive type so it conceptually is an object? If so, why are you
criticizing Java for not doing this, but ignoring the fact that almost
every other language you've mentioned fails to do it as well??

Anyway, I am trying not to argue whether you are right or wrong much
in this post. I've pointed out enough flaws in your "facts" and
arguments in other posts. Basically, I feel that you have been called
on your bullshit one too many times for us to sit here and believe you
when you make such vague unsubstantiated claims, so I am asking you to
prove what you say.

[Richard]

John Adelsberger writes:
] George Reese wrote:

] : John Adelsberger wrote:
] : : Distribution:
]
] : : Before I knew enough to write real lib code, I wrote for a lot of startup
] : : MudOS setups; almost all of them were DW.
]
] : Please name those; there are in fact very few DW muds.
]
] One(right now) is Citadel. I wrote for RoD(not a startup:) for a little

Citadel have my respect :) The only mudlib that started from the DW dist
mudlib on ftp.imaginary.com lately.

Who were you on Rod? I'd just like to say that most of the code there is
not something I would be proud of. (lib code that is, never bothered looking
at their areas)

] while. I also wrote for a couple that never got off the ground(you've

] never heard of them.) As for 'very few DW muds,' anyone who goes and
] looks at an intermud listing _knows_ you're lying through your teeth.

Umm, I just had a look:
41 Lima
22 Nightmare
13 Discworld

I excluded some DW libs because they were only dev libs, there was a total
of 114 muds online at the time.

As I say below, intermud is not a good way to judge. Nightmare and Lima
have an unfair advantage.

] : : This group isn't even _read_ by most admins of MudOS startups. Sorry,

] : : but while there's no way to prove it, DW is by far the most popular
] : : MudOS lib in history.
]
] : You are hilarious. DW is the single least popular. That is not a
] : reflection of its quality; it is however a fact.
]
] Lima is more popular recently. But as far as number vs all time, DW
] wins hands down.

Logically Descartes has to be right here. There was a publically available
distribution version of Nightmare and there is one of Lima. On the other hand
have you ever tried to start a mud using the DW dist lib that is on
ftp.imaginary.com? I tried to help compile a version of mudos for two groups
of people but bringing the lib upto scratch to let the driver load was
not within my abilities at the time. Seeing the number of vacant muds
using either the Lima or Nightmare libs on intermud indicates that starting
a mud using either lib was not that hard to do.

There have been at least 8 failed attempts to start DW variant muds using
the Sorrows or Cento mudlibs alone.

] : That startups may or may not read this newsgroup is irrelevant; there

] : was an actual MudOS lib count done a while ago. To get a quick count,
] : just check the intermud mudlists--all MudOS libs come with intermud
] : access by default.
]
] All MudOS libs come with intermud access by default... that's a good one.
] As for a 'lib count,' if it was done via intermud, the list I just took
] off of Citadel is almost all DW and Lima. A couple of old Nightmares,
] one TMI something or other, one Foundation, and a couple of homebrews,
] and then like 3 or 4 2.4.5 knockoffs. Guess what? You're wrong.

This is a rigged battle, only two distributed variants of the DW lib
come with built in Intermud3. Sorrows and Cento. Nightmare and Lima are
always going to come out on top if that is used as a measure.

] : Nightmare is very well indented, has a consistent naming system, is

] : well documented, etc. Even in alpha. Please address something
] : relating to NM.
]
] The version I saw 18 months ago was none of the above.
]
] : And more important, it is well-designed.
]
] I couldn't tell; reading the code was such a chore that I gave up after
] about 10k worth of it. Stock DW is easier to comprehend.

I have to agree, what little code of Nightmares I read was a chore to read.
But then if I didn't code it my way, it doesn't look right to me.
But.. compared to reading and trying to comprehend some of Limas code NM
has nothing on hard to digestness.

Stock DW is easier to comprehend IMO, ignoring the Pinkfishified variable
names that give it that personal touch. Nyah to any who might suggest its
bad coding practice.

If you know anyone who wants to start up a mud and use the Discworld lib,
send them to me. We have a dist lib that is relatively clean but in
comparison to the Discworld dist lib its spotless *grin* No offense to
Pinkfish or any of the other DW staff, I personally think it is still
the best option to take as a starting mudlib on ftp.imaginary.com.

In the spirit of the DW lib,
Womble on :)

--
Richard Tew (above spudent -> student, lame spam avoidance thingy)
Admin on Nameless Sorrows.

[Greg Foley]

Stig Hemmer wrote:
>
> Kris Van Hees <ae...@ny.fnx.com> writes:
> > Of course, I think the original issue was the OO-ness of LPC :-)
>

> You know, I don't think they care about the original issue (which was
> about making a distributed LPC)
>
> It seems that all they care about is bashing at eachother... sad really.
>
> Stig Hemmer.
oh i am sure that they will get back to it eventually but for now
they are kinda distracted trying to prove something else :)
i do however wish to thank aedil and jtv2j for clearing up my
questions and pointing out futher reading material :)

[Jake S Greenland]

In article: <1997Sep6.094915@cantva> Richard <rm...@spudent.canterbury.ac.nz>
writes:

> Stock DW is easier to comprehend IMO, ignoring the Pinkfishified variable
> names that give it that personal touch. Nyah to any who might suggest its
> bad coding practice.

Well if your code is in public view you might as well make it as hard as
possible for someone to copy :)

> If you know anyone who wants to start up a mud and use the Discworld lib,
> send them to me. We have a dist lib that is relatively clean but in
> comparison to the Discworld dist lib its spotless *grin* No offense to
> Pinkfish or any of the other DW staff, I personally think it is still
> the best option to take as a starting mudlib on ftp.imaginary.com.
>
> In the spirit of the DW lib,
> Womble on :)

It might be now, Once upon a time it wasn't :) The 7a release was infamous
for that at least. To be perfectly honest, the lack of availibility of
servers these days in general makes starting any mud a huge challenge
regardless of lib+driver choice. Also people who play mainly DW muds are
going to see lots of DW muds spring up, people who play mainly NM muds are
going to see lots of those spring up etc etc. Peoples background is very
prone to colouring their viewpoint.

Wibble onwards

J

--
--------------------------------------------------------
Ja...@Mythology.demon.co.uk Sojan@Discworld

"I am not a Frog, I am a Free Womble"
--------------------------------------------------------

[George Reese]

Jake S Greenland <ja...@mythology.demon.co.uk> wrote:
: regardless of lib+driver choice. Also people who play mainly DW muds are

: going to see lots of DW muds spring up, people who play mainly NM muds are
: going to see lots of those spring up etc etc. Peoples background is very
: prone to colouring their viewpoint.

Not if they count :)

[news_check.py]

Indeed; sorry about that.

Just for grins, has anyone considered non-stackmachine implementations of

LPC? The language itself, despite claims to the contrary, is easy to
learn and relatively clean, and well supports(better, than, for instance,
C++) most OO concepts. It could be fun:) (For that matter, the parts
that aren't real clean right now _could_ be in a new implementation:)

--

[news_check.py]

[John Adelsberger]

news_check.py (ltest@rte9-sun_5.5.1) wrote:
: In article <EFvy6...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees):

: Main: Abstraction
: Encapsulation
: Modularity
: Hierarchy

Ok.

: Sub: Typing
: Concurrency
: Persistence

Um, here I'm going to have to differ. Concurrency has nothing to do with
OO, and in fact, afaik, most of the good concurrency-specification languages
are anything _but_ OO. I think maybe Booch was making a wishlist for a
language instead of describing a category of languages:)

(Actually, I'd say the same thing about persistence, too. Persistence isn't
a basic programming methodology component at all; why you'd put it on a level
with issues like typing is utterly beyond comprehension.)

--
John J. Adelsberger III
j...@umr.edu

"If any man cometh to me, and hate not his father, and mother, and wife, and
children, and brethren, and sisters, yea, and his own life also, he cannot
be my disciple." -- Jesus Christ (Luke 14:26)

[John Viega]

In article <5v6p37$gci$1...@news.cc.umr.edu> j...@ultra5.cc.umr.edu (John Adelsberger) writes:

> : In article <EFvy6...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees):
>
> : Main: Abstraction
> : Encapsulation
> : Modularity
> : Hierarchy
>
> Ok.
>
> : Sub: Typing
> : Concurrency
> : Persistence
>
> Um, here I'm going to have to differ. Concurrency has nothing to do with
> OO, and in fact, afaik, most of the good concurrency-specification languages
> are anything _but_ OO. I think maybe Booch was making a wishlist for a
> language instead of describing a category of languages:)

> (Actually, I'd say the same thing about persistence, too. Persistence isn't
> a basic programming methodology component at all; why you'd put it on a level
> with issues like typing is utterly beyond comprehension.)

<sarcasm>
John, I have to congradulate you on this post, it is very well
researched, for once. You _obviously_ mastered what Booch meant by
sub principles, and went over all his reasoning for including them
before posting.
</sarcasm>

Hey, why don't you go read the damn book before you try to put words
into Booch's mouth? You look oh so intelligent slamming a respected
scholar for writing 4 words that you saw completely out of context.

Instead of coming to the conclusion that your awesome intellect has
intuited every ounce of someone like Booch's intent, why don't you ASK
SOMEONE or for gods sake DO SOME READING if something seems so wrong
to you.

Jesus, that is almost as bad as flaming Knuth for not knowing anything
about algorithms just because someone summarized a sorting algorithm
from his text that didn't sound right to you.

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:
: John Adelsberger <j...@ultra3.cc.umr.edu> wrote:

: : George Reese (bo...@imaginary.com) wrote:
: : : John Adelsberger <j...@ultra1.cc.umr.edu> wrote:

: : Multiple inheritance is a _requirement_ if you want to do real work in

: : a staticly typed language. If you want, I'll dig up the paper that
: : demonstrates it; I think it's available on the web somewhere.

: What do you consider real work? I consider the work I do very real
: work; of course, you are the expert on whether my work is real or not,
: aren't you?

No, the inventor of Eiffel is the expert in the case of static typing.
Are you going to say that Bertrand Meyer is a liar now, Georgy?

<Note to readers: sorry about keeping all the following quotation, but
it is needed for context>

: : : : : I do challenge you to find literature that does not support my

: : : : : minimalist view of object orientation in a programming language.

: : : : The Smalltalk development papers. Oops, those were written by the guys
: : : : who invented OO. Sorry, you lose, play again sometime, fool.

: : : What specifically do these papers say that define OO?
: : : Who specifically are you referring to as 'the guys who invented OO'?

: : Oh, Xerox PARC's Smalltalk team and the academics who gave them the

: : ideas. Nobody special by comparison to _you._ And what they did was
: : define OO in a very strict sense that your 'minimalist' defn doesn't

: : meet. I'm not going to repeat what they said; either read the damn

: : things yourself or quit pretending you know something about OO.

: You are pretending that what you are saying is relevant. 'Some guys
: from Xerox said...'
: Cite something real or shut up.

What part of "Smalltalk development papers" do you fail to comprehend? I
cited them. Do you claim that they are unreal in some way, or is
'something real' defined solely by you and in fact an anti-definition
used in an attempt to shut me up?

: Sun uses the term 'Java' to suit their needs at a given time. I
: choose the broader definition. NO MATTER WHICH DEFINITION YOU CHOOSE,
: it does not change what I am asking for--that which I list below.

You miss an important point. It is a trademark - it does not HAVE a
broader definition. You are wrong, as much as are people who call all
tissues "Kleenex" and so forth. That said, if it doesn't change what
you're asking for, then forget it, eh?

: : You won't get Python syntax with design by contract; the ugliness of
: : Eiffel is mostly _due_ to design by contract.

: And we know you are the expert on what is possible with OO programming
: languages...

As I said below, if you would read before blabbering insensibly, it is
not a matter of possibility, but a matter of what we _know_ -- it says
in the below quote of me that "nobody has figured out an elegant
implementation..." which is a far cry from a statement of what is
possible. Until you understand what people are saying, don't insult
them:)

: : The simple fact is, it
: : is a good idea that nobody has figured out an elegant implementation for
: : as yet. As for "Java's OO support," Eiffel kicks the shit out of Java
: : for OO, as does Python(although less so than Eiffel.) I detest Eiffel
: : as a programming language, not because of features but because the
: : whole point of hlls is to make life easy on programmers, and Eiffel's
: : syntax is sacrificed utterly for semantics.

: I have stated you can make arguments for Eiffel OO support being
: better than Java. I personally do not think it is a 'kick the shit
: out of' argument. It is a very debatable point on both sides.
: Of course, you make no argument one way or the other. I think no
: matter how many times I ask you to provide an argument, you will still
: avoid it.

Ok, how's this.

1) Multiple inheritance is a requirement in a staticly typed language.
Unless you can counter the argument for this published by Bertrand
Meyer, SHUT UP ABOUT IT.

2) Java doesn't have it, but _is_ staticly typed.

3) Eiffel doesn't have this problem.

Of course, I could do better, pointing out that Eiffel doesn't make the
mistake of Java, in having nonobject intrinsic types that are then
wrapped up in hacks to provide a simulation of a real object language.
I could say that Java lacks operator overloading and therefore that
designing reusable types in it requires ugly hacks like using this
syntax to handle complex numbers or similar:
foo = plus(a, b);
and that the preceding could be parsed by an intelligent assembler, so
why bother having an interpreter or compiler. (Before you go making a
fool of yourself by saying that assemblers can't do user defined types,
do your homework; several already do.)

Hell, I could say that your view of OO is parochial and small and that you
lack academic depth in your treatment, choosing instead to cling to whatever
is fashionable at the moment, because it's true, but that isn't really an
argument.

: As far as Python, what drugs were you taking when you thought this up?
: How many OO features does Python have that Java does not?

: And what about a little something called encapsulation that Python is missing?

Hell, C has encapsulation, even if Georgy can't find it, and so does Python,
after a fashion. Let's play a game. Can Georgy find the encapsulation in
C?

[John Viega]

In article <5vfnpc$g17$1...@news.cc.umr.edu> j...@ultra6.cc.umr.edu (John Adelsberger) writes:

> : John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
> : : George Reese (bo...@imaginary.com) wrote:
> : : : John Adelsberger <j...@ultra1.cc.umr.edu> wrote:
>
> : : Multiple inheritance is a _requirement_ if you want to do real work in
> : : a staticly typed language. If you want, I'll dig up the paper that
> : : demonstrates it; I think it's available on the web somewhere.
>
> : What do you consider real work? I consider the work I do very real
> : work; of course, you are the expert on whether my work is real or not,
> : aren't you?
>
> No, the inventor of Eiffel is the expert in the case of static typing.
> Are you going to say that Bertrand Meyer is a liar now, Georgy?

I don't know if you are selectively ignoring posts, or what, but
considering that I sent you mail asking you to keep up w/ the thread
via dejanews if your newsfeed sux that bad, I'm a bit upset that you
haven't cought up on the rest of what has been said. However, I will
reiterate and expand.

Before I reiterate why you are WRONG on this issue, let me talk about
why your argument is poor.

Since you seem to have absolutely no ability to CITE A SOURCE (okay,
Meyer said it, now WHERE? Ya think we might want to go read it
ourselves?) I can only guess that you are refering to the following
quote:

"Robust multiple inheritance facilities are essential to support
combining various abstractions and reusable components, both in
modeling (CALCULATOR_WATCH inherits from CALCULATOR and WATCH) and
design/implementation (INTEGER inherits from NUMERIC and
COMPARABLE). "
(http://www.eiffel.com/doc/manuals/technology/oo_comparison/index.html)

Well, if you check the top of the web page, it says of their comments
on the page that "someone else might have different views". In other
words, IT IS AN OPPINION. If this is your source, I am amazed that
you consider Eiffel PROPAGANDA scientific proof. I have also skimmed
through my copies of Meyer's books (OO Software Design and Eiffel the
language), and a few other resources, I can not find a single place
where he attempts to prove your claim that "Multiple inheritance is a

_requirement_ if you want to do real work in a staticly typed
language."

Okay, here is a quote of a post I wrote in response to your original:

(BTW, before you continue with this post, please read the original
post if you haven't read it yet. It is availible at :
http://xp7.dejanews.com/getdoc.xp?recnum=%3cJTV2J.97...@adder.cs.virginia.edu%3e&server=db97p4)

| This is absolute complete and utter bullshit. The most obvious
| argument here is a Turing completeness argument. More practically,
| when there is no multiple inheritance in an OO language, there are 2
| common coping strategies. One of them is textual code substitution,
| the other is aggregation or delegation.

Okay, let me expand on my original comment, since you seem to be
clueless enough to need it. Yes, some people use multiple inheritance
quite extensively, including myself. Parts of the Eiffel standard
library use it pretty extensively. But it is by no means required in
a language to do the same work. If you put a little bit of RESEARCH
behind your words, you would find a whole range of languages that
don't even have inheritance, that are CLEARLY capable to doing the
same things using a delegation model, with the same sort of EASE OF
EXPRESSION. (Look up the paper "Delegation Is Inheritance" in the Oct
'87 Sigplan for one example).

In fact, in a language like Java, it is easy to simulate multiple
inheritance with a combination of interfaces and delegation. If
writing the dispatch methods is a bit tedious to you, then gee, you
can easily write a little preprocessor in conjunction with the Java
disassembler to automate the process. [I'm working on an academic
paper on this very topic as a matter of fact].

Therefore, if you try to go and claim that by "_requirement_" you were
talking about ease of expression, you are *still* wrong.

> <Note to readers: sorry about keeping all the following quotation, but
> it is needed for context>
>
> : : : : : I do challenge you to find literature that does not support my
> : : : : : minimalist view of object orientation in a programming language.
>
> : : : : The Smalltalk development papers. Oops, those were written by the guys
> : : : : who invented OO. Sorry, you lose, play again sometime, fool.
>
> : : : What specifically do these papers say that define OO?
> : : : Who specifically are you referring to as 'the guys who invented OO'?
>
> : : Oh, Xerox PARC's Smalltalk team and the academics who gave them the
> : : ideas. Nobody special by comparison to _you._ And what they did was
> : : define OO in a very strict sense that your 'minimalist' defn doesn't
> : : meet. I'm not going to repeat what they said; either read the damn
> : : things yourself or quit pretending you know something about OO.
>
> : You are pretending that what you are saying is relevant. 'Some guys
> : from Xerox said...'
> : Cite something real or shut up.
>
> What part of "Smalltalk development papers" do you fail to comprehend? I
> cited them. Do you claim that they are unreal in some way, or is
> 'something real' defined solely by you and in fact an anti-definition
> used in an attempt to shut me up?

I already responded to these absurd claims in the post at the URL
above. This time I will not reiterate them. However, I will note
that you have *still* failed to CITE A SOURCE. "Smalltalk development
papers" are not enough for people to GO LOOK IT UP. Fuck, Parc
produced a shitload of papers about aspects of Smalltalk and the Xerox
Star. Care to tell us which paper "DEFINES OO", as you claim? GIVE
ME THE TITLE OF THE PAPER, AND THE EXACT PUBLICATION DOWN TO THE
ISSUE. If you read the above mentioned post, you will find that
"Object Oriented" was NOT FORMALLY DEFINED until either Cardelli &
Wegner (Dec '85 ACM computer surveys) or Wegner (Sigplan Oct 86) (I
don't remember which paper actually contained the definition). In
other words, YOU ARE WRONG.

> : : You won't get Python syntax with design by contract; the ugliness of
> : : Eiffel is mostly _due_ to design by contract.
>
> : And we know you are the expert on what is possible with OO programming
> : languages...
>
> As I said below, if you would read before blabbering insensibly, it is
> not a matter of possibility, but a matter of what we _know_ -- it says
> in the below quote of me that "nobody has figured out an elegant
> implementation..." which is a far cry from a statement of what is
> possible. Until you understand what people are saying, don't insult
> them:)

You say that design by contract has ugly SYNTAX, but to back up your
point, you claim that "nobody has figured out an elegant
implementation...". WHAT DOES THE IMPLEMENTATION HAVE TO DO WITH HOW
PRETTY OR UGLY THE SYNTAX IS? Do you care to really prove your
point??? Or are you just going to go off on a tangent to try to look
credible??

> : I have stated you can make arguments for Eiffel OO support being
> : better than Java. I personally do not think it is a 'kick the shit
> : out of' argument. It is a very debatable point on both sides.
> : Of course, you make no argument one way or the other. I think no
> : matter how many times I ask you to provide an argument, you will still
> : avoid it.
>
> Ok, how's this.
>
> 1) Multiple inheritance is a requirement in a staticly typed language.
> Unless you can counter the argument for this published by Bertrand
> Meyer, SHUT UP ABOUT IT.

Okay, I have disproved YOUR CLAIM, both prima facie, and if try to
make inferences from it. Now why don't you do the following:

1) PROVIDE US WITH A REAL SOURCE
2) Demonstrate WHAT YOU ARGUMENT IS instead of just defering to a
publication to which you don't even GIVE A REFERENCE.

> Of course, I could do better, pointing out that Eiffel doesn't make the
> mistake of Java, in having nonobject intrinsic types that are then
> wrapped up in hacks to provide a simulation of a real object language.

Okay, you have absolutely not demonstrated how not having primitive
data types be objects is a "mistake" in any particular OO methodology,
nor how the wrappers are "hacks". I will make the first argument for
you: It would be good if the base datatypes were objects because, as
MacLennan notes, "Regular rules, without exception, are easier to
learn, use, describe, and implement". I can also make arguments
against this particular feature. Just one example, it does not leverage off a
programmer's previous experience from other languages. In other
words, it detracts from regularity ACROSS programming languages. Not
to mention that it makes it easy for a compiler writer to produce an extremely
inefficient implementation of the language since the obvious
implementation would use a pointer to an actual integer, carry around
superclass info, etc... and that it complicates the compiler writers
job to implement efficiently, since the "purity" of the object system
would not extend to the implementation, as the compiler would have to
turn instances of your object into a native data type.

Note that I am not taking sides here, I have made arguments for both
sides. My point is that I HAVE MADE ARGUMENTS, and not just claims.
Why don't you use some FACTS and EXAMPLES when you argue?

> I could say that Java lacks operator overloading and therefore that
> designing reusable types in it requires ugly hacks like using this
> syntax to handle complex numbers or similar:
> foo = plus(a, b);

This is a matter of oppinion, there are convincing arguments both
ways. Again, I don't take sides, but I will note that your argument
is highly shallow. You have not even argued why it is even desirable to
overload an operator with well defined semantics. You seem to assume
that it is obvious. Well, let's see, if you apply MacLennan's design
principles to operator overloading (Principles Of Programming Languages):

Operator overloading violates the notion of simplicity (make it as
simple as possible). People need to remember or discover on a case by
case basis if an operator is being overloaded, or if we have to call a
method directly.

Operator Overloading encourages the user to violate the notion of
manifest interface, since it allows the programmer to create an
interface to an object that is not obvious from the syntax. Unless
you live in a cave, you will hear of many people complaining about how
often overloading of operators is abused.

Anyway, the developers of the Java language obviously chose NOT to
include operator overloading, and you might stop to consider that they
would have a good reason to do so. Just because you hold the believe
that operator overloading is a desirable OO feature, and not having it
is bad, does not make it so! Booch doesn't list it as a requirement
in his methodology.

Also, your argument is very one-sided. You fail to mention features
Eiffel lacks that Java has that some people feel are desirable in an
OO system. For example, on page 488 of [Booch, OO Analysis and Design
2nd ed], three features that are desirable in the Booch methodology are
show to be lacking in Eiffel that are present in Java: Class variable
/ methods (static members in C++), multitasking and persistent
objects. The Java language with standard libraries supports both. Of
course, I mentioned that in the afforementioned post, as well.

BTW, I definitely do not take sides in language wars (I use both
languages, as well as a host of others, depending on the task at
hand), I am just pointing out how one sided and slipshod your
arguments are.

> Hell, I could say that your view of OO is parochial and small and that you
> lack academic depth in your treatment, choosing instead to cling to whatever
> is fashionable at the moment, because it's true, but that isn't really an
> argument.

I *will* say that about you. Your view of OO is small, and you lack
academic depth in the matter. You have demonstrated quite clearly in
this thread that you do not know:

1) What it means to be Object Oriented, formally. Instead you claimed
that the Smalltalk development papers defined OO, when in fact, one of
the developers coined the term, BEFORE THE SMALLTALK PROJECT (Alan Kay
in his Flex system, see another post in this thread), but did not give
a formal definition. Smalltalk developed the notion of a 'pure
object' language, but did not set down the guidelines for what is and
what is not an object oriented language.

2) Anything about any design methodology, especially Booch. You
showed your ignorance of Booch and your complete lack of debth on what
is and what is not a desirable feature in an OO language by slamming
his classification despite an OBVIOUS lack of research on your part.
I will not reiterate my response to your absurd post, but if you would
like to go read it, it is availible on the web at:
http://xp7.dejanews.com/getdoc.xp?recnum=10563946&server=db97p4

3) Anything substantial about not having multiple inheritance. Your
belief that multiple inheritance is some sort of "requirement" shows
that you lack the academic debth. If you possessed it, you would know
about Actor languages, which disprove your notion of MI being a
"requirement" (cf the source above). You obviously lack the
experience to know how people cope with the lack of the feature,
because otherwise, you would see that "requirement" is definitely not
the case.

4) The history of OOP, more specifically the influences of Smalltalk,
as debunked in the previously mentioned news article.

By the lack of depth in your arguments, it is also easy to believe
that you know little at all about the pros and cons of your favorite
features. You seem to have no notion that a large number of people
find multiple inheritance undesirable. There are tons of reasons
against multiple inheritance, ranging from added complexity for the
programmer to difficulty in tool building, to further encouraging the
programmer to violation notions of information hiding, perpetuating
the problems of single inheritance (Ie, subclasses having access to
the implementation of the superclass). Some of these problems Stroustoup
discusses in [Design and Evolution of C++, starting at page 269]. He
also sites 5 other papers that discuss the issue. There are others.
I find it hard to believe that someone who is well versed in the
literature would be so ready to push MI as obviously desirable,
especially without any sort of evidence. I can make similar
complaints about your treatment of other features, such as operator
overloading.

Also, by your inability to cite exact sources, it is easy to believe
that you lack any sort of grasp on the academic side of things.

> : As far as Python, what drugs were you taking when you thought this up?
> : How many OO features does Python have that Java does not?
>
> : And what about a little something called encapsulation that Python is missing?
>
> Hell, C has encapsulation, even if Georgy can't find it, and so does Python,
> after a fashion. Let's play a game. Can Georgy find the encapsulation in
> C?

Um, you are fighting over stupid ambiguities in the definition of
encapsulation. Just to use one popular definition, Sethi (Programming
Languages -- Concepts and Constructs) says that encapsulation or
"representation independence" is the principle that: "A program should
be designed so that the representation of an object can be changed
without affecting the rest of the program".

You take the interpretation that if the programmer has ADTs and
functions, he can make it so no programmer *needs* to access the
representation. Therefore any language w/ ADTs and functions support
encapsulation.

George Reese takes the interpretation that if a language does not
provide the ability to protect data, no design can hide the
representation from an adversarial client. Therefore, only languages
with a notion of protection support encapsulation.

Ambiguity exists in pretty much every definition of the term. Most
people define encapsulation as a PROCESS that the programmer goes
through, and not as a language feature. (Cf, [Booch p45, ibid]).

Despite the ambigutiy in the definition, I find it difficult to
believe that you really missed the point George Reese was making. It
seems like you're just being an asshole, arguing a technicality
instead of the real meat of the problem in hopes that you will
actually be the victor in your little personal vendetta.

Lets get at the real meat of the problem by using more exact phrasing.
Java enables data *protection*. Python does not. Protection promotes
information hiding, which is a known good thing (often perhaps the
most imoprtant thing in many peoples mind) in the OO paradigm.
Therefore, Java has an OO leg up over Python in that regard.

One final note: I will make sure you see this post by forwarding a
copy to you. When and if you respond, please also respond to the
challenges I put forth to you in my post availible on the web at:
http://xp7.dejanews.com/getdoc.xp?recnum=%3cJTV2J.97...@adder.cs.virginia.edu%3e&server=db97p4

That article addresses similar deficiencies in your arguments, where
you basically did not provide enough evidence to make a convincing
argument, but there is surprisingly little overlap with this post.

[John Viega]

Reading my post from last night, I have a few clarifications /
additional comments. This won't be long like the last post.

I wrote:

> Okay, let me expand on my original comment, since you seem to be
> clueless enough to need it.

Sorry for calling you clueless, it was inappropriate. I was just put
off by the fact that you were being so forceful and rude in pushing a
contraversial, unresearched, unsupported oppinion without
acknowlegeing it as such.

[ Big exchange between John A and George R about the definition of OO,
who coined the definition, and where to go to find the info]

[My response also deleted...]
I think much of the meat in this exchange got lost in my reply by my
complaining about your lack of a reference, and your lack of knowlege in
the actual formal definition of OO. So let me sumamrize my points for
clairtys sake:

1) The bare minimum for "what is OO", the requirements by which PL
people classify programming languages into the OO category is Wegner's
definition, which I have cited several times in this thread: "OO =

data abstraction + abstract data types + type inheritance".

2) The generally used baseline definition of OO is *not* larger than
this, as you claim.

3) The formal generally used definition of OO was not put forth in the
"Smalltalk development papers" as you put forth.

Okay, that is pretty much everything additional I have to say. Do
note that I have tried to keep things on a professional level. The
one place where I feel I lapsed, I appologised for as soon as I
noticed. I would hope that you can participate further in this thread
in an civil manner, instead of reverting to name calling like you have
done in the past when arguing against George Reese. I would also hope
that you will support yourself with well developed arguments and well
researched references to the literature. I want to be able to go to
the departmental library, find the exact issue of the publication you
are talking about, look at the table of contents and find the paper.

John Viega

[John Adelsberger]

Kris Van Hees (ae...@ny.fnx.com) wrote:

: I have condidered such an implementation (and actually have a design for

: Abyss using a non-stackmachine approach). However, unless you intend to
: do compilation into machine code, there is little or nothing to gain.

This last statement is precisely correct.

: The downside of non-stackmachine implementations is that usually they'll

: involve more advanced compiler techniques such as register colouring. I
: found those to be too much of a slowdown. With concurrent compilation,
: or even if compilation on the fly isn't too much of an issue (or in the
: very exotic case that someone writes a JIT compiler for an LPC-based
: language) a non-stackmachine implementation would be superior.

Exotic? It was precisely what I had in mind:)

--
John J. Adelsberger III
j...@umr.edu

"If any man cometh to me, and hate not his father, and mother, and wife, and

[Kris Van Hees]

On 15 Sep at 03:10:49, John Adelsberger wrote <5vi8vu$h34$1...@news.cc.umr.edu> which contained:

> Kris Van Hees (ae...@ny.fnx.com) wrote:
>
>: I have condidered such an implementation (and actually have a design for
>: Abyss using a non-stackmachine approach). However, unless you intend to
>: do compilation into machine code, there is little or nothing to gain.
>
> This last statement is precisely correct.

Well, of course it is correct. It's both trivial to see, and I simply would
not have mentioned it if it wasn't correct :)

>
>: The downside of non-stackmachine implementations is that usually they'll
>: involve more advanced compiler techniques such as register colouring. I
>: found those to be too much of a slowdown. With concurrent compilation,
>: or even if compilation on the fly isn't too much of an issue (or in the
>: very exotic case that someone writes a JIT compiler for an LPC-based
>: language) a non-stackmachine implementation would be superior.
>
> Exotic? It was precisely what I had in mind:)

Well, then good luck, and I'll be happy to have a look at the finished code
when you're done with it. I personally don't think a JIT cmpiler (and any
compilation of LPC-based languages into machinecode) is very useful unless
you have a matching environment to run it in (e.g. Limbo running in Inferno).
Without the environment in which the machinecode can truly run as an integrated
component, it seems a bit odd.

Aedil

[John Adelsberger]

George Reese (bo...@imaginary.com) wrote:
: John Adelsberger <j...@ultra6.cc.umr.edu> wrote:

: : One(right now) is Citadel. I wrote for RoD(not a startup:) for a little

: : while. I also wrote for a couple that never got off the ground(you've
: : never heard of them.)

: And you have done exactly what for those muds?

RoD: I worked on several things. I was just learning LPC, but before I
finally ended up too busy to go on working for them, I put together
a large part of a sailing ship inherit that I doubt they ever
completed, and was responsible for a level of their underworld.

Citadel: random encounter system, cleanups of DW messiness in general,
repairs to stuff that new driver versions have broken, currently
rewriting the room inherit, bugfixes all over the place to other
people's code, some security fixes, and other stuff I've
forgotten.

The others: see Citadel, minus the random enc and room rewrite. I typically,
if I'm not working on my own project, end up as the 'utility
lib guy,' because I've spent so much time writing lib and
frequently know more about LPC and MudOS in particular than
anyone else on staff.

Why do you ask, anyway?

: Nightmare, Foundation, Discworld (and derivatives), TMI-2, and Lima

: all come with intermud enabled.

I've seen several DW derivatives that have no intermud support whatsoever.
I've seen several others whose intermud doesn't work by default(or didn't
for me, anyway.) FR, in particular, didn't do intermud when I ran it,
and is one of the more popular ones because it will run out of the box
on the driver supplied, and one can then modify it running.

: Then you were not looking at Nightmare. If you want, I can tell you

: the naming convention and post some code for indentation style
: proof. I challenge you to find anyone who can say another lib is
: better documented than NM.

I'll assume you mean lib that is released. Oh, wait, that doesn't include
yours. Well, then, mine is(and is getting better in that regard.)

: : Recognized authority? By whom? For what? And meaning what? More

: : importantly, I always prepended to the word moron the reason, quite
: : logical in nature, for my lending to your credits the title of moron.

: I guess I would have to know what you consider an authority. Somehow,
: I think your definition of authority contains the caveat: cannot be
: George. In which case, this discussion is futile.

No, you've turned the thing around; I don't really hold much stock in _any_
sort of 'authority,' save that which demonstrates to _me_ its superior
knowledge/skill/etc. That was the point, and is the point, of what I said
immediately above. You have demonstrated that you can be rude, that you
can make claims about a lib nobody can read, and that you can be shortsighted,
but you have not demonstrated any superior knowledge or skill. Having
written a book may mean that someone _else_ thinks you possess such, but
I didn't ask for anyone else's opinion.

: Now, I have stated this before, I do not believe that truth is a

: democratic issue. However, when you say 'anyone reading my posts
: knows otherwise', you are basically suggesting that you have people
: who agree with you. Name one person who has posted supporting your
: contentions. I can only think of an endless army of people laughing
: publically at your posts.

Apparently, judging from the first and last sentences of this paragraph,
your ability to hold a principle extends for approximately 20 seconds of
typing time.

: : : There is a lot more to it.

: : As usual, your claim is backed up by evidence and sound logic.

: You want me to post an entire book on this subject? Please.

There's a difference between a book and a single unsupported sentence.
You might have noticed this before, but then again, you might not have.
It would certainly explain how you wrote a book.

: : If a book makes one an expert, then all the guys who write about how

: : OO is a fad are experts. I doubt you would agree with that
: : statement.

: It means they are probably an expert on something. The question is,
: from what point of view were they writing their books? So, yes, I
: would agree: they are most likely experts.

Luddites have written books(albeit using quill pens.) Mass murderers with
no education beyond the 2nd grade have written books. Are they experts?
In what?

: : More importantly, your proposal _is_ idiotic, and I gave reasons which

: : I will here recount for the listening audience.

: : 1) By the time you get your limited form of distribution even running,
: : the net will be capable of doing so much more; this is the time
: : to be running what you are talking about, not designing it for
: : the future.

: Why? My proposal works well in a fast Internet.

And fails to take advantage of 90% of what can be done on such an entity.
You can have a fully distributed object system with a directory service on
such an entity, but because you don't need a directory service on your LAN,
you ignore it. Nobody wants to run multiple different drivers on a LAN,
George. Nobody but you and your MudOS/Java mix. Why you even felt the need
to make a 'standard' for this, given that you are the only person doing it,
is beyond me, save that it probably serves to reinflate your head.

: : 2) You could be writing to a standard; instead, you choose to write a

: : nonstandard setup, and then hack it later to meet the standard. This
: : is a bad idea to anyone who knows about things like design, but I'm
: : sure your reuse religion will let you justify it easily.

: To whom? So far, you are the only one harping on this. And Ibelieve
: I have given very sound reasons for it. You may not agree with them;
: but they are sound and can hardly be passed of as "idiotic".

Your reason, the only one you've given, is that doing it right is more work.
Sorry, but that's no justification for bad design and subsequent hacks.
See Discworld.

: : 3) Your standard is so specialized as to be useless: it is needless if

: : you only want to use one driver, and useless if you're running on
: : more than one site. Who wants to run MudOS one one machine, and then
: : right next to it on the same desk, DGD, and run one game on the two?

: You say it is specialized, but then you give an example of how it is
: generalized.

I do? Where? (I have, genuinely, missed this one.)

: : You have to know where the remote objects are when you first start up.

: : This is not true of a CORBA setup. Try and tell me how you can do RMI
: : without knowing the machine on the other end so you can start up a
: : communication? CORBA directory services, provided by an ORB, let you
: : do just that; you need only find the ORB(via multicast or broadcast)
: : and then you don't have to know anything else.

: You have one service (kinda like a directory service) that worries
: about locational issues. This is not rocket science.

So you're going to create your own object request broker standard, rather
than implementing the real one? This is getting funnier by the day. And
you are right, this is not rocket science. I would think that even you
could comprehend the simple statement:

"Standards are a good thing, and good standards should be followed."

: : : Of course distributed garbage collection is possible; a heterogeneous

: : : distributed GC system is questionable. If you think you know
: : : otherwise, you are questioning everybody on earth dealign with
: : : RMI/CORBA interoperability.

: : A heterogeneous distributed GC system? IBM was doing stuff like that years
: : ago; the fact that the crew of people working on RMI crap doesn't know shit
: : about history or what's been done before, and insists on reinventing the
: : wheel, is irrelevant.

: In a CORBA environment, eh?

No, but if it's a heterogeneous object bus, it's the same damn thing.
(In fact, their SOM derives some of its newer capabilities from CORBA,
but has contributed far more _to_ CORBA. They've been doing this stuff
for a long, long time, your utter lack of context notwithstanding.)

: Then why is it that everyone but you seems to find this issue hard to
: deal with.

It isn't trivial, but it isn't impossible, either. (Hint: it requires
another _standard._)

: And as far as the RMI crew, Jim Waldo has to be one of the most

: brilliant people I have spoken to. FYI, he is the guy overseeing that
: area of Java.

He may be a genius; I don't know him. Your testimony doesn't mean much to
me. Whether or not he is a genius, if he thinks heterogeneous GC is
impossible, he doesn't know his history very well.

: Explain why MudOS got so popular when, for the longest time, Amylaar

: was clearly a better choice.

Because while MudOS kept getting better, Amylaar kept staying the same?
Because MudOS is more flexible, more general, faster, and has a more
sane lib interface? Or maybe... because it is easier to find current
versions and decent docs for.

: Explain why DGD has had such a hard time getting equivalent popularity

: even though it is a product of similar quality (cleaner, stabler, but
: fewer features)?

Because it is so minimalist that one has to know quite a bit of OS theory
to write a decent mudlib for it?

: : I work about 4-8 hrs a day on it. That's probably more time than you spend

: : doing anything of this sort, when taken as my consistent average over
: : months and months of time.

: What is 'of this sort'? Building muds? Don't make me laugh.

Ok, you spend 4-8 hrs a day or more on a mud(or more,) you presumably spend
at least 8 a day on your 'real job,' you find time to do things like write
books, and you probably eat and sleep, too. Where can I get that 30-hour
day extension? Does that come with NT?

: : No, it does not. If you implemented IIOP, it could at least be the

: : foundation of a CORBA service, but that's the only similarity.

: Bullshit. I based the damn thing off RMI and CORBA.

If what you mean is that you took some of their ideas and incorporated them
into your post, you did. If what you mean is that what you wrote is even
remotely similar to CORBA in capability, you're fooling yourself.

: : The internet is slower _now._ Years from now, when you actually get your

: : silly little standard implemented, it will be fast by todays standards,
: : and your standard will not take advantage of that fact in any meaningful
: : way.

: So how does RMI or CORBA take advantage of a faster Internet in a way
: that DLPC would not?

Directory services are required in order to spread an object system over more
than a few hosts, because reconfigurability becomes a _major_ issue. I
would think you would know that. Of course, you just in the post I am
replying to mentioned that you are intending to implement one, so you
must have realized that I was about to make you look really, really dumb,
but anyone checking Dejanews knows that you never before mentioned a
directory service, that your original DLPC post contained no such entity,
and that you are in fact covering up for your cognitive inadequacy.

: What argument?

Your deliberate obstinance has managed to make me no longer care to attempt
explanation. I tried about 5 times in a row, and on this point, I am
now left simply to assume your lack of _ability_ to comprehend. (You could
disagree, if you could even comprehend, but as it is, you can't even do
that.)

: : Most of the big OO guys. Sounds like a clique. Of course, most of

: : the big OO guys talked about how wonderful C++ is for years, and
: : that is rapidly being debunked as a complete joke. Eiffel has a
: : chance, if people can stomach its ugliness, but Java is a bad hack
: : based off a bad attempt at an OO language.

: Yes, you keep saying this stuff.

Ok, I'll take that last sentence of mine and substitute concretes for the
logical placeholders, for the cognitively impaired.

"Java is a bad hack based off C++, which is a bad attempt at an OO language."

Did you get it that time?

: : : Perl5 OO? *rofl*

: : Have you used it? Have you read about it? Do you even know that it has
: : object extensions? I doubt it.

: Yes, I have used it. Its object extensions are a horrible hack on top
: of a worthless language.

I'll forward this to my favorite Perl God[tm] and let him respond.

: : : Ignore Eiffel. Eiffel is a controversial one;

: : Yeah, ignore the one that proves you wrong incontrovertibly. Moron.

: If I make the following claims simultaneously:
: 1 Bill Clinton was the first president of the USA.
: 2 Too bad Kurt Cobain's suicide broke up the Beatles.
: 3 Lowering taxes helps the working poor.
: 4 Ronald Reagan was the best French leader of the 20th century.

: Are you going to waste your time debating #3 when 1, 2, and 4 are so
: blatantly wrong?

Yes.

: As I stated before, arguments can be made that Eiffel is more OO than

: Java--it is not something I hold to be true. Smalltalk actually falls
: into that same class.

Yeah, the language that _defined_ OO isn't OO. Perhaps if you would slow
down, take a deep breath, have a beer, and _think,_ for once, instead of
just following the party line? You're saying some things in defense of
this silly Java religion of yours that are just hideous. When will you
decide that we should all write realtime systems in Java? Or have you
already?

: : Smalltalk: it's an object system unto itself, and its design is
: : cleaner.

: How is its design cleaner?

Everything _is_ an object, conceptually(and at the source code level) which
avoids certain syntactic stew present in Java. That's one thing.

: : Ada: it doesn't lack little things like parameterized types.

: You name one thing Ada has (that is not core to OO) that Java does not
: have TODAY (they will be in the future). This is hardly an argument
: to support your claim.

Parameterized types are rapidly becoming a standard feature. "Core to OO"
is relative the source you quote. Hell, one could say that OO is nothing
but inheritance, if one looked back far enough. Have a look at the xt
toolkit for X.

: : Perl5: This is a weird one, and contrary to your Eiffel bullshit, this

: : is the controversial one. Nevertheless, if you can get past its
: : inherent weirdness, the Perl5 OO stuff is incredibly usable, and
: : incredibly powerful/expressive, neither of which are aspects of
: : Java.

: That is not an argument.

It sure does look like one. The heart of OO, the whole reason there _is_
OO, is to make programming easier. Certainly nobody is going to claim
that OO is done for the machine's benefit. Perl5's OO extensions are
arguably far more usable than Java.

: : : Integer is a real data type and looks like a real data type.

: : Integer.intval? That looks like accessing a regular type to you? You
: : MUST be a moron.

: In Java, an integer is represented by the int primitive data type JUST
: LIKE IN LPC.

Yes, but nobody uses them that way. They can't. They have to pass around
Integer instances, or their stuff won't work with any of the libraries
or anyone else's code.

: : : LPC is a shit language for data abstraction (which answers your

: : : question why LPC is not a true object language) for two reasons:

: : : * all abstract data in LPC is of the same type; your stack object is
: : : type object and nothing more, so is your date object or file object or
: : : whatever

: : Actually, while I'm sure many would disagree, I call this a feature.
: : Strongly typed UDTs only work if you have multiple inheritance, truly
: : static typing, overloadable operators, and a bunch of other stuff that
: : Java generally utterly lacks, and that is undesirable in LPC. Typing
: : info can be simulated in LPC anyway, your lack of imagination
: : notwithstanding.

: This is all doublespeak. Overloadable operators *in any language* is
: nothing more than syntactic sugar. The rest of what you are saying is
: nonsense.

OO is nothing more than syntactic sugar, you moron. And you _can_ simulate
typing info in LPC - this is no nonsense. You have a real way of ignoring
things that demonstrate you to have been wrong about something - you just
call it nonsense, insult the author, or ignore/cut it.

(While I'm at it, C is nothing more than syntactic sugar. Hell, assembler
isn't either - why don't you go write your reusable objects in raw binary
machine code, you buffoon?)

: : : * in order to do data abstraction in LPC, you have to step outside the

: : : LPC garbage collection paradigm and do your own memory managemen,
: : : otherwise you end up with serious leaks

: : You keep saying this. I do a lot of clean_up stuff, but that's it.

: Calling destruct(ob); in LPC is the same damn thing as delete ob; in
: C++. clean_up() is not a good mechanism since, in a lot of cases, you
: do not want ADT instances to be cleaned. Cleaning up is not the same
: as reference counting.

MudOS does in fact supply a mechanism(in the devel package) for getting
the ref count on an object. If you want to do ref counting yourself,
you can.

: : : What exactly does Java sacrifice for simplicity?

: : Overloadable operators, integral object typing of basic types, multiple
: : inheritance... that's too much already.

: Those are all definitely good things that Java has omitted, except the
: integral object typing of basic types, which is neither good nor bad.

Yeah, conceptual integrity is worthless. Why bother with little things like
making sense, when you can just throw together whatever is easiest to write
a compiler for and be done with it?

: : : : Or even semantic consistency. Little things like always either passing

: : : : something by reference or value as the default, and not making it depend
: : : : on things like location:)

: : : Which is a completely irrelevant issue in the LPC world.

: : You keep saying that. Obviously you will never be a language designer
: : of any skill. Language designers don't excuse their lack of good design
: : by saying 'don't do this; its a bad idea' to programmers.

: Good ones prvent programmers from doing bad things.

I won't even go there, except to say that no language has ever done this
without incurring penalties that are, in the general case, unacceptable.

: : Java's is useless for anything but toys, but they're supposedly fixing

: : that using digital signature technology. I'll wait and see before I
: : comment.

: You know nothing about what people are using Java for in the real
: world, yet you make this statement? I use it securely for things that
: are more than toys, and a lot of other people are as well.

Until they finish the digital signature stuff, a Java program can run with
two security levels: utter incapability to do anything without asking the
user specifically(which gets annoying and is only useful for toys,) and
the ability to do anything doable by a process with the uid of the VM it
runs in. This is hardly useful for anything real in the distributed world.

: : I haven't had this problem writing what is currently about 300k of LPC

: : and growing rapidly. On the other hand, I have found the MudOS compiler
: : to be incredibly handy in debugging if you have a decent error handler
: : and all the debugging useful pragmas enabled by default. I've yet to
: : encounter a bug I couldn't fix in five minutes or so, and I'm writing
: : from scratch. When I moved to AIX from Linux, there was zero difficulty
: : beyond getting MudOS to compile on a crusty old version of AIX that has
: : no dl libraries and so on, which took me about 3 tries.

: You are missing the point. Java requires less debugging. And its
: logging information is as good as that MudOS produces.

Do you have any reasoning or evidence to support your claim that Java
requires less debugging?

: : On the other hand, a good friend has a simple calendar project he co-wrote

: : with a team for a semester project. It runs flawlessly on Solaris. It
: : barely even pretends to run elsewhere. But hey, it checks out as
: : '100% Pure Java.' What a joke.

: You provide one anecdotal piece of information without any reference
: to what problems were actually encountered and you expect it to serve
: as evidence to damn Java?

I'll forward this to him as well as the perl bit; he's both people. He knows
more details of the matter than I do.

: : : Do you even know what data abstraction is? This ain't it.

: : No, of course not. The Integer type isn't an attempt at abstracting int
: : into an object type. Not at all. Do you in fact know your ass from your
: : elbow?

: That is not what you were talking about. You said that it cannot be
: added normally (It is value is immutable). That is not an issue of
: data abstration.

The value of an Integer is not immutable, you dolt. Therefore, that clearly
is not what I meant. I meant that you cannot do:

Integer a, b, c;
...
c = 5;
a = b + c;

And you cannot. There is nothing more to say; you are wrong. This is not
good data abstraction, and it is the only way in Java.

: Furthermore, an abstraction of int in LPC could no more be added to.

An LPC int _is_ an object, logically, even if not in type. It is not a
hardware supplied type(well, it ends up using one, but all LPC ints,
on all platforms, are identical, and you can mix ints and objects in
arrays and so forth - they're all basically objects.)

: : : First, getting into your little off topic issue, show me an LPC

: : : abstraction of an int that beats Integer.

: : I don't need to. The LPC int _is_ an abstraction unto itself; it is
: : exactly the same, behaves exactly the same, on all platforms. And
: : you don't have to dereference a member of it to get its value. Imagine
: : that.

: You mean, just like the Java int type?

Apparently not, since I can put an LPC int into an array right alongside
another object, whereas putting a Java int into an array of objects won't
even compile.

: : : Second, let's talk about real data abstraction issues, such as how to

: : : build a Data or File object in LPC.

: : A Data object? I do believe that's type object. The whole point of objects
: : is to contain data of all sorts. Precisely what more do you expect?
: : Maybe this?

: : class Data
: : {
: : string type;
: : mixed MyData;
: : }

: In LPC, class is a misnomer. This is nothing more than a struct.

Your point being?

: : And then a bunch of simuls like typeof and datap so on?

: Oh, that is real OO. *rofl*

I don't think it is, but then, I don't feel the need to have an abstraction
that encompasses everything that is 'data.' I've always found that data
is well represented and grouped by that thing called an object, which is
supplied by that thing called the language.

: : As for a file, I've never felt the need to do this, because the

: : persistence primitives(save_object and restore_object) make it too
: : unimportant to bother with, but if you wanted to, the read and write
: : family of efuns would make building such fairly easy. You could have
: : syntax kinda like this in usage:

: : object my_goddamn_file = new(File);

: : my_goddamn_file->open("/txt/thingie");
: : my_goddamn_file->read_bytes(some_bytes);
: : my_goddamn_file->close();

: : Would this give you a woody?

: I have such an object, and so does Lima. The problem is that it is
: type object and it does not automatically GC.

The fact that it is type object is a bonus, because now you can stick files
in with similar objects in an array. The fact that it doesn't automatically
GC seems to be logical enough... when would a file want to go away? Do you
mean you want persistent reference counting? If so, Java ain't it. If you
mean merely that you want the object to unload itself from memory when not
referenced, use the ref counting efun.

: : : Java's inheritance mechanism with interfaces makes for a more robust

: : : representation of common design patters.

: : Such as? And because?

: Please look at Rust's post for a much better summary of this than I
: can give.

Which one? He has, in his lifetime, posted more than once.

: : : And if multiple inheritance is what you want, let's talk about LPC's
: : : virtual inheritance...

: : You mean MudOS's virtual inheritance. It doesn't have to be that way;
: : it is not inherent in the language itself.

: That is the way it is. Arguing about hypotheticals is silly.

Then quit arguing about Java's forthcoming parameterized types, support for
IIOP in RMI, and so on. You can't have it both ways.

: : : : Readability: probably similar, but its subjective

: : : Java is much easier to read.

: : I disagree, and as I said, it is subjective. LPC supports some things
: : that Java falls on its ass for(the fn pointers, the ({}) immediate form
: : of array notation, etc) that aren't as pretty as one might like, but
: : can you improve on them?

: And LPC also has plenty of its own uglies.

: Prototyping is my favourite.

LPC prototypes look like C and C++ prototypes. What do you find difficult
about this?

--
John J. Adelsberger III
j...@umr.edu

"If any man cometh to me, and hate not his father, and mother, and wife, and

[George Reese]

Your posts are getting more and more inane each time. Rust (John
Viega) is certainly a much more patient responder than I and has done
a wonderful job of exposing you for the fool you are. I am sure his
followup to this post will blow away mine. Neverthless, I am going to
take a moment to address the bullshit you are spewing...

John Adelsberger <j...@ultra5.cc.umr.edu> wrote:

: George Reese (bo...@imaginary.com) wrote:
: : John Adelsberger <j...@ultra6.cc.umr.edu> wrote:

: : : One(right now) is Citadel. I wrote for RoD(not a startup:) for a little
: : : while. I also wrote for a couple that never got off the ground(you've
: : : never heard of them.)

: : And you have done exactly what for those muds?

: RoD: I worked on several things. I was just learning LPC, but before I
: finally ended up too busy to go on working for them, I put together
: a large part of a sailing ship inherit that I doubt they ever
: completed, and was responsible for a level of their underworld.

So you basically did nothing of consequence...

: Citadel: random encounter system, cleanups of DW messiness in general,

: repairs to stuff that new driver versions have broken, currently
: rewriting the room inherit, bugfixes all over the place to other
: people's code, some security fixes, and other stuff I've
: forgotten.

: The others: see Citadel, minus the random enc and room rewrite. I typically,
: if I'm not working on my own project, end up as the 'utility
: lib guy,' because I've spent so much time writing lib and
: frequently know more about LPC and MudOS in particular than
: anyone else on staff.

This ain't a hell of a lot of mud work.

: Why do you ask, anyway?

Because you pontificate about all your mud knowledge and yet you
basically have zero experience really running a mud.

: : Nightmare, Foundation, Discworld (and derivatives), TMI-2, and Lima

: : all come with intermud enabled.

: I've seen several DW derivatives that have no intermud support whatsoever.
: I've seen several others whose intermud doesn't work by default(or didn't
: for me, anyway.) FR, in particular, didn't do intermud when I ran it,
: and is one of the more popular ones because it will run out of the box
: on the driver supplied, and one can then modify it running.

Probably simply pointing to the wrong IP. I cannot address why your
experiences are such.

: : Then you were not looking at Nightmare. If you want, I can tell you

: : the naming convention and post some code for indentation style
: : proof. I challenge you to find anyone who can say another lib is
: : better documented than NM.

: I'll assume you mean lib that is released. Oh, wait, that doesn't include
: yours. Well, then, mine is(and is getting better in that regard.)

There are still plenty of Nightmare muds out there. How many copies
of your mud are out there?

: : : Recognized authority? By whom? For what? And meaning what? More

: : : importantly, I always prepended to the word moron the reason, quite
: : : logical in nature, for my lending to your credits the title of moron.

: : I guess I would have to know what you consider an authority. Somehow,
: : I think your definition of authority contains the caveat: cannot be
: : George. In which case, this discussion is futile.

: No, you've turned the thing around; I don't really hold much stock in _any_
: sort of 'authority,' save that which demonstrates to _me_ its superior
: knowledge/skill/etc. That was the point, and is the point, of what I said
: immediately above.

You know, I cannot think of a single regular poster to this newsgroup
who does not qualify as an authority over you.

: You have demonstrated that you can be rude,

Yes, I have been rude to you... in response to your completely
unwarranted rudeness to me. Your failure to agree with my proposal is
not grounds for rudeness.

: that you

: can make claims about a lib nobody can read,

That no one can read? There are hundreds of people out there TODAY
with access to a Nightmare mud.

: and that you can be shortsighted,

No, I am practical.

: but you have not demonstrated any superior knowledge or skill.

*rofl*

: Having

: written a book may mean that someone _else_ thinks you possess such, but
: I didn't ask for anyone else's opinion.

Other opinions clearly mean nothing to you.

: : Now, I have stated this before, I do not believe that truth is a

: : democratic issue. However, when you say 'anyone reading my posts
: : knows otherwise', you are basically suggesting that you have people
: : who agree with you. Name one person who has posted supporting your
: : contentions. I can only think of an endless army of people laughing
: : publically at your posts.

: Apparently, judging from the first and last sentences of this paragraph,
: your ability to hold a principle extends for approximately 20 seconds of
: typing time.

Judging from this comment, you are completely unable to read.

My first sentence: 'I do not believe truth is a democratic issue.' (It
is called a disclaimer)

You were commenting: 'anyone reading my posts knows otherwise'

Clearly, however, in this newsgroup, NOT A SINGLE SOUL AGREES WITH
YOUR CRAP. Given my disclaimer, that means that while 100%
disagreement with you does not mean you are wrong or right, it does
mean your comment 'anyone reading my posts knows otherwise' IS
PATENTLY FALSE. Do you understand?

: : It means they are probably an expert on something. The question is,

: : from what point of view were they writing their books? So, yes, I
: : would agree: they are most likely experts.

: Luddites have written books(albeit using quill pens.) Mass murderers with
: no education beyond the 2nd grade have written books. Are they experts?
: In what?

Are they backed up by the money of people who are looking to sell
books by people on the basis of them being experts? No.

Learn what an analogy is before you try to use them.

: : : More importantly, your proposal _is_ idiotic, and I gave reasons which

: : : I will here recount for the listening audience.

: : : 1) By the time you get your limited form of distribution even running,
: : : the net will be capable of doing so much more; this is the time
: : : to be running what you are talking about, not designing it for
: : : the future.

: : Why? My proposal works well in a fast Internet.

: And fails to take advantage of 90% of what can be done on such an entity.
: You can have a fully distributed object system with a directory service on
: such an entity, but because you don't need a directory service on your LAN,
: you ignore it. Nobody wants to run multiple different drivers on a LAN,
: George. Nobody but you and your MudOS/Java mix. Why you even felt the need
: to make a 'standard' for this, given that you are the only person doing it,
: is beyond me, save that it probably serves to reinflate your head.

Directory services (in fact, all services) are things that run ON TOP
OF the distributed architecture. My proposal was:
a) an architectural proposal
b) a starting point for discussion

a) means that it is premature to discuss directory services
b) means that I did not present it as and never intended for it to be
THE WORD on distributed LPC. Instead, I intended it to start some
intelligent discussion on the subject. Thanks to you, however, all we
have gotten is ignorant flamage.

: : : 2) You could be writing to a standard; instead, you choose to write a

: : : nonstandard setup, and then hack it later to meet the standard. This
: : : is a bad idea to anyone who knows about things like design, but I'm
: : : sure your reuse religion will let you justify it easily.

: : To whom? So far, you are the only one harping on this. And Ibelieve
: : I have given very sound reasons for it. You may not agree with them;
: : but they are sound and can hardly be passed of as "idiotic".

: Your reason, the only one you've given, is that doing it right is more work.
: Sorry, but that's no justification for bad design and subsequent hacks.
: See Discworld.

I have given several very sound reasons for it. You just don't
listen. I will try once again.

* CORBA is an architecture for distributed computing in a heterogenous
language environment. It comes with a lot of complexity surrounding
its need to be able to interoperate with other languages. Since
distributed LPC needs, as I see them+, are limited to LPC->LPC
communication, it seems to me best to start off simple wth a protocol
that allows *distributed LPC* while providing a framework that may be
easily plugged into RMI and CORBA down the line.

Doing CORBA for LPC seriously complicates things and gains you nothing.

+ notes an assumption. Perhaps that assumption is wrong, but it is
something worth discussing, not flaming like the asshole you are.

: : : 3) Your standard is so specialized as to be useless: it is needless if

: : : you only want to use one driver, and useless if you're running on
: : : more than one site. Who wants to run MudOS one one machine, and then
: : : right next to it on the same desk, DGD, and run one game on the two?

: : You say it is specialized, but then you give an example of how it is
: : generalized.

: I do? Where? (I have, genuinely, missed this one.)

'Your standard is so specialized as to be useless'

then you note that is supports multiple driver types. Sounds
generalized to me.

Furthermore, it is only useful on the same LAN... but so are CORBA and
RMI. So where do you get off suggesting that this is somehow a
limitation inherent only in my policy? Given today's Internet,
distributed mudding across the Internet *using any distributed
technology* is unfeasible. Given a future, high speed Internet, all
DLPC, CORBA, and RMI all would be able to take advantage of
distribution across the Internet. So what are you harping on?

: : : You have to know where the remote objects are when you first start up.

: : : This is not true of a CORBA setup. Try and tell me how you can do RMI
: : : without knowing the machine on the other end so you can start up a
: : : communication? CORBA directory services, provided by an ORB, let you
: : : do just that; you need only find the ORB(via multicast or broadcast)
: : : and then you don't have to know anything else.

: : You have one service (kinda like a directory service) that worries
: : about locational issues. This is not rocket science.

: So you're going to create your own object request broker standard, rather
: than implementing the real one? This is getting funnier by the day. And
: you are right, this is not rocket science. I would think that even you
: could comprehend the simple statement:

The real one? There are a billion naming service standards. As
Rassilon pointed out to me the other day, you could even use DNS.

: "Standards are a good thing, and good standards should be followed."

Good standards do not always apply to all situations. There is an
argument to be made for following CORBA. You have not made it. You
have just made personal attacks on me. No one else has felt so
strongly about it that they have bothered to even discuss it.

: : : : Of course distributed garbage collection is possible; a heterogeneous

: : : : distributed GC system is questionable. If you think you know
: : : : otherwise, you are questioning everybody on earth dealign with
: : : : RMI/CORBA interoperability.

: : : A heterogeneous distributed GC system? IBM was doing stuff like that years
: : : ago; the fact that the crew of people working on RMI crap doesn't know shit
: : : about history or what's been done before, and insists on reinventing the
: : : wheel, is irrelevant.

: : In a CORBA environment, eh?

: No, but if it's a heterogeneous object bus, it's the same damn thing.
: (In fact, their SOM derives some of its newer capabilities from CORBA,
: but has contributed far more _to_ CORBA. They've been doing this stuff
: for a long, long time, your utter lack of context notwithstanding.)

Yes, as Rust has shown, you are quite the programming historian and
academician.

: : Then why is it that everyone but you seems to find this issue hard to
: : deal with.

: It isn't trivial, but it isn't impossible, either. (Hint: it requires
: another _standard._)

Who said it was impossible?

Of course, also, for you to have any success, that requires that the
LPC community have the clout to enforce a standard on other
languages. So you see, you are bordering on the ridiculous here.

Well, really, you are always bordering on the ridiculous.

: : And as far as the RMI crew, Jim Waldo has to be one of the most

: : brilliant people I have spoken to. FYI, he is the guy overseeing that
: : area of Java.

: He may be a genius; I don't know him. Your testimony doesn't mean much to
: me. Whether or not he is a genius, if he thinks heterogeneous GC is
: impossible, he doesn't know his history very well.

Who said heterogeneous GC was impossible?

: : Explain why MudOS got so popular when, for the longest time, Amylaar

: : was clearly a better choice.

: Because while MudOS kept getting better, Amylaar kept staying the same?
: Because MudOS is more flexible, more general, faster, and has a more
: sane lib interface? Or maybe... because it is easier to find current
: versions and decent docs for.

What are you talking about? You are making claims about a time where
YOU WERE NOT EVEN IN MUDS.

Amylaar was faster.
Amylaar had some very major features missing in MudOS (closures).
Amylaar was being actively developed.

And your comment 'has a more sane lib interface' is total bullshit.
MudOS had a crappy lib interface until Beek cleaned it up.

Nevertheless, because of Nightmare and TMI, MudOS prospered.

: : Explain why DGD has had such a hard time getting equivalent popularity

: : even though it is a product of similar quality (cleaner, stabler, but
: : fewer features)?

: Because it is so minimalist that one has to know quite a bit of OS theory
: to write a decent mudlib for it?

You mean because there are no major mudlibs for it?

: : : I work about 4-8 hrs a day on it. That's probably more time than you spend
: : : doing anything of this sort, when taken as my consistent average over
: : : months and months of time.

: : What is 'of this sort'? Building muds? Don't make me laugh.

: Ok, you spend 4-8 hrs a day or more on a mud(or more,) you presumably spend
: at least 8 a day on your 'real job,' you find time to do things like write
: books, and you probably eat and sleep, too. Where can I get that 30-hour
: day extension? Does that come with NT?

Oh my god. You are honestly trying to claim you do more with respect
to muds than I?

Your assessment of my day is pure conjecture. You also ignore that I
have been doing this since 1991 and that I have been involved at each
level of mud building:

* I have built areas for Orlith and Igor
* Wrote the Nightmare and Foundation mudlibs (and thus every systme
that makes up a mudlib)
* I have written some driver code for MudOS, including porting it to
Win32.
* I am currently working on a JavaMud project.

: : : No, it does not. If you implemented IIOP, it could at least be the

: : : foundation of a CORBA service, but that's the only similarity.

: : Bullshit. I based the damn thing off RMI and CORBA.

: If what you mean is that you took some of their ideas and incorporated them
: into your post, you did. If what you mean is that what you wrote is even
: remotely similar to CORBA in capability, you're fooling yourself.

We don't need something similar in capability of CORBA.

: : : The internet is slower _now._ Years from now, when you actually get your

: : : silly little standard implemented, it will be fast by todays standards,
: : : and your standard will not take advantage of that fact in any meaningful
: : : way.

: : So how does RMI or CORBA take advantage of a faster Internet in a way
: : that DLPC would not?

: Directory services are required in order to spread an object system over more
: than a few hosts, because reconfigurability becomes a _major_ issue. I
: would think you would know that. Of course, you just in the post I am
: replying to mentioned that you are intending to implement one, so you
: must have realized that I was about to make you look really, really dumb,
: but anyone checking Dejanews knows that you never before mentioned a
: directory service, that your original DLPC post contained no such entity,
: and that you are in fact covering up for your cognitive inadequacy.

You were about to make me look really, really dumb? I am not in the
least bit concerned about directory services at this point for the
reasons I mentioned earlier in this post. My lack of commentary on
the subject means absolutely nothing.

You need to be clued on a simple fact: Just because people do not
mention things does not mean they are not thinking about them. There
are appropriate places to bring up different topics. This was not the
place for discussing this topic.

: : What argument?

: Your deliberate obstinance has managed to make me no longer care to attempt
: explanation. I tried about 5 times in a row, and on this point, I am
: now left simply to assume your lack of _ability_ to comprehend. (You could
: disagree, if you could even comprehend, but as it is, you can't even do
: that.)

Think about it John. I am clearly not as stupid as you paint me to
be. And if your continual opposition to me means that one of us is
stupid, it does not bode well for you...

: : : Most of the big OO guys. Sounds like a clique. Of course, most of

: : : the big OO guys talked about how wonderful C++ is for years, and
: : : that is rapidly being debunked as a complete joke. Eiffel has a
: : : chance, if people can stomach its ugliness, but Java is a bad hack
: : : based off a bad attempt at an OO language.

: : Yes, you keep saying this stuff.

: Ok, I'll take that last sentence of mine and substitute concretes for the
: logical placeholders, for the cognitively impaired.

: "Java is a bad hack based off C++, which is a bad attempt at an OO language."

: Did you get it that time?

Uh, yes, you keep saying this.

YOU HAVE OFFERED NO ARGUMENT.

: : : : Perl5 OO? *rofl*

: : : Have you used it? Have you read about it? Do you even know that it has
: : : object extensions? I doubt it.

: : Yes, I have used it. Its object extensions are a horrible hack on top
: : of a worthless language.

: I'll forward this to my favorite Perl God[tm] and let him respond.

Please do. Add to it that I think there is no reason on Earth for
Perl to continue to exist when Python does everything it does in a
much more elegant, easy to use, and, yes, more OO fashion than Perl.

: : : : Ignore Eiffel. Eiffel is a controversial one;

: : : Yeah, ignore the one that proves you wrong incontrovertibly. Moron.

: : If I make the following claims simultaneously:
: : 1 Bill Clinton was the first president of the USA.
: : 2 Too bad Kurt Cobain's suicide broke up the Beatles.
: : 3 Lowering taxes helps the working poor.
: : 4 Ronald Reagan was the best French leader of the 20th century.

: : Are you going to waste your time debating #3 when 1, 2, and 4 are so
: : blatantly wrong?

: Yes.

Then you are strange. You can't possibly win a controversial argument
when the opposition is claiming complete nonsense to be true.

: : As I stated before, arguments can be made that Eiffel is more OO than

: : Java--it is not something I hold to be true. Smalltalk actually falls
: : into that same class.

: Yeah, the language that _defined_ OO isn't OO.

Where did I even suggest Smalltalk was not OO? Stick to the facts, damnit.

: Perhaps if you would slow

: down, take a deep breath, have a beer, and _think,_ for once, instead of
: just following the party line? You're saying some things in defense of
: this silly Java religion of yours that are just hideous.

I am not towing any party line. You have yet to make a single factual
statement about Java, so I have yet to say anything about it in
response. Maybe if you make a real claim regarding it, I will
respond.

Oh, wait, you make a beauty of a claim below. I will address that in
a minute.

: When will you

: decide that we should all write realtime systems in Java? Or have you
: already?

I know people who are doing so. It is in fact possible I will be
writing Java Card applications in the near future. Do I think this is
the best application of Java? I don't know yet.

: : : Smalltalk: it's an object system unto itself, and its design is
: : : cleaner.

: : How is its design cleaner?

: Everything _is_ an object, conceptually(and at the source code level) which
: avoids certain syntactic stew present in Java. That's one thing.

And as Rust points out, that causes other problems. Like basic data
types are basic for a reason.

: : : Ada: it doesn't lack little things like parameterized types.

: : You name one thing Ada has (that is not core to OO) that Java does not
: : have TODAY (they will be in the future). This is hardly an argument
: : to support your claim.

: Parameterized types are rapidly becoming a standard feature. "Core to OO"
: is relative the source you quote. Hell, one could say that OO is nothing
: but inheritance, if one looked back far enough. Have a look at the xt
: toolkit for X.

What about Smalltalk? *DOH*

Parameterized types have little to do with being OO, and Java *will*
have parameterized types. So what exactly is your point?

: : : Perl5: This is a weird one, and contrary to your Eiffel bullshit, this

: : : is the controversial one. Nevertheless, if you can get past its
: : : inherent weirdness, the Perl5 OO stuff is incredibly usable, and
: : : incredibly powerful/expressive, neither of which are aspects of
: : : Java.

: : That is not an argument.

: It sure does look like one. The heart of OO, the whole reason there _is_
: OO, is to make programming easier. Certainly nobody is going to claim
: that OO is done for the machine's benefit. Perl5's OO extensions are
: arguably far more usable than Java.

In what nightmare world? Name one extension of Perl5 that is easier
to use and that makes any sense whatsoever.

: : : : Integer is a real data type and looks like a real data type.

: : : Integer.intval? That looks like accessing a regular type to you? You
: : : MUST be a moron.

: : In Java, an integer is represented by the int primitive data type JUST
: : LIKE IN LPC.

: Yes, but nobody uses them that way. They can't. They have to pass around
: Integer instances, or their stuff won't work with any of the libraries
: or anyone else's code.

Nobody uses them that way? Maybe you should actually code in Java
before making claims about how people use it. Mostly, people use the
basic int data type that is identical to LPC. There are only a few
instances in which you use Integer, and you do it for very good reasons.

One last time: stop making claims about things you clearly know
absolutely nothing about.

: : : : LPC is a shit language for data abstraction (which answers your

: : : : question why LPC is not a true object language) for two reasons:

: : : : * all abstract data in LPC is of the same type; your stack object is
: : : : type object and nothing more, so is your date object or file object or
: : : : whatever

: : : Actually, while I'm sure many would disagree, I call this a feature.
: : : Strongly typed UDTs only work if you have multiple inheritance, truly
: : : static typing, overloadable operators, and a bunch of other stuff that
: : : Java generally utterly lacks, and that is undesirable in LPC. Typing
: : : info can be simulated in LPC anyway, your lack of imagination
: : : notwithstanding.

: : This is all doublespeak. Overloadable operators *in any language* is
: : nothing more than syntactic sugar. The rest of what you are saying is
: : nonsense.

: OO is nothing more than syntactic sugar, you moron. And you _can_ simulate
: typing info in LPC - this is no nonsense. You have a real way of ignoring
: things that demonstrate you to have been wrong about something - you just
: call it nonsense, insult the author, or ignore/cut it.

OO is quite a bit more than syntactic sugar. But I defer to Rust's
much better discussions of this issue.

: (While I'm at it, C is nothing more than syntactic sugar. Hell, assembler

: isn't either - why don't you go write your reusable objects in raw binary
: machine code, you buffoon?)

You really don't have the first idea of what you are talking about, do
you?

: : : : * in order to do data abstraction in LPC, you have to step outside the

: : : : LPC garbage collection paradigm and do your own memory managemen,
: : : : otherwise you end up with serious leaks

: : : You keep saying this. I do a lot of clean_up stuff, but that's it.

: : Calling destruct(ob); in LPC is the same damn thing as delete ob; in
: : C++. clean_up() is not a good mechanism since, in a lot of cases, you
: : do not want ADT instances to be cleaned. Cleaning up is not the same
: : as reference counting.

: MudOS does in fact supply a mechanism(in the devel package) for getting
: the ref count on an object. If you want to do ref counting yourself,
: you can.

You are completely missing the point, aren't you. First, the devel
package is not something you compile in to a production mud. Second,
even if you did, don't you think doing your own reference coiunting is
goiung a little bit over the deep end?

At least you finally admitted you were wrong on this topic, if not in
a rather backass way.

: : : : What exactly does Java sacrifice for simplicity?

: : : Overloadable operators, integral object typing of basic types, multiple
: : : inheritance... that's too much already.

: : Those are all definitely good things that Java has omitted, except the
: : integral object typing of basic types, which is neither good nor bad.

: Yeah, conceptual integrity is worthless. Why bother with little things like
: making sense, when you can just throw together whatever is easiest to write
: a compiler for and be done with it?

Conceptual integrity? Why do you always insist on changing subjects
when you are losing an argument? Where the hell did that come frome?

Java has the single most consistent conceptual framework of any
language I have ever seen.

: : : : : Or even semantic consistency. Little things like always either passing

: : : : : something by reference or value as the default, and not making it depend
: : : : : on things like location:)

: : : : Which is a completely irrelevant issue in the LPC world.

: : : You keep saying that. Obviously you will never be a language designer
: : : of any skill. Language designers don't excuse their lack of good design
: : : by saying 'don't do this; its a bad idea' to programmers.

: : Good ones prvent programmers from doing bad things.

: I won't even go there, except to say that no language has ever done this
: without incurring penalties that are, in the general case, unacceptable.

Really? What unacceptable penalties has Java incurred?

: : : Java's is useless for anything but toys, but they're supposedly fixing

: : : that using digital signature technology. I'll wait and see before I
: : : comment.

: : You know nothing about what people are using Java for in the real
: : world, yet you make this statement? I use it securely for things that
: : are more than toys, and a lot of other people are as well.

: Until they finish the digital signature stuff, a Java program can run with
: two security levels: utter incapability to do anything without asking the
: user specifically(which gets annoying and is only useful for toys,) and
: the ability to do anything doable by a process with the uid of the VM it
: runs in. This is hardly useful for anything real in the distributed world.

Take a class on the Java security model. AS I have stated several
times, I AM GOING REAL WORK IN JAVA. Java works here and now and can
build any business system that you could do in any other language
faster and more soundly.

And the Java security model has many, many security levels. You just
don't have the first clue as to how it works. Perhaps your knowledge
of Java is limited to what you have seen in Netscape?

: : : I haven't had this problem writing what is currently about 300k of LPC

: : : and growing rapidly. On the other hand, I have found the MudOS compiler
: : : to be incredibly handy in debugging if you have a decent error handler
: : : and all the debugging useful pragmas enabled by default. I've yet to
: : : encounter a bug I couldn't fix in five minutes or so, and I'm writing
: : : from scratch. When I moved to AIX from Linux, there was zero difficulty
: : : beyond getting MudOS to compile on a crusty old version of AIX that has
: : : no dl libraries and so on, which took me about 3 tries.

: : You are missing the point. Java requires less debugging. And its
: : logging information is as good as that MudOS produces.

: Do you have any reasoning or evidence to support your claim that Java
: requires less debugging?

Yes, because I have been doing group development with it for 2 years
and with LPC for nearly 7 years.

Mostly, Java catches most errors at compile time. Something that
LPC does not. LPC catches very few errors at compile time.

: : : On the other hand, a good friend has a simple calendar project he co-wrote

: : : with a team for a semester project. It runs flawlessly on Solaris. It
: : : barely even pretends to run elsewhere. But hey, it checks out as
: : : '100% Pure Java.' What a joke.

: : You provide one anecdotal piece of information without any reference
: : to what problems were actually encountered and you expect it to serve
: : as evidence to damn Java?

: I'll forward this to him as well as the perl bit; he's both people. He knows
: more details of the matter than I do.

Thank god. Someone who can actually point to something concrete
instead of making your vague claims.

: : : : Do you even know what data abstraction is? This ain't it.

: : : No, of course not. The Integer type isn't an attempt at abstracting int
: : : into an object type. Not at all. Do you in fact know your ass from your
: : : elbow?

: : That is not what you were talking about. You said that it cannot be
: : added normally (It is value is immutable). That is not an issue of
: : data abstration.

: The value of an Integer is not immutable, you dolt. Therefore, that clearly
: is not what I meant. I meant that you cannot do:

: Integer a, b, c;
: ...
: c = 5;
: a = b + c;

: And you cannot. There is nothing more to say; you are wrong. This is not
: good data abstraction, and it is the only way in Java.

Besides being massively incorrect Java code...

How about:

int a, b, c;

c = 5;
a = b + c;

That is correct Java code. And it supports all proprties of integers.

: : Furthermore, an abstraction of int in LPC could no more be added to.

: An LPC int _is_ an object, logically, even if not in type. It is not a
: hardware supplied type(well, it ends up using one, but all LPC ints,
: on all platforms, are identical, and you can mix ints and objects in
: arrays and so forth - they're all basically objects.)

There is a huge difference in LPC between the basic types: int, float,
string, and buffer and the object types: object, function, mapping,
and array.

And, one more time, an int in Java is identical to an int in LPC. NO
DIFFERENCE.

: : : : First, getting into your little off topic issue, show me an LPC

: : : : abstraction of an int that beats Integer.

: : : I don't need to. The LPC int _is_ an abstraction unto itself; it is
: : : exactly the same, behaves exactly the same, on all platforms. And
: : : you don't have to dereference a member of it to get its value. Imagine
: : : that.

: : You mean, just like the Java int type?

: Apparently not, since I can put an LPC int into an array right alongside
: another object, whereas putting a Java int into an array of objects won't
: even compile.

Java cares about data types. You can stick an int into an int array.
You cannot stick an int into a String array.

LPC does not give a shit because LPC will let you divide strings.

Try this:
eval return this_player()->GetName()/this_player()->GetCapName()

That compiles in LPC. It won't in Java for exactly the same reason
you cannot stick an int into a String array.

: : : : Second, let's talk about real data abstraction issues, such as how to

: : : : build a Data or File object in LPC.

: : : A Data object? I do believe that's type object. The whole point of objects
: : : is to contain data of all sorts. Precisely what more do you expect?
: : : Maybe this?

: : : class Data
: : : {
: : : string type;
: : : mixed MyData;
: : : }

: : In LPC, class is a misnomer. This is nothing more than a struct.

: Your point being?

: : : And then a bunch of simuls like typeof and datap so on?

You act as if it is some OO magic. It is not.

: : Oh, that is real OO. *rofl*

: I don't think it is, but then, I don't feel the need to have an abstraction
: that encompasses everything that is 'data.' I've always found that data
: is well represented and grouped by that thing called an object, which is
: supplied by that thing called the language.

Where did you get this tangent from?

I am trying to create a file object abstraction. And, iut is a very
useful abstraction.

: : : As for a file, I've never felt the need to do this, because the

: : : persistence primitives(save_object and restore_object) make it too
: : : unimportant to bother with, but if you wanted to, the read and write
: : : family of efuns would make building such fairly easy. You could have
: : : syntax kinda like this in usage:

: : : object my_goddamn_file = new(File);

: : : my_goddamn_file->open("/txt/thingie");
: : : my_goddamn_file->read_bytes(some_bytes);
: : : my_goddamn_file->close();

: : : Would this give you a woody?

: : I have such an object, and so does Lima. The problem is that it is
: : type object and it does not automatically GC.

: The fact that it is type object is a bonus, because now you can stick files
: in with similar objects in an array.

You can stick them in arrays in Java too. Woo woo.

First you argue for parametrized types, then you argue for the
bastardization they are designed to prevent. What is it you really
want?

: The fact that it doesn't automatically

: GC seems to be logical enough... when would a file want to go away?

Gosh, maybe when no one is using it?

Do ya think?

: Do you

: mean you want persistent reference counting? If so, Java ain't it. If you
: mean merely that you want the object to unload itself from memory when not
: referenced, use the ref counting efun.

That is totally stupid, as I have discussed before.

: : : : Java's inheritance mechanism with interfaces makes for a more robust

: : : : representation of common design patters.

: : : Such as? And because?

: : Please look at Rust's post for a much better summary of this than I
: : can give.

: Which one? He has, in his lifetime, posted more than once.

Yes, and every single followup has been beautifully lucid and really
put your pathetic ass in your place. Just look up any followup by him
to a post by you.

: : : : And if multiple inheritance is what you want, let's talk about LPC's
: : : : virtual inheritance...

: : : You mean MudOS's virtual inheritance. It doesn't have to be that way;
: : : it is not inherent in the language itself.

: : That is the way it is. Arguing about hypotheticals is silly.

: Then quit arguing about Java's forthcoming parameterized types, support for
: IIOP in RMI, and so on. You can't have it both ways.

Parameterized types will exist. IIOP for RMI will exist.

Real virtual inheritance in MudOS right now is nothing more than a
pipe dream.

Also keep in mind, my references to IIOP and parameterized types are
asides that are not relevant to my main point. The lack of any
reasonable virtual inheritance in LPC seriously undermines your point
about multiple inheritance in LPC.

: : : : : Readability: probably similar, but its subjective

: : : : Java is much easier to read.

: : : I disagree, and as I said, it is subjective. LPC supports some things
: : : that Java falls on its ass for(the fn pointers, the ({}) immediate form
: : : of array notation, etc) that aren't as pretty as one might like, but
: : : can you improve on them?

: : And LPC also has plenty of its own uglies.

: : Prototyping is my favourite.

: LPC prototypes look like C and C++ prototypes. What do you find difficult
: about this?

That they even exist at all.

[John Viega]

[Complementary CC sent to original author]

In article <5vmrd1$85p$1...@news.cc.umr.edu> John Adelsberger writes:

[tons of insults and crap I don't care about much deleted]

> : : : Perl5 OO? *rofl*
>
> : : Have you used it? Have you read about it? Do you even know that it has
> : : object extensions? I doubt it.
>
> : Yes, I have used it. Its object extensions are a horrible hack on top
> : of a worthless language.
>
> I'll forward this to my favorite Perl God[tm] and let him respond.

Funny to watch you berate someone for not having used Perls
(admittedly quite clunky as far as they go ) object facility when you
haven't used it yourself.

> : As I stated before, arguments can be made that Eiffel is more OO than
> : Java--it is not something I hold to be true. Smalltalk actually falls
> : into that same class.
>
> Yeah, the language that _defined_ OO isn't OO.

1) He certainly is not claiming Smalltalk isn't OO. Don't put words
into his mouth. However, something he realizes which you have so far
failed to admit is that people have methodologies for using OOPLs, and
there are language features which are desirable and undesirable in
each methodology... Smalltalk isn't the best OO language for everyone
just because one of the authors of the language coined the term
"object oriented" with respect to programming languages.

2) Despite the fact that I have publicly debunked your belief that
Smalltalk defined OO at least twice, you continue to make the claim.
I will reiterate once again: Alan Kay coined the term before he ever
got to Parc or worked on Smalltalk. Go read about Flex, the language
he worked on before Smalltalk. Also, as I have told you just as many
times, whether you want to believe it or not, Cardelli and Wegner gave
the formal definition of OO. I've cited the paper twice, Cardelli &
Wegner, "On Understanding Types, Data Abstraction, and Polymorphism".
Luca Cardelli actually has the pdf and postscript on his web page, go
there and read it:
http://www.research.digital.com/SRC/personal/Luca_Cardelli/Papers.html

>
> : : Ada: it doesn't lack little things like parameterized types.
>
> : You name one thing Ada has (that is not core to OO) that Java does not
> : have TODAY (they will be in the future). This is hardly an argument
> : to support your claim.
>
> Parameterized types are rapidly becoming a standard feature. "Core to OO"
> is relative the source you quote. Hell, one could say that OO is nothing
> but inheritance, if one looked back far enough. Have a look at the xt
> toolkit for X.

First of all, you can say whatever the hell you like, but inheritance
is neither necessary nor sufficient for being OO. _Type inheritance_
is necessary, but not sufficient. Type inheritance does not imply
traditional inheritance. Again, Cardelli and Wegner *are* the basis
for formal classification in computer science, and I've given you
several sources to support this.

Beyond that, I won't agree that parameterized types are rapidly
becoming a standard feature. There are too many untyped object
oriented languages these days to make that claim. Java *is* going to
have them soon, though. By the way, if you think Sun is so
incompetent w/ Java, why don't you go look at the Pizza compiler,
which is Sun sponsored research, and is an experimental superset of
Java. It has parameterized types (actually, Hindley/Milner parametric
polymorphism, which is far more desirable than probably all of the
parameterized typing you are used to), higher order functions, and int
and Integer are completely interchangable. In general, 3/4 of the
stuff you have mentioned you don't like about Java are not the same in
Pizza. So if Mr. Reese stops mentioning Java, and starts talking
about Pizza instead, will you stop being so disdainful to a language
that many, many people belive have a lot to offer?

>
> : : Perl5: This is a weird one, and contrary to your Eiffel bullshit, this
> : : is the controversial one. Nevertheless, if you can get past its
> : : inherent weirdness, the Perl5 OO stuff is incredibly usable, and
> : : incredibly powerful/expressive, neither of which are aspects of
> : : Java.
>
> : That is not an argument.
>
> It sure does look like one. The heart of OO, the whole reason there _is_
> OO, is to make programming easier. Certainly nobody is going to claim
> that OO is done for the machine's benefit. Perl5's OO extensions are
> arguably far more usable than Java.

Huh? Your argument boils down to, "If you can get past the fact that
perl's OO extensions are hard to use, they're incredibly usable".
That makes sense.

I'd like to see you make the argument that Perl5's OO extensions are
far more usable than Java (Pizza adds nothing to Java that Perl5 has).
By your own arguments, you should prefer Pizza/Java because the notion
of everything is an object that you like so much from Smalltalk is
better supported by Pizza (or even Java, since unlike Perl it does not
add new primitive non-object types beyond numerical and character
types). Plus, all of the hacks onto perl to graft OO functionality in
w/o affecting legacy code, such as "blessing" are generally considered
hard to use, whereas the Java object model isusually considered to be
very streamlined and simple.

>
> : : : Integer is a real data type and looks like a real data type.
>
> : : Integer.intval? That looks like accessing a regular type to you? You
> : : MUST be a moron.
>
> : In Java, an integer is represented by the int primitive data type JUST
> : LIKE IN LPC.
>
> Yes, but nobody uses them that way. They can't. They have to pass around
> Integer instances, or their stuff won't work with any of the libraries
> or anyone else's code.

That's a crock of shit. Integers etc are only used where you want to
put a primitive type into a polymorphic data structure. It is even
more a crock of shit in Pizza. If LPC only allowed objects as values
to hash tables, instead of its even less type safe implementation,
then you would be doing the same sort of thing.

> OO is nothing more than syntactic sugar, you moron. And you _can_ simulate
> typing info in LPC - this is no nonsense.

*simulate*. And you complain about having to hack in Java???!!! If
you're going to do static type checking, why not use the information
(unlike LPC)? There is no excuse to have to do so much and such
kludgy run time type identification, especially when the language
syntactically seems like it should have a strong notion of type.

> (While I'm at it, C is nothing more than syntactic sugar. Hell, assembler
> isn't either - why don't you go write your reusable objects in raw binary
> machine code, you buffoon?)

And there you go trivializing real concerns again, when if you are
reasonably intelligent, you see the real meat of the problem. Yeah,
ignore it so you come out on top. Whee. The truth is, LPC's type
system in general is a *horrible* excuse for a type system in an OO
language. Go read that Cardelli and Wegner paper, learn something
useful about types, then come back and praise LPC's type system, if
you dare.

> MudOS does in fact supply a mechanism(in the devel package) for getting
> the ref count on an object. If you want to do ref counting yourself,
> you can.

Uh, aren't you the guy who keeps screaming "but that's a hack" Re:
Java? Hey, guess what, having to use a dev only feature, especially
one that EXPOSES THE IMPLEMENTATION is a hack.

> Yeah, conceptual integrity is worthless. Why bother with little things like
> making sense, when you can just throw together whatever is easiest to write
> a compiler for and be done with it?

Since you seem to be so in love w/ LPC over Java, at least Java was
designed. LPC was hacked together, and people have been hacking on it
ever since (w/ the exception of Dworkin).

> : Good ones prvent programmers from doing bad things.
>
> I won't even go there, except to say that no language has ever done this
> without incurring penalties that are, in the general case, unacceptable.

Um, first of all, many things you can do to protect the programmer
from himself not only incur no runtime cost, (e.g. data protection can
be enforced at compile time, and usually is), but also are often MORE
efficient (e.g. static type checking) if implemented properly.

I have never seen such a feature that *did* incur a speed hit where a
large group of people didn't agree it was worth it for some practical
metric, BTW. Speed isn't everyones goal.

> : You are missing the point. Java requires less debugging. And its
> : logging information is as good as that MudOS produces.
>
> Do you have any reasoning or evidence to support your claim that Java
> requires less debugging?

Sure, Java catches far more errors at compile time, largely due to the
fact that it is statically type checked, with objects and interfaces
being real types. That is one reason. Excercise your brain a bit,
you shouldn't have much of a problem coming up w/ more.

> : : On the other hand, a good friend has a simple calendar project he co-wrote
> : : with a team for a semester project. It runs flawlessly on Solaris. It
> : : barely even pretends to run elsewhere. But hey, it checks out as
> : : '100% Pure Java.' What a joke.

>

> An LPC int _is_ an object, logically, even if not in type.

Uh, no. It isn't. Not from a black box point of view, when looking
at the language as a programmer, nor from the implementations point of
view. Sorry.

> It is not a
> hardware supplied type(well, it ends up using one, but all LPC ints,
> on all platforms, are identical, and you can mix ints and objects in
> arrays and so forth - they're all basically objects.)

Uh, no, mappings and arrays accept the set of all types, unlike in
many languages where they must have a uniform type or uniform base
type. That is not the same as a type being an object. You need to
learn the difference between objects and a type system. Go read that
paper I keep hitting you over the head with.

> : : I don't need to. The LPC int _is_ an abstraction unto itself; it is
> : : exactly the same, behaves exactly the same, on all platforms. And
> : : you don't have to dereference a member of it to get its value. Imagine
> : : that.
>
> : You mean, just like the Java int type?
>
> Apparently not, since I can put an LPC int into an array right alongside
> another object, whereas putting a Java int into an array of objects won't
> even compile.

Huh? What does that have to do w/ your original point?? You're
discussing a property of LPC's mapping and array types, not a
property of integers. Also, this has *nothing* to do w/ the argument
right above... The Java int type is portable across all platforms,
behaves the same on all platforms, and you don't have to dereference
it to get a value. Just like LPC.

> : : And then a bunch of simuls like typeof and datap so on?
>
> : Oh, that is real OO. *rofl*
>
> I don't think it is, but then, I don't feel the need to have an abstraction
> that encompasses everything that is 'data.' I've always found that data
> is well represented and grouped by that thing called an object, which is
> supplied by that thing called the language.

Then you're way out in left field in the OO data abstraction world.
Aren't you mr. orthogonal?? Don't you see that having a data
abstraction mechinism w/o methods and one w/ methods is NON-ORTHOGNAL?

Oops, maybe LPC isn't the rockin' OO language you claim it to be when
compared to Java.

> : I have such an object, and so does Lima. The problem is that it is
> : type object and it does not automatically GC.
>
> The fact that it is type object is a bonus, because now you can stick files
> in with similar objects in an array.

If you are doing such a thing, it is likely a sign of bad OO design by
almost any methodology. Now if you had some base class common to all
your data members, then that would make a bit more sense.

> The fact that it doesn't automatically
> GC seems to be logical enough... when would a file want to go away? Do you
> mean you want persistent reference counting? If so, Java ain't it. If you
> mean merely that you want the object to unload itself from memory when not
> referenced, use the ref counting efun.

Ummm... Mr. "Hacks suck" promoting the hack again. Rock out.

> : And LPC also has plenty of its own uglies.
>
> : Prototyping is my favourite.
>
> LPC prototypes look like C and C++ prototypes. What do you find difficult
> about this?

Just because C and C++ do it means it isn't ugly?? C, C++ and LPC all
have order dependancies, which are usually considered to be a bad
thing in a programming language. Prototypes allow you to relax this a
bit, but there are still order dependancies, since a delcaration of a
method still must appear before you can start to use it.

If you think order dependancies rock, let me recommend The Design And
Evolution of C++ to you again. There are several good discussions as
to their evils.

John Viega

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:
: > Java cares about data types. You can stick an int into an int array.

: > You cannot stick an int into a String array.
: >
: > LPC does not give a shit because LPC will let you divide strings.
: >
: > Try this:
: > eval return this_player()->GetName()/this_player()->GetCapName()
: >
: > That compiles in LPC. It won't in Java for exactly the same reason
: > you cannot stick an int into a String array.

: Again, I think you should restrict yourself to the particular LPC dialect you
: use, and not kick at LPC in general, since again for DGD this is not true.

Then why does the above compile for me on DGD?

Are you trying to suggest that DGD type checking is anywhere near that
of Java?

[Kris Van Hees]

On 16 Sep at 20:50:19, John Adelsberger wrote <5vmrd1$85p$1...@news.cc.umr.edu> which contained:

> George Reese (bo...@imaginary.com) wrote:
>: Explain why DGD has had such a hard time getting equivalent popularity
>: even though it is a product of similar quality (cleaner, stabler, but
>: fewer features)?
>
> Because it is so minimalist that one has to know quite a bit of OS theory
> to write a decent mudlib for it?

Excuse me, but why would anyone need to know OS (Operating System) theory to
write a mudlib for any driver? Although the name MudOS contains OS, it is
very far from an OS, and even *if* MudOS and/or DGD would resemble an OS, the
OS work has already been done, and thus no OS theory applies.

One has to be a fairly decent programmer, and preferably know something about
designing algorithms, and if you want to make it a clean mudlib, some knowledge
on object modeling might help also.

Aedil

[Kris Van Hees]

On 17 Sep at 18:49:19, George Reese wrote <5vp8mp$itv$1...@darla.visi.com> which contained:

> Kris Van Hees <ae...@ny.fnx.com> wrote:

>: > Java cares about data types. You can stick an int into an int array.

>: > You cannot stick an int into a String array.
>: >
>: > LPC does not give a shit because LPC will let you divide strings.
>: >
>: > Try this:
>: > eval return this_player()->GetName()/this_player()->GetCapName()
>: >
>: > That compiles in LPC. It won't in Java for exactly the same reason
>: > you cannot stick an int into a String array.
>

>: Again, I think you should restrict yourself to the particular LPC dialect you
>: use, and not kick at LPC in general, since again for DGD this is not true.
>
> Then why does the above compile for me on DGD?

Because you are doing arithmetic with the return values of function calls in
other objects. Since LPC does not have a mechanism to specify the return
value types for different objects (and that is actually a rather powerful
aspect of the language in my opinion - yours may vary), there is no way that
compile time type checking can take place in that case. However, for local
function calls or function calls within the inheritance tree, and for plain
variable arithmetic, compile time typechecking can be done when strict typing
is being used.

>
> Are you trying to suggest that DGD type checking is anywhere near that
> of Java?

I am not trying to suggest anything, and you might want to tone down a little.
I happen to like the flexibility which languages like LPC give, even if it is
at the sacrifice of some type checking. LPC and Java are two different
languages, and comparing them in detail as with type checking properties is
useless and a waste of time. The typechecking in DGD is good, and though it
can be improved in some areas perhaps, it does a great job. And it is for
sure sufficient within the language concept of the LPC dialect used in DGD.

You are a major Java advocate, and I don't want to enter a LPC vs Java
discussion. I merely wanted to point out that you are again not giving
attention to the fact that the LPC dialect and implementation you are
basing your comments upon is just that... one particular case.

Aedil

[John Viega]

[ Complementary CC sent to original author ]
In article <5vpjsi$agg$2...@news.cc.umr.edu> j...@ultra3.cc.umr.edu (John Adelsberger) writes:

> John Viega (jt...@adder.cs.virginia.edu) wrote:
> : In article <5v6p37$gci$1...@news.cc.umr.edu> j...@ultra5.cc.umr.edu (John Adelsberger) writes:
>
> : > : Sub: Typing

> : > : Concurrency
> : > : Persistence
> : >
> : >Um, here I'm going to have to differ. Concurrency has nothing to do with
> : >OO, and in fact, afaik, most of the good concurrency-specification languages
> : >are anything _but_ OO. I think maybe Booch was making a wishlist for a
> : >language instead of describing a category of languages:)
> : >(Actually, I'd say the same thing about persistence, too. Persistence isn't
> : >a basic programming methodology component at all; why you'd put it on a level
> : >with issues like typing is utterly beyond comprehension.)
>

> : Hey, why don't you go read the damn book before you try to put words

> : into Booch's mouth? You look oh so intelligent slamming a respected
> : scholar for writing 4 words that you saw completely out of context.
>

> Even if he didn't consider them required, persistence and concurrency
> have _nothing_ conceptually to do with OO whatsoever.

Goes to show how ignorant you are. If you actually read Booch, you'll
learn that they are *very* desirable to his OO design methodology.
Just because they are features that do not require an OO language to
exist doesn't mean they can't promote the ideals of an OO methodology.
This is the case with many features you personally consider to be
conceptually tied to OO based on your other posts in this thread, such
as operator overloading,

> Moreover, they
> certainly are not language design issues on the level of typing, OO or
> not. Nothing else Booch could _possibly_ have said could change these
> _facts._

Who said Booch was talking about language design??? He was talking
about desirable properties of an OO language for use in his
methodology. Apparently *you* need to read for comprehension, because
I made that perfectly explicit in another post on this thread.

> : Jesus, that is almost as bad as flaming Knuth for not knowing anything

> : about algorithms just because someone summarized a sorting algorithm
> : from his text that didn't sound right to you.
>

> I don't recall flaming Booch.

Your statement boils down to, "Booch is full of shit", which is a
flame, especially considering the fact you have not done enough
research to begin to back this up. GO READ THE BOOK before you try to
counter his work. You are so obviously completely oblivious to the
foundations upon which his statements rest, despite the fact that you
seem to feel that your big brain has groked that aspect of Booch
completely.

> Perhaps if you'd read _before_ replying,
> and for _comprehension?_

The comprehension I lack with respect to your original post is equal
to the academic depth you've shown this newsgroup in terms of all
things object oriented -- that is, none at all. Let me demonstrate:

Here is what you had to say, repeated one more time:

> : >Um, here I'm going to have to differ. Concurrency has nothing to do with
> : >OO,

Boy, you're saying that concurrency doesn't have anything to do w/ OO.
That's obvious. But hey, neither does operator overloading. However,
both can be useful in an object oriented language. All Booch was
saying is that if you use his OO analysis and design methodolgy,
concurrency is a very big plus. You see, I understood your point, but
you failed to understand the context in which Booch wrote that list.

> : and in fact, afaik, most of the good concurrency-specification languages
> : >are anything _but_ OO.

That is completely irrelevent to whether concurrency in an OO language
can promote better object oriented designs. Neither Booch nor anyone
else here has said that being concurrent implies being OO, NOR VICE
VERSA. You're trying to put words in Booch's mouth.

> : >I think maybe Booch was making a wishlist for a

> : >language instead of describing a category of languages:)

"You think" wrong. He was not making a wishlist. He was describing a
two sets of language features, once set required and one set highly
desirable *TO HIS METHODOLOGY*.

Please quit arguing uninformed points of view, and slinging insults
just because people disagree with you (eg, claiming I read your
previous post without comprehension -- it should be pretty clear to
you know that I understood precicely what you said, and I find you to
be very wrong).

Besides, your arguments have been shown to lack factual sustainance so
much that disagreeing with you on this newsgroup has become a safe
bet. =)

[John Viega]

[ Courtesy CC sent to original author ]

In article <EGo8t...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees) writes:

> Newsgroups: rec.games.mud.lp
> From: ae...@ny.fnx.com (Kris Van Hees)

> On 17 Sep at 18:49:19, George Reese wrote <5vp8mp$itv$1...@darla.visi.com> which contained:
> > Kris Van Hees <ae...@ny.fnx.com> wrote:

> >: > LPC does not give a shit because LPC will let you divide strings.

> >: >
> >: > Try this:
> >: > eval return this_player()->GetName()/this_player()->GetCapName()
> >: >
> >: > That compiles in LPC. It won't in Java for exactly the same reason
> >: > you cannot stick an int into a String array.
> >

> >: Again, I think you should restrict yourself to the particular LPC dialect you
> >: use, and not kick at LPC in general, since again for DGD this is not true.
> >
> > Then why does the above compile for me on DGD?
>
> Because you are doing arithmetic with the return values of function calls in
> other objects. Since LPC does not have a mechanism to specify the return
> value types for different objects (and that is actually a rather powerful
> aspect of the language in my opinion - yours may vary),

This was exactly his point. Type checking in LPC is so poor that it
doesn't check the return type of a call to a function outside the
caller at compile time. There is no difference between MudOS and DGD
here. Note that his example made sure to use external calls, because
"foo"/"bar" doesn't compile anywhere that even a bit of static type
checking is done. It seems to me that you thought he meant ALL string
division compiles on MudOS, which is now what he was saying.

> there is no way that
> compile time type checking can take place in that case.

Sure there could, but run-time type checking is still required, but
LPC duplicates all its type checks at runtime already anyway,
due to the rockin' cast / mixed crap.

> I am not trying to suggest anything, and you might want to tone down a little.
> I happen to like the flexibility which languages like LPC give, even if it is
> at the sacrifice of some type checking. LPC and Java are two different
> languages, and comparing them in detail as with type checking properties is
> useless and a waste of time. The typechecking in DGD is good, and though it
> can be improved in some areas perhaps, it does a great job. And it is for
> sure sufficient within the language concept of the LPC dialect used in DGD.

Sure, it is all a matter of oppinion. Here's my oppinion:

<oppinion>
I find it pretty astonishing how little type safety LPC has.
Essentially, all compile time checking is necessarily ignored at run
time (well, with some effort you can determine when a variable is
never affected by a remote object, and occasionally make some
optimizations there, but that is high effort for essentially no
payoff). It is a shame that when the LPC type system was devised it
was devised so poorly. Sure, there is some benefit to getting some
errors caught at compile time. However, if you're not going to do a
reasonable job at static checking, it is almost not even worth
statically declaring types for LPC. Basically, a lot of novices code
in LPC, and requiring them to learn a notion of types may not really
be worth the gain (This is hard to quantify, but Lima's experience is
that mud building should have a much lower entry bar than LPC, as many
people with great ideas who are non-programmers have too many high
hurdles to jump before they can be productive. We see lots of people
bail early on LPC, and IMHO, that's a bad thing. That's why we
created a small compiled (to LPC) language just for area
building... you don't have to extend yourself to learn LPC until it
becomes necessary for some *very* complex task, by which time you have
hopefully invested enough effort on your mud and learned enough
programming basics that the hurdles are fewer and smaller).

I think that a Henley / Milner type system would work pretty well for
an LPC-like language... You would get very strong compile time
checking, and the novice programmer would hardly have to learn the
notion of type since there wouldn't in practice be too many cases
where the type inferencer would fail.
</oppinion>

> You are a major Java advocate, and I don't want to enter a LPC vs Java
> discussion. I merely wanted to point out that you are again not giving
> attention to the fact that the LPC dialect and implementation you are
> basing your comments upon is just that... one particular case.

In this particular case, George's example does indeed apply to all
drivers.

[John Adelsberger]

John Viega (jt...@adder.cs.virginia.edu) wrote:
: In article <5v6p37$gci$1...@news.cc.umr.edu> j...@ultra5.cc.umr.edu (John Adelsberger) writes:

: > : Sub: Typing
: > : Concurrency
: > : Persistence
: >
: >Um, here I'm going to have to differ. Concurrency has nothing to do with
: >OO, and in fact, afaik, most of the good concurrency-specification languages
: >are anything _but_ OO. I think maybe Booch was making a wishlist for a
: >language instead of describing a category of languages:)
: >(Actually, I'd say the same thing about persistence, too. Persistence isn't
: >a basic programming methodology component at all; why you'd put it on a level
: >with issues like typing is utterly beyond comprehension.)

: Hey, why don't you go read the damn book before you try to put words
: into Booch's mouth? You look oh so intelligent slamming a respected
: scholar for writing 4 words that you saw completely out of context.

Even if he didn't consider them required, persistence and concurrency

have _nothing_ conceptually to do with OO whatsoever. Moreover, they

certainly are not language design issues on the level of typing, OO or
not. Nothing else Booch could _possibly_ have said could change these
_facts._

: Jesus, that is almost as bad as flaming Knuth for not knowing anything

: about algorithms just because someone summarized a sorting algorithm
: from his text that didn't sound right to you.

I don't recall flaming Booch. Perhaps if you'd read _before_ replying,
and for _comprehension?_

--

[Kris Van Hees]

On 17 Sep at 01:43:49, George Reese wrote <5vncj8$445$1...@darla.visi.com> which contained:

>: Do you have any reasoning or evidence to support your claim that Java
>: requires less debugging?
>
> Yes, because I have been doing group development with it for 2 years
> and with LPC for nearly 7 years.
>
> Mostly, Java catches most errors at compile time. Something that
> LPC does not. LPC catches very few errors at compile time.

I think you should (as is often the case) specify *which* LPC you are talking
about. It is for sure a matter of the driver, not the language dialect. In
DGD, quite alot of compile-time error catching is going on, if you write code
in a proper way (strict typechecking being enforced).

>
> Java cares about data types. You can stick an int into an int array.
> You cannot stick an int into a String array.
>
> LPC does not give a shit because LPC will let you divide strings.
>
> Try this:
> eval return this_player()->GetName()/this_player()->GetCapName()
>
> That compiles in LPC. It won't in Java for exactly the same reason
> you cannot stick an int into a String array.

Again, I think you should restrict yourself to the particular LPC dialect you

use, and not kick at LPC in general, since again for DGD this is not true.

Aedil

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:

: On 17 Sep at 18:49:19, George Reese wrote <5vp8mp$itv$1...@darla.visi.com> which contained:

: > Kris Van Hees <ae...@ny.fnx.com> wrote:

: >: > Java cares about data types. You can stick an int into an int array.

: >: > You cannot stick an int into a String array.
: >: >
: >: > LPC does not give a shit because LPC will let you divide strings.
: >: >
: >: > Try this:
: >: > eval return this_player()->GetName()/this_player()->GetCapName()
: >: >
: >: > That compiles in LPC. It won't in Java for exactly the same reason
: >: > you cannot stick an int into a String array.
: >

: >: Again, I think you should restrict yourself to the particular LPC dialect you

: >: use, and not kick at LPC in general, since again for DGD this is not true.

: >
: > Then why does the above compile for me on DGD?

: Because you are doing arithmetic with the return values of function calls in
: other objects. Since LPC does not have a mechanism to specify the return
: value types for different objects (and that is actually a rather powerful

: aspect of the language in my opinion - yours may vary), there is no way that
: compile time type checking can take place in that case. However, for local

: function calls or function calls within the inheritance tree, and for plain
: variable arithmetic, compile time typechecking can be done when strict typing
: is being used.

That is exactly my point, Aedil. MudOS and DGD do not differ at all
on this point.

Reread my original post and please explain what you are trying to
addess.

: > Are you trying to suggest that DGD type checking is anywhere near that
: > of Java?

: I am not trying to suggest anything, and you might want to tone down a little.

: I happen to like the flexibility which languages like LPC give, even if it is
: at the sacrifice of some type checking. LPC and Java are two different
: languages, and comparing them in detail as with type checking properties is
: useless and a waste of time. The typechecking in DGD is good, and though it
: can be improved in some areas perhaps, it does a great job. And it is for
: sure sufficient within the language concept of the LPC dialect used in DGD.

: You are a major Java advocate, and I don't want to enter a LPC vs Java

: discussion. I merely wanted to point out that you are again not giving
: attention to the fact that the LPC dialect and implementation you are
: basing your comments upon is just that... one particular case.

In what way? You have not shown in the least bit that my comments are
only relevant to MudOS. My comments are entirely true of all versions
of LPC in public distribution right now.

[John Viega]

> <oppinion>
> </oppinion>
D'oh! That one was bad!
Rust attempts to speel, but fails miserbably.

[George Reese]

Joost de Heer <joo...@sci.kun.nl> wrote:
: In <5vp8mp$itv$1...@darla.visi.com> George Reese <bo...@imaginary.com> writes:

: >: > Try this:

: >: > eval return this_player()->GetName()/this_player()->GetCapName()
: >: >
: >: > That compiles in LPC. It won't in Java for exactly the same reason
: >: > you cannot stick an int into a String array.

: will 'eval return (string)TP->GetName()/(string)TP->GetCapName()' compile?
: I can't check it atm, got no compiled driver ready. I guess that the
: eval mentioned in the quoted part works, because the data type of the
: call_others aren't known at compile time, and that the casted version won't
: compile because the data type is known at compile time. Isn't there a
: 'basic rule' that call_other's should be casted, to avoid nonsense like
: the eval in the above quote?

Not really. Casting a call other no more ensures that you are going
to get a string than failing to cast it does. It just means you
believe you are going to get a string. Trying to divide two call
others, IMHO, has the same effect: it shows that you believe you are
going to get two numbers.

We'll find out the truth at runtime.

[Kris Van Hees]

On 17 Sep at 23:44:09, George Reese wrote <5vppvi$2h3$1...@darla.visi.com> which contained:
<< Division of call_other()'s which will return strings. >>

>
> That is exactly my point, Aedil. MudOS and DGD do not differ at all
> on this point.

You know, if you try that vision on Pike (formerly known as uLPC), it will
work, and it will yield an array of strings, as if explode() was done with
the given data. I won't go as far as calling Pike in the same league as
other LPC dialect though, since it is far better. But it shows a rather
interesting exception.

Anyway, I fully agree that MudOS and DGD will handle your particular example
in the same way.

>
> Reread my original post and please explain what you are trying to
> addess.

I think my posting happens to explain that just fine, so perhaps you could
in the meantime reread mine?

>
> In what way? You have not shown in the least bit that my comments are
> only relevant to MudOS. My comments are entirely true of all versions
> of LPC in public distribution right now.

Quotes as examples from your original post, George:

Example 1:
<< About Java requiring less debugging than LPC. Not type checking related. >>

# Mostly, Java catches most errors at compile time. Something that
# LPC does not. LPC catches very few errors at compile time.

At least with DGD, most errors for me tend to be found at compile time.
Once it compiles, it usually works for me. Your mileage might vary of
course, both with driver, coding style, and design methodology.

Example 2:
<< About John saying that all types are basically objects. >>

# There is a huge difference in LPC between the basic types: int, float,
# string, and buffer and the object types: object, function, mapping,
# and array.

The 'buffer' type doesn't exist in DGD, neither does the 'function' type.
And I haven't looked lately how mappings and arrays have been implemented
in MudOS, but it used to be quite different from DGD (especially after the
change to create local copies for arrays and mappings referenced in other
objects when a thread finishes). They are not object types.

Example 3:
# LPC does not give a shit because LPC will let you divide strings.
#
# Try this:
# eval return this_player()->GetName()/this_player()->GetCapName()
# That compiles in LPC. It won't in Java for exactly the same reason
# you cannot stick an int into a String array.

Like I mentioned in the previous post, your example is correct, yet the
more general statement that LPC lets you divide strings is not true if
you code in a decent way. I personally run DGD with strict typing on,
as allowing non-strict typed code is asking for trouble.

Maybe you didn't mean that statement in the general way I read it, and
perhaps you just meant that if you really want to, you can get LPC to
accept code which would end up dividing two strings. If that is the
case, I apologize for reading it differently.

Aedil

[Felix A. Croes]

John Viega <jt...@adder.cs.virginia.edu> wrote:
>[...]

> Sure there could, but run-time type checking is still required, but
> LPC duplicates all its type checks at runtime already anyway,
> due to the rockin' cast / mixed crap.

Nope. DGD uses compile-time type information to avoid typechecks at
runtime.

>[...]

> Sure, it is all a matter of oppinion. Here's my oppinion:

> <oppinion>
> I find it pretty astonishing how little type safety LPC has.
> Essentially, all compile time checking is necessarily ignored at run
> time (well, with some effort you can determine when a variable is
> never affected by a remote object, and occasionally make some
> optimizations there, but that is high effort for essentially no
> payoff).

Wrong. There is no such "necessity", as I can demonstrate by supplying
a counter example, DGD. In particular, DGD's LPC->C compiler can map
LPC integers to C integers thanks to compile-time typechecking.

Incidentally, in MudOS it is not possible to determine whether a variable
is not affected, since store_variable() can affect even private inherited
variables.

> It is a shame that when the LPC type system was devised it
> was devised so poorly. Sure, there is some benefit to getting some
> errors caught at compile time. However, if you're not going to do a
> reasonable job at static checking, it is almost not even worth
> statically declaring types for LPC.

Now you are confusing the declaration of types at compile time for the
purpose of typechecking at runtime with compile-time typechecking.

> Basically, a lot of novices code
> in LPC, and requiring them to learn a notion of types may not really
> be worth the gain (This is hard to quantify, but Lima's experience is
> that mud building should have a much lower entry bar than LPC, as many
> people with great ideas who are non-programmers have too many high
> hurdles to jump before they can be productive. We see lots of people
> bail early on LPC, and IMHO, that's a bad thing. That's why we
> created a small compiled (to LPC) language just for area
> building... you don't have to extend yourself to learn LPC until it
> becomes necessary for some *very* complex task, by which time you have
> hopefully invested enough effort on your mud and learned enough
> programming basics that the hurdles are fewer and smaller).

I do not think that an appraisal of typechecking should be based on
the experience of novice programmers, especially if they program in
a different language.

> I think that a Henley / Milner type system would work pretty well for
> an LPC-like language... You would get very strong compile time
> checking, and the novice programmer would hardly have to learn the
> notion of type since there wouldn't in practice be too many cases
> where the type inferencer would fail.

You can't do Hindley-Milner type inferencing in a language like LPC
which overloads operators.

> </oppinion>

> > You are a major Java advocate, and I don't want to enter a LPC vs Java
> > discussion. I merely wanted to point out that you are again not giving
> > attention to the fact that the LPC dialect and implementation you are
> > basing your comments upon is just that... one particular case.

> In this particular case, George's example does indeed apply to all
> drivers.

Please speak only for the ones you know.

Regards,
Dworkin

[Kris Van Hees]

On 17 Sep at 22:49:39, John Viega wrote <JTV2J.97S...@adder.cs.virginia.edu> which contained:
<< Example of division of two call_other()'s by Descartes, and my commentary.>>

>
> This was exactly his point. Type checking in LPC is so poor that it
> doesn't check the return type of a call to a function outside the
> caller at compile time. There is no difference between MudOS and DGD
> here. Note that his example made sure to use external calls, because
> "foo"/"bar" doesn't compile anywhere that even a bit of static type
> checking is done. It seems to me that you thought he meant ALL string
> division compiles on MudOS, which is now what he was saying.

I did read George's example indeed in a different sense. However, it is a
very poor example for saying that LPC's compile time type checking is poor.
It is a very specific example of a language design choice where a rather
interesting flexibility has been given priority over type checking. This
particular case must be handled in runtime checking.

>
>> there is no way that
>> compile time type checking can take place in that case.
>

> Sure there could, but run-time type checking is still required, but
> LPC duplicates all its type checks at runtime already anyway,
> due to the rockin' cast / mixed crap.

No, there could not be any compile time type checking since the types are
completely unknown at the time of compilation. There are two main reasons
for this:

1. The this_player() function has a known return type, however it is
the generic 'object' type, and thus it doesn't provide information
on the definition of the object in which the functions will be
called. Hence it is impossible to get the prototype information.
2. Even if specialized types would be known, and thus this_player()
would be known to refer to a particular class, even then in the
LPC model there is not the slightest guarantee you can get the
prototype information, as it may not be loaded. Heck, the code
may even not have been written yet.

The casting requirements of MudOS under strict typed code made me hope that
MudOS does use the casting information for compile time type checking (and
the same for DGD). I actually haven't verified that, and it's been a long
time I checked the type checking code for either driver, so I simply don't
remember. I'll have a look (or if Beek and/or Dworkin can comment and put
up a description that would be nice too).

I fully agree that the 'mixed' type is a wonderful flaw in the LPC design,
and though it is actually useful in various cases, the use of it should
have been restricted massively. Abyss still retains 'mixed' in a limited
sense, to resolve some typing issues, however it is governed by strict
rules.

>
>> You are a major Java advocate, and I don't want to enter a LPC vs Java
>> discussion. I merely wanted to point out that you are again not giving
>> attention to the fact that the LPC dialect and implementation you are
>> basing your comments upon is just that... one particular case.
>
> In this particular case, George's example does indeed apply to all
> drivers.

Yes indeed, and thus my statement quoted above was in general, not just
for the division example he showed.

Aedil

[George Reese]

Kris Van Hees <ae...@ny.fnx.com> wrote:

: On 17 Sep at 22:49:39, John Viega wrote <JTV2J.97S...@adder.cs.virginia.edu> which contained:

: << Example of division of two call_other()'s by Descartes, and my commentary.>>
: >
: > This was exactly his point. Type checking in LPC is so poor that it
: > doesn't check the return type of a call to a function outside the
: > caller at compile time. There is no difference between MudOS and DGD
: > here. Note that his example made sure to use external calls, because
: > "foo"/"bar" doesn't compile anywhere that even a bit of static type
: > checking is done. It seems to me that you thought he meant ALL string
: > division compiles on MudOS, which is now what he was saying.

: I did read George's example indeed in a different sense. However, it is a
: very poor example for saying that LPC's compile time type checking is poor.
: It is a very specific example of a language design choice where a rather
: interesting flexibility has been given priority over type checking. This
: particular case must be handled in runtime checking.

A very specific case that is responsible for a large number of bugs
when running LPC code. Remember the question, about which language
produces more bug free code?

: > In this particular case, George's example does indeed apply to all
: > drivers.

: Yes indeed, and thus my statement quoted above was in general, not just
: for the division example he showed.

Why would you make a general comment like that when I was only making
one comment? It is kinda like cautioning me not to swim in shark
infested waters because I decided to take a swim in a pool.

[John Viega]

In article <EGpM4...@nonexistent.com> ae...@ny.fnx.com (Kris Van Hees) writes:

> 1. The this_player() function has a known return type, however it is
> the generic 'object' type, and thus it doesn't provide information
> on the definition of the object in which the functions will be
> called. Hence it is impossible to get the prototype information.

Yes, good point.

> 2. Even if specialized types would be known, and thus this_player()
> would be known to refer to a particular class, even then in the
> LPC model there is not the slightest guarantee you can get the
> prototype information, as it may not be loaded. Heck, the code
> may even not have been written yet.

Sure, but you could change this.

>
> The casting requirements of MudOS under strict typed code made me hope that
> MudOS does use the casting information for compile time type checking (and
> the same for DGD). I actually haven't verified that, and it's been a long
> time I checked the type checking code for either driver, so I simply don't
> remember. I'll have a look (or if Beek and/or Dworkin can comment and put
> up a description that would be nice too).

MudOS rechecks at run time.

> Yes indeed, and thus my statement quoted above was in general, not just
> for the division example he showed.

Gotcha. =)

[John Viega]

In article <5vrfm0$du3$1...@darla.visi.com> Felix A. Croes <dwo...@nospam.imaginary.com> writes:

> >[...]

> > Sure there could, but run-time type checking is still required, but
> > LPC duplicates all its type checks at runtime already anyway,
> > due to the rockin' cast / mixed crap.

In this case I actually meant to clarify for the scope of the whole
post that I was only talking about MudOS. I definitely don't pretend
to know emough about what DGD does, I am sorry about posting something
false...

[...]

> Incidentally, in MudOS it is not possible to determine whether a variable
> is not affected, since store_variable() can affect even private inherited
> variables.

That was exactly what I had in mind...

> > It is a shame that when the LPC type system was devised it
> > was devised so poorly. Sure, there is some benefit to getting some
> > errors caught at compile time. However, if you're not going to do a
> > reasonable job at static checking, it is almost not even worth
> > statically declaring types for LPC.
>
> Now you are confusing the declaration of types at compile time for the
> purpose of typechecking at runtime with compile-time typechecking.

No, I'm not. First, in the context of MudOS it does do compile time
type checking, but it rechecks everything at run time. Second, I
noted that was an opinion... I personally feel that it is pretty
worthless to declare types if you only check them at run time. If you
are getting such little benefit from your type system, then I
personally would rather have the code uncluttered by not having the
types at all.

[...]

> I do not think that an appraisal of typechecking should be based on
> the experience of novice programmers, especially if they program in
> a different language.

And I do not agree with you, especially since I would like to see a
mud language like LPC be an easy to use language for anyone who has
the creative bug.

[...]

>
> You can't do Hindley-Milner type inferencing in a language like LPC
> which overloads operators.

don't see where operator overloading came in at all. I certainly did
not mention it.

> > In this particular case, George's example does indeed apply to all
> > drivers.
>

> Please speak only for the ones you know.

I have heard from a couple people that tried it out that George's
example did indeed work on DGD.