Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2000:
[Freeciv-Dev] Re: Plans for 1.12
Home

[Freeciv-Dev] Re: Plans for 1.12

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Dan Sugalski <dan@xxxxxxxxx>
Cc: Freeciv Dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Plans for 1.12
From: Tony Stuckey <stuckey@xxxxxxxxxxxxxxxxx>
Date: Mon, 26 Jun 2000 13:04:11 -0500

On Mon, Jun 26, 2000 at 01:38:22PM -0400, Dan Sugalski wrote:
> Perl's reasonably simple to embed into an existing application, so that's 
> not a big deal. Given the feelings folks have for particular languages 
> (We've had perl and Scheme. Python'll probably be next, then someone'll 
> want C for speed) it might be better to come up with a general API and 
> dynamic loading scheme and let whoever wants to embed things just go do it.

        People who use C are smart enough to realize that it's really dumb
to use it as a scripting language. :)
        The big argument with scripting languages is whether to use a
general purpose one, or an application-specific and defined one.  Both have
good and bad points.

        I have a residual hatred of Scheme from my college experiences with
it.  I prefer both LISP and C to Scheme.

> Most of the folks that'll use this won't really care what language it's 
> in--they'll be using black box scripts and probably just make sure that the 
> scripting engine they need (be it perl, python, scheme, TCL, or whatever) 
> is installed.

        Right.  Most people won't care.  The big issue with scripting
languages at all in commercial games is that less than 1% of your players
ever want to modify the game.  Very little reward for a relatively large
effort in game design/programming/quality assurance terms.  And there's the
continuing hope/myth that a well-defined and programmed game won't *need*
the kind of massive repetition that scripting languages address.
        Even of those who care, most will ignore a language with a tortured
syntax.  PERL can certainly be cryptic and lame.  An application defined
language can look more like:

        Set goto of unit 15 to find_nearest_city()
        or
        Tell Howitzer at 12,17 to attack Rifleman at 12,18

        Or something that is plainly obvious what it does.  Expressivity
does not have to be incredibly limited.  One case that the general-purpose
language people have to make is that the benefits (people already know it
from elsewhere, proficiency in the language is useful elsewhere, etc) are
greater than the clarity and specificity benefits that a proper
application-defined language can provide.
-- 
Anthony J. Stuckey                              stuckey@xxxxxxxxxxxxxxxxx
"And they said work hard, and die suddenly, because it's fun."
        -Robyn Hitchcock.



[Prev in Thread] Current Thread [Next in Thread]