Two stories

Via Patrick (who was once a LtU contributor), two interesting blog posts:

  • A discussion of the uses of Lua in Lightroom and about the use of dynamic language to develop desktop software in general (blog post by a LtU member). Apparently, some 63% of the code written by the Adobe Lightroom team is in Lua.
  • A brief history of IBM's Visual Age, originally written in Smalltalk (the product, not the blog post), and Digitalk (remember Digitalk?!).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

a bit more about Lua and Lightroom

It’s All Glue: Building a desktop application with Lua. Slides from Mark Hamburg's talk at the 2005 Lua workshop. Goes into detail about the benefits and tradeoffs of using the language.

An interview with Mark, where he discusses why and how he chose Lua.

"Lack of Static Type-Checking" slide (#19)

• Programmers make typos
• Catching everything at runtime requires exhaustive testing and
some bugs can be subtle
• Unit tests help but don’t work as well for UI code

• Wrong name v wrong type

• Added checks at the global environment via __index and
__newindex metamethods
• Added lint tool that checks the files
• Class constructor looks for an optional __fields entry and if so
adds __index and __newindex metamethods to check keys

Since the talk was in 2005, I wonder if the Lua people have done more work on automatically catching these problems.

Where I work we keep moving things from Python into C++ to avoid these kinds of problems.


It seems unlikely that elaborate compile-time type-checking will be added to Lua, because they place really high priority on keeping the language (including the compiler) very small. Instead, their solution has largely been to use the metatable hooks (e.g. __index) to modify how the language handles references to variables that are not yet defined. It's pretty easy to extend the language so that all new global variables need to be activated with a statement such as "use varname". Not as elegant a solution as full compile-time type-inference, but it helps.

These problems are pretty common to most dynamically-typed languages, really. Using a language that starts dynamic but can be turned increasingly static once the design is mostly set is another option, but at the moment I can't think of anything besides Common Lisp that supports this.