Lua's presence is honestly hugely because it is so easy to embed in other programs. If you needed some scripting capabilities, Lua was the way. Whether it's a webserver (nginx) or editor (vim) or a window manager (awesome), Lua was the easiest & best at hand option to integrate.
There is a huge opportunity, IMO, for more players here. Deno definitely has some good gestures toward a this. Wasm though seems like the likely general heir, and will have many different offerings for how to do that (Deno being one!).
> hugely because it is so easy to embed in other programs
Not only; Lua is also an example of excellent language design: a minimum of concepts for a maximum of expressability; it's minimal, complete and elegant.
> Deno definitely has some good gestures toward a this
Lua is much leaner, only ~100k machine code. WAMR looks like a better candidate than Deno, but concerning performance and simplicity it has still to catch up.
I think a "competitor" to Lua would be Guile [1], but I am not sure if it gets close to Lua in terms of lightweightness... it was designed to be used in the GNU project, with similar objects as Lua: to be light, easily embeddable. It's a Scheme (Lisp) so maybe not for everyone's taste... its "coolest" use i know of is for configuring Guix [2] (the GNU version of Nix).
The competitors in practice were REXX and TCL. All three provide embeddable interpreters as libraries, and easy ways to extend what is available in scripts with custom domain-specific functions that one could call from them.
I've just used `cloc`-ed Lua repo's entire code base, excluding makefile's and markdown's: 33619 lines in total of C, Lua, and C / C++ Header code; very lightweight code base.
TCL, Forth and Lisp are languages with minimum possible syntax, delegating all higher-level concepts to runtime structures and conventions (e.g. which list position means what), whereas Lua for its syntax and semantics inherited, pruned and elegantly integrated the best features of Modula-2 and other languages. It is true that Lua is more familiar to C developers than the mentioned languages, since both Lua and C look back to the ALGOL ancestry; but Lua - unlike C - clearly follows the Pascal heritage.
mruby[1] fits that category too. It can be used with H2O[2] server as well. There was a discussion here a couple of months ago regarding some use cases[3].
It's not just that it's easy to embed but it's also tiny as well, I've run it on many embedded platforms. It wasn't until quickjs came along that there was anything even in the same ballpark.
When you factor in LuaJIT[1] and the incredible performance/zero-overhead-FFI[2] it really is a neat language.
How timely! Right now I'm learning Lapis [1] by building a toy CRUD app that I plan on deploying to fly.io. Lua reminds me of Go insofar as it's a really "dumb" language. You can't get too cute and there are a few powerful abstractions that let you accomplish a lot. Coming from Python (which is an endless horizon of PEPs and build artifact standards and name mangling and kwargs and... well, you get the idea) it's kind of a breath of fresh air.
As for 1-based indexing: it makes more sense. We're all just used to 0-based because that's how C worked. If you stop and think about it early C was really just a veneer on top of assembly and since addressing an array in memory meant having a pointer to the first element that meant that it was arr[0]. We have no need for this decades later.
Oh you can totally get too cute with metatables. I've seen inheritance/straight-OO(Java/C++ style), component based design, and eventing/message based approaches all with the core primitives that Lua provides.
I think my favorite one was one that used yield[1] with the parameters being the number of frames to resume the execution of the coroutine. That was used by a number of our game designers to write AI scripting that felt close to literate programming(I.E. "move x, look for player, yield 30, if found player, go here, etc). You could build a whole AI state machine that fit into one page of code and was very easy to follow.
Years ago I wrote a DNS-over-HTTPS proxy as an nginx / OpenResty module in Lua. The Lua code included a very stripped-down DNS message parser. The 1-based indexes and closed (instead of half-open) intervals were a massive pain in the arse. The code has a tricky mixture of odd and even offsets that would all have been even in C, and it would have been much easier to replace the magic numbers with named constants.
> There is a huge opportunity, IMO, for more players here.
There are quite a few embeddable scripting languages [1]. I think these days it's less common to embed a language mostly because there are good high-level languages that applications can be predominantly written in.
But that's just how Lisp works. Emacs Lisp (not CL) uses those too. It's Scheme that decided to rename car and cdr (and by doing so obscure how things are implemented underneath).
Okay, you're right. They are there as well. And actually the "first" and "rest" functions aren't even standard but are just there in some implementations as synonyms.
Sure, but that's no reason to keep carrying past mistakes.
I don't understand why languages don't have a 'version' id as the very first thing, and then you can run appropriate interpreter/compiler given the version.
New versions of the language can drop historical mistakes.
You could kick-start the process in any existing language by making a next release that requires a version tag (and which maybe strips out a ton of legacy cruft). It would then default to a 'legacy' interpretation if the tag isn't present.
> I don't understand why languages don't have a 'version' id as the very first thing, and then you can run appropriate interpreter/compiler given the version.
Common Lisp may have that. My Symbolics Lisp Machine runs six different Common Lisp variants and additionally ZetaLisp side by side in one system.
There are often feature symbols which note language versions: CLtL1, CLtL2, ANSI90, ANSI-CL. It also has packages, where LISP will mean symbol table with CLtL1 symbols and COMMON-LISP will mean a symbol table with CLtL2 symbols.
> New versions of the language can drop historical mistakes.
Lisp may not work that way:
Lisp is not just a language, it is a running system. One can load many different libraries and programs into one running Lisp. Some older code will use CAR/CDR and some newer code won't. It still runs side by side in the same ONE environment and will call each other.
I can for example say:
#+ansi-cl (print "this is code for an ANSI CL compatible Common Lisp")
#-ansi-cl (error "this is Common Lisp does not support ANSI CL")
This will check if the Common Lisp has the features ANSI-CL.
Since cons cells and lists made of cons cells are so fundamental to Lisp, that it would be painful to support software where such a core data structure would be changed (for example by renaming the core operators).
Again, code from several decades with different language variants can be running in one Lisp.
In TXR Lisp, I made ^ quasiquote. That wasn't some run-to choice or anything; there is a history behind it. Before there as a TXR Lisp, only TXR, backquote was used for interpolated strings: `@foo @bar`, so the character was not available for quasiquoting.
In hindsight, ^ is nice because it stands out. I might have been influenced by ^ptr syntax from Pascal for dereferencing a pointer. Or exponentiation in some languages x^2. Hat denotes "power" and quasiquote is power!
(For a while I experimented with an idea of making regular quote ' somehow intelligent so it could do quasiquoting when unquotes are present. The semantic restrictions are too severe though and cannot be fixed: e.g. you can't do the equivalent ^(foo '(bar ,unquote-here)) with '(foo '(bar ,unquote-here)) where the unquote isn't going to the quote that we want.)
Because @ is significant, I had to turn ,@ into ,*. That's not too bad because * already denotes repetitions in regex: zero or more. And splicing brings in zero or more, so ...
The only issue is that if you want to interpolate a special variable, you have to write , *foo* and not ,*foo, because the latter actually means , foo*.
Common Lisp has the same issue with @, but @ isn't a popular symbol prefix, so it rarely comes up:
[1]> (defvar @foo@ '(1 2 3))
@FOO@
[2]> `'(,@foo@)
*** - SYSTEM::READ-EVAL-PRINT: variable FOO@ has no value
[...]
[4]> `'(, @foo@)
'((1 2 3))
For many purposes, Starlark[1] could be used as an alternative to Lua. It's also designed to be embedded, it's a very simple language, and has 3 implementations (in Java, in Go and in Rust).
Easy embedding is one of the goals of FixScript [1] (my language). It consists of a single C file (and a header). It even includes a JIT while not being gigantic. It also provides a more direct C API which I think is more friendly for embedding.
It has strong support for backward and forward compatibility, a great feature for embedding usage to not make your scripts obsolete and generally working in any version of the host application.
> Wasm though seems like the likely general heir, and will have many different offerings for how to do that (Deno being one!).
I was recently blown away by some ideas that StackBlitz [0] apply based on WebContainers. The idea of a "server in the browser", they allow you to run Node-based environment like that via Wasm.
Anytime Lua comes up I'm reminded of John Earnest's Lil scripting language[1]. It's inspired by Lua and Q, built for Decker[2] which is a re-imagined version of HyperCard. Generally though, I love lua for its embeddability and am extremely happy anytime I see someone chatting about integrating it. Modding and scripting in games was a tremendous motivation for me to dig more into programming and these approachable languages are a core aspect of that.
For anyone looking for a HTTP server, or a Lua runtime with batteries included, have a look at the Mako Server[1]. It's really wonderful to work with.
I've automated my house based on it. It includes everything you may need , from JSON to TLS, email to websockets... all in a tiny 3MB binary, including the Lua interpreter!!
I run it on a Raspberry Pi and the process takes around 3MB of RAM. Just unbelievable comparing to anything like Node.JS or Java which would require a few 100's MB.
Click on "Okay, Got it" big button and you can follow along the tutorials, edit code on a demo server, which is how I actually developed my stuff... I actually used a mix of the online editor and editing the Lua files via SSH in emacs, via TRAMP. I highly recommmend either approach.
It is inevitable that people complain about Lua's 1-based "tables" which serve as both arrays and hash maps.
I usually encourage people to remember the practical origins of 0-based arrays when thinking in terms of pointers, where 0-based counting is useful in terms of talking about offsets from a point in memory, as contrasted to 1-based counting where you are primarily talking about quantities of collections.
Lua is a great language. My only wish is that it was easier to do multithreaded work in it. Unfortunately, this is not the case without some significant architectural forethought.
The reason why 0 makes sense for pointers isn't due to some arcane implementation detail of programming but because of how one conceptualizes ranges and distance and pointers just so happen to be a place where that comes up very directly in programming. Any time you attempt to develop an algorithm that needs to think about multiple ranges of a collection at the same time or needs to scale ranges through a collection, 1-based indexing causes you to have to throw in a bunch of +/-1 compensation factors to prevent you from double-counting or scaling past an edge. Life is just too short to have to constantly debug the issues that come from 1-based indexing when developing complex algorithms, even if it means beginners feel a bit confused by "counting from 0".
No, it actually does originate from 1960's era programming practices. Not to say there weren't also 1-based or N-based numbering, but you're historically misled here.
You could also say the same about counting collections. No regular person counts 0... 1... 2... 3... and ends counting N-1. It, too, is a workaround.
I don't think 0-based was ever
as common a practice as it is today, especially in the 60s. In the beginning there were two camps fighting which system was to be preferred and there were many more 1-based or agnostic languages (like the whole Pascal family). "Numerical Recipes" a pretty popular book for some time even came in two editions, a 0-based and a 1-based version. I think the victory of C had a big influence on 0-based winning.
Personally I find it very sad that the agnostic approach of Pascal did not prevail. Let the programmer decide what they think fits the situation best and let the compiler deal with the technicalities. This, and I also miss range types... for like 40 years now...
> Personally I find it very sad that the agnostic approach of Pascal did not prevail. Let the programmer decide what they think fits the situation best and let the compiler deal with the technicalities. This, and I also miss range types... for like 40 years now...
I am with you there. However, Pascal, a toy Algol, was designed to be a language for a compiler course. It took its ideas like "where does an array start" from other Algol implementations and added a broken type system. Pascal gets the love now, as witnessed by the Lua designers referring to Pascal and not to Algol.
I wouldn't call assembly 0-based. Sure, the zero flag is convenient for branching on zero when counting backwards but what makes assembly 0-based apart from that? I'd say having a pointer to the first element of an array is pure convention and you could as easily point it to the imaginary element before, similar to how the program counter always points to the next imaginary instruction on most architectures.
The offset addressing modes all start from zero. You could hack around it in some places by storing the pointer to an element before but that's clearly going against how it is intended to be used.
For example if you have an array that you cast between different sized types (e.g. uint64 to uint8) then you have to change the pointer value!
I think so, too, but my point is that it makes sense for other historical reasons—not the one the poster mentions. Those decisions weren't made due to mathematics.
Agree. I came here to say that 0-based is more sensible, but as I thought through my arguments, I realised that I’m wrong. I do most of my coding in TS, Go and plpgsql. PL is 1 based, but the only time I find it frustrating is when translating between language boundaries. The rest of the time it’s just convention (eg, using <= instead of < in loops).
But I realised that I frequently want to get the last element in an array, and of course it’s easier with 1-based arrays.
So ultimately I don’t think it matters, except that most people are used to 0-based which can cause cognitive friction.
We aren't talking about counting. We are talking about indexing.
Most programs don't need numeric indexing. They can either treat indices as opaque keys or they can use a foreach loop to avoid touching indices at all (or friends like map, filter, zip, and so forth). Even in an old language like C the only place indices usually matter is in the first line of a for loop. But sometimes you really do need numeric indices, and when you do zero-based indices are almost always cleanest.
Just think of how gnarly a flat 2D array would be if you had to use one-based indices. Gross!
You are right, but the thing that is wrong is that the word "first" is associated with the number 1!
Think about it. Natural language could easily have associated the initial ordinal with 0. Let's call it the Nilth (zeroth is really hard to say).
The nilth element is element 0, the first element is element 1, etc.
The winner of a race is in nilth place. Silver goes to the person who came first. Bronze so second.
You walk in to a building on the nilth floor, climb the stairs to the first floor (that might sound weird to Americans but it's how it works in other parts of the world).
This is probably all sounding crazy to you but it's way more elegant and self-consistent.
Some of us Americans know our elevator numbers are wrong — zero / nilth is the correct ground floor by far! — but that doesn’t mean when you pick up the first apple in a bowl of apples you should rename it to nilth. Counting order is different from Indexing order. One is the order of objects in a list and the other is the offset (2nd floor is two floors up from zero). They are just different things and that is why they sound right in different contexts!
[0] just means the address of the element is ptr+0. The first element is at the address from a memory addressing perspective it makes sense that it would be at [0]
> 1-based indexing causes you to have to throw in a bunch of +/-1 compensation factors to prevent you from double-counting or scaling past an edge.
Way back then, I started with Algol 68, moved on to Turbo Pascal, and finally Fortran (I was young and needed the money). My vectors and arrays started at 1, as was the default, and I do not even know what you allude to. The first element has the index 1. Since there is no zeroth element - neither in language nor in thinking -, starting at 0 is what causes problems. You always have to use a corrective term in your head - the element five elements after the third one has index 7.
My experience is that the +-1s come up less often in 1-based languages if you're writing high-level code, and when they do they're more intuitive to catch, even after years and years of coding 0-based.
The problem with 1-based arrays is that it makes the offset and location be different. For example, we want to place an item into a simple circular buffer with zero-based indexing:
arr[idx mod capacity] = 123
Now with 1-based indexing:
arr[(idx-1) mod capacity + 1] = 123
This is absolutely makes it a PITA if you're working with things like bitmaps, blending, or sound mixing. If you only need a language for high-level scripting, then it indeed is not such a big deal.
> Weird then that scientific computing languages prefer 1 based arrays.
Not really when the code is routinely transcribed from papers, and the ages-old convention throughout mathematics is one-based indexing, both bounds of the interval included. (With the notable exception of Euler’s beta and gamma functions.) Of course, in a paper intended for a human reader the occasional off-by-one error is much less dire than in code, so the author is freer to use a more error-prone convention.
I once had to translate from a one-based paper to zero-based Python code (with the added bonus of different discrete Fourier conventions *shudder*), and it’s remarkably annoying even if the resulting code is more obviously correct than the paper’s original formulas.
I've been working on a PR to document and make atomic pointer interface public in Julia. It's really not that hard to handle it under the hood so that array indexing and translates to LLVM and C zero indexing.
Lua tables support do 0 as an index. You can also use negative numbers or floating point numbers, which can be convenient for some applications.
One issue with using them that way is that some Lua idioms don't work as expected. For example, "for i,v in ipairs(t) do ... end" will start iteration with i=1 and stop when it reaches an index that isn't present. Also the length operator (#) won't work as expected.
Just reading the comments here, x seems to always be a hashmap. It is implied that there's no fundamental array type in the language. So no, x[0] and x[1] do not refer to the same variable, although they certainly could compare the same depending on their specific values.
The point here is that with the Lua code the CPU is doing some extra work because mod is 0 based because of mathematics and Lua is 1 based by design.
However mod itself is doing extra work compared to incrementing a counter by one.
This is pseudocode because I don't use Lua much and I don't have the time to check the syntax now, but it should give the general idea
class CircBuf(size)
buf = new Array(size)
i = 1
add(value)
buf[i] = value
if i == size
i = 1
else
i = i + 1
The relative efficiency boils down to a comparison+increment vs mod on the particular CPU the code is running on. Mod should be a division, unless size is a power of two.
It is potentially odd (or even) but nothing compared to everything else when it comes to programming oddities or quirks.
What is the first item in this collection? Oh that would be the one in the box marked zero unless it should be in the one marked ... one!
You mention a circular buffer as an outlier but you simply have to decide where it (the buffer) started off life - 0 or 1 or something else. Make sure that when it is defined, everyone agrees on offsets and off you trot.
No it isn't particularly easy but then bitmaps and blending and sound mixing involve some very involved concepts that are way more complicated than sorting array bounds and worrying about where you are on the Magic Roundabout.
It's cute that you can do this, but it's not a practical solution, so I don't really know why people keep bring this up.
As shown by your example, arrays constructed the native way will start at 1. So you're going to need to make your own custom constructor which means additional overhead.
Also, all built-in functions that expects 1-based arrays will completely break:
for _, value in ipairs({[0]="foo", [1]="bar"}) do print(value) end
This will print "bar"
And even if you still insist on pushing through all of this friction by handrolling your own stdlib, everything is out of the window once you interact with any external library that you don't control.
There's a very good reason why no one is using this trick. Anything other than 1-based indexing is just undefined behavior.
Dijkstra conveniently ignored the other situations where 1-based works out better than 0-based. For example, getting the least element of the array, or iterating backwards over the array.
This reminds me of that somewhat famous observation about the bright scientists working to increase clicks at Google/FB instead of finding cures for diseases and such.
So much brain power to defend something that existed a long time ago and was adopted as some kind of law of the Universe when there is clearly no good reason to be this way today other than "it's just how it is" and every new programmer has to pass for a quick phase where the 1-based it beaten out of his mind.
Lua also allows floating point indices. In fact, any value can be an index into a table. That means any number, string, True/False, function reference, thread (coroutine) reference, table reference, "userdata" reference (usually a pointer to a C object), or nil can be an index.
I'm not going to complain about the indexing but I am going to complain about tables. The fact that you need at least one element to be in a table to trigger heuristics to serialize it properly makes Lua uniquely bad for use in polyglot distributed systems.
I've specifically run into this with OpenResty and JSON processing...
I would avoid trying to serialize tables in polyglot systems since it sounds like a specialized data structure whose counterparts don't really exist in other languages anyway.
It's a specialized data structure that the whole Lua ecosystem drives you to use as your primary collection type. They're blessed by the language, every library function will use will take and return them, and your deserializer will produce them, whether you like it or not.
Ultimately, you can use different data structures in Lua... but you'll have to write reams of boilerplate to do it. That's why I'm saying that (unfortunately) it's Lua itself that's a bad fit, not just tables.
The difference between 1-based and 0-based indices is irreverent enough, that’s the reason it feels uncomfortable for choosing to use something that is different. It is like little-endian vs big-endian, but you never see people choosing to use big-endian now
Just gonna add to the Lua love. I was also introduced to it by LOVE2D and revisted it with Redbean. In terms of ergonomics, it is still my favorite programming language; I find it very easy to read and reason about, and I credit that to its minimalism.
Lua is a language in which I implemented a class system at a point at which I'd still be scratching my head over another language's syntax sugar. I love it.
I just looked at this. It feels awfully brittle. My goal at the moment is to try to support every version of LÖVE going forward. All my apps work with any version after 11.0. Hopefully that streak won't be too onerous to continue in the future.
Here's how my apps' version check works, based on suggestions from the LÖVE Discord (but mistakes are mine): https://git.sr.ht/~akkartik/template-live/tree/9cddb20b96aa1... I don't use t.version in conf.lua anymore in Freewheeling Apps (though my early apps are not perfect)
I've never used love. It's certainly difficult if you're going with portability, and then add to that backwards compatibility.
I've talked about this before, but I think the only way to do versioning is the way everyone does it nowadays. Have a directory, with a wrapper around the dvcs/(Commits/ Tags/) and then a subdirectory for a "git workingset", And then you Import("url",{tag="",commit="",req="x.y.z"}), it should be fast because you're just doing io.open($REPOHOME/$URL/TAG/$TAG/$COMMIT/x/y/z) which just gets dropped to require() as normal. of course, add LÖVE to the mix and I just don't know. love should have mandatorily a love-VERSION as the command.
For native libs it's a wild west and success depends a lot on your environment. Sometimes the lib is being built with -Werror and fails if you're using more recent compiler, sometimes include paths are not resolved correctly using pkgconfig or similar and so on.
Great question! It's not ideal, but has been outweighed so far by the other benefits I mentioned. I do track the issues I run into due to lack of static types[1] in the Manual_tests files in each of my projects, e.g. https://github.com/akkartik/lines.love/blob/e568378ecb/Manua...
[1] I wouldn't say Lua/Python/Javascript has no types. They just lack types for variables rather than values. Forth, on the other hand, has no types period.
It’s a single file web application engine, and more, in an executable you can run on several OSes and I think even bare metal, but it’s been a while since I looked at it so it’s probably even more awesome today.
There's also the http://prosody.im/ XMPP server that's written in Lua, and it's very successful there. The other major XMPP server implementation is in Erlang and they are equally praised, so that should tell something about Lua's versatility.
The author fails to mention a super use case for lua which is celebrated by productivity nerds like myself - configuration.
I use neovim, hammerspoon which can be configured using lua richly. In a world of ever complicated software, I think lua is coming out as a gold standard for configuration files.
Wow, I just integrated Lua into a C++ project for the first time last night.
Took <15 minutes to integrate it with the build system (FASTBuild), watched a tutorial video[1], and then in another 15 minutes I had it hooked up to configure my application.
I'm surprised people dislike 1-based indexing. I use both types of indexing commonly and never had an issue with it.
The only issue I've come across in practice is lack of immutable tuples that could be used as table keys. I found myself either emulating this with nested tables or creating string identifiers for my multi-valued keys.
I dislike 1-based indexing, but I also don't really care that much. In my experience, people react with disgust to it, then get used to it, and still prefer 0-based but discover that 1-based isn't all that much more awkward in practice.
You get used to it pretty quickly when the whole language is built around it.
I solved the immutable table thing by encoding my tables to CBOR in the canonical representation. The same table structure always encodes to the same CBOR. I did have to write my own CBOR encoder, though, because the existing art wasn't good enough.
1 - based indexing is superior when thinking about actual collections, and not memory pointers. Most regular folks think of '1' index based. Eg. Most elevators (at least in NYC) start at floor 1, not 0. Once they start CS/programing classes they adjust to 0 thinking
0 - based indexing is better when dealing with pointers. But, none of us do today, (at least directly), and it seems that 0 based indexing is just an artifact of time.
When I used Lua for professional programming, I thought that 1 - based index is just better. I saw my self doing a lot less (-1) calculations.
We really don't want to use U.S.A. lifts as a gold standard, unless we want array indexing that unpredictably misses out array index 13 based upon the religious beliefs of the initial software developer. (-:
The same applies to most former continental Europeans colonies in latin america and africa. 0 based indexing, sometimes with Floor 0 (argentina comes to mind) or simply ground (Terreo in Brazil)
It’s not consistent but I would estimate that “0” buttons are as common as “G” buttons in elevators in Europe - along with -1, -2, etc for basement levels.
In my building the 1st floor is on set of stairs/1 elevator ride up, the real first floor (i.e the ground floor) is labeled lobby (or a big green button in the elevator).
0-based indexing makes just a much sense at higher level abstractions, aka iterators because there you're more likely to think in distances and ranges than indices, iter.advance(0) => stay where you are, so if iter is at the start, iter+0 is the first element.
I've been in game dev for decades, and I've never understood the desire for lua.
That's not totally true, it's easy to integrate and fast. But the language semantics and tooling leave a lot to be desired.
I'm hopeful we get an embedded version of another language. Something as easy to embed as lua, but without the lua. I'd much rather write JavaScript or Rust or anything else.
I agree with you, I don't like Lua either. I especially don't understand why it's so good for embedding, and how people haven't implemented a subset of the project's original language as a scripting language, so that they don't have to write two very different syntaxes (and programming paradigms).
I have a hard time imagining that. PHP for example is fun to script in, and resembles a C/C++ more than Lua does. Of course fun is subjective, and I have no idea about the issues of embedding (why Lua works for that, and why other languages haven't got more traction).
I've started to view Lua as an extension to C rather than a language in its own right, which isn't really accurate, but reflects how well the two languages complement each other.
I hate how people are desperately trying to embed (C)Python in their programs just to hop on the hype-driven Python bandwagon instead of doing the sane choice and just relying on Lua, which was designed to begin with to do so. Lua is simple enough it can be thought efficiently in a few hours, and it's just so trivial to embed.
In comparison, CPython often requires to implement most of your code logic as a library and then load it into the interpreter, which is less than ideal.
I used to poke at the python API in blender and most of the wrapper work was done with magic.
Very rarely would you have to implement any custom C code aside from what you’d have to do with any other embedded scripting language to deal with the differences between the two languages and/or blender wonkyness.
I’ve also played around with lua embedding a bit — I just like python more so didn’t do anything with it. I do remember that I got it to work as an experiment but I would have had to start writing some serious C code (the kind you claim is unnecessary) to do anything useful with it and I’m pretty sure the maintainer of the game would have been opposed to being able to script things.
But, I’m one of those people who actually enjoys wrapping C libraries to use in python so…
Pico-8 fantasy console uses Lua (a subset of; with Pico-8-specific console APIs). I keep going back to it in my personal projects time and again. I always think, "OK, I'm going to build the next thing in C" and wind up falling back to Pico-8 and Lua.
The in-the-works Picotron will grow from Pico-8's roots and present a full fantasy computer, with an OS, windowing system, etc. and expands Lua support to the full v5.4 language.
nice pointers, that sounds interesting. Have they kept it near-compatible with lua when it comes to how to embed it in a host app? Wondering if they are "competitive" in that aspect.
I'm currently using Lua as an extension language in my app [1]. Users can write their own custom UIs and DSP code. It's great how the Lua interpreter (and LuaJIT) allow you to provide your own memory allocator, so I can preallocate a region and do realtime-safe allocation within it.
Lua is also the language of choice for the nmap scripting engine.
While cute, easy to learn and all, I feel like it has kept back the development of nmap scripts. Only a few people are dedicated enough to take the time to learn it.
Then again, I think this has kept the quality of the available scripts high.
Before reading your post, if i were in a situation where I needed to do complex stuff with nmap, i'd just integrate it in a script that would run it multiple times, parse the output etc.
I never imagined it had a scripting language inside itself.
Guessing the only people who know about that are admins in large networks and black or white hat crackers...
The problem with lua - in my opinion is, the lackluster infrastructure for shared code.Lua rocks are version crippled and hard to integrate, bloat the code pretty fast (every instance has a full copy of all library code). Its also problematic that there are no default implementation for a API-Library layer. Which creates funny little re-implementations from v[1] to v.x and what have you not.
I'm not all that familiar with Lua so happy to be corrected here, but from what I know it's really small, really fast and really simple (to use), which makes me wonder why it's not used more often. Like I get it's not gonna be as fast as C, but apparently it's about as fast as C++. And it's not as simple as Python, but from what I've seen it's not far off. What's the catch?
There’s a lot of surface area to cover. In my opinion, the main thing that holds Lua back from wider adoption is the thing that makes it useful for its niche case. That is, the runtime and standard library are extremely small, making it easy and lightweight to embed in programs across a variety of platforms. However, that minimalist runtime and standard library also mean that it’s hard to deliver Lua libraries and frameworks without requiring native code extensions (e.g. any kind of networking and serious file system interactions) would require platform-specific extensions. Additionally, because Lua is so simple (for example there is no built-in concept of classes), the way to write code in Lua is quite open-ended. Many Lua users use their own or one of many prebuilt class systems. Using code from someone’s library might mean pulling in its custom class system and interacting with it as well. Custom class systems can be somewhat magical and involve metatable and suddenly things aren’t very simple anymore. Lua is also just a bit odd to use with one based indices, tables being kinda-sorta arrays if you use them in just the right way, needing to use pairs vs. ipairs in loops, variables being global by default if you forget to type “local” (unless you use Lua strict, and also all the libraries you want to use are compatible).
Java had Sun and Google. Python, Kotlyn and Go have Google. C had AT&T. Basic and C# had Microsoft. Objective-C and Swift had Apple. FORTRAN and Cobol had IBM. Javascript and Rust had Mozilla, ...
Lua has a lot of small sponsors but no big one.
Very few languages succeed just on their merits, without big sponsors.
Lack of types hurts. Then there's the 1-base indexing that bothers many. The whole "tables" concept is kinda weird—and this makes more complex kinds of programming difficult/unergonomic. Luckily like JavaScript, there are a wealth of languages that compile to Lua to smooth over missing language features. One outlier feature is that Lua supports tail call optimization.
This is timely - we've been gearing up on Lua as we're building an open-source web app firewall [1] on top of Redis and whatever framework, and it's been a great experience.
Lua really unlocks some superpowers with Redis with respect to being able to chain multiple requests into a single call, handle some application logic, etc.
You can learn Lua in a weekend, easy. The language is ridiculously small, but also ridiculously powerful. You can learn how to use C libraries in Lua in another weekend, easy. Using Lua from C is also easy, one weekend or less.
If you're looking for something like a "typed Lua" I suggest checking out Nelua (nelua.io).
It's almost 100% regular Lua syntax and compiles to C, so you get the nice syntax plus speed, similar to Crystal/Ruby. It's not perfect but is interesting nonetheless.
As a complete lua noob, can you run lua without C or C++? I've always thought of it as an embedded scripting language. I intend to learn it because of that but what can it do on its own?
Yes, there's a command line. Check LuaBinaries for that.
Also, if you want a fun way to play with it, see the LÖVE game engine. You can be making your own simple 2D games in next to no time. And I think that's a nice playground for trying out a language.
Lua can be run without using C or C++ just by running the interpreter. The shortcoming is that the standard library is intentionally very limited so there is very little you can do using Lua alone.
The main path is to implement with C or C++ bindings to the libraries you want to use and expose them as Lua module. This is the way Lua is supposed to be used.
Love Lua. They even added a compile time feature to address the fact that c++ exceptions and setjmp / longjmp are undefined behavior when used together.
2. Define your build for the sources (just compile them! No dependencies! Brilliant!) (don't compile lua.c and luac.c if you provide your own main)
3. Integrate with e.g. this main.cpp (if using c++ is your thing, just plain main.c or whatever is binary compatible):
#include <stdio.h>
extern "C" {
#include <lua.h>
#include <lauxlib.h>
#include <lualib.h>
}
// Native function to be called in Lua
static int add_numbers(lua_State* L)
double a = luaL_checknumber(L, 1);
double b = luaL_checknumber(L, 2);
lua_pushnumber(L, a + b);
return 1;
}
int main() {
// Instantiate a Lua interpreter
lua_State L = luaL_newstate();
// Load Lua libraries
luaL_openlibs(L);
// Register native function in Lua
lua_register(L, "add_numbers", add_numbers);
// Call native function in Lua
luaL_dostring(L, "result = add_numbers(10, 20)");
// Read out the result of the function application
lua_getglobal(L, "result");
const char* result = lua_tostring(L, -1);
printf("The result is: %s\n", result);
// Define a function in Lua
luaL_dostring(L, "function concatenate_strings(s1, s2) return s1 .. s2 end");
// Call Lua function in native side
luaL_dostring(L, "result = concatenate_strings('Hello, ', 'world!')");
// Read out the result of the function application
lua_getglobal(L, "result");
const char* result2 = lua_tostring(L, -1);
printf("The result is: %s\n", result2);
// Close Lua interpreter
lua_close(L);
return 0;
}
The ConTeXt typesetting system tightly integrates Lua. One aspect of Lua I dislike is that it isn't object-oriented. What's impressive is that the language can be extended to be so in astonishingly little code:
It's actually not ConTeXt which integrates Lua, but LuaTeX; ConTeXt is based on the features of LuaTeX. Lua includes all features required for OOP (see e.g. https://www.lua.org/pil/16.html).
maybe I'm being dim but what possible aesthetic benefit does it offer? The only benefit that springs to my mind from a language design perspective is that it is most likely familiar to the user of the language from languages they have used before.
Both Smalltalk and APL use 1 based indices so I just find any claim of obvious aesthetic superiority on this issue a little hard to accept without some back up.
If speaking aesthetics the fact that the number of items in your array is equal to the position of the last index item in the array would seem aesthetically superior.
Lua's 1-based indexing is largely inspired by Fortran. Lua's first users were Brazilian engineers in the early 90s, who were mostly experienced in Fortran.
Arguably, one-based indexing is more closed aligned to mathematics tradition.
That point about being easier to index the last element helps to iterate backwards over an array. With zero-based indexing, a backwards loop becomes for(i=N-1; i>=0; i--). Yuck.
exactly, I have a hard time understanding any argument for 0 based indexing other than tradition or a performance hack that I find unlikely was ever that great a benefit anyway.
It is admittedly a mindset that is born of C coding. Pointers and memory offsets and so forth. But lots of languages that abstract such "close to the metal" factors away, still use 0 based indexing.
Why? 0 based indexing came from a time where you used memory addresses directly to index into arrays. Today, we don’t do that, so 1 based indexing seems extremely reasonable. Besides, with Lua you can still do 0 based indexing with a small personal extension function.
One of the first things requested by users of an internal media sequencing tool where time is measured by frames was 1-based indexing, they absolutely hated starting from 0
Yea, I love how 0 indexing is such a big deal. Like tabs vs spaces, it doesn’t matter even a tiny bit, it’s like a religion. It’s not that hard to index off of 1, and like I said, you can write like 5 lines of code to make 0 indexing the default!
I suppose it's whether you think of array indexing as an operation that offsets the read location relative to th start of the array. It's probably rather low level for the way people are used to working these days.
Ehh, local being a keyword (instead of local default, global only if required) was a significantly bigger gaff. The other would be no nulls in tables. 0/1 based indexing is familiarity only.
Requiring a keyword to declare a variable is a good thing. Otherwise, it'd be easily to accidentally declare new variables when you meant to assign to an existing one. Since global is the default, starting a program with something like this effectively keeps that from happening:
local gindex = {}
setmetatable(_G, {__index = function(t,k)
local v = gindex[k]
if v == nil then
error("Bad read of global variable " .. tostring(k), 2)
else
return v
end
end, __newindex = function(t,k,v)
error("Bad write of global variable " .. tostring(k), 2)
end})
for k,v in pairs(_G) do
gindex[k] = v
rawset(_G, k, nil)
end
I once read through the entire Stroustrup C++ book and figured in one case, there is absolutely no way to make this work except for a secret, hidden variable in the class. Did a test compile and: There it was! OK, I get C++, done. Then I saw actual C++ programs. Whoa, how do you index into an array using a string? You don't of course, you overload the [ ] operator.
Reading about Lua when it was newer I could foresee the same thing happening on steroids. Yes, the language itself is simple but what you can do with it - emulate almost any construct in any language - promises confusion. When it comes to readable code, sometimes "less is more" in terms of langauge features.
Let's put aside the god-awful 1-based tables, in 1993, which alone should have killed the language. My big problem with Lua is that it tries very hard to make possible all styles of language to all people, and as a result it is a language with a lot of boilerplate to do any one of them.
For example, consider Lua's OO. The most obvious inspiration for Lua here was Newtonscript, via Self. They're quite open about it. Newtonscript and Self are prototype-style OO languages done well, as opposed to Javascript, which is a prototype-style OO abomination. Lua advertises itself as being able to do prototype-style OO, all you have to do is make some tweaks to its metatables. But while this stuff is baked into Newtonscript and Self, it is an amazing amount of boilerplate to do it in Lua, to the point of parody. https://www.lua.org/pil/16.1.html
There is a huge opportunity, IMO, for more players here. Deno definitely has some good gestures toward a this. Wasm though seems like the likely general heir, and will have many different offerings for how to do that (Deno being one!).