Looking for scripting suggestions
Spam MeNot
application. What I want is fairly simple, but difficult to locate.
First, the syntax has to be simple and comfortable. I need for
non-programmers to be able to generate these simple scripts.
Second, the language should be non-typed. This makes it easier for
new users to pickup.
Next, and this one is a bit strange, I don't want it able to do a
great deal of processing. The idea is that these scripts could do
simple conditional checks and validations on data entry, but any
serious processing would be delegated to a remote service.
Also, it needs to be embeddable and simply extendable. I will be
wanting to add access to certain functions in the host environment
that the script is running in. The main application is written in
C/C++.
Finally, it should be small. I'm not looking for a "DO EVERYTHING"
type language.
As I started poking around, I thought perhaps JavaScript would do the
job. It's syntax is familiar (to web developers and programmers) and
has some of the other features. The SpiderMonkey version from
Mozilla, but it was a bit cumbersom to use. I also looked at NJS.
This one has potential, when the full port to C is complete.
I also though strongly of TCL. This is what it was originally
designed for, but it is growing into a full platform of it's own.
Also, though I like TCL, it's syntax is a bit odd.
Lastly I considered a flavour of BASIC. This one has potential. As I
want the scripts to manipulate data fields and call other methods, I'm
not certain I need any form of OO.
So basically, if you were developing an application that could load
different control pages (think of a web browser that loads different
web pages) and you wanted to be able to embed simple
control/validation scripting into the pages, what would you consider
using for a language?
J.
[I'd use an old version of TCL. -John]
Eric Tetz
> I'm looking for a scripting library that can be embedded in an
> application. What I want is fairly simple, but difficult to locate.
I recently went through the exact same search. I whole heartedly recommend
Lua. www.lua.org
> First, the syntax has to be simple and comfortable. I need for
> non-programmers to be able to generate these simple scripts.
Lua was designed to be easy for non-pros to use. Clean, Pascal-like syntax.
> Second, the language should be non-typed. This makes it easier for
> new users to pickup.
Lua.
> Next, and this one is a bit strange, I don't want it able to do a
> great deal of processing. The idea is that these scripts could do
> simple conditional checks and validations on data entry, but any
> serious processing would be delegated to a remote service.
Not Lua. :( Lua is a full featured language.
> Also, it needs to be embeddable and simply extendable. I will be
> wanting to add access to certain functions in the host environment
> that the script is running in. The main application is written in
> C/C++.
Lua was designed to be embedded and easily extensible.
> Finally, it should be small. I'm not looking for a "DO EVERYTHING"
> type language.
Well, Lua is small. Around 60Kb for the whole language, including it's
standard library. If you leave out the standard library (leaving only
application defined functions), and leave out the scanner/parser/code
generator (you would have to pre-compile scripts to byte-code), it can be as
small as 24Kb. Yet it is a full-featured language.
> As I started poking around, I thought perhaps JavaScript would do the
> job. It's syntax is familiar (to web developers and programmers) and
> has some of the other features. The SpiderMonkey version from
> Mozilla, but it was a bit cumbersom to use.
I liked JavaScript, too. Especially the way it uses associative arrays as
the uber-data structuring mechanism (it's similar to Lua in this regard).
But, as you discovered, it's a bit large. The Mozilla implementation will
add around 300KB to your application. The Mozilla implementation is not
very fast, either, though Microsoft's implementation flat-out *screams*
(must be JIT).
> I also though strongly of TCL. This is what it was originally
> designed for, but it is growing into a full platform of it's own.
> Also, though I like TCL, it's syntax is a bit odd.
TCL, besides being large and slow, also happens to be a pretty crappy
language IMHO. For details, including Richard Stallman's "Why you should not
use Tcl", see:
http://www.people.virginia.edu/~sdm7g/LangCrit/Tcl/
> Lastly I considered a flavour of BASIC. This one has potential. As I
> want the scripts to manipulate data fields and call other methods, I'm
> not certain I need any form of OO.
Lua is procedural, but has meta-mechanisms that allow one to do OO.
> So basically, if you were developing an application that could load
> different control pages (think of a web browser that loads different
> web pages) and you wanted to be able to embed simple
> control/validation scripting into the pages, what would you consider
> using for a language?
Lua is tiny, fast, and powerful, has highly portable source, is easy to
embed, and is easy for newbies to learn; it has been nothing but a pleasure
to use.
To see what the code looks like for your self, check out the Great Computer
Language Shootout.
http://www.bagley.org/~doug/shootout/
Besides the performance comparisons, this page has source for several
routines implemented in a dozen different languages. You can easily compare
Lua and Tcl source here.
Cheers,
Eric
Joachim Durchholz
> So basically, if you were developing an application that could load
> different control pages (think of a web browser that loads different
> web pages) and you wanted to be able to embed simple
> control/validation scripting into the pages, what would you consider
> using for a language?
Not sure about the page embedding aspect, but apart from that I'd go
for Rexx. Simple syntax, simple rules, built for pushing all "real
processing" into external calls. More information can be found on
http://www.rexxla.org/; the page to free interpreters can be found by
following the "Links" and "Free" links. (Just dug this up via Google,
I'm not affiliated with RexxLA.)
Regards,
Joachim
Joshua Levy
> I also though strongly of TCL. This is what it was originally
> designed for, but it is growing into a full platform of it's own.
> Also, though I like TCL, it's syntax is a bit odd.
> [I'd use an old version of TCL. -John]
I'd use a new version of TCL, and cut out all the stuff you
don't want the users to have. Even last time I looked, the
core embedable language was not that big. Even better, it is
easy to cut out commands you don't want, and that can make
it even smaller. I agree that the syntax is a bit odd, I
think you will find that most of the oddness is in control
flow that you would not use in a simple data checking type
application.
Joshua Levy
George R. Goffe
It's probable that you've already made your decision(s) about this
topic but I thought I'd put my two cents in anyway.
There is a "product" named Regina which is maintained/developed by
Mark Hessling that is prety darn close to the rexx standard. His
website is http://www.lightlink.com/hessling. Regina/rexx is VERY
POWERFUL and he has one or more APIs that can be imbedded in an
application. Check out his site if you're at all interested. This is
way cool software.
Regards,
George...
Jim Lawless
> So basically, if you were developing an application that could load
> different control pages (think of a web browser that loads different
> web pages) and you wanted to be able to embed simple
> control/validation scripting into the pages, what would you consider
> using for a language?
I might build in a simple stack-based RPN language with minimal
syntax. I have a core interpreter I use that I can throw in to
existing applications for simple scripting chores.
I've extracted this core into a sample interpreter:
http://www.radiks.net/~jimbo/stack.zip
This archive contains a stack interpreter win32.exe with C source and
three sample scripts. The commands are inlined in a big if-else
construct in the interp() function. A circular buffer is used to hold
temporary strings to avoid complex garbage-collection.
Jim Lawless
ji...@radiks.net
http://www.radiks.net/~jimbo
[Sounds like forth. -John]
Ron Pinkas
> application. What I want is fairly simple, but difficult to locate.
>
>
> Finally, it should be small. I'm not looking for a "DO EVERYTHING"
> type language.
Well, what is your view of small?
I have developed a script engine for the Harbour/Clipper language
(dBase/FoxPro superset). It is written in Harbour
(www.Harbour-Project.org) which is compiled into ansi c.
It can be available in different embeddable forms. I can forward a COM
dll(900K), compiled with MSVC, with a sample C++ client.
Ron
[Maybe I'm showing my age, but 900K isn't small. A 24K TCL interpreter
is fairly small. A 2K TRAC interpreter is definitely small. -John]
Manoj Plakal
> I'm looking for a scripting library that can be embedded in an
> application. What I want is fairly simple, but difficult to locate.
>
> First, the syntax has to be simple and comfortable. I need for
> non-programmers to be able to generate these simple scripts.
>
> Second, the language should be non-typed. This makes it easier for
> new users to pickup.
>
Have you considered Python? The base language
itself is simple, clean and easy for beginners and
non-programmers. It's dynamically typed and
easily embedded and extended.
Several folks have ported Python to hand-held
and embedded devices by stripping out a lot
of modules and things like FP math.
The Pippy project (http://www.endeavors.com/pippy/)
has a version of Python that runs on PalmOS (with
4MB of memory) while "Deeply Embedded Python"
(http://www.abo.fi/~iporres/python/) have stripped
the Python VM+libraries down to around 120KB
for a Hitachi SH1 board with 256KB RAM.
Manoj
Fabrice Medio
> I'm looking for a scripting library that can be embedded in an
> application. What I want is fairly simple, but difficult to locate.
>
> First, the syntax has to be simple and comfortable. I need for
> non-programmers to be able to generate these simple scripts.
OK for this particular constraint.
> Second, the language should be non-typed. This makes it easier for
> new users to pickup.
>
> Next, and this one is a bit strange, I don't want it able to do a
> great deal of processing. The idea is that these scripts could do
> simple conditional checks and validations on data entry, but any
> serious processing would be delegated to a remote service.
Did you think about Lisp-ish languages, most probably Scheme, to
fulfill this task ? Weak typing, extremely simple syntax and a very
small memory footprint makes it a scripting language of choice.
> Also, it needs to be embeddable and simply extendable. I will be
> wanting to add access to certain functions in the host environment
> that the script is running in. The main application is written in
> C/C++.
There are many free Scheme implementation written in C, many of them
being specifically targetted at being extension/scripting
language. The GNU Guile project may in the spirit of what you're
looking for (see http://www.gnu.org/software/guile/)
> Finally, it should be small. I'm not looking for a "DO EVERYTHING"
> type language.
Funny enough, some small (and canonical) Scheme implementations fit in
2000 lines of C code. You might even want to write it yourself :)
Fabrice
--
Fabrice Medio
<fm...@chez.com>
George B. Smith
> TCL, besides being large and slow, also happens to be a pretty crappy
> language IMHO. For details, including Richard Stallman's "Why you should not
> use Tcl", see:
>
> http://www.people.virginia.edu/~sdm7g/LangCrit/Tcl/
This is, IMO, a very cheap shot. The version of Tcl that RMS critqued
bears little resemblence to a modern Tcl, ie 8.3.3.3 or 8.4a3, in
terms of features and most especially performance. People who are
still pointing out this very dated argument from RMS are doing a
disservice to inquiring minds.
George B. Smith
g...@k9haven.com
Eric Tetz
Hmmm... I didn't mean it as a cheap shot; I think the majority of that
article is quite relevant today. The fact that a bunch of new stuff
has been tacked on to TCL, and that more efficient implementations
exist, cannot cure fundamental flaws in the language. You don't make
an octopus by nailing extra legs onto a dog.
TCL's author readily admits the language is flawed, "Some of the
flaws, like the lack of a compiler and the lack of module support,
will get fixed over time. Others, like the substitution-oriented
parser, are inherent in the language. Is it possible to design a
language that keeps TCL's advantages, such as simplicity, easy glue,
and easy embedding, but eliminates some of its disadvantages?" The
answer to this last question is a resounding YES!! It has been done
many times over since Ousterhout wrote those words.
Without even getting into TCL's technical issues, lets look at the
flaming hoops TCL makes you jump through for even simple operations:
proc fib {n} {
if {$n < 2} {
return 1
}
return [expr {[fib [expr {$n-2}]] + [fib [expr {$n-1}]]}]
}
The expression in that second return statement is just absurd. And
this example is *trivial*. What happens when the task at hand becomes
more complicated? Obfuscated C doesn't look so bad anymore. And it
*does* get more complicated; one of Stallman's primary points is that
regardless of your intentions, the scripting language *will* be asked
to do more than you originally planned.
Here's Lua, Ruby and Python versions of the same code:
function fib (n)
if n < 2 then
return 1
end
return fib(n-2) + fib(n-1)
end
def fib(n):
if (n < 2):
return(1)
return( fib(n-2) + fib(n-1) )
def fib(n)
if n < 2 then
1
end
fib(n-2) + fib(n-1)
end
Neat, clean, and to the point. I recommended Lua because it happens to
have a small implementation and is fast.
Unfortunately for me, I'm stuck with TCL. I'm work on a network test
tool. The primary author chose TCL as the scripting language because
(a) other network test tools use it, so the testers were likely to
already know it, and (b) TCL was only to be used for configuration and
very light scripting, with all the heavy lifting done in C++. It
didn't work out that way. We now have a large parts of our regression
suite written in TCL. Some of it is horrendous (through no fault of
the testers). Stallman's words could not have been more true.
IMO, TCL is perpetuated by the momentum of its large user-base, and
not by the technical merits of the language. So why continue to foist
TCL on unsuspecting newcomers, especially when better alternatives
exists? It's a dirty trick, and people will only resent you for it
later. ;)
Cheers,
Eric