The Misunderstood Language Lua

Lua is one of my favorite programming languages. I have used it for creating a CMS on an educational website, developing IoT devices, building mini-games, and experimenting with decentralized networks. However, I don't consider myself an expert — merely a knowledgeable user with experience across various contexts over many years.

I'm frustrated with articles and posts that misunderstand Lua's purpose and design philosophy. Critical discussions on LWN and Hacker News often feature commenters complaining about Lua's perceived "incompleteness."

Lua Should Be Viewed as a Toolkit

Hisham's 2017 LuaConf presentation described Lua as "minimalist" with "zero ways to do something." This philosophy emphasizes that Lua provides mechanisms rather than policies, allowing developers to adapt the language to their environment rather than vice versa.

Here's a useful metaphor: Lua functions like milk in a smoothie recipe — a base ingredient to which developers add desired components. Those demanding a "complete package" are looking for a ready-made powerful tool with numerous options. They fail to recognize that Lua fulfills its intended purpose excellently.

Lua was always intended for scripting applications where you build core functionality in another language and embed Lua for flexibility. In game development, for instance, you create the engine in an appropriate language, then add Lua to enable scripting without recompilation.

Developers often misunderstand that numerous Lua distributions with extended capabilities already exist. Other developers selected Lua, added beneficial base components, and released complete packages. Anyone can create a customized Lua distribution containing necessary features without requiring approval from PUC-Rio's team.

This approach produces reliable software because developers control what gets used. You gain complete authority and make decisions optimizing your specific project. This prevents situations where Lua or LuaRocks teams obstruct your goals — you can fork the source code and never consult the community again.

You'll truly appreciate Lua only upon embedding it in your software. Until then, you're combining code in another language (like C), and Lua's potential remains hidden. Using exclusively Lua resources makes it appear as just another scripting language like Python or Ruby — prompting comparisons with languages serving entirely different purposes.

Complaints About 1-Based Array Indexing

Many people insist C-style indexing is the only correct implementation. Understanding zero-based indexing's purpose matters: in C, index values function as multipliers for calculating memory offsets. With an array pointer, element size, and index, you multiply size by index, add the pointer value, and locate the element. Indexing starts at zero for memory access simplicity — C's fundamental approach.

One-based indexing makes sense when thinking like humans. When standing in a queue expecting hot dogs, you'd say you're first, not zeroth. Humans naturally count from one. Additionally, one-based indexing simplifies iterator creation — no need for tricks like i-1 or conditions like i<total. You simply count from one to the total quantity like a normal person. Pascal employed this convention, and it deserves tremendous respect.

Complaints About Lack of Object Orientation

Lua isn't object-oriented, but it contains tables — extremely flexible data structures — plus metatables providing even greater flexibility. This feature demands consideration as a tool (see the pattern?). Using tables and metatables, you can construct numerous impressive implementations like namespaces and elaborate OOP systems. You control everything. Want to develop a system like NewtonScript with dual prototype inheritance? Absolutely possible. Lua provides mechanisms, not policies. You employ these mechanisms to create whatever you require. You're not bound to what library authors or PUC provide.

"Some Language Will Replace Lua"

This assertion appeared in the same Hacker News discussion. Many don't recognize Lua's portability. It compiles using the c89 standard (despite c99 default usage), with minimal hardware requirements — making it ideal for embedded management systems and applications. Many languages positioning themselves as Lua replacements demand greater resources, higher hardware demands, and OS requirements. Janet is an excellent alternative (and also compiles to c89 standard), though Lua's position remains strong.

Lua demonstrates considerable modesty — not regarding binary size and resource usage, but source code complexity. It's small enough for newcomers to understand internal mechanics while retaining comprehension. Consequently, it excellently suits academic research. Languages with understandable internals significantly simplify experimentation, making Lua particularly suited for research and practical applications.

Final Thoughts

I initially titled this section "Conclusions," but reconsidered. As a Lua article, instead of concluding, I offer final remarks, leaving conclusions to readers.

I'm not a computer scientist. I studied at PUC-Rio from 1998-2001, never meeting the Lua team despite regularly using CGILua for work. I abandoned development and graduated as a film director and screenwriter. I possess no academic background many readers have, though this never prevented me from enjoying Lua. I presented at LuaConf 2017, demonstrating an internet-connected automatic cocktail mixer I developed. I selected Lua because I found it most appropriate. I needed not a language "with a complete feature and option package," but an additional toolkit enabling my creation.

When you encounter Lua, don't perceive it as a product. Regard it as LEGO blocks. Lua provides bricks — you imaginatively conceptualize, then construct the product you need.