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.

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.

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

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).

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.