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.
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.
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.
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.
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.
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.
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))
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.
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.
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.
> 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.
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.
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).
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.
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.
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.
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.
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!
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.
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 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.
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.
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...
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.
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.
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.
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).
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 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!
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...
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!
> 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.
[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]
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!
> 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.
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.
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.
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.
> 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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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)
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.
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. (-:
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.
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.
238 comments
[ 0.21 ms ] story [ 58.7 ms ] threadAlso worth noting, NetBSD has had lua hooks into their kernel for about 10 years I think.
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!).
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.
https://cacm.acm.org/magazines/2011/7/109909-passing-a-langu...
https://docs.groovy-lang.org/latest/html/documentation/guide...
[1] https://www.gnu.org/software/guile/
[2] https://guix.gnu.org
[1]https://mruby.org
[2]https://h2o.examp1e.net/configure/mruby.html
[3]https://news.ycombinator.com/item?id=34937297
When you factor in LuaJIT[1] and the incredible performance/zero-overhead-FFI[2] it really is a neat language.
[1] https://luajit.org/
[2] https://github.com/dyu/ffi-overhead
I've ignored CL because it seems like the BASIC or bloated kitchen-sink of lisp/likes, but probably mainly because 'car'? 'cdr'? 'setq'? seriously?
http://clhs.lisp.se/Body/f_firstc.htm#first
http://clhs.lisp.se/Body/f_rest.htm#rest
Common Lisp added FIRST, REST, SECOND, THIRD, ..., TENTH and some others to the language standard in the early 80s.
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.
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.
I understand the history; some to-do with registers, but the names make no sense conceptually.
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:
:)
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.
[1] https://leafo.net/lapis/
https://github.com/fanf2/doh101/blob/master/roles/doh101/fil...
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.
[1] https://www.lua.org/manual/5.1/manual.html#pdf-coroutine.yie...
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.
[1] https://github.com/dbohdan/embedded-scripting-languages
https://gist.github.com/matiasinsaurralde/0a4ecf8f3e0d8768b3...
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.
[1] https://www.fixscript.org/blog/introduction
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.
[0] https://stackblitz.com/
[1] https://webcontainers.io/
[1] https://github.com/bazelbuild/starlark
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.
[1]: https://www.youtube.com/watch?v=4l5HdmPoynw
* no Luarocks
* no native libraries
More details: http://akkartik.name/freewheeling
That way lies npm and left-pad.
Tools encourage behaviors. I avoid tools that encourage behaviors I want to avoid.
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.
https://github.com/Alloyed/flirt
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 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.
[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.
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.
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.
https://redbean.dev/
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.
I also recommend the excellent ZeroBrane IDE - https://studio.zerobrane.com/
As a Java/Python dev there is something about using such light weight and fast tools like redbean, lua and ZeroBrane that brings a smile to my face.
For those looking for a GUI library for Lua, check out TekUI. http://tekui.neoscientists.org/index.html
I tested it on various distros without hassle, both on x86 and ARM. It would probably be worth of porting to other languages too.
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...
* https://manpages.debian.org/sid/nmap/nmap.1.en.html#NMAP_SCR...
> if i were in a situation where I needed to do complex stuff with nmap
Note: I've never been in such a situation. My network admin duties are like 0.5% of my time.
Not javascript.
Not python.
This.
That which educates the young, shapes the future, may the elders like it or not.
Roblox Lua/Luau tutorials on youtube - millions of views https://www.youtube.com/results?search_query=luau+roblox&sp=...
Luau
https://github.com/Roblox/luau
Roblox wrote a superset of Roblox Lua which is way faster https://luau-lang.org/
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.
Lucas Pope is developing for the platform now https://dukope.itch.io/mars-after-midnight
* https://github.com/kikito/middleclass/blob/master/middleclas...
Using OOP, typesetting a hexagonal grid and a symbolic representation of a neural network on top is easier develop, IMO.
A vertex defines a point in 2D space:
* https://github.com/DaveJarvis/keenwrite-themes/blob/main/bos...
An edge connects two vertices:
* https://github.com/DaveJarvis/keenwrite-themes/blob/main/bos...
A graph connects edges:
* https://github.com/DaveJarvis/keenwrite-themes/blob/main/bos...
A priority queue serves for ordering edges by weight of adjoining vertices:
* https://github.com/DaveJarvis/keenwrite-themes/blob/main/bos...
With these concepts in hand, we can typeset a grid and a "neural network" on top:
* https://github.com/DaveJarvis/keenwrite-themes/blob/main/bos...
Here's an example of the output from the first chapter:
* https://i.ibb.co/19DCDZy/ch-1.png
And a later chapter, where the "network" has grown in complexity:
* https://i.ibb.co/ncf16vg/ch-2.png
This is for my near future hard sci-fi book on AGI. I'm looking for alpha readers to give me feedback. See profile for contact details.
P.S.
There's a subtle bug in the code that can result in one or two disconnected vertices. If you spot it, let me know!
https://tug.org/TUGboat/tb40-2/tb125adams-3d.pdf
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.
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.
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.
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!
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...
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 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.
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.
Which century is the year 2023 in again?
(It’s 2023, and we both are right)
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.
Yes, whatever.
If the biggest complaint about Lua is 1-based tables, I’d say that’s a compliment to the language indeed.
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.
Starting at 1 is a convention:
array = {“hello”, “world”}
print(array[1]) —- displays “hello”
array[0] = “why”
array[2] = “there”
for i=0,2 do print(array[i]) end —- “why” “hello” “there”
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:
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.
People absolutely do this, and you have to for things like using LuaJIT’s FFI and doing work across C.
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.
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.
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.
No. A circular buffer is just a simple example where you need to go between offsets and locations.
The same theme happens in many similar cases, like directly manipulating bitmaps. E.g. with zero-based indexing into an RGB bitmap:
vs. 1-based indexes: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
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.https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
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.
I've specifically run into this with OpenResty and JSON processing...
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.
If you have to iterate over n elements, the first syntax is optimized for 0 to n-1, while the second is optimized for the other case. See:
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
You're not forced to index from 1 and onwards. You can use any range you want to: https://www.lua.org/pil/11.1.html
[1] https://beyondloom.com/decker/lil.html
[2] https://beyondloom.com/decker/
[1] https://audulus.com
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.
> ...
> When it comes to readable code, sometimes "less is more" in terms of langauge features.
Please tell me that is meant as satire. There is no sane way to look at C++ and Lua and decide "less is more" would favor C++.
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.
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.
European buildings are generally 0-indexed: https://en.wikipedia.org/wiki/Storey#Numbering
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.
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.
I love that so many games use it.
Great language and great runtime(s)
Want to also raise awareness of TypeScriptToLua, a fantastic TypeScript transpiler for Lua: https://typescripttolua.github.io/
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.
1 - https://wafris.org
Really easy, well documented and fun framework that uses Lua.
[0]: https://love2d.org/