[MUD-Dev] TECH: programming languages (was: Re: TECH: STL / Heaps, etc.)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Bruce Mitchener wrote:
> 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?

I believe MUDDLE (spelling?) uses a variation of classic
prolog-style unification to do the computations. I assume one
important reason for going with LP is that he knew Prolog very well
from his AI-related work at Essex? I guess it is wasteful to
speculate as he happens to be on the list, but given the speed of
the computers at the time; I somehow doubt that one could make good
use of unifaction in a near real-time system in the 80's and early
90's...

I personally think that Prolog would be more useful as a subsystem.
gprolog seems to have C-interfaces, but I've never tried to
interface to C-code myself.  Datalog might be a lighter and better
alternative than Prolog, though...?

>>>  * 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.

I meant for wireless.  Consumers currently buy cell phones for
making phone calls and to use non-networked applications. A
networked game is a plus, not a necessity, so you get this expanding
set of devices with various technological limitations that you want
to support in the best possible way.  Besides, to get paid you are
at the mercy of the telecoms, their partners and their technology
frameworks.  Rather messy.  That is my impression anyway.

>> 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.

Hmm... I think most imperative languages are rather Algol like, but
I guess you are right in the sense that a lot of languages produce a
lot of disturbing source-code bloat when you try to use certain
approaches.  Efficiency considerations and the lack of design in C++
which leads to horrible function objects is one example... (For some
reason it seems to be modern to promote verbosity as if that
improved legibility; STL, Java.)

If set-oriented languages had been efficient... :-) Dream on.

> 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.

Yes, of course, but not exactly what I would think of as
implementing a new type of server? And you are generally better off
writing a dedicated language with good context dependant
expressiveness IMO.

> 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.

I have to admit that state persistence isn't quite what I was
thinking about when you said new type of server. I was more thinking
along the lines of expressiveness and dynamics that would yield new
experiences for the user. Not a new framework to implement existing
world designs and approaches.

> 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 ....

Yes, I agree with that. I.e. a slow high level language with
powerful abstraction mechanisms is sometimes better for thinking
abstractly (in C i tend to think how it translates to machine
language). However, if I work from a design done on paper, then I
don't think it would make all that much of a difference for me if I
work in C, C++, Simula, Beta... Well, dealing with objects in Forth
and Postscript probably is a bit painful...

> That changed mindset leads to different ways of solving problems,
> some of which are sometimes visible to the end-user, others which

I guess I could agree if you primarily argue the psychological
issues.

--
Ola  -  http://www.notam.uio.no/~olagr/

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev