Re: Circle 4.x wish list

From: Thomas Arp (
Date: 11/22/02

From: "Mysidia" <jmhess@I-55.COM>
<from former reply>
> > > >4. Add Oasis/Dg Scripting.
> > > Oasis: Nay.
> > > DG Scripts: Undecided.
> > > Embedding Perl/Python/etc.: Aye.
> > [snip]

Whether or not DG scripts should be part of the stock distribution
is up to the circle developers, but I think - as current developer
of dg scripts - that if it's included, it should be optional.

The list above (and I believe a previous post to the list) seem
to suggest that the olc system will be made modular, especially
concerning scripting languages. I believe this is the way to go.
Even more so, when we see mails like yours, speaking fondly for
embedded 'outside' scripting languages like perl, python, lua, etc.

As long as people might want to use another scripting language,
I believe that's reason enough for not forcing anyone to use
dg scripts. Let us who like it enjoy it, though :)

> >
> > Feh, at that point just stick to the spec_proc stuff.  The point
> > is to create something easy for non-coder world builders to use.
> >
> > Personally, most scripting languages I've seen are not a whole lot
> > easier to use then some full programming languages, so I've never
> > really cared much for scripting.
> In terms of `preferring a language' or not, that is not very important.
> The reason I say 'eww' to perl or java interpreters is they generate
> a large footprint: a javascript interpreter is fairly small, and using
> it would generate less overhead.
Having had a look at lua 4.0.1, the complete extra code amounts to about
700KB. lisp (gcl2.4.3) is roughly 12MB, perl 5.8.0 takes up a stunning 48MB
and python 2.2.2 is 29MB. The corresponding number for dg scripts is 790KB,
and with that it already has ten times the funtionality of the lua package
currently available. I wasn't able to find a version of javascript which
was both multi-platform compatible and free.

> Simple is good, and perl is far from simple, but javascript and lisp
> are close.
> No, that's not the point.  Your goals are apparently different.
> I would like to see spec procs completely replaced with stored procedures.

Me too.

> I view an embedded script interpreter not as a tool whose purpose is
> to help beginners but as a tool for making the system more modular:
>   o Procedures can be created/destroyed/edited without restarts
This is one of the main purposes of scripts, along with the next paragraph:

>   o There is no risk of errors procedure coding crashing the mud by
>     causing buffer overflows or null pointer exceptions: in the worst
>     case, the stored procedure breaks.
<snip of stuff general for all scripting languages>
>   o My contention is that dg scripts is actually not easier to learn
>     than javascript, perl, or lua (for instance): that i've seen, dg
>     scripts can actually look quite convulated and _more_ confusing
>     than actual program code.

Functionality comes at a price. Seen from my perspective most shell
scripts and perl scripts look like greek[1]. I've never seen a lua script,
so I figure it'd be the same.
Some of the syntax is under revision, though, since some find it confusing.
DG scripts don't handle arrays well yet, so those are next[2] :)

>   o If it's possible to support 'interpreter' plugins, that would
>     be a most useful approach, since implementors could then "choose their
>     own scripting language" as it were by choosing the plugin they like.

The big problem with this approach is the limitations pushed onto
people who doesn't work off a server with a lot of scripting languanges
installed, or the people compiling on a windows machine, or people with
limited drive space. People, who are better off with a featurefull
internal programming language than with embedded scripts. After all,
it could be made as simple as a #define.


[1] No offence meant, greek people. I just can't read it.
[2] After I release a clean pl 9 patch, of course.

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT