For me Lua, from a minimalism point of view, feels like the Go of dynamically typed languages.
I love how you can acquire the language easily within a very short period of time (apart from some idioms, which like in other languages take more practice). I appreciate the low number of keywords and that you have only one real way to structure data, through tables. Yet, you can use meta tables to "emulate" classes as blueprints for object creation and even inheritance, if you really need OOP, or for that matter other paradigms. In a way this reminds me of JavaScript prototypes.
As an indie game dev, Love2D really clicked. Lua is awesome as a scripting language inside a host language like C/C++/Rust, because it is simple, intuitive (both for imperative or functional styles) and rather fast.
I'm even using it as my go-to scripting language for the Linux CLI instead of Python. Python, as great as it is, feels sometimes too comprehensive for small scripts. I like to script using a language I can fully keep in my "working memory", without having to refresh my memory about some constructs/idioms. That said, I use Rust as my main statically typed language, so maybe I'm just finding excuses for my love for Lua...
I also think Lua is underrated as a possible first language. Its simplicity, readability and details like using keywords for blocks (do, end, etc) IMO make it suitable for beginners.
I agree on all points, especially the idea of using Lua as a first language. It has so few features that you're really forced to focus on fundamental concepts like functions and (simple) data structures. And its flexibility to be used in an imperative or functional manner is great too. It's almost like a stripped back Javascript, and anyone who learns it will find jumping to JS easy.
I guess one might argue that 1-based indexing could cause beginners to get confused when they move to another language. But maybe it's good for them to get used to the idea that things like this can be different across languages.
> 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.
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.
This point made me think for a while... We're so used to languages with batteries included, like for instance Python which I often compare to Lua, that we assume it's always a good feature to have. It can be, but it's not for free. We definitely become a bit lazy and often turn more into "library users" than coders. It's convenient at first sight, nevertheless a bad habit. There's so much we can learn by implementing our own versions of even the most simple algorithms. In addition to that, our solution is probably going to be leaner, even if not as feature-rich, than the library next door. But then again, we probably don't need most of those features.
I believe we can still do them for fun, for practice. But having them readily available (also, tested) when you are trying to build something is much better.
Both views have valid points. I guess it depends on how quickly you need to get something up and running. Battle-tested libraries definitely have their pros, but then again the surface area for possible bugs is also greater. For sure, most of my code in Rust for instance is quite complex and I wouldn't be able to do it without external crates. That said, in most projects I end up with 300+ indirect dependencies, most of which I don't even know anything about. It adds to compile time, final binary size and most importantly, I'm building my software on top of a huge stack of stuff I don't really know. I guess the higher level we go, the less we can avoid this anyway. Nevertheless some of my points don't necessarily apply to interpreted languages.
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.
I often hear this (probably because PIL is so optimistic about it), but I would say that 1-based indexing is not just a convention, it's a default that's baked into the language:
> array = {"A", "B", "C"}
> array[1]
A
And there's more: built-in functions like ipairs will not work with hacked-up zero indices (which you would have to specify every time you create an array). Overall, straying from the default is not a great idea unless you really need to (like in LuaJIT).
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.
Interesting viewpoint. It is my belief that Lua would be nice as a first language, but maybe this opinion is tainted by all my years of experience in programming. Lua definitely wasn't my first language, I started out with C/C++ and Java, long ago. Nothing beats having first-hand experience as a teacher and thus I'll accept your opinion as something more substantiated than my gut feeling.
I'm quite interested in this topic, since I would like to write a good book to introduce absolute beginners into the world of programming. I have a good and encompassing knowledge about many different languages, nevertheless I lack teaching experience.
In your opinion, which languages are good candidates as a first choice and what do you think about using a Lua game framework, like for instance Love2D to teach programming (instead of raw standalone Lua)? The idea being that instead of clunky low level awkwardness, like string manipulation, students would instead see geometrical shapes moving on a screen with just a bunch of simple and imperative statements. Would that provide a better motivation?
I think if you were going to design a rigorous approach to programming from the ground up as part of a like new quadrivium or something, lua could have a place in it.
But when people decide to learn programming now, they usually have a goal in mind so the best language is the one that lets them keep that objective in focus as they learn. Not necessarily do it most easily: love is good because while making a game with it is a huge undertaking for a novice, they can see the whole time that game-making is what they're building up to.
But for example I've seen rank beginners get really fascinated with data visualization, or interacting with their local government's API, or text generation, or audio stuff. All things that are going to be out of reach for a novice in lua. And a lot of people will show up saying they want to make games, but it's because video games are the one programming artifact they have positive experiences with. Once they start to see the broader possibilities other interests develop.
Anyway I have had a lot of success introducing programming with roblox scripting. It adds a lot of the "missing" lua library features and the script editor is a decent basic IDE that simplifies tooling, another huge pain point for novices.
For non-game focused beginners I've had the best results in ruby. Python works as well once you get going but the whitespace is a frustrating time sink in a classroom environment. In these the strength is being able to grab a library for any API they'd want to work with, and build something that feels like an actual useful tool to them.
> Anyway I have had a lot of success introducing programming with roblox scripting. It adds a lot of the "missing" lua library features and the script editor is a decent basic IDE that simplifies tooling, another huge pain point for novices.
I've had some success introducing programming in Lua to kids (ages 7-12) by way of the OpenComputers Minecraft mod. They were all already into playing modded Minecraft, and getting in-world feedback from running various commands (turning on/off redstone signals, moving around blocks, attacking monsters, etc.) meant that the "boring" time between "hey, let me show you how to program" and something exciting happening was <5 minutes. Beyond Minecraft-specific libraries, the computers in the mod also come with a HTTP client library, an editor and a shell that directly runs Lua scripts.
Yeah, this is one of the situations it makes sense to use lua. They're specifically interested in something that can be accomplished in it, and it's already configured into an environment that mitigates some of its weaknesses as a learning language. Roblox scripting is another area where I've had good results introducing kids to programming.
I remember telling my friend to start his brother on ApplesoftBasic because its batteries included, has no files or libraries, you just do some math and print and draw colored dots and lines and I trained two people like that on an Apple][ emulator with good results.
My friend was like "no way. im gonna start him with something simple like html."
Within seconds he realized he had to explain what paths were, and his brother struggled so much with them. My friend took for granted what he had already spent time learning. He was unable to guess what would be difficult to understand without priors.
Walled gardens like Processing seem to be better for education.
I would absolutely never, EVER encourage the use of a package manager when getting someone accustomed to programming. Why on earth would you do that? The problems that package managers solve are completely orthogonal to the environment of someone who hasn't even built up the intuition for basic things like flipflops, lexical scope, iteration, etc.
Downloading archives with a web browser and extracting them and just doing manual file management is vastly preferable in such an environment. That is a vastly simpler process which is impossible to break, and odds are the student will already be familiar with most of the process.
See my other comment I guess. My experience has been that a lot of the things that motivate beginners are out of reach without using a package. In ruby or python I can say hey just install this thing here's how. Even in JS, it's a bigger hurdle but I can show them npm. Lua has nothing as accessible as this.
Managing archives is not easier in my experience, for the format I teach. Students are not necessarily using the same packages, not all on the same OS, and familiarity with manually managing files cannot be assumed. Probably the majority of middle schoolers I teach do not have that skill coming into my class, high school maybe 50/50.
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.
Types/type checking would also be nice. Luau does seem to offer some level of static typing, but it isn't used by a whole lot that I've seen.
That said, I think a lot of people are also glad it doesn't include much, because one of the biggest draws of Lua is that it's extremely compact and embeddable. And I do understand that, too. I remain a huge fan of Love2d even though I haven't actually released anything with it.
> 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 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 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.
Yeah, they definitely won on the embed side. Ruby was also designed for this use case, though I can't think of too many examples, which may hint that the small size and footprint of Lua was important. (There's RGSS in RPG Maker XP.)
Lua on the other hand is all over the place. Wireshark dissectors, OpenResty, game engines, and tons more.
That said, it seems like almost everyone is still embedding Lua 5.1 or forks of it like LuaJIT, and I think a lot of game engine people want slightly different things out of Lua than what it offers, hence offshoots like Luau, GameMonkey script, and Squirrel lang. Maybe it's good that Lua doesn't try to be all things to all people, since it has broad applicability, but it does feel, at least to me, like things could be better. For example, at least having a syntax for types that could be checked externally, like Python. The core shouldn't be bloated up with a module system and package manager, but a CLI tool with that functionality certainly would be nice, could probably be written in Lua. And I do understand why people don't want an all-encompassing standard library, but not having bitwise operators in the language or standard library can be a bit of a drag. That's just my thoughts on the matter, anyway.
For every new language I learn, there's a task I eventually want for various purposes, and that's to use whatever reflection system that is available to traverse data structures in memory, and at the very least, dump a log of those structures to a certain depth.
C# took about 2h to do this acceptably.
Javascript took 4h or so and I'm still not happy with it. Too many warts and odd ways of accessing arrays etc...
Lua took 30 minutes and it just worked perfectly. There was nothing left to do. it's just so simple.
I love Lua (LuaJIT is great for many reasons, I love its FFI and its high efficiency), and Go, they are simple and easy to be productive in them, for sure.
Lua is definitely a likeable language and due to its (very) limited nature can be used as a first language.
But as a Linux CLI lang, or for simple one-off scripts... Python is better. Scripts (and also competitive programming) favour languages capable of compact solutions and universal stdlib. Lua, because is has no stdlib to speak of and a limited amount of syntax sugar. It is just so much less useful for these purposes.
As for competitive flavours of programming... I recently gave it a go for Advent of Code 2024.
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.
I work in Lua every day as a game developer. A GOTY in 2023 being my highest achievement so far. By and large Lua just gets out of the way, which is the most important thing for me.
I have some minor issues with it, nothing huge, and I work around them with some utility functions that I've created or collected over the years.
The most recent edition of this book is from 2016. Surely time for a new edition.
First off, congrats and feel free to share a link to your game here as I got interested.
I totally resonate with your comment about the language not getting in your way. I use all sorts of languages for different kinds of applications for many years and only recently I started creating games.
Whereas in other domains I appreciate complex languages that address necessarily complex tasks, in game development, while the game as a whole is a complex system, you often are handling simpler tasks and mostly thinking about algorithms. At least in my experience tackling these algorithms requires mostly mathematical calculations and for that, you definitely want the language to stay out of your way.
In game dev no matter if you pick an imperative or functional approach, you really need to use all your brain power on your problem domain. Language complexities are often distractions that aren't super useful, since like I already said, the task at hand is mainly algorithmic in nature.
My experience is the same as you describe: I want to think about algorithms, state machine, system structure, design, the... game. Rather than the language semantics, quirks, or fancy features. 100% agree with you.
This the latest edition I know about being online somewhere: https://archive.org/details/pil-4th (Programming In Lua - Fourth edition, for Lua 5.3, 2016)
I'm not sure there is a fifth edition (for Lua 5.4) but the manual/reference + fourth edition seems good enough for at least my usage: https://www.lua.org/manual/5.4/manual.html
Back in 2019, a group of students was organizing a week of computer science in my university (IME-USP) and they were collecting suggestions. I suggest to bring Roberto to talk something about Lua without hope that the suggestion would be accepted and that he would come. And when I checked the schedule I saw that he would present in that week.
Not only that, the day before his presentation the professors of our department arranged an informal conversation with him, and I was there. Lua is probably one of software projects that I admire the most due to it has been created to solve a problem and that solves it well, without trying to be more than that. Seeing Roberto speaking about it so close was really a memorable moment.
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?
There is design tension between the language designer and the VM implementation. AFAIK some features post 5.1 make performant VM implementations difficult. Lua is originally a configuration language where performance didn't matter all that much. Because Luajit is so fast much more of the application code can be done in the scripting environment so now the performance matters much more than it did.
So the spectrum is from newer language and slower to older language and faster. If performance is an issue the cost of the newer language features could be that more of the application code has to be written in C++ instead of Lua - in that context the Lua language shouldn't be considered independent of the host language. Performance matters to me so increase in C++ code would not be worth the newer language features. Using Rust instead of C++ as the host language might change the landscape again since Rust is so much more ergonomic than C++.
It's the only edition which is provided for free. This edition uses Lua 5.0, which is very similar to 5.1 which is still very popular as it's targeted by LuaJIT. The changes between 5.1 and 5.2 seem small as well.
Their defence is always that they do not follow semver.
I remember some undocumented edge cases in string match patterns breaking between 5.1 and 5.2. Imagine Python changing how regexes worked between two minor releases.
> Their defence is always that they do not follow semver.
"Defence"? Seems like the correct answer and a fact, Lua doesn't do semver, so when there are major changes between 5.3 and 5.4, it's not illogical or actually breaking semver, as they don't follow it.
Plenty of projects don't follow semver, and that's perfectly fine.
On Aardwolf (a MUD), Lua is our main scripting language and it is amazing what people who come into the game not knowing how to program have been able to create with it, way beyond anything we envisioned.
It is lightweight when not in use and integrates perfectly with the core C codebase.
If I had to pick one single thing that has had the most impact in our game over the 25 years we have been around it would be moving all of our in-game scripting to Lua.
For me Lua, from a minimalism point of view, feels like the Go of dynamically typed languages.
I love how you can acquire the language easily within a very short period of time (apart from some idioms, which like in other languages take more practice). I appreciate the low number of keywords and that you have only one real way to structure data, through tables. Yet, you can use meta tables to "emulate" classes as blueprints for object creation and even inheritance, if you really need OOP, or for that matter other paradigms. In a way this reminds me of JavaScript prototypes.
As an indie game dev, Love2D really clicked. Lua is awesome as a scripting language inside a host language like C/C++/Rust, because it is simple, intuitive (both for imperative or functional styles) and rather fast.
I'm even using it as my go-to scripting language for the Linux CLI instead of Python. Python, as great as it is, feels sometimes too comprehensive for small scripts. I like to script using a language I can fully keep in my "working memory", without having to refresh my memory about some constructs/idioms. That said, I use Rust as my main statically typed language, so maybe I'm just finding excuses for my love for Lua...
I also think Lua is underrated as a possible first language. Its simplicity, readability and details like using keywords for blocks (do, end, etc) IMO make it suitable for beginners.
I agree on all points, especially the idea of using Lua as a first language. It has so few features that you're really forced to focus on fundamental concepts like functions and (simple) data structures. And its flexibility to be used in an imperative or functional manner is great too. It's almost like a stripped back Javascript, and anyone who learns it will find jumping to JS easy.
I guess one might argue that 1-based indexing could cause beginners to get confused when they move to another language. But maybe it's good for them to get used to the idea that things like this can be different across languages.
> 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.
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.
This point made me think for a while... We're so used to languages with batteries included, like for instance Python which I often compare to Lua, that we assume it's always a good feature to have. It can be, but it's not for free. We definitely become a bit lazy and often turn more into "library users" than coders. It's convenient at first sight, nevertheless a bad habit. There's so much we can learn by implementing our own versions of even the most simple algorithms. In addition to that, our solution is probably going to be leaner, even if not as feature-rich, than the library next door. But then again, we probably don't need most of those features.
I believe we can still do them for fun, for practice. But having them readily available (also, tested) when you are trying to build something is much better.
Both views have valid points. I guess it depends on how quickly you need to get something up and running. Battle-tested libraries definitely have their pros, but then again the surface area for possible bugs is also greater. For sure, most of my code in Rust for instance is quite complex and I wouldn't be able to do it without external crates. That said, in most projects I end up with 300+ indirect dependencies, most of which I don't even know anything about. It adds to compile time, final binary size and most importantly, I'm building my software on top of a huge stack of stuff I don't really know. I guess the higher level we go, the less we can avoid this anyway. Nevertheless some of my points don't necessarily apply to interpreted languages.
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.
I often hear this (probably because PIL is so optimistic about it), but I would say that 1-based indexing is not just a convention, it's a default that's baked into the language:
And there's more: built-in functions like ipairs will not work with hacked-up zero indices (which you would have to specify every time you create an array). Overall, straying from the default is not a great idea unless you really need to (like in LuaJIT).Yes, it's technically possible, but indeed it's such a default that no one really tries to fight it.
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.
Interesting viewpoint. It is my belief that Lua would be nice as a first language, but maybe this opinion is tainted by all my years of experience in programming. Lua definitely wasn't my first language, I started out with C/C++ and Java, long ago. Nothing beats having first-hand experience as a teacher and thus I'll accept your opinion as something more substantiated than my gut feeling.
I'm quite interested in this topic, since I would like to write a good book to introduce absolute beginners into the world of programming. I have a good and encompassing knowledge about many different languages, nevertheless I lack teaching experience.
In your opinion, which languages are good candidates as a first choice and what do you think about using a Lua game framework, like for instance Love2D to teach programming (instead of raw standalone Lua)? The idea being that instead of clunky low level awkwardness, like string manipulation, students would instead see geometrical shapes moving on a screen with just a bunch of simple and imperative statements. Would that provide a better motivation?
I think if you were going to design a rigorous approach to programming from the ground up as part of a like new quadrivium or something, lua could have a place in it.
But when people decide to learn programming now, they usually have a goal in mind so the best language is the one that lets them keep that objective in focus as they learn. Not necessarily do it most easily: love is good because while making a game with it is a huge undertaking for a novice, they can see the whole time that game-making is what they're building up to.
But for example I've seen rank beginners get really fascinated with data visualization, or interacting with their local government's API, or text generation, or audio stuff. All things that are going to be out of reach for a novice in lua. And a lot of people will show up saying they want to make games, but it's because video games are the one programming artifact they have positive experiences with. Once they start to see the broader possibilities other interests develop.
Anyway I have had a lot of success introducing programming with roblox scripting. It adds a lot of the "missing" lua library features and the script editor is a decent basic IDE that simplifies tooling, another huge pain point for novices.
For non-game focused beginners I've had the best results in ruby. Python works as well once you get going but the whitespace is a frustrating time sink in a classroom environment. In these the strength is being able to grab a library for any API they'd want to work with, and build something that feels like an actual useful tool to them.
> Anyway I have had a lot of success introducing programming with roblox scripting. It adds a lot of the "missing" lua library features and the script editor is a decent basic IDE that simplifies tooling, another huge pain point for novices.
I've had some success introducing programming in Lua to kids (ages 7-12) by way of the OpenComputers Minecraft mod. They were all already into playing modded Minecraft, and getting in-world feedback from running various commands (turning on/off redstone signals, moving around blocks, attacking monsters, etc.) meant that the "boring" time between "hey, let me show you how to program" and something exciting happening was <5 minutes. Beyond Minecraft-specific libraries, the computers in the mod also come with a HTTP client library, an editor and a shell that directly runs Lua scripts.
Yeah, this is one of the situations it makes sense to use lua. They're specifically interested in something that can be accomplished in it, and it's already configured into an environment that mitigates some of its weaknesses as a learning language. Roblox scripting is another area where I've had good results introducing kids to programming.
I remember telling my friend to start his brother on ApplesoftBasic because its batteries included, has no files or libraries, you just do some math and print and draw colored dots and lines and I trained two people like that on an Apple][ emulator with good results.
My friend was like "no way. im gonna start him with something simple like html."
Within seconds he realized he had to explain what paths were, and his brother struggled so much with them. My friend took for granted what he had already spent time learning. He was unable to guess what would be difficult to understand without priors.
Walled gardens like Processing seem to be better for education.
I would absolutely never, EVER encourage the use of a package manager when getting someone accustomed to programming. Why on earth would you do that? The problems that package managers solve are completely orthogonal to the environment of someone who hasn't even built up the intuition for basic things like flipflops, lexical scope, iteration, etc.
Downloading archives with a web browser and extracting them and just doing manual file management is vastly preferable in such an environment. That is a vastly simpler process which is impossible to break, and odds are the student will already be familiar with most of the process.
See my other comment I guess. My experience has been that a lot of the things that motivate beginners are out of reach without using a package. In ruby or python I can say hey just install this thing here's how. Even in JS, it's a bigger hurdle but I can show them npm. Lua has nothing as accessible as this.
Managing archives is not easier in my experience, for the format I teach. Students are not necessarily using the same packages, not all on the same OS, and familiarity with manually managing files cannot be assumed. Probably the majority of middle schoolers I teach do not have that skill coming into my class, high school maybe 50/50.
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.
Types/type checking would also be nice. Luau does seem to offer some level of static typing, but it isn't used by a whole lot that I've seen.
That said, I think a lot of people are also glad it doesn't include much, because one of the biggest draws of Lua is that it's extremely compact and embeddable. And I do understand that, too. I remain a huge fan of Love2d even though I haven't actually released anything with it.
> 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 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 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.
Yeah, they definitely won on the embed side. Ruby was also designed for this use case, though I can't think of too many examples, which may hint that the small size and footprint of Lua was important. (There's RGSS in RPG Maker XP.)
Lua on the other hand is all over the place. Wireshark dissectors, OpenResty, game engines, and tons more.
That said, it seems like almost everyone is still embedding Lua 5.1 or forks of it like LuaJIT, and I think a lot of game engine people want slightly different things out of Lua than what it offers, hence offshoots like Luau, GameMonkey script, and Squirrel lang. Maybe it's good that Lua doesn't try to be all things to all people, since it has broad applicability, but it does feel, at least to me, like things could be better. For example, at least having a syntax for types that could be checked externally, like Python. The core shouldn't be bloated up with a module system and package manager, but a CLI tool with that functionality certainly would be nice, could probably be written in Lua. And I do understand why people don't want an all-encompassing standard library, but not having bitwise operators in the language or standard library can be a bit of a drag. That's just my thoughts on the matter, anyway.
For every new language I learn, there's a task I eventually want for various purposes, and that's to use whatever reflection system that is available to traverse data structures in memory, and at the very least, dump a log of those structures to a certain depth.
C# took about 2h to do this acceptably. Javascript took 4h or so and I'm still not happy with it. Too many warts and odd ways of accessing arrays etc...
Lua took 30 minutes and it just worked perfectly. There was nothing left to do. it's just so simple.
I love that about it.
I love Lua (LuaJIT is great for many reasons, I love its FFI and its high efficiency), and Go, they are simple and easy to be productive in them, for sure.
Lua is definitely a likeable language and due to its (very) limited nature can be used as a first language.
But as a Linux CLI lang, or for simple one-off scripts... Python is better. Scripts (and also competitive programming) favour languages capable of compact solutions and universal stdlib. Lua, because is has no stdlib to speak of and a limited amount of syntax sugar. It is just so much less useful for these purposes.
As for competitive flavours of programming... I recently gave it a go for Advent of Code 2024.
My impressions: https://www.reddit.com/r/adventofcode/comments/1hvnou1/2024_...
My repo: https://github.com/vkazanov/advent-of-code-2024?tab=readme-o...
TL;DR Python is better here.
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.
I feel like most languages are easy to learn. There's only so many ways to write a parser.
It's the standard library that forms the "grammar" of the language and is often the hardest part to incorporate.
I work in Lua every day as a game developer. A GOTY in 2023 being my highest achievement so far. By and large Lua just gets out of the way, which is the most important thing for me. I have some minor issues with it, nothing huge, and I work around them with some utility functions that I've created or collected over the years.
The most recent edition of this book is from 2016. Surely time for a new edition.
First off, congrats and feel free to share a link to your game here as I got interested.
I totally resonate with your comment about the language not getting in your way. I use all sorts of languages for different kinds of applications for many years and only recently I started creating games.
Whereas in other domains I appreciate complex languages that address necessarily complex tasks, in game development, while the game as a whole is a complex system, you often are handling simpler tasks and mostly thinking about algorithms. At least in my experience tackling these algorithms requires mostly mathematical calculations and for that, you definitely want the language to stay out of your way.
In game dev no matter if you pick an imperative or functional approach, you really need to use all your brain power on your problem domain. Language complexities are often distractions that aren't super useful, since like I already said, the task at hand is mainly algorithmic in nature.
My game is called YOYOZO https://news.ycombinator.com/item?id=38372936
My experience is the same as you describe: I want to think about algorithms, state machine, system structure, design, the... game. Rather than the language semantics, quirks, or fancy features. 100% agree with you.
This the latest edition I know about being online somewhere: https://archive.org/details/pil-4th (Programming In Lua - Fourth edition, for Lua 5.3, 2016)
I'm not sure there is a fifth edition (for Lua 5.4) but the manual/reference + fourth edition seems good enough for at least my usage: https://www.lua.org/manual/5.4/manual.html
The most recent edition of this book is indeed from 2016.
One of the lesser known parts of Lua is that it has its own pattern matching language!
https://www.lua.org/pil/20.1.html
It is not as powerful as regexp, but it's a huge step up for string munging over raw find/substr.
Sometimes I look back with nostalgia to a past role I had and then realize the only thing I miss is Lua, and the salary.
Learned to write code with Roberto, the founder of lua, in my graduation but only found out about that once I had already graduated.
Really good teacher.
I can only imagine how good he is a teacher.
Back in 2019, a group of students was organizing a week of computer science in my university (IME-USP) and they were collecting suggestions. I suggest to bring Roberto to talk something about Lua without hope that the suggestion would be accepted and that he would come. And when I checked the schedule I saw that he would present in that week.
Not only that, the day before his presentation the professors of our department arranged an informal conversation with him, and I was there. Lua is probably one of software projects that I admire the most due to it has been created to solve a problem and that solves it well, without trying to be more than that. Seeing Roberto speaking about it so close was really a memorable moment.
This is from 2003 (December, so it's about 21 years ago). Is it still relevant?
Yes. The differences between 5.0 and 5.1 are small and I do not recommend using newer versions, regardless.
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?
Mike Pall (LuaJIT author/maintainer) is not happy with some of the design decisions and (breaking) changes:
https://www.freelists.org/post/luajit/Port-bitop-to-53,1
The biggest issue certainly is the addition of integer types.
Why? Only because of luajit?
most likely,also sadly
what's wrong with luajit ? (I never used it)
edit: sorry I should have searched, Luajit only supports up to Lua 5.1
There is design tension between the language designer and the VM implementation. AFAIK some features post 5.1 make performant VM implementations difficult. Lua is originally a configuration language where performance didn't matter all that much. Because Luajit is so fast much more of the application code can be done in the scripting environment so now the performance matters much more than it did.
So the spectrum is from newer language and slower to older language and faster. If performance is an issue the cost of the newer language features could be that more of the application code has to be written in C++ instead of Lua - in that context the Lua language shouldn't be considered independent of the host language. Performance matters to me so increase in C++ code would not be worth the newer language features. Using Rust instead of C++ as the host language might change the landscape again since Rust is so much more ergonomic than C++.
It's the only edition which is provided for free. This edition uses Lua 5.0, which is very similar to 5.1 which is still very popular as it's targeted by LuaJIT. The changes between 5.1 and 5.2 seem small as well.
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.
> 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.
Their defence is always that they do not follow semver.
I remember some undocumented edge cases in string match patterns breaking between 5.1 and 5.2. Imagine Python changing how regexes worked between two minor releases.
> Their defence is always that they do not follow semver.
"Defence"? Seems like the correct answer and a fact, Lua doesn't do semver, so when there are major changes between 5.3 and 5.4, it's not illogical or actually breaking semver, as they don't follow it.
Plenty of projects don't follow semver, and that's perfectly fine.
On Aardwolf (a MUD), Lua is our main scripting language and it is amazing what people who come into the game not knowing how to program have been able to create with it, way beyond anything we envisioned.
It is lightweight when not in use and integrates perfectly with the core C codebase.
If I had to pick one single thing that has had the most impact in our game over the 25 years we have been around it would be moving all of our in-game scripting to Lua.
I love Lua for the same reason I love Go.
PSA: if you are using (modern) C++, https://github.com/ThePhD/sol2 makes embedding Lua incredibly easy and straightforward.
Lua is nice on small platforms like a Motorola 68030.
Title should be just "Programming in Lua".
We've popped the first Lua off the title now. Thanks!
(Submitted title was "Lua Programming in Lua (first edition) (2003)")
No, it is the first edition, there are newer editions
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"
Lua Programming in Lua with Lua