<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] Languages for MUD drivers --> <!--X-From-R13: Qlaor eh Fnera <plaorNzhd.bet> --> <!--X-Date: Wed, 17 Nov 1999 23:44:03 -0800 --> <!--X-Message-Id: 199911180738.BAA18605@laurel.actlab.utexas.edu --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] Languages for MUD drivers</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:cynbe@muq.org"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00353.html">Previous</a> | <a href="msg00355.html">Next</a> ] Thread: [ <a href="msg00344.html">Previous</a> | <a href="msg00361.html">Next</a> ] Index: [ <A HREF="author.html#00354">Author</A> | <A HREF="#00354">Date</A> | <A HREF="thread.html#00354">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] Languages for MUD drivers</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: Re: [MUD-Dev] Languages for MUD drivers</LI> <LI><em>From</em>: Cynbe ru Taren <<A HREF="mailto:cynbe#muq,org">cynbe#muq,org</A>></LI> <LI><em>Date</em>: Thu, 18 Nov 1999 01:38:23 -0600</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> "Laurent Bossavit" <laurent#netdive,com> commented: | Cynbe sez : | | > That's pretty close to the set of design goals I've used in the | > Muq design and implementation. | | Hullo Jeff. IIRC I think Muq lacks the distributed aspect ? Well, it wasn't in the original 1991 design specs, but it has crept in over time. One has to check back every 3-4 years to see what is new. :) (Also, I should update the docs thoroughly soon: I've been concentrating on getting the code solid in recent years.) The current level of distributed support falls considerably short of what I would ideally like to offer, but I believe the current Muq Micronesia worldkit demonstrates by construction that the current level of Muq server support for distributed operation is sufficient to achieve interesting and useful levels of distributed operation. I expect some performance issues will need appear and need to be resolved as Micronesia moves from theory to practice. For example, Diffie-Hellman shared secrets are transparently computed and stored for each local-user/remote-user pair which wind up communicating and this sort of public-key stuff is CPU intensive (and my big-int stuff probably half as fast as it could be) so there may be some start-up lag when encountering a large batch of new users. There are also as-yet-unresolved issues in Muq at the intersection of OOP and distribution, such as how to handle a local instance of a remote class, or class definition objects replicated on multiple servers (standard library classes, for example): The current Muq Micronesia worldkit codes around these issues in order to get something usable out the door in the same millenium the project started. :) | I liked Muq a lot at any rate, though the source code turned out to | be a bit too syntactically remote from my Java/C++ experience for | comfort. Are you still actively working on Muq btw ? Or doing | something else now ? Well, I just accepted a job, so I'll be doing less on Muq next year than I did this year. :) But I'm focussed on a version 0.0 first-beta 99Dec29, and we should start getting actual experience with it after that. I've also added OpenGL bindings and a C-ish syntax softcode language of late. | I don't quite agree - the feeling I get from my recent overview of | languages with support for distributed programming is that given a | language with proper structures one can 'think about' distributed | processes more clearly than otherwise. IOW, languages are about | semantics as well as syntax. I was merely suggesting that most of the value-added in your requirement set is unrelated to syntax issues. E.g., by limiting yourself to "languages", you might be overlooking a distributed operating system or computation project which in fact meets your needs nicely, except for needing to have your choice of Python or Scheme or whatever bolted to it -- a relatively trivial task these days. | Definitely not obvious, possibly not true literally - I migh be able | to express this better if I work at it. Of course the implementation | of a distributed, persistent, mutable, reflective, secure system with | a programming language which makes these features available (and | coherent) is not likely to be written in that language. (E.g. E is | written in Java.) Having just come off spending a year of my professional programming life working in Java, this is one of the things that makes me a bit skeptical of E :-/ | I know from experience that dynamic compilation to Java bytecode | (hence to native code) of a 'scripting' language is workable. Yes, one of the things the Java (Oak) design crew did very nicely (imho) was design to promote this sort of ease of compilation -- definitely a Java strength. Which makes sense, Oak was intended for embedded programming -- making toaster ovens sit up and talk &tc -- where CPU efficiency is critical. | I'm waiting to see how integrating persistence works out. Activerse tried doing virtual world persistence in Java shortly before I arrived and finally gave the entire thing up in disgust as a bad job. Java was -not- designed to be a persistent, distributed or multi-user (or text-oriented) language, and it shows. It is also a big enough juggernaut that changing its direction and structure at this point is pretty iffy. My own experience with Muq design and implementation has been that doing a good job on persistence has easily been the hardest part of the design and implementation effort to date, with the hardest efficiency issues and most pervasive effects through the rest of the system: This inclines me to be skeptical of efforts to retro-fit persistence after-the-fact to a design and implementation. But we shall see -- perhaps Java will pleasantly surprise me. :) | I'm a bit frustrated at how many M* "projects" there are out there | which seem to have gone dead at various points between the design | stage and half-hearted prototype implementations, or on which there | exists so little recent information that they might as well be dead. | To name a few, Lithium (never got past design), Doug Orlean's unnamed | thesis project (see <A HREF="http://www.ccs.neu.edu/home/dougo/mud/">http://www.ccs.neu.edu/home/dougo/mud/</A>), or in | the 'no info' category Matrix, Neverworld or Mu (see previous URL for | links). I'm wondering why that should be - especially as M* servers | should by nature be more visible on the Internet than other kinds of | programming projects. Or is it that there is no tenable middle ground | between IRC and Quake and that text-based social virtual realites, as | a class of software, are doomed to fail ? I've wondered similar things myself: When I started Muq seven years ago, my main reference competitors were MOO and Cold, and that is still pretty much it now, give or take Java-based possibilities. To my mind, probably contributing factors are: (1) The current crop of servers were basically all hacked up by an undergrad or two while in college. I think we've reached the limit of what can be achieved in that mode: Writing a new server from scratch in that mode and producing something noticably -better- than existing servers is not really practical. (2) Doing a quantum-leap-better next-generation virtual world server from scratch now requires prohibitively broad expertise: TinyMUCK was built from a quick-and-dirty ("lousy") db, compiler, bytecode interpreter &tc &tc. Implementing all of those things -well- (i.e., enough better than the existing crop of servers) is getting to be a task well beyond the abilities of the first-time undergrad hacker crowd who have traditionally provided new hackers. (3) Current server implementations have reached their design limits: The easy hacks have been done, and significant progress really depends on starting with a fresh design -- which is a major barrier from both a compatibility and a coding viewpoint. If Muq succeeds, it may wind up being seen as the last harrah of the lone-hacker school of new server development: Seven years in alpha and a quarter million lines of code is clearly stretching the limits of this development model. Even if it fails completely, it might wind up looking like the reductio ad absurdum of that line of development. :) It looks to me as though future quantum leaps forward will require some different model of development. Assembling systems out of parts such as Java class libraries is attractive, but seems to work better in theory than in practice, so far: Aside from Java's fading immaturity problems, it turns out to be difficult to just add a class library that makes everything nicely persistent. Possibly this will prove true only for a couple of critical things like persistence? If so, once they are resolved, this might be the model of the future: One person can grab a few million lines of code and assemble something dramatically better in an afternoon. We can dream. :) Massively multi-programmer projects like GNOME are another possible way to break through to a new level. Unfortunatly, the winning new designs of the past all seem to be done by one or two person teams: The Chinese Army approach so far seems limited to problems where the design is essentially already done (as POSIX did for the Linux kernel) or "embarassingly parallel", consisting of a host of fairly obvious small parts -- GNOME seems to satisfy both requirements, in that it is largely a clone of an existing model made of many small parts. Figuring out how to get a new design right -- and then excite a critical mass of programmers to implement it mass-hacking style -- remains I think an unsolved problem, if not perhaps an insoluable one. | So when are we going to see new M* technology that really pushes | the envelope? 99Dec29 :) ;) :) Cynbe _______________________________________________ MUD-Dev maillist - MUD-Dev#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00353.html">RE: Distribution schemes (was Re: [MUD-Dev] Languages for MUD drivers)</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00355.html">Re: Player statistics calculation (Was: Re: [MUD-Dev] code baseinquiry)</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00344.html">RE: [MUD-Dev] Languages for MUD drivers</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00361.html">RE: [MUD-Dev] Languages for MUD drivers</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00354"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00354"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: [MUD-Dev] Languages for MUD drivers</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00265" HREF="msg00265.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe@muq.org">cynbe@muq.org</a>, Tue 16 Nov 1999, 05:12 GMT </LI> <LI><strong><A NAME="00317" HREF="msg00317.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Laurent Bossavit <a href="mailto:laurent@netdive.com">laurent@netdive.com</a>, Wed 17 Nov 1999, 23:19 GMT </LI> <LI><strong><A NAME="00351" HREF="msg00351.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe@muq.org">cynbe@muq.org</a>, Thu 18 Nov 1999, 07:34 GMT </LI> <LI><strong><A NAME="00344" HREF="msg00344.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe@muq.org">cynbe@muq.org</a>, Thu 18 Nov 1999, 07:34 GMT </LI> <LI><strong><A NAME="00354" HREF="msg00354.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe@muq.org">cynbe@muq.org</a>, Thu 18 Nov 1999, 07:44 GMT </LI> <LI><strong><A NAME="00361" HREF="msg00361.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe@muq.org">cynbe@muq.org</a>, Thu 18 Nov 1999, 17:01 GMT </LI> </ul> </LI> <LI><strong><A NAME="00256" HREF="msg00256.html">[MUD-Dev] code base inquiry</A></strong>, Ilya, Game Commandos <a href="mailto:Ilya@gamecommandos.com">Ilya@gamecommandos.com</a>, Tue 16 Nov 1999, 01:19 GMT <UL> <LI><strong><A NAME="00278" HREF="msg00278.html">Re: [MUD-Dev] code base inquiry</A></strong>, Lars Duening <a href="mailto:lars@bearnip.com">lars@bearnip.com</a>, Wed 17 Nov 1999, 02:18 GMT <UL> <LI><strong><A NAME="00285" HREF="msg00285.html">Re: [MUD-Dev] code base inquiry</A></strong>, Travis S. Casey <a href="mailto:efindel@io.com">efindel@io.com</a>, Wed 17 Nov 1999, 16:31 GMT </LI> </UL> </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>