[Home] [Groups] - Message: [Prev in Group] [Next in Group]
20581: Re: [MUD-Dev] TECH: programming languages (was: Re: TECH: STL / Heaps, etc.)
[Full Header] [Plain Text]
From: Bruce Mitchener <bruce@puremagic.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 16 Aug 2001 07:44:59 -0600
References: [1] [2] [3] [4] <-newest
Organization: Kanga.Nu
Ola Fosheim Grøstad wrote:
> Bruce Mitchener wrote:
>> * Has anyone used Prolog or a logic language in their mud?
> Richard Bartle obviously?
Happen to know of any further information on this? How was it used?
>> * How about XSLT? (Anyone doing wireless and using this to
>> translate for the various systems?)
> You are probably better off buying somebody's product :-(.
For XSLT or for wireless? I only mentioned wireless as I knew of
some people using XSLT for such a thing. I personally have little
interest in wireless.
There are plenty of good XSLT libs available though under various licenses.
>> Or is it that most from-scratch muds by hobbyists are done with
>> the intent to learn C/C++/Java more than doing research into what
>> might make for a more effective new type of server?
> Not really sure how a different imperative implementation language
> is going to get you to a new type of server?
Languages impose constraints upon the space of what is easily
achievable and their assumptions shape the design of a system.
While many of the differences will be within the implementation,
that doesn't render them irrelevant.
Taking a simple example, if you're working with a language or
embedding a language which can be sandboxed, or otherwise secured to
allow user-programming in a way similar to MOO or Cold, you're going
to end up with an end result that would be significantly different
from one that didn't have the capability of offering
user-programming.
The implementation level differences are obviously significant as
well. Taking one project that I've seen, with a language that
supports garbage collection and method forwarding, Miro's managed to
create a really cool object persistence system that has large parts
that are entirely transparent to the server programmer. That's led
to a number of very different ways of looking at problems elsewhere
in the server and alternative ways of solving other problems because
the persistence system is a great enabling technology.
Another fun example would be E. With full capability-based security
at one's fingertips, some pretty cool features could be given to the
users.
Similarly, I know that my mindset changes depending on what language
I'm working in. I write different sorts of code if I'm writing in
ColdC, or C, or C++, or Objective C, or TOM, or PostScript, or ....
That changed mindset leads to different ways of solving problems,
some of which are sometimes visible to the end-user, others which
merely greatly change the internal implementation.
So, maybe I've misunderstood your comment.
- Bruce
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev