Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm currently using a CPU-slow machine, and I've discovered everything is slow among the popular scripting languages, except Lua. I've thought JS has good startup time, but some of my Lua scripts that are doing file i/o finish faster than node.js does a ‘hello world.’ Lua is also very lightweight on memory, to my knowledge. I think it can even do true multithreading, via libraries.

So, there's a Lisp on top of Lua―compiled, not interpreted: https://fennel-lang.org

It's deliberately feature-poor, just like Lua: you use libraries for everything aside simple functions and loops. And it suffers somewhat from double unpopularity of Lua and Lisp. But it works fine.



I am using Fennel for this: https://itch.io/jam/autumn-lisp-game-jam-2019

I will not finish ... I suck at lisp. But it works.


Have you looked at Julia?


Julia is compiled to machine code, not interpreted


Many lisps compile to machine code too. Compilation vs. interpretation is a feature of an implementation, not a language.


Scripting languages are by definition interpreted. The question was about fast scripting languages. I'm skeptical that Lisp compiled to Lua would count as in that category, but Julia unequivocally doesn't.


"Scripting languages are by definition interpreted" [[Citation Needed]].

There are Common Lisp implementations of both Python and Javascript (ES3) that compile to Common Lisp and then the Common Lisp compiles to machine code: as I said before, whether or not a language is interpreted or compiled is an implementation detail, not part of its spec.


https://www.webopedia.com/TERM/S/scripting_language.html

I chose this based off a random search on google of "scripting language." You can do the same and would get the same result.

It's not a rigorous term, because (you are right) its a property of the implementation not the language itself, despite the name.

But I don't think Julia has relevance to discussion of the speeds of interpreted Lisp.


That term was a long time ago already seen as problematic in the Lisp community. At the time when Ousterhout used it for marketing TCL.

Basically a scripting language interpreter runs source code files, called scripts.

Lisp does that, too. But many Lisp implementations compile the code and often to machine code, since the runtime includes an incremental compiler. The incremental compiler can compile individual expressions to memory.

Thus when you use a Lisp system, running a script just looks like running an interpreter, even though the code gets compiled incrementally.

Lisp uses the function LOAD, which can load a textual source file and which can then read, compile, execute expressions from the file. Typically this is also available via command line arguments.

Like in SBCL one can do:

  sbcl --script foo.lisp
and it will read/compile/execute expression by expression from a textual source code file, actually incrementally compiling each expression to machine code.


> Scripting languages are by definition interpreted.

I don't think this is correct. Scripting aren't rigorously defined, of course, but it would be reasonable to say they are defined by practice (i.e. a scripting language is practical for scripting).

Most compiled languages knock themselves out of contention in this definition because the startup and/or compile times are too long to be practical. But I've used luaJit in scripting contexts before, so that at least muddies the waters. Also common lisp (a variant that was always compiled).


It's a term for a simpler era where these divides made sense.

I've always understood it to mean interpreted and from a quick google search there are at least a sizeable number of people who agree.

I think now that there are a lot of high level compiled languages, it makes less sense.


That has nothing to do with how "lispy" it might be. Part of the compiler is implemented in femtolispe no?


I suspect this does have to do with whether or not it is a fast scripting language, considering a language compiled into machine code is by definition not a scripting language.

Sure, flag me, but my comment was relevant to the discussion.


Julia is currently (only) jit. AOT is stil work in progress AFAIK.

It's about as "compiled" as Luajit is.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: