Lua Programming in Lua (first edition) (2003)

> I guess one might argue that 1-based indexing could cause beginners to get confused when they move to another language.

The creator of Lua once visited my university, he told us about the 1-indexing (it looked like this is the thing that everybody asks him). Lua was created in a time that 0-indexed languages wasn't so dominant over the 1-based languages.

Lua is older than Java and JS, and a few years newer than Perl and Python. Before those, as far as I remember about more popular languages: C and C++ are 0-indexed; COBOL, MATLAB and FORTRAN are 1-indexed; Pascal can be 0 or 1 indexed, but its for loop is better suited for 1-indexed.

This way, there wasn't a strong bias to use 0-index in a new language as we have today, they could use what made more sense. Since it was created for engineers used to math notation (sum, products and matrices generally are 1-indexed) and without background in programming, they have chosen to start in 1.

*However*, about using Lua for studying algorithms and data structures, some books use 1-indexed arrays in their pseudocode, notably CLRS' Introduction to Algorithms. When I was studying algorithm analysis using CLRS I used Lua to implement them. I still prefer 0-indexed languages, though.

Your analogy to a stripped back version of JavaScript is really on point. I feel that way about Lua too. Through time Lua kept its simplicity, whereas ECMAScript kept accreting stuff which most of the times makes life easier, but also gives way too many choices for how to do the same thing.

Indeed the 1-based indexing, which often generates heated discussions, could be a source of confusion later on. However, like you mentioned, it can also prompt the beginner to quickly understand the languages are just tools, which have slightly different ways to be used, depending on what they're trying to solve.

In fact, this 1-based indexing is by convention (although everyone uses it), once again showing how flexible and "hackable" Lua is.

The other great thing about Lua is the utter sparsity of the standard library, it teaches one to think for themselves instead of only taking goods off the shelf.

I've taught programming to beginners, both children and adults, and lua is the worst of the languages I've done it with. It's an amazing technical accomplishment, and CS students should study its implementation. But for actual beginners its "focus on fundamental concepts" and flexibility are liabilities.

The main struggle people have learning to code is getting over the initial frustration hurdle where they can't actually accomplish anything yet. What they have to get them through this is excitement about their actual goals. With lua you burn too much goodwill and beginner spark on debugging string manipulation functions that don't seem important to the actual interest or goal that brought them to programming. Or figuring out how to use luarocks so you can make http requests, or regex, or whatever.

> 1-based indexing could cause beginners to get confused when they move to another language.

This is so far from the problems that beginners actually have. You should teach some programming, it's a really fascinating experience that will mess with your intuitions about how people learn this skill, and what's hard about it.

> In my opinion, Lua would kill for many use cases

Perhaps it could, but it should?

Let me explain. Take the example of JavaScript, which was kinda similar to Lua when it was conceived: both were simple languages, targeted to solve specific problems, waiving more complex features and delegating many things to their users.

Example: early JS and Lua don't have OO, but they have the tables (Lua) and objects (JS) which are hash tables with some syntax sugar to look like POO languages if you needed. Then, the user is responsible to handle this in a sane way, which should not be big deal for the scenario that those languages were created.

JS, however, has grown outside its original purpose. Somehow it became a server language, and somehow it became a monster. TypeScript, CoffeeScript, ClojureScript and others were created to delegate back stuff to the language. Lua, however, is still doing well its job in its simplicity.

> In my opinion, Lua would kill for many use cases... If it had a bigger standard library, and batteries-included module/packaging system. I know LuaRocks exists, but it doesn't seem terribly common.

This is because of the design choice of Lua. Authors do not ensure retro compatibility and this is why there were so much outdated external libraries when Lua 5.2 came in. Even the most popular LuaSocket wasn't updated in years.

In fact, Lua is definitely not intended to be used as a drop-in replacement to Python, Ruby or Perl because of that. It's entirely designed to be embedded as-in in your host-program and that you must provide your own extensions.

However, keep in mind that:

a. you will need to carry the documentation of Lua you've included b. if you plan to upgrade the bundled Lua you will have to polyfill all changes to avoid breaking your userbase code (and this is a real PITA) c. you'll end up with lots of `#ifdef` in your code

I think that are few reasons why Lua stalled that much (without even mentioning all uncommon features `~=`, `goto`/`break` but no `continue`, array start at 1, too minimalist unicode support, ...). I've been including Lua 5.1, 5.2 and 5.3 in one of my projects before I eventually stopped to backport compatibility layers. I also gave up on my LuaSDL repository because it was too much of headaches. It's a shame because I loved this language a lot.

In my use cases, I’ve appreciated how easy it is to cut out most of Lua’s standard library and run only the bare language.

As a game engine guy, I’ve been setting up Lua to be used by semi-technical game designers. I know I’m going to have to help them debug some crazy script months from now, so I want to carefully prescribe the APIs they get to play with from the beginning. Ex: No raw file system access! Only load assets through the asset system.

Lua shines when it is embedded in a larger program, giving high-level commands. There have been plenty of projects trying to build full applications in Lua. But, that’s really fighting against its design.

Lua's best place is as the language "on top of" another language.

ie. You have a big application that has a configurable feature and you also need that configurable feature to be super flexible since the amount of possible variations on that feature is so large that it's not worth maintaining it in the "main" language. An example could be say, an enemy AI decision script in a turn based RPG. While you can hardcore the decisions into the language itself, it doesn't make it easy to modify (especially if you want to iteratively test it, since each iteration needs a recompilation of the entire program).

That's where LUA shines - instead you just put it in a LUA file and it's dynamically loaded and interpreted when it's needed, allowing you to rapidly modify it without needing to recompile the entire game.

Python is amazing for scripts that are also software in their own right, LUA is amazing for snippets (so a layer smaller than scripts), since on that level, none of it's shortcomings are a problem. The C interop and sandbox also makes it fairly easy to set up a DSL/importable module that runs your "main" language if that's what you need as well.

Fair point about the Linux CLI, especially the lack of a comprehensive stdlib. As for the syntax sugar and code terseness, maybe it's just me, but I prefer verbosity over compactness. Surely it takes more time to write and read, but personally it makes it more readable for me.

The title should not start with "Lua" is the point. The logo is just placed there because of the webpage design.

At least not "Lua Programming in Lua"

Out of curiosity: is LuaJIT supporting only 5.1 because of technical difficulties imposed by newer versions, or is it simply that the design of newer Lua versions did not appeal to the LuaJIT maintainers?

Why? Only because of luajit?

> The changes between 5.1 and 5.2 seem small as well.

And then after 5.1, basically every minor version (5.2, 5.3, so on) have major changes between them, from what I recall.

Of course, there is also this (quote from the site):

> If you find this online version useful, please consider buying a copy of the current edition. This helps to support the Lua project.