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?"

Javascript!

[Geek Boy]

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.

ICI

[tpv]

ICI [sf.net] is very lightweight and generally quite usable by semi-programmers.

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?

Why so many languages?

[Futurepower(R)]

"...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 [root.cern.ch] or Ch [softintegration.com].

Depends on the host programming language and OS

[angel'o'sphere]

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

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

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

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

Re:The need for "extension languages"

[ajagci]

I agree: the use of C/C++ for most Linux applications just doesn't make a lot of sense. It's more effort to develop in than a HLL, a lot harder to debug, and usually, it isn't even any faster. Python would probably be a good choice for many desktop apps.

However, when it comes to statically type checked, non-C/C++ languages on Linux, there isn't much choice:

• Java: no fully compliant open source implementations; some serious design flaws.
  
• C#: not a standard part of major Linux distributions; some concerns (probably unjustified, but still) about Microsoft patents.
  
• Eiffel: open source compiler does not support separate compilation; some serious design flaws in its type system.
  
• Modula-3, Oberon: not widely used.
  
• O'CAML: great language but probably too complex and sophisticated for your average Linux hacker; lacks some facilities essential for high performance computing.
  

Overall, C# looks like the most promising to me: it combines the best features and simplicity of Java with most of the efficiency and C-interoperability of C++. Let's hope Mono will make it into all major Linux distributions soon.

I'm doing this with Ruby

[CatGrep]

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.

Re:!TCL

[Anonymous Coward]

But TCL is showing it's age these days. TCL is really a pretty ugly language (has 'let' assignment syntax as I recall - oh the pain, I don't want to remember). It was fine in 1988, but now programmers hope for more. Seriously, there are much better choices now. I'm partial to Ruby myself (http://www.ruby-lang.org). It's quite easy to embed in a C/C++ app, or you can use SWIG to wrap your C/C++ code for access from Ruby. Ruby is pretty small as well, the sourcecode and libraries are about 1MB (well, it's a bit larger now with the 1.8 release, but you don't need all of the libraries that are included now).