Slashdot Mirror
Lightweight Scripting/Extension Languages?
Andy Tai asks: "Extension languages are designed to be embedded in applications to support customization of the application behavior. Common scripting languages, like Perl and Python, are fairly 'large' with powerful run-time engines and libraries and are widely available and 'script' writers usually assume their stand-alone existences in the deployment environment. However, if one is looking for a language that's small enough so its source can be embedded in the distribution of and built as part of the application, Python and Perl may be 'overweight.' For the real lightweight choices there are Lua and Tinyscheme. Are there others? What are people's preferences and opinions regarding lightweight extension languages?"
Is PHP/Perl/Python too big? Just use them. I don't care about a couple more megs of system RAM. RAM is cheap. Learning a new language takes time.
Unless there are extremely good grounds for using some annoying new/odd language, use something mainstream.
God knows the words "lightweight" and "Gnu" don't generally go together, but how about Guile?
Its easy to learn and use (very good if the people using our embeded language are not programmers). Its mature, supposed to be extensible, and if you decide you need something more powerful later on even the current full verion is not that bloated.
Just how much customising do you need?
From my experiance if you only need a little customisation then you can do most of that stuff from a config file, .ini if you want it to be easy to edit, xml if your going to write a gui to do it or your users are compertant. Any more than that your better off going with something like python or perl, they are widely known, and have rich libraries to let the people using the app do some really imaginative things.
The other thing that you can do is write your app in such a way that it is easy for scripting langs to get there hooks into. For example, on windows you can do this by providing com interfaces to all the things you want to have control over, then you can use any lang you want to control your app.
Is usually a sign that you are using too low-level a language for the application itself. There is no reason you can't write your whole app in something like Python (or better yet, a compiled high-level language).
I can see why you might want to stay with C/C++ for a major commercial application (not because of speed reasons, but because the maturity of the implementations of alternative high-level languages) but it pains me to see tons of OSS software, especially non-speed-critical GUI apps, still being written in C!
A deep unwavering belief is a sure sign you're missing something...
ECMAScript/Javascript seems like a logical choice. it was made for just that - embedding. It's quite small to implement, and there are many opensource implementations out there already. It can be procedural or OO, and everyone knows how to use it if they've done some basic web work.
It's sufficiently C-like to suit anyone who has done C/C++/Java/Perl/... but high level enough to be a feasible extension language.
Of course it depends on what type of person you expect to use your extension language. Are they programmers?
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
i recommend you look at paxscript.
it's the most complete and quickest of any embedded source stuff that we've investigated.
supports basic, c, objectpascal (ie delphi) and javascript.
not free, but you get the source when you purchase it (US$179).
delphi and borland c++ builder only.
nostrils
didn't see anyone else mention it, so i thought i would.
REBOL is a ridiculously simple and easy-to-learn web-oriented language. so easy, in fact, that i wrote a fully-functional IRC dice bot in under 400 lines, overnight. and if that weren't impressive, then might i add that i was running on ZERO caffeine, learning the language for the first time, learning IRC Client protocol for the first time, and came up with a few unusually witty statements and insults to boot?
now the bad part: REBOL is not open source. poo. (i really was a bit disappointed.) but REBOL/Core is free (for any use, i gather), and the license fees for View and Command seem rather reasonable.
the nice part: it has been ported to and runs on about 43 platforms, last i checked, and is light enough that the executable weighs in at around 250kb for the win32 release. (haven't used the other platforms, so no comment.)
it runs on just about every unix i've heard of, on every relatively common configuration, and works beautifully and seamlessly. and, after a quick glance, i see it runs on serveral major embedded systems, including WinCE, QNX, and Linux, and will even run on my friend's dated Amiga.
enjoy and happy coding.grey wolf
LET FORTRAN DIE!
TinyPerl
Error: PANTS NOT FOUND. Press <F1> to continue.
ficl.sourceforge.net
A portable object oriented forth at less than 100K for a full implementation, able to handle calls from your apps as well as call your apps fgunctions or other dll's.
Under a BSD-ish license.
The upside:
1) Its tiny
2) The forth code you write will be tinier
Downsides:
1) You need to learn forth (I mean properly) to appreciate it.
Forth is unlike most other languages, it was designed to avoid the debug, recompile cycle that is so common.
Sam
blog.sam.liddicott.com
I've been working on a system for embedding JS in KDE apps (amongst other reasons it is a about 1/10 the size of a python interpreter). You can find lots of information at http://xmelegance.org/kjsembed. The interpreter in KDE has no dependency on KDE/Qt or anything else so you might find it usable in your app.
I guess atai must have submitted the same question here as well, but the "original" discussion took place on advogato:
http://www.advogato.org/article/735.html
It would be useful if he could state what his requirements and limits are, in detail, because that's a very necessary part of evaluating what would work.
http://www.welton.it/davidw/
Well you're not obligated to provide the libraries. For instance, Blender, which uses Python, did not include Python libraries ; however it was possible for people which really wished it, to set paths to point to libraries. Forcing the users to learn a new language, just to cut the size of the distribution is misguided IMHO. Just provide the extension language (& support) as an optionnal individually downloadable shared library.
"...learning LUA takes exactly 1 hour."
I couldn't read the reference manual in one hour. I couldn't learn the quirks of co-routines in one hour.
I think there is a big, big misunderstanding about computer languages. The "quick and dirty" ones are incomplete and limited. The complete languages are necessarily complex. At one time, Perl was like Lua. Then it needed this and that until now it is beginning to be as complex as C++. The same will happen with Lua, I'm guessing, if it remains popular.
It seems that every self-motivated serious programmer writes at least one editor or one language or one compiler. Even I wrote a language and compiler -- for Hewlett-Packard data acquisition equipment.
I think Larry Wall didn't foresee the future when he started Perl. Did he begin Perl with the idea that it would eventually be object-oriented? Did he expect that he would spend his entire life developing his "report language"?
I'm tired of learning new languages. I don't see the point in it. I'll bet there are hundreds of thousands who learned Pascal in college who wish they had not wasted their time; except for Delphi, Pascal is dead.
For those who want an embedded scripting language, how about a C interpreter? Try Cint or Ch.
Or, how about EiC, now hosted at Sourceforge. "EiC is pointer safe."
What about Ruby (ruby-lang.org). It's easy to learn, powerful and has a reasonable set of classes and methods built-in. It's also quiet widespread nowadays, lightweight compared to Python and easy to embed via libruby.so
see the Ruby book (section Embedding a Ruby Interpreter
On Mac OS X you definitly will use AppleScript. Regardless of programming language used for your application. OTOH, you can use any language that offers a library to send high levle events to your apps(not sure about that in our days).
t ml
... as soon as you start working with SWIG you will realise that making an application scriptable menas to craft special hook functions to access only the wanted part of the application, likely via strings only arguments and return values.
On Windows you likely will use Visual Basic for Applications or Visual Basic Script or any other Active Scripting language.
If you write ONLY Java, like I do in our days, its easy: the scripting language will be either Java(Dynamic Java, see: http://koala.ilog.fr/djava/ or Bean Shell, aka bsh, see: http:www.beanshell.org) or Java Script, aka Rhino, see: http://www.mozilla.org/rhino/ or any other language running on a JVM see: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.h
If you write your program ina C-ish language I would consider to use CORBA --- yes indeed!! --- to be able to script it with everything.
If you want to use traditional scripting languages like TCL, PERL etc. you likely will want to look into SWIG, see: http://www.swig.org.
But
The bigger your applicatin gets, the more complex will be the access layer for the scripting languages.
When you have reached that point you likely regret not to have used something more suiteable, like CORBA or the Java stuff I sketched above or you are to the point where you throw it away and rewrite it in a "embed" approach where you will use a scripting language as development language and write certain modules as plugins into that language.
Then however you are bind to the scripting language as host language.
BTW: there are a lot of free mini orbs which make CORBA a toy. And writing IDL is not much harder than writing SWIG config files. If you like to shield your customer from CORBA give him a lib for his scripting language, which hides the fact that CORBA is used.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Nasal is a very well designed small embeddable language with a Javascript-like syntax and an LGPL license. I prefer it to Lua because I am not fond of Lua's Pascal-style syntax. Be aware that Nasal is not very battle-hardened yet and does not have even a 1/100th of the developer community of Lua.
lua is a great scripting language when it's used well. When i was studying game development in school, we were introduced to it as a good way to drive out games. Its easy to add functionality for it... its fast... it simple. I could write all my rendering/sound/network/input code in c++, and just have interfaces for everything from lua... this way, when i wanted to drive a game app, i could do the following: (pseudo lua... hmm... pseudo scripting :) )
load level
load char at xyz
load enemy at xyz
go
then, my c++ code could handle all the collision detection/AI/proper sounds for things... it all comes down to good design. Something like lua is great for having somethign high level drive a low level engine.
Wouldnt you like to be a pepper too?
When I was answering this question, I ended up looking at nasal. While not perfect, it was the closest to what I wanted ... and was under a compatible license (LGPL). But then I wanted something small, lua is way too big.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
Until the 1.8 release the whole Ruby source code and libraries could be distributed on a 1.4MB floppy with room to spare. With 1.8 a lot of libraries have been added so it's about twice as big. (you can always leave out libraries you don't need to keep it light)
Ruby is also easy to embed as well, but we decided to use swig to wrap our C++ classes so that they're accessable from Ruby and then script the whole thing in Ruby. This offers several advantages for our application since we wanted to allow users to script it anyway.
Another project involves including Ruby and libs on a CD with a Ruby script that is used for license detection/management and installation. The Ruby script queries the rpm repository (on Linux) or registry (on windoze) and makes certain determinations about the system on which the actual software on the CD is to be installed. Turns out that including Ruby and most of it's libraries on the CD took much less room than the statically linked executables we used to include for doing the same thing (which were developed in C++). At any rate, the potential user of our CD doesn't need to have Ruby installed on their system because we include it on the CDROM and start up the Ruby script from a shell script (or a bat file on Windows.). Oh, and the Ruby code for this particular project that replaced C++ code is about 1/3 as big and only took us 1/4 of the time to develop & debug as compared to the previous C++ solution. And the Ruby-based system is much more flexible than the previous C++ one - when new requirements come in we can usually have the Ruby system updated & tested in a matter of hours as compared to days for the previous C++ based system. The productivity gains alone were well worth the conversion to Ruby.
COM/ActiveX works swimmingly in this regard in that you have a choice of languages for both producing and consuming COM/ActiveX components, and COM allows you to pass object references across the barrier while ActiveX allows you to work with GUI widgets in this way. And it is true multi-language, not the fake multi-language of the .NET languages.
On the other hand, COM/ActiveX pretty much limits you to Windows, you have to be careful of the lowest-common-denominator effect of which COM data types work in which languages (the more restrictive set of "Automation" types compared to the wider set of C-compatible types and a more restrictive situation for scripting languages and Web browsers than with Visual Basic 6). Also, COM/ActiveX can get ugly in some environments (C++ and MFC/ATL -- you are really stuck taking the Wizard-generated code at face value unless you really know what you are doing), and as a component developer you have to pick up some IDL basics.
Is there anything out there that even comes close? With the Python/C-C++ meld, you are pretty much restricted to Python on one end and C++ on the other hand, and the C++ end is, shall we say, a bit lower level than the Python end, although there are things like SWIG that look amazingly like, hey, IDL and Visual Studio Wizard code.
Another thing I have looked into is the Matlab-Java meld -- a lot of academic engineer and scientists use Matlab as their all-purpose scripting tool, but I wouldn't want to develop high power apps in it. The Matlab-Java meld is surprisingly clean, the Java side can be a Swing app and it runs in its own Swing windows. Again, you are restricted to Matlab on the scripting side, Java on the custom app side, but the interesting thing is that it is pointedly the sort of thing SUN isn't interested in. According to the SUN world view, Java is everything you would ever need and the idea of scripting Java from anything else doesn't enter into their universe.
Is there anything else out there that scripts Java? I suppose there is Jython. Anything else?
Ferite is a scripting language and engine all in one managable chunk. It is designed to be easily extended in terms of API, and to be used within other applications making them more configurable and useful to the end user. It has a syntax similiar to a number of other langauges but remains clean and it's own language.
I love that it was designed from the Start to be Thread Safe and Embeded, unlike PHP or Python.