This Thursday, I will give a talk at the St. Louis Java User Group on “Scripting your Java Application”, Thursday Nov. 9. Here is the blurb:
First, this talk will show how to plug in scripting capability to your application, using common scripting mechanisms, including those from the scripting related JSRs (223, 274, etc), and point out the tradeoffs in selecting a scripting mechanism and/or language. Then the bulk of the talk will focus on the questions of Why and Where: the motivations for scripting support, areas of an application that warrant such support, and placement of scripting plug-points across client/server application tiers. Lastly, it will address script/application API design and plugability, including the ideal of an end-to-end script plugin.
My current plan is to use no slides, only a 1-page handout and code on the screen. (Yes, I’ve been to an Edward Tufte class…)
Joel seems to “play it safe” … then goes off the deep end of irony in his final paragraph:
Fortunately DHH saved me some minutes of typing about it, with a scathing commentary.
Over at Oasis Digital we use both common tools (.NET, Java, PHP, C, Delphi, etc.) and more unusual ones (Lua, Prolog, Ruby, sorry no Lisp yet), so I believe that puts us in the DHH and Paul Graham camp: If you want to win, you must be willing to do something different from the pack… such as, in an extreme case, creating your own language optimized for the task at hand, whether in the form of Lisp macros or a C# compiler for Wasabi.
Over on defmacro today, a new article appeared: defmacro – Why Exotic Languages Are Not Mainstream in which the author laments that while there appear to be various choices to use Haskell on Windows, it turns out that all of them are, in some way, not ready for prime time… or even for effective hobbiest use.
I’ve noticed this myself, in my last few forays in to esoteric languages: the illusion of plenty of choices, runs in the the reality of no good choices. This is not a universal problem; I’ve had great results with Ruby, Python, and Lua, all of which are to some extent esoteric. The thing that those languages have in common is that there is at least one (and generally, only one) robust, production grade implementation with a community actively supporting it.
If you want to see your favorite language gain acceptance, spend your time creating / maintaining / vigorously supporting a production-ready implementation.
At the St. Louis Code Camp on May 6, I gave a talk that was somewhat poorly titled “Painless Scripting with Lua”. The topic more mostly about the overall use of scripting as a configuration and extension mechanism, with Lua as an example language.
The talk had no slides, only code and a 1-page handful with some notes. You can download the source code: 2006_code_camp_lua.zip and the notes follow:
Alternate Hard and Soft Layers
This is a Pattern from the C2 Wiki: http://c2.com/cgi/wiki?AlternateHardAndSoftLayers
In a system built with “hard” code (not in the sense of difficulty, rather in the sense of statically typed, statically compiled languages), organize that code in to layers, and between those hard layers, put “soft” layers in the form of scripts written in a dynamic, runtime modifying languages. AHSL is closely related to the idea of scriptable applications, with the additional notion of layering, rather than ad hoc extension.
“hard layer” languages:
“soft layer” languages:
- Emacs Lisp
- Lua (*)
This talks’ examples are in Delphi (hard) and Lua (soft). Delphi is a mostly static language, essentially similar in certain ways to C, C++, and Java, but with a Pascalish syntax.
Key Points about Lua:
- An easily learned, dynamic programming language
- Small, highly embeddable (~ 100 KB)
- Multi-platform (highly portable C code)
- Well suited to “Alternate Hard and Soft Layers”
- Free and open source
- Stable and mature
- Safe and Sandboxed
- Actively developed and maintained
Recommendation on Scripting:
- If you’re building a .NET system, use a .NET-centric scripting mechanism
- If you’re building a Win32 system with a lot of COM in it, use the Windows Scripting Host and expose your system’s feature to the scripts via COM.
- If you’re building a system with a “hard” (very static) language, and want to keep your options open for cross-platform development / deployment, than Lua is an excellent choice, it is small, fast, proven, COM-free, and cross-platform.
My friend Brian Button is still looking for St. Louis Code Camp speakers; if you’ve thought about giving a user group talk, this is a great way to get your feet wet. A “code camp” is an informal event, likely with a lot of group discussion. You don’t need a large topic or a long speech. Simply pick a technical topic (perhaps something from your work, or something you’ve been wanting to learn on the side), prepare a few examples and notes, and sign up.
I’m already signed up to give a talk on Lua.