[Encore] A Modest Proposal

[Daniel Jung]

Kevin,

Kevin Jepson wrote:
> With apologies to Jonathan Swift :-)

Are you telling me that the current enCore development is so poor in 
nature that everybody were better off if we just ate our own moos? :o

...

Seriously, Kevin, thanks for your concerns, the time to write them down, 
and the actual text you submitted for discussion. Thanks, too, for your 
encouraging words on the coding. All of that is highly appreciated.

I do, however, disagree with you in some points, even strongly in some 
of them. Please let me list and comment what I believe are some of your 
major points. I hope I got them right. I sharpened a few of them for 
conciseness reasons.


Your theses:
------------

1. enCore v5 is not a MOO
2. enCore v5 has lost the ability to generate an immersive environment
    (which is still present in v4)
3. If the stream of information is subsumed into WEB,
    spatiality is lost.
4. The text side of the MOO and the WEB side can be made to work better
    with the immersive elements. This goes for v4 but not v5.
5. Code in v5 has lost flexibility. It is not amenable to analysis
    by any reasonably competent MOO coder.
6. Only MOO code is object oriented. Moving away from MOO code means
    depriving participants from sharing a collaboratively created world.
    MOO code results cannot be achieved in other languages than MOO code.
7. We should fork the development into
    - one branch for creativity and gaming, and
    - one branch for administration of students



My reply:
---------

1. enCore v5 is not a MOO

    What's in a name? that which we call a MOO
    By any other name would work as sweet;
    So enCore would, were he not MOO call'd,
    Retain that dear perfection which it owes
    Without that title:--MOO, doff thy name;
    And for that name, which is no part of thee,
    Take all ourselves.

(OK, -- you started the literary references!)

We need to agree on what we mean by the word MOO. It's a mess, really, 
since everything seems to be called MOO: the lambamoo server, the 
programming language, the so-called database, the technology in general, 
the actual metaphorical/virtual world, etc.

If you mean by MOO 'a technology on the basis of datastreams between 
local telnet clients and a central CGI, enabling realtime 
communications', then you are right. enCore v5 is not a MOO anymore, and 
v6 will be so even less.

If you mean by MOO 'a collaborative environment based on spatiality 
(notably room, avatar and object metaphors), enabling realtime 
communications', then you are wrong. This is what we want to preserve, 
and as far as I can see, we have done just that.

Let's drop the name, Romeo, and see what we really want rather than 
clinging to a problematic name.

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

2. enCore v5 has lost the ability to generate an immersive environment
    (which is still present in v4)

I don't really understand that (but want to). Please give me some 
examples where v5 is less immersive (in structure) than v4. Please keep 
in mind a MODERN computer user, not someone used to a telnet client.

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

3. If the stream of information is subsumed into WEB,
    spatiality is lost.

I don't really understand that (but want to). WEB, notably HTTP (as 
opposed to telnet) is a protocol, channel, or means, of conveying 
information. I cannot see clearly why the protocol should and could 
affect the contents, notably the spatiality constructed in the head of 
the user.

True, the transgression from ASCII-based telnet chat to unicode-based 
HTML chat made it possible to use (a) foreign characters (b) 
images/icons, (c) colors and (d) font changes (and a lot more). This 
affects the way "the space is read" by the user. Movement messages 
(players, objects) are now grey by default to mark them as non-talk. In 
my opinion, this underlines spatiality even more. It is in any case 
indisputable that the MODERN user finds it easier to structure the the 
flow of information.

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

4. The text side of the MOO and the WEB side can be made to work better
    with the immersive elements. This goes for v4 but not v5.

Agree on the first part. But please give me a few examples where the 
current development has obstructed v4's ability to do just that.

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

5. Code in v5 has lost flexibility. It is not amenable to analysis
    by any reasonably competent MOO coder.

Please explain what you mean by flexibility. Just because someone finds 
it difficult to read v5 code doesn't mean the code is less flexible. Did 
I misunderstand you?

Please let me rephrase your statement:

    It is not amenable to analysis by anybody else than a reasonably
    competent MOO coder.

And that's exactly the point: If we keep on using MOO language to 
produce pages, we are not attracting potential new programmers. MOO 
language is not interesting to the common programmer. We are cutting our 
fist in the marked.

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

6. Only MOO code is object oriented. Moving away from MOO code means
    depriving participants from sharing a collaboratively created world.
    MOO code results cannot be achieved in other languages than MOO code.

No, no, and no.  :)

(a) MOO language code is NOT object oriented in the narrow sense of the 
word, although the acronym lets us believe so. A language like Python is 
OO from scratch, Java even more so, since it borrows the syntax from C++ 
(loosely speaking). A language like PHP has included OO since PHP4.

There are two languages involved in MOO as of today: (i) the moo server 
(lambdamoo), written in good ol' C, (ii) the MOO language in the verbs 
in the so-called database, written in MOO. Neither of them are OO 
(again, in the narrow, and programmer's, sense of the word). What is 
object oriented, is the structure of objects/artefacts in the 
representation of the virtual world, and maybe the fact that users can 
create entities (which more or less might live their own lives) called 
objects.

(b) Why would that be? Please explain. For users who have programmers' 
permissions, the language in which to write and read verbs would change. 
The result of these verbs (what they are doing to the virtual world) 
would not. For the common user (builder), nothing would change. The 
ideas of verbs and properties would of course still prevail. (Again, 
Romeo, if PHP calls it "script" and MOO calls it "verb", it is still 
DOING the same thing.)

(c) Please explain what PHP or Java cannot achieve, but MOO language 
can. The CGI (the lambdamoo C-files) is listening to a port on the 
server it lives on, and reacting to input. Example:

    If a user input begins with a double quote ("), lambdamoo replaces
    the quote with a 'say' and sends the string to the room the user is
    in, thus activating this room's 'say'-verb, which in return
    activates the present players' 'tell'-verb, which prints out
    something to them.

I cannot understand why we couldn't replace the language with another 
(better) language and still achieve the same thing.

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

7. We should fork the distribution into
    - one branch for creativity and gaming, and
    - one branch for administration of students

Hm. When I first read your mail, I thought: Let's answer him "Yes, and 
you are free to do that".

We have been through this discussion a lot of times, without really 
having been "through" it. enCore is composed of two layers, or ideas: 
The virtual world idea with rooms and objects and avatars in the center, 
and the real world idea with student enrollment, internet email and time 
zones. The latter is a layer on top of the first, and both ideas are 
competing. We know that.

But can't we do both? As a matter of fact, the consortium Steering 
committee had a meeting where it (provisionally) embraced the idea of 
strengthening both the accessibility/distributional idea (through 
migrating to another structure/language) AND the gaming/immersion idea 
(through developing virtual world objects and tools for setting up games).

So I would say, no, don't fork distribution. Fork development, and braid 
it to a common distribution that enhances both aspects. Users who don't 
want to play can use that as a better tool, and users who don't want to 
enroll can use that as a better tool.

I am in the progress of writing a document on this. Answering your email 
has helped me. Thanks. I am looking forward to futher discussion.


- Daniel