The Lua Language (Information Technology,Programming)

Paul M. Foster (09/16/19 11:34:54 Revision 0)

Recently, the Lua language came up on my radar as a possible scripting language to replace Perl, Python or PHP.

To recap, I have some bones to pick with readily available scripting languages. The context in which I'd use these languages is in scripting quick and dirty non-web tasks. For example, I just wrote a script called "project" whose purpose is to take me to the source directory for one of my programming projects, and fire up vim with its session manager, to recover all the files and placemarks I was in the progress of editing. I wrote the script in bash because it was such a short affair, and I could do it without having to delve deeply into the obscure syntax of bash. That's my primary beef with bash. Its syntax is peculiar, and you have to get it just right, or the script with dump out with errors and be unusable.

Perl's day has come and gone. A friend of mine once called Perl a "write-only language". Because you can't figure out what the hell Perl's doing by reading it. That's an exaggeration of course, but Perl has a lot of cruft connected to it, and its syntax is obscure, though less so than bash. Perl is more or less the reason Python was created.

I hate Python. It has no line terminators, and manages conditionals and loops strictly by using indentation. The problem is that, if for some reason you lose your exact indentation on a file, you could spend hours trying to piece its loops and conditionals back together. In order to edit Python, I have to set my indentations in vim very specifically for the Python language, something I'm not forced to do with any other language. And what if you have to pass around your source files to other programmers? You better hope they're using the same conventions you are. In addition, Python a nasty habit of throwing exceptions in cases where other languages would simply compensate for the out-of-bounds conditions. It's a mess.

PHP is a profoundly good scripting language, as far as I'm concerned. It has a syntax and libraries almost identical to C, which is a language every programmer should know how to use. (Because of C's ubiquitous influence, I think it should be the first language taught to any aspiring programmer or student of programming.) Further, PHP handles memory and garbage collection just like every other scripting language should. And PHP has an absolute wealth of array handling functions and options. I use this part of PHP constantly. It makes up the lion's share of the interface between your data store and the rest of your program. I've used PHP now for decades, mostly for web coding, but it works easily as well for regular non-web scripting. The major problem PHP has is that it simply isn't used much as a general scripting language. It's almost as though no one realizes it can be used this way. It does require a separate standalone package be installed for general scripting, but this is a minor issue. For my money, PHP is the best scripting language out there.

Lua came up as a general purpose scripting language recently (to me), and I decided to take a crack at it. I use short scripts to filter text files in various ways, and I have a collection of Perl, Python and PHP filters. But if I could replace these with scripts of a single language, I'd be happy. Lua, at first glance, looked promising. So I installed the Lua package, and purchased a book on Lua. I started with some simple "Hello World" type programs. But I don't do well learning a language by trying to code random, artificial applications. I do better when I have a specific real-world task to do. I happened to have one in mind. I have a password manager which I coded myself in bash. It simply encrypts and decrypts a flat file which has a certain syntax. Password records have a specific set of record and field delimiters. There are a variety of fields available, something which most password managers don't offer. For example, for some of my password entries, I have up to three security questions and answers, which will be asked by my bank or whatever. These fields have a certain prefix in my flat file which dictates the significance of the field on that line. So I was interested in some sort of parser which could parse the lines and give me an array of labeled fields.

Originally, I came up with a syntax which seemed to work for the purpose. Each record would take up some number of lines (one for each field), with record delimiters. Each field would have a prefix on the line which would act as a key to indicate the significance of that field. That worked okay. But then I started working with vcards, and realized that the basic model for vcard structure might work for my password records. The only problem was that vcard records have a peculiar syntax when more than one of the same type field exists in the record. This makes it hard to parse and array-ize the records. It makes them harder to read and interpret. I know, because I converted my address book application to vcard format recently, and had to tweak the vcard standard to make the programming simpler for my web-based address book application.

While working with vcards, I was reminded of my work years ago with EDI, a standard for transmitting all types of records among trading partners. EDI had, to my mind, a superior syntax, and a simpler way of expressing "duplicate" fields, etc. I had already converted my password entries into a vcard like syntax. So I did a third version of my password entries, using an EDI-like syntax. So far, all this syntax work is just for show. When I use the password manager, it simply shows me the file. It doesn't break records and fields down for indivual editing or anything. But the idea of a parser which would parse the individual records seemed like a cool idea.

The simple work I'd been doing with Lua forced me to look deeply into its syntax. It has a lot of peculiarities, compared to most of the other languages I've used. It's not as bizarre as bash, but it's still weird. Lua does (mercifully) have loop and conditional terminators, mostly consisting of the key word end. It does not have statement terminators the way C and other languages do (not Python). It's a line-oriented language, but because of the loop/conditional terminators, you can easily decode things and indent as you like; indentation is optional, but recommended.

For my parsing project, I needed extensive array functions and string parsing functions. PHP has this stuff in abundance. It's very rich in these areas. Not so much in Lua. PHP has an explode function with is ideal when dealing with strings which have internal field delimiters. It pulls in the string and divides it into array items, based on the delimiter you give it. Very handy in parsing some strings. Lua lacks this, but in doing some web searches, I found an implementation of this functionality for Lua. Bonus, because I desperately needed this to parse the individual lines.

Then the next hurdle came up. What if I wanted some "library" functions I wrote in various Lua scripts? Was there a Lua version of the include directive from C and PHP? Somebody posed almost that exact question in a forum, and the answer was not simple at all. There were various alternatives, but as I continued to study, it became clear that this type of functionality in Lua was predicated on the idea that Lua was meant to be an embedded language. For example, you could embed Lua code in a C program to provide convenient functionality for capabilities that C lacks. As I continued to study, it became clear that many of Lua's quirks derived from this fact. The inclusion of other "translation units" (source code files) is not as straightforward in Lua as it is in other languages. The more I looked into this, the more clear it became that Lua was only secondarily a standalone scripting language.

For someone who primarily operates in languages which borrow heavily from C, Lua's syntax is largely familiar, but also has some odd quirks which are hard to remember. For example, Lua has no switch/case statement. You have to implement that kind of functionality in if/else structures, which strikes me as very "last century". In addition, Lua's for structures are peculiar, contrasted to C, Javascript, PHP and other similar languages.

All in all, my enthusiasm for Lua has dampened. I'd have to do a lengthy amount of study to fully master Lua, and I don't do that many applications which require general scripting. Some guys really dig learning new programming languages, but I'm not one of them. A language is there to help me get things done. I'm focussed on the task, not the language which helps me accomplish it. If a language works to perform some job, I don't normally see a reason to use some other language. My idea was to replace all these filter scripts and some others with one language suitable to the task, one which didn't involve Perl and Python (the two most used general text-handling languages). Moreover, while PHP has an abundance of database and other libraries which allow it to do just about anything you'd want, Lua does not have these things. I imagine the "host" language is supposed to take care of these things, and Lua is just grafted on to add some higher level functionality. It lacks the breadth of resources which are native to PHP.

So for now, I'll stick to PHP. I may investigate Lua later, when I have some time to kill. But for now, it's no longer on my radar.

Add Comment:

*
*