[jwhite]

Interpreted language? Common Lisp is typically compiled. Besides which, why is interpreted a particular advantage? e.g. Python was interpreted 10 years ago when I was using it, but Common Lisp felt far more flexible and powerful, because you can compile single functions with a key press in SLIME and seamlessly load them into your running (compiled) image... shortest feedback loop I've ever experienced. Maybe Python has caught up in the mean time, I haven't used it seriously for a long time though, so I don't know.

[terminalcommand]

I instinctively used the "interpreted" term, because mainly you can execute instructions on the fly in an interpreter the language ships with. Whether it's compiled to bytecode and then executed from there is IMHO an implementation detail. With compiled languages (following this logic) such as Java or Go or C, you need to write your program pass it through a compiler to get an output.

With languages like Javascript, Lisp, Python, Ruby etc. you can write your programs incrementally, going back and forth between the REPL.

Sorry if my terminology has caused you trouble. I regard dynamically typed languages that ship with an interpreter as interpreted languages. For optimization reasons the implementation probably uses some sort of compilation but you can still use the built-in interpreter on all of these "interpreted" languages.

I should probably have used the term "ships with an interpreter" :)

BTW the current python-mode in Emacs also allows SLIME-like behaviour. You can open a python process with C-c C-p and then send the buffer, functions, marked areas, lines etc. to the python session.

[jwhite]

Well, SBCL does not ship with an interpreter, for example. Expressions entered at the REPL get compiled directly to machine code, so there's no difference in performance for a function entered at the REPL (or via SLIME C-c C-c) and one built as part of a batch compile.

Contrast that to Haskell's ghci interpreter, which is slower (last time I checked) than the same code built on the command line with ghc, the compiler. But I would still consider Haskell a compiled language, not an interpreted one, since you never run code in production under ghci, you always ship your binaries.

I suppose it's about perception. To me "interpreter" refers to a language implementation strategy. It's fuzzy, I know, since there is some continuum between interpreting an AST directly, compiling the AST to bytecode and running the bytecode on a VM, JIT compiling the bytecode to machine code on the fly, and compiling offline direct to machine code (like C/Go/Rust). To some ears, "interpreted" can sound synonymous with "slow", which is I guess what prompted my comment.

Finally, to me the place where you can enter expressions to try out your program interactively is the REPL, not the interpreter.

Anyway, thanks for explaining your position to me. (Also, good to know Python dev environments have improved, but I guess it's to be expected, 10 years is a long time :-) .)