Embedded programming languages

A long time ago when I first started at IBM I used an editor named XEDIT that ran under the VM/CMS operating system on mainframes. It was a fullscreen, line-oriented editor that looks primitive now but was quite sophisticated in its time. One of the best things about it was that it was scriptable: you could write very sophisticated programs that could manipulate files and their contents. XEDIT really became powerful when used with the REXX programming language and many of my thoughts and philosophy about embedded languages were formed during my use of REXX.

I love embedded programming languages. Today these not only allow you to manipulate text editors, word processors, and spreadsheets, but also 3D environments like World of Warcraft (Lua) and Second Life (LSL).

These days you don’t need to figure out how to write an embedded language for an application, you can pick up an engine “off the shelf” and link it to your program. This is important, because for non-trivial languages you can spend a tremendous amount of time worrying about basic issues like scanning, parsing, symbol tables, scoping, garbage collection, and other topics. While you must understand the semantics of what it means for the embedded language to operate within your application, it’s still easier to borrow the work of others that start from scratch, unless this is what you want to do.

Note that if you are using an open source embedded programming language you must understand the license used and what you can and cannot do. For example, if the engine is GPL, do not plan to statically link it to your commercially distributed proprietary software.

Here are some of your options for languages to embed open source programming engines in your applications:

Suggestions for other languages and links are welcome.

Also see:

This entry was posted in Software and tagged , , , , , , , , . Bookmark the permalink.

One Response to Embedded programming languages

  1. Ted King says:

    Thanks for the links. It’s nice to see mentions of early virtualization (VM/370 with the CMS client) and the best response to the “vi vs. emacs” argument (XEDIT or another SPF-type editor). I was in a shop that went from EXEC to EXEC2 to REXX over a few months (mid-1980′s). REXX was a huge improvement.

Comments are closed.