I rather like Scheme, if you want to work with the JVM you should check out Clojure, which is a lisp that is designed to work in the JVM. And yes Lisp is still worth learning to see how powerful such a minimal design can be! The folks who created lisp got some things really right. Its amazing how many of the cool new features of modern languages lisp had in the 1960's!
For an embeded scheme try guile: http://www.gnu.org/s/guile/
The paper is interesting in many ways.
The most interesting part is this: the authors falsified the paper from 1984 just two years later in 1986 themselves. Brooks and Gabriel developed a highly optimizing Lisp compiler and sold it commercially very successful for several years: Lucid Common Lisp (PDF).
Maintenance for this Lisp compiler is still available from LispWorks: it is now called Liquid Common Lisp.
The compiler optimizations of Liquid CL are documented in Chapter 3 of the Advanced User's Guide: Optimizing Lisp Programs.
Several commercial applications have been written and deployed in Lucid CL. For example in my home town the first public transport information system for the HVV (Hamburger Verkehrsverbund) was deployed using Lucid CL on a SUN SPARCstation. It was available for the public in train stations using a large touch screen and in the call center.
Lucid CL was successful because its production mode compiler created fast Common Lisp applications, mainly for Unix / RISC platforms.
Brooks and Gabriel are writing about Lucid Common Lisp in 1986:
The dynamically retargetable compiler has been shown to be a means by
which ease of compilation for a variety of Lisp implementations can be
performed; a means of porting Lisp systems to a variety of computers;
and a tool for producing high-quality, high-performance code for a
variety of computers from a common source.
Thus they had just implemented what the A Critique of Common Lisp claimed to be difficult or impossible.
Nowadays the more advanced implementations are doing a lot of optimizations, but the hardware is also 1000+ times faster than what we had in 1984. A VAX 11/780 then had one MIPS (million instructions per second) and a Lisp Machine was also in that range. A Motorola 68000 had a clock rate of 8 MHz.
The criticism about floating point performance and generally varying performance is still valid, but this reflects implementors choice. Some implementations are not developed as high-performance compilers. Their main focus could be portability, compactness or something else and thus they have different implementation goals.
As a user/developer one is not forced to write portable code and use all of the ten+ currently supported Common Lisp systems. Use the implementation which is best suited to the application problem.
Best Answer
For Common Lisp I'm using something like this:
ASDFas a tool for that)compile-file, a file is a compilation unitFiles in a system:
a subsystem in a file:
If you develop, you load the compiled system developed so far and extend it incrementally. Once a new functionality is written and tested -> compile the system again, load it and test it again.
The old book 'Lisp: Style and Design' by Molly M. Miller and Eric Benson describes organizing principles and gives an example. Since this book is old, there is some newer infrastructure and some new tools. But the general principles mentioned in the book are still useful.