Lua, a misunderstood language

Posted Friday, January 15th, 2021 

development

Lua is one of my favourite programming languages. I’ve used it to build a CMS for my old educational website, for creating cool IoT hardware projects, for building little games, and experimenting with network decentralisation. Still, I don’t consider myself an expert on it at all, I am at most a somewhat competent user. This is to say that I have had exposure to it in various contexts and through many years but I am not deep into its implementation or ecosystem. Because of that, it kinda pains me when I read blog posts and articles about Lua that appear to completely miss the objective and context of the language. Usually these posts read like a rant or a list of demands. Most recently, I saw a post about Lua’s Lack of Batteries on LWN and a discussion about that post on Hacker News that made me want to write back. In this post I’ll address some of the comments I’ve seen on that original article and on Hacker News.

Lua should be considered a toolkit

I think it was Hisham who in his talk in LuaConf 2017 said that Lua is minimalistic (aka: “there are zero ways to do it”). This was of course about Lua offering mechanisms over policies, or how it unlocks agency in the developer by letting them adapt the language to suit their environment and not vice versa. Lua should be viewed as a base ingredient to which you add whatever you want. If you are making fruit smoothies, Lua is the milk and you add whatever fruits you need.

People who want batteries want a ready-made powertool full of opinions. They are not looking towards Lua in the context that Lua wants to exist. It is like looking at a boat and complaining it can’t fly. It was not meant to fly. Unless you build the rest of the place and make an hydroplane out of it. It is up to you, Lua doesn’t care.

Lua has always been a language for scripting applications. It has always been assumed that you’d build your domain specific code using something else and embed a Lua engine in it to make it flexible. Are you building games? You build your whole engine in whichever language makes sense for you game, including the domain specific stuff that only your game cares about, and then add Lua to it so that you can script and tweak your game without recompiling the source.

The same context applies to other software that offers Lua as the scripting language for their plugins or add-ons, this is what Lua has been built for, it offers advantages to this approach. The fact that you can write the whole software in Lua is a side-effect of it being a good language but it was not the primary use-case for it.

People who wants battery-included Lua do not realise that there are plenty of battery-included Lua distributions floating in the wild. Other developers picked Lua, added what they thought was a good baseline, and are shipping a complete package. You too can build your own battery-included Lua that has the stuff you want. We don’t need blessing from the Lua team at PUC to do it. This is how it is supposed to work. You pick the language and assemble what you need.

This leads to robust software since the developer are responsible for making the calls. You are in complete control and can make the decisions that are suitable for your development. There is no situation where Lua team, or LuaRocks team, can prevent you from doing what you want like the drama that has been happening inside the Elm community. You can grab the source for the version you want, and then never again look at Lua community.

I think that you can only appreciate Lua when you embed it on your own software. Until what you are building is a combination of some code in other language (such as C) and Lua, the power of Lua will not click for you. Not only the power, but the way of Lua will not click for you. If all you’re using is 100% Lua source code, it will feel just like another scripting language–not unlike Python, or Ruby–and you will start trying to analyse Lua in terms of those other languages, which are not really comparable since they have different objectives.

Complaints about 1-based indexing for arrays

Mentioned in this comment. I often see this kind of complain from people who think that the C way of doing things is the only valid way. It would be great if people spent more time thinking about why use a 0-based index instead. C uses such indexes because the value is actually a multiplier that you can use to find the memory offset for the location of the data. If you have an array, and thus a pointer to the starting position for that data in memory, and you know the size of the array elements, you can multiply the size by the index, sum with the pointer value, and get the data that corresponds to the element referenced by that index. That is it. Indexes are zero based to help you find stuff in memory when you have a pointer which is basically all that C gives you.

Using 1 as the initial position for an array makes sense when you’re talking like a human. When you and your friends are in a queue waiting for your hotdogs, you might say to them that you are first in line. I doubt you’ll say you are zeroth in line. We usually start to count from one. When a baby completes its first roundtrip around the Sun, they’re one year old, not zero years old. Also, 1-based indexing help when you are doing iterators, you don’t need those hacks such as i-1 or counting til i<total. You can count from 1 to the total and be fine, like a normal human would do. If I remember correctly, this was a Pascal convention. Pascal is a language that deserves a ton of love IMHO.

Complaints about object-orientation

Lua is not object-oriented. That is it. Lua has tables which are a very flexible data structure. Lua has Meta Tables, which enables even more flexibility when using Tables. This should be approached as a toolkit (can you see a theme here?). Using Tables and Meta Tables, you can build a ton of cool stuff such as namespaces, and fancy OOP systems. You are in control. Do you want to build a system like NewtonScript with its dual parent prototypical inheritance? Well, code it away. Lua offers mechanisms, not policies. You use these mechanisms to build what suits you. You’re not tied to what PUC or a library author offers you.

Some language will replace Lua

Mentioned in this comment. Be aware that I am not singling Janet here, I really like Janet. Many people don’t realise that Lua is extremely nimble. Lua can be built by compilers using the c89 standard (even though the default is c99 IIRC), using very little assumptions about the hardware it is running on. This makes it a prime candidate for embedded work both in hardware and inside your own apps. Many languages that are touted as Lua replacements require more resources and make more assumptions about the hardware and operating systems they are running on. Janet is still awesome (and it builds with c89 IIRC) though.

Lua is quite small, and I am not saying about binary size and resource usage. I am talking about source-code complexity. Lua is small enough that newbie developers can understand its internals well and keep it in their mind. This makes it a great language for academic research. A language that you can comprehend easily will foster experimentation. Lua is specially well positioned to be used for both research and practical purposes.

Final words

Originally I titled this section Conclusion but that felt wrong. It is a post about Lua, so instead of giving you a conclusion, I will give you final words–just another piece in your toolkit–so that you can form your own conclusion.

I am not a computer scientist. I was a student at PUC-Rio from 1998 to 2001, and while there I never met the Lua team even though I used old CGILua for work at the time. I quit engineering and graduated from another university as a filmmaker and scriptwriter. I don’t have all the academic background many people reading this post have, and yet that never prevented me from using or enjoying Lua. I was a speaker at LuaConf 2017 and presented an Internet-Connected Automated Drink Mixer I built. I chose Lua for that machine because it felt right. What I wanted was not a language full of batteries and opinions. I wanted another tool in my toolkit, something that offered me just enough mechanisms to allow me to build what I wanted.

When you approach Lua, don’t look at it like a product. Approach it like you approach a LEGO set. Lua offers you bricks, you provide the imagination, design, and in the end, you build the product.

Oh, and this is the video for my drink mixing machine…