Thank you, I hadn't heard of it before so I'll check it out!
I'm not optimistic about Wayland, since early on they decided not to use an extension language, and that's not something you can have a change of heart about later, and then just nail onto the side.
It would be interesting to see how Arcan uses L ua, which is a great language for that kind of stuff. It's a lot smaller and sleeker and better designed than JavaScript.
The Arcan developers should check out how Factorio modding works! (But then all work on Arcan would halt when for months while they were addicted to Factorio.)
https://wiki.factorio.com/Modding
Lua's main problem is that it isn't JavaScript (i.e. in JavaScript's enviably lucky position of ubiquitous dominance).
If I had a time machine, I'd go back and try to convince Netscape to use Lua 2.1 instead of inventing JavaScript (released December 4, 1995). And hire the Self guys (Dave Ungar, Randy Smith and the crew who eventually made the Java HotSpot compiler) away from Sun, and Mike Pall (LuaJIT) from wherever he was!
https://www.lua.org/versions.html
>Lua 2.1 was released on 07 Feb 1995. Its main new features were extensible semantics via fallbacks and support for object-oriented programming. This version was described in a journal paper. Starting with Lua 2.1, Lua became freely available for all purposes, including commercial uses.
https://news.ycombinator.com/item?id=12574290
https://channel9.msdn.com/Blogs/Charles/A-Conversation-with-...
I get paid to work on Arcan so I don't think factorio would have that big of an impact ;-)
The initial choice of Lua for Arcan was based on its use, at the time (2004-2005ish), in World of Warcraft. The UIs that people were hacking together in WoW even with little to no serious programming experience was way more advanced than what would ever be needed for desktop interfaces so it seemed like a good fit. Even for other projects, Lua is still my goto "safe" keyword for C.
There are more interesting properties though, especially how the VM- bindings integrate with C. Stay away from using too much metatable magic etc. and what you get is an ok "protocol+binding" in one. Substitute the stack for socket read/write, add an identifier to function translation and you can chose between in-process or stronger separation. The reality is slightly more involved, but not by much.
Don't be so sure you won't miss work if you haven't yet tried Factorio! ;)
https://news.ycombinator.com/item?id=20362179
WoW was what convinced me how practical and powerful Lua really was, too. And that there were people out there that knew how to program it really well.
The WoW "Auctioneer" mod in particular was quite advanced and elegantly written. It would analyze the prices of items in the auction house over time, and help you price and sell your own items competitively. Not just lots of fancy user interface, but some respectable data wrangling and number crunching too.
One important thing about Lua is how cleanly and efficiently it integrates with C code. TCL/Tk also has this virtue, but TCL was a terribly designed (but brilliantly implemented) programming language. While both Lua's design and implementation are quite excellent. It also has a great community, plus RMS never declared a holy war on it, either!
https://news.ycombinator.com/item?id=14944103
https://vanderburg.org/old_pages/Tcl/war/0000.html
> TCL was a terribly designed (but brilliantly implemented) programming language.
What do you dislike about Tcl? I always kinda liked it.
> While both Lua's design and implementation are quite excellent.
The implementation is pretty good, but 1-based arrays are pretty evil. I don't know if I like the way arrays & tables are conflated either: part of me thinks it's clever, and part thinks that it's too clever by half.
It's also pretty verbose.
Something I like about both Tcl & Lisp is that they have a good built-in messaging format (Tcl object notation in the former, and S-expressions in the latter). Lua doesn't really have something similar, which is IMHO unfortunate.
Just curious, who is paying you to work on arcan?
Some (most) details from recent years are subject to NDAs of various sorts - the rough areas are in some computer vision projects for automated IoT/mobile device testing, runtime "VJ-ing" with watermark injection/removal and embedded device forensics.
'Desktop/display server' parts is just a sidetrack that I do to get about as far away from what is otherwise happening in that space as possible, I need a sane work environment that doesn't keep making decisions behind my back or is laughably unreliable, and this turned out to be the easiest, albeit time-consuming, route.
>> I'm not optimistic about Wayland, since early on they decided not to use an extension language, and that's not something you can have a change of heart about later, and then just nail onto the side.
I don't see a need for an extension language for a compositor. A miminum of DE features will be implemented in Wayland compositors and everything else will be other programs - write them in what you like. Or am I wrong about the partitioning on Wayland?
The extension language is most useful for the window manager, which should be running in the same address space as where the events are being generated and processed.
I think this was tried with GNOME Shell and turned out not to be such a good idea. It runs JavaScript in its Wayland compositor/window manager and that reportedly causes unreasonable problems with lag and unresponsiveness. The Purism people were advised to write their own compositor/shell instead for the GNOME/GTK-based Librem 5 phone.
Maybe that's a Wayland problem though, with the way it combines the windows manager with everything else into one process.
I had no idea Lua was that old. The world that might have been, eh?
Instead of creating a half-assed extension language, a better solution is to have one language do both. Like Common Lisp for example.
Is Scheme a half-assed extension language? What about Guile?
How do you like Niels P. Mayer's XLISP-based Motif X11 toolkit widget interpreter, Winterp?
https://pdfs.semanticscholar.org/f169/54db7cb7c07ac842e31247...