Sometimes, the standard C libraries just aren’t enough for a large project involving a lot of high-level programming that just isn’t the easiest to do in C code. But, when the project absolutely has to be written in C whether its avoiding a pre-installed (or extra-install) JVM for users that may have plugin-phobia, or just the need for speed of a compiled binary over interpreted bytecode or text, embedding other scripting/portable languages looks to be an easy way out for a small cost, and here we examine several of the commonly embedded languages and their impact on a project as a whole.

First off, this article aims to examine these aspects of embedding other large-API languages in regular, portable C code:

• The ease of use
• Amount of code
• Comparison to the original(not-embedded) language syntax
• Graphical applications

We will mainly be focusing on scripting languages like Python and Perl here, but also discussed will be Java via the JNI library.

Python is a perfect advocate for being embedded, since its API has just about everything you need: mass computational libraries, the lovely Tkinter and qt GUI libraries, and a fairly easy-going syntax. So when embedding is a viable option, Python seems like a good candidate.

The good news is, most of Python’s APIs operate fairly close to regular Python, the only exception being the really low-level stuff like threading and IPC (this has a workaround that doesn’t require much C code). However, to the Python programmer that is not somewhat-fluent in C, things can get real hairy real fast, the worst of which being dependencies needed by Python when you are embedding it.

The simplest way to accomplish embedded Python (to get your homework done) is to simply include Python.h, call Py_Initialize() and run Python code as a string argument to PyRun_SimpleString(). This will accomplish a sort of one way street for running interpreter-independent Python, but does not cover passing Python objects to C, or other advanced embedding characteristics.

In addition to the code mentioned above, you need to track down external dependencies (platform-dependent) and include them at link time, which can get real tedious outside of build your own separate Python from source strictly for developmental linking(recent releases include a top-level setup.py Distutils script for minimal linking).

Digging into deeper embedding techniques with Python requires a lot of pointers to Python objects, dictionary usage, type conversion (quite a bit), dereferencing Python objects as needed, the process of callback and handler objects, and pre-compiling strings to bytecode for better performance. This just skims the surface of Python embedding, and just the terms listed here can generate hundreds of lines of code to do something fairly easy in Python. The ppembed project has done some good in easing this process, but the amount of code has not changed enough to make this a viable option in a large-scale project, although still recommended over the standard C libraries when using GPL code is not really an option.

Now, let’s change gears and talk about Perl. Perl, like Python, is a scripting language just not compiled like Python is, instead being interpreted line by line on the spot. While Perl does not have nearly the large API Python does, it is still great for text processing and code reduction where it is embedded thanks to the behind-the-scenes C code that drives Perl’s interpreter.

Perl is so easy to embed its not even funny. The only real C code involved is including perl.h and EXTERN.h from the perl distribution, make a pointer to the actual Perl interpreter, then simply run strings of perl code in perl_eval_pv after constructing, parsing, and running the Perl interpreter (the pointer made earlier).

So like Python there is still a little C overhead, although nothing a mid-main include file couldn’t solve. The only other thing to consider when embedding Perl is getting a Perl variable of a specific type for C usage, which involves C code to actually KNOW what C type a scalar is ahead of time.As mentioned earlier, Perl could mainly be used for text processing and some computational subroutines, but for the most part Perl is limited compared to other alternatives for embedding. Perl’s main advantage is ease of code management, and its niche of text processing. The VMWare team used Perl for their free VMWare server application, although the task Perl was handling is unclear.

The other popular embedded language used by the likes of OpenOffice.org, Adobe, and a host of others presumably for its large API is Java. Java is embedded via the Java Native Interface, or just JNI for short, which is an entire project itself as far as code management goes. Embedding Java is pretty similar to embedding Python, and like Perl requires you to allocate a pointer to the JVM for usage of Java code, which has to be passed through javah from real java code before execution.

Embedded Java would be the biggest payoff because of the sheer API size, saving hours of standard library hacking and bugfixes, but embedding it is not the easiest. On the other hand, Perl is really simple to embed but the language itself does not have anything a large application would want per se, as others could easily point out some things Perl might handle better than straight C (although, Perl is interpreted BY C, hence the motto “you can write faster code in C, but you can write code faster in perl”). And Python is the best of both worlds, but I personally don’t find it too extreme enough in either direction for me, unless you were comparing executable size or something.

And now, the explanation for all of this: I recently picked up Python after knowing Perl for some time, and wanted to run a Python program on Windows. After having trouble installing the interpreter and thinking to myself “The average Windows user probably does not want to go through all of this” I looked into embedding Python, and my old friend Perl while I was at it, and a friend of mine showed me his JNI code. The biggest advantage in embedding as a whole would be the ability to write your favorite non-C/C++ code with your favorite API calls (or to reuse old code in a new app), without relying on a pre-installed interpreter or Java runtime, which users apparently have trouble wrapping their pretty little heads around.

So while not all embedded code is pretty, it can still get the job done faster in place of hours of C hacking, and plugin-independence is a huge plus for desktop employment, presumably in a private firm you may administer for when you need a tkinter GUI written FAST and your C code is less-than-optimal .