Thoughts on learning Lua
No, I’m not going to write any tutorials, but Sean suggested writing some thoughts on learning Lua for Lightroom….
Getting this far with Lua has been a real struggle. I am not a trained programmer like Jeffrey Friedl. I know no C, C++, Cocoa etc, so I don’t know if Lua is easy for people with such a background (though it heartened me when he described Lua as “horrid”). But I do have a lot of experience of the various flavours of Microsoft VB and VBA, and of JavaScript, PHP, AppleScript, ActionScript 2 and 3, and other useful technologies like XML, SQL etc, all self taught. That brings a confidence that things should be possible, but it barely overcomes the why the bloody hell should I add features that should have been there in the first place? So over the last year the effort has been pretty sporadic, learning a certain amount, achieving something vaguely interesting, and then finding something else to do with my time.
I’ve always liked Microsoft’s approach to scripting professional applications – the Office suite being the prime example. There’s an assumption that you’ve got to enable the end users to do it themselves. In Cubicleland you don’t want to wait for the IT guys to write that code to automate your budgeting spreadsheet or interface with the MRP system. Bringing in a programmer means jumping through authorisation hoops, and inevitably you’ll find yourself left with something you can’t tweak as you perceive the task has nuances you hadn’t anticipated. Rely on self-interest and provide a user-friendly language and tools, and the end user should be able to do the job. That’s how I began going off the rails.
In InDesign and Photoshop, Adobe provide the perfect triangle of scripting languages, VB+JS+AS, so you can automate and streamline your work. Integration with the non-Adobe world is enabled with two platform specific languages, while cross-platform functionality is there for an Adobe-centric workflow. Imagine how great that would be for Lightroom. Someone somewhere would make Photoshop do something like apply NoiseWare or other noise reduction to a batch of images with different settings for differing ISOs. Or say you wanted to bring into Lightroom all that metadata originally entered in Aperture or that is now in the Excel data exported by some other DAM. Again, one VB or JS or AS script could do the job, and if the coding hits a problem there would be a world of experience and existing code and examples that even an ex-accountant could adapt.
Lua by comparison is a niche language, and what documentation exists is written for programmers. You have to write the code in glorified text editors rather than helpful development environments such as Microsoft’s VB IDE, and when there’s a syntax error it’s in gobbledegook that’s only intelligible once you have enough experience not to have made the mistake in the first place. Lightroom’s SDK is also mainly targeted at the developer, provides just half a dozen examples, and you can no longer learn by taking apart others’ plug-ins because everyone’s now encrypting them.
But Lua is not going away, and after a load of grumbling I usually snap (and funnily enough, as I added that link I realised that I’m wearing my Mt St Helens t shirt).
So what I’ve been doing over the last year is attacking Lua every so often. Little and often. You also need to approach from a number of directions until the penny drops. Once you’ve got the SDK, I would suggest customizing a copy of the web template. As it’s in Lua, it will get you familiar with the syntax and structure. It also has HTML and CSS elements, so you’re not totally on foreign territory, and you can focus your efforts on producing something you can use. In my case I just adapted the built-in web template so my online contact sheets have star ratings to help draw attention to the best images (as if they won’t do so themselves!).
Second, look at customizing the FTP client that’s provided in the SDK. That exposes you to how export plug-ins work, and also to the way the Plug-In Manager works.
The third area of the SDK is custom metadata, and again there’s an example which you need to tear apart and put back together again. Here you can add new fields to the catalogue, new metadata panels, Library Filter columns, and Smart Collection criteria. This area is where I’ve spent most of my real effort, and it typifies something I dislike about Lua – that you need to proceed by trial and error. Change a line, reload the plug-in, see if you’ve broken anything, hope the error message is remotely decipherable, and then see if it still does what it’s supposed to do. Only then is the SDK documentation and attempt to marry up its descriptions to what you think you’ve just done.
That’s not the only reason I keep both the SDK PDF and the API html open all the time – it’s also so you can see what else is in the toolbox. For example, while writing the last few days’ plughini I noticed that you can code the progress bar. While that’s off the critical path for now, sometimes the really hard bit is realising that something can be done. So look at others’ plugins, and note what is possible.
So a lot of of the learning process is about taking apart a series of substantially-discrete components. Adding custom fields, reading and writing fields, calling dialog boxes, accessing operating system properties…. All in a language that glories in making itself doubly obscure by calling arrays “tables” and forcing you to define that each line of code as a “row”. It’s a bit like building your own car – put the effort into learning to make the bodywork, tyres, leather seats etc, and eventually the experience coalesces and you can bolt together something that’s roadworthy. For those who know Trainspotting, and perhaps another volcanic analogy lurks here, it’s all a bit like Renton getting his fix.