Scott Bell wrote a lot of that. I was fascinated by the self-hosting technique. The whole repo is so small that you can almost dismiss it as some kind of academic toy, if you don't realize it's a full-featured production-grade lisp.
(Not to take anything away from Fennel! The more lisp, the better.)
Thanks for posting this. I took a look at Fennel a few months ago and although they list 2 web frameworks on the front page, there's little documentation (that may have changed since then) about how to interface with other Lua projects. I kept running into things I couldn't figure out when working with the existing Lua ecosystem and projects.
Lua is way more common for game scripting than Python. One of the few major games which used Python I can think of was Civ IV, and Civ V switched to Lua.
Lua is smaller, easier to embed interface / interact with (e.g. it's way less ceremony to expose a native function to Lua than to Python), and tends to be faster, especially when jumping back and forth between the engine and the scripting. Embedding / scripting (within a larger program) is the original use-case of Lua, not so Python.
I believe it's also much easier to secure / sandbox (remove bits you don't want script writers to have access to) as well, the stdlib is smaller and I think it has less interactions between modules.
Python embedding / scripting tends to be more common for software where the securing / restriction aspect is smaller but flexibility & larger embeds are necessary e.g. 3D, CAD and other "production pipeline" software tends to be scripted with Python.
I've made a suite of digital musical instruments for Android phones in Lua. Now I'm using same language to build some VR prototypes.
Here are some benefits of Lua over Python. It's really powerful language (anonymous functions, closures, tail-call optimization, full lexical scoping, coroutines...) that supports many paradigms, and yet it is tiny and elegant. There are few surprises and everything is explicit.
Runtime is easily embeddable, which means it will be more readily available on exotic platforms. The interpreter is much faster than Python. C code is effortless to call into with FFI and resulting code looks just like normal Lua.
Not everything is roses. I prefer readability and less verbosity of Python. The 1-indexing needs some getting used to. Batteries are not included (to be more portable), so there are dozens of implementations of basic things like serialization, OO classes and table copying. Most online material (wiki) was written very long ago and it's full of language proposals that never succeeded. Some valuable resources can be found in documentation of hosting frameworks (Defold, Solar2D, Roblox, ComputerCraft, WoW).
I wrote a console-based email-client, using Lua for all configuration and scripting needs.
Using Lua is generally done because it is easy to embed inside a host-application. While it is possible to embed Python, Perl, or other languages, they're relatively heavyweight and not so commonly used in that case.
In my own application I always felt annoyed that mutt didn't have "real" scripting. Just an ad-hoc configuration that made lots of things possible, but neglected some basics (such as loops and similar).
Configuring a mail-client in Lua was a nice exercise, but eventually I moved on to pay for gsuite rather than self-hosting a mailserver of my own so it became a "done" project. Definitely a useful learning experience though, experimenting with user-interface, embedded scripting, and going through lots of learning relating to MIME-handling & etc.
Lua is a tiny, relatively simple language with a simple data model built on a small runtime that's very fast for an interpreter and easy to embed into C/C++ applications (once you dealt with the stack, mentally or otherwise). Startup time is ~nil.
Python is a large, complex language with an exceedingly complicated data model built on a runtime where the core interpreter is about ~4 MB, which is also a pretty slow interpreter (mostly due to the exceedingly complicated data model). Python is certainly not hard to embed on an API level, but somewhat annoying to package up for a build. Python is very hard to sandbox, whereas Lua is basically sandboxed by default. Startup time is on the order of ~100-200 ms.
If I use Python instead of Lua for monte carlo tree search, my machine will page out, and even before it pages out, my training pipeline will be running dozens of times slower than it was with Lua.
If I use Python instead of Lua to make a game, I will not be able to update my game state and render all my images at 60hz.
If I use Python instead of Lua to write programs that do many tasks at the same time, I will have to write "await" a thousand times instead of 0 times.
the easiest way to put it is that you embed Lua into your app (say scripts that are loaded at startup or even as a command line) while it’s more natural to embed your external functionality into Python (e.e. numpy).
It’s simpler to connect lua to your c/c++ datastructures than it is to connect Python, and it’s more complicated to write little things in Python.
Sometimes it’s easier to grab a pencil and scribble a little note on a piece of paper. Sometimes it’s a lot more useful to type a note into your phone or computer than to deal with paper.
I have embedded lua in Spring Boot webapps where I required an external rules files which could be easy to read for business folks.
Example: Specialised handling for different customer types and you don't want to manage all the rules in the RDBMS but would rather run a separate script for each customer type and have this script in a plain text format and version managed using Git.
I use it at work to process SIP messages on behalf of a cellular carrier. The actual parser is written using LPEG, a parser expression grammar for Lua. Because Lua is meant to be embedded, it only has the functionality required to do the job and no more.
This and a recent feature addition to neovim (passing lua closures to vimscript functions [1]) should make a good substitute for elisp to configure neovim.
I don't see it mentioned but there is a neovim plugin called conjure [1] that is written in fennel. This is a general purpose REPL client that works for Clojure (I use it daily for Clojure and ClojureScript) but also for fennel itself. So you can have a really nice neovim plugin dev experience using this tool. Conjure works with fennel out of the box, but if you want to go deeper you may be interested in another plugin called aniseed [2] which provides interesting facilities for the fennel language and that is used internally by conjure.
Disclaimer: I am not the author of those tools, just a random Clojure dev.
I haven't spent any time with Fennel, but it seems more promising to me.
I couldn't get comfortable with Hy. It drops so many lispy things, such as let statements and persistent data structures, in order to stay close to the Python substrate. (You can get both from libraries, but at the cost of easy interop with Python packages, which kind of defeats the whole point of being on the Python platform in the first place.) It ultimately came out feeling less like I was working with a lisp, and more like I was working with an s-expression syntax for Python.
OTOH, if you think that Python, while otherwise great, is really suffering for lack of defmacro, Hy absolutely succeeds in getting you Python with defmacro.
There is another small lisp that targets both Lua and Javascript called "lumen"[1]. Small enough that you can easily tinker with it. I added clojure style {} literals to the reader and paired it with hyperapp to write a toy web application.
I really wish Lua were popular for small-scale utility scripting instead of Python and JS. Because Lua is way snappier: even with language translation, plenty of Fennel scripts will run under Python's startup time. Likewise, Lua seems like a great fit for small mobile apps and automation (dunno about threading though, but I seem to have read that Lua can do threads with a library).
My primary woe with Lua is the absence of ‘null’. You can't preserve structure of deserialized tables if there are nil values in them, so you can't really build API middleware and such, without extra effort for that (so you'd also not be able to use functional libraries like Penlight in your middleware).
Lua will never be more popular without a proper standard library.
Leaving everything up to the user so that you have to manually implement (or hunt the web for) even the most basic features is mega annoying. How many millions of people need to rewrite string.startswith?
The whole "sequence iteration stops at the first internal hole and therefore the # operator doesn't do what you think it should" gotcha is extremely user hostile.
Metatables are cool and all, but holy crap are they confusing for Lua newbies. Having an integrated class system would go a long way.
The reason I used Lua was its "accessibility" -- so end users can script -- and not necessarily for the beauty and elegance of the language. It was also very easy to integrate into a C++ project.
[+] [-] rudolfwinestock|5 years ago|reply
I'd like to see him visit this thread.
https://news.ycombinator.com/user?id=technomancy
[+] [-] reitzensteinm|5 years ago|reply
[+] [-] bokchoi|5 years ago|reply
https://technomancy.us/190
[+] [-] pragmatic|5 years ago|reply
https://lobste.rs/u/technomancy
[+] [-] mumblemumble|5 years ago|reply
[+] [-] masklinn|5 years ago|reply
> Clojure's license makes it a complete non starter for me, sorry. Live free or die.
when at first glance fennel looks a lot like clojure e.g. `fn`, square brackets, {} for maps / table literals.
[+] [-] rcarmo|5 years ago|reply
https://fennel-lang.org/v0.6.0/
[+] [-] sillysaurusx|5 years ago|reply
Scott Bell wrote a lot of that. I was fascinated by the self-hosting technique. The whole repo is so small that you can almost dismiss it as some kind of academic toy, if you don't realize it's a full-featured production-grade lisp.
(Not to take anything away from Fennel! The more lisp, the better.)
[+] [-] tgbugs|5 years ago|reply
edit: Looking at the git history is very educational for how to bootstrap a self hosting system like this. Fascinating.
[+] [-] pmoriarty|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] minxomat|5 years ago|reply
[+] [-] yawn|5 years ago|reply
[+] [-] j_m_b|5 years ago|reply
[+] [-] masklinn|5 years ago|reply
Lua is smaller, easier to embed interface / interact with (e.g. it's way less ceremony to expose a native function to Lua than to Python), and tends to be faster, especially when jumping back and forth between the engine and the scripting. Embedding / scripting (within a larger program) is the original use-case of Lua, not so Python.
I believe it's also much easier to secure / sandbox (remove bits you don't want script writers to have access to) as well, the stdlib is smaller and I think it has less interactions between modules.
Python embedding / scripting tends to be more common for software where the securing / restriction aspect is smaller but flexibility & larger embeds are necessary e.g. 3D, CAD and other "production pipeline" software tends to be scripted with Python.
[+] [-] jmiskovic|5 years ago|reply
Here are some benefits of Lua over Python. It's really powerful language (anonymous functions, closures, tail-call optimization, full lexical scoping, coroutines...) that supports many paradigms, and yet it is tiny and elegant. There are few surprises and everything is explicit.
Runtime is easily embeddable, which means it will be more readily available on exotic platforms. The interpreter is much faster than Python. C code is effortless to call into with FFI and resulting code looks just like normal Lua.
Not everything is roses. I prefer readability and less verbosity of Python. The 1-indexing needs some getting used to. Batteries are not included (to be more portable), so there are dozens of implementations of basic things like serialization, OO classes and table copying. Most online material (wiki) was written very long ago and it's full of language proposals that never succeeded. Some valuable resources can be found in documentation of hosting frameworks (Defold, Solar2D, Roblox, ComputerCraft, WoW).
[+] [-] stevekemp|5 years ago|reply
Using Lua is generally done because it is easy to embed inside a host-application. While it is possible to embed Python, Perl, or other languages, they're relatively heavyweight and not so commonly used in that case.
In my own application I always felt annoyed that mutt didn't have "real" scripting. Just an ad-hoc configuration that made lots of things possible, but neglected some basics (such as loops and similar).
Configuring a mail-client in Lua was a nice exercise, but eventually I moved on to pay for gsuite rather than self-hosting a mailserver of my own so it became a "done" project. Definitely a useful learning experience though, experimenting with user-interface, embedded scripting, and going through lots of learning relating to MIME-handling & etc.
[+] [-] formerly_proven|5 years ago|reply
Python is a large, complex language with an exceedingly complicated data model built on a runtime where the core interpreter is about ~4 MB, which is also a pretty slow interpreter (mostly due to the exceedingly complicated data model). Python is certainly not hard to embed on an API level, but somewhat annoying to package up for a build. Python is very hard to sandbox, whereas Lua is basically sandboxed by default. Startup time is on the order of ~100-200 ms.
[+] [-] anonymoushn|5 years ago|reply
If I use Python instead of Lua to make a game, I will not be able to update my game state and render all my images at 60hz.
If I use Python instead of Lua to write programs that do many tasks at the same time, I will have to write "await" a thousand times instead of 0 times.
[+] [-] stevedonovan|5 years ago|reply
[+] [-] gumby|5 years ago|reply
It’s simpler to connect lua to your c/c++ datastructures than it is to connect Python, and it’s more complicated to write little things in Python.
Sometimes it’s easier to grab a pencil and scribble a little note on a piece of paper. Sometimes it’s a lot more useful to type a note into your phone or computer than to deal with paper.
[+] [-] pkphilip|5 years ago|reply
Example: Specialised handling for different customer types and you don't want to manage all the rules in the RDBMS but would rather run a separate script for each customer type and have this script in a plain text format and version managed using Git.
[+] [-] spc476|5 years ago|reply
[+] [-] chgibb|5 years ago|reply
[+] [-] vsurabhi|5 years ago|reply
[1] https://github.com/neovim/neovim/pull/12507
[+] [-] adz5a|5 years ago|reply
Disclaimer: I am not the author of those tools, just a random Clojure dev.
[1] https://github.com/Olical/conjure
[2] https://github.com/Olical/aniseed
[+] [-] merricksb|5 years ago|reply
https://news.ycombinator.com/item?id=18016168
[+] [-] miguendes|5 years ago|reply
It reminds me of hy, for python. [1] [1] https://github.com/hylang/hy
[+] [-] mumblemumble|5 years ago|reply
I couldn't get comfortable with Hy. It drops so many lispy things, such as let statements and persistent data structures, in order to stay close to the Python substrate. (You can get both from libraries, but at the cost of easy interop with Python packages, which kind of defeats the whole point of being on the Python platform in the first place.) It ultimately came out feeling less like I was working with a lisp, and more like I was working with an s-expression syntax for Python.
OTOH, if you think that Python, while otherwise great, is really suffering for lack of defmacro, Hy absolutely succeeds in getting you Python with defmacro.
[+] [-] dunham|5 years ago|reply
[1]: https://github.com/sctb/lumen
[+] [-] rcarmo|5 years ago|reply
[+] [-] Rochus|5 years ago|reply
[+] [-] aasasd|5 years ago|reply
My primary woe with Lua is the absence of ‘null’. You can't preserve structure of deserialized tables if there are nil values in them, so you can't really build API middleware and such, without extra effort for that (so you'd also not be able to use functional libraries like Penlight in your middleware).
[+] [-] ebg13|5 years ago|reply
Leaving everything up to the user so that you have to manually implement (or hunt the web for) even the most basic features is mega annoying. How many millions of people need to rewrite string.startswith?
The whole "sequence iteration stops at the first internal hole and therefore the # operator doesn't do what you think it should" gotcha is extremely user hostile.
Metatables are cool and all, but holy crap are they confusing for Lua newbies. Having an integrated class system would go a long way.
[+] [-] samatman|5 years ago|reply
null and nil are effectively synonyms, and I'm having difficulty understanding what about Lua's use of nil has caused problems for you.
[+] [-] slumos|5 years ago|reply
https://github.com/slumos/dot.hammerspoon
[+] [-] molloy|5 years ago|reply
[+] [-] fortran77|5 years ago|reply
[+] [-] galfarragem|5 years ago|reply
[+] [-] molloy|5 years ago|reply
[+] [-] remix2000|5 years ago|reply
[+] [-] manexploitsman|5 years ago|reply