A modern day operating system has been written in Lisp. If you're talking about x86, there is Movitz as proof of concept, but there is more to "operating system" than a bootstrapped self-hosted shell.
Regarding high performance numeric code in CL, you have the whole of Richard Fateman's career and body of work to peruse. Recently, Didier Verna did a few awesome things:
There was an awesome report from a boutique audio shop that produces gear for audiophiles; they were doing some realtime stuff and they pushed LispWorks harder than anyone I know. Too bad can't think of their name atm.
I did not mean that he had to build it, just that CL is not the fastest LISP dialect out there. You need to sacrifice a few features when looking for stupid levels of speed. Still you can can use a LISP for this stuff even if it's not CL.
Keep in mind that GOAL was designed for deployment on a game console. Also, a lot of the bottle-neck issues that games face are not the same as in high performance, number crunching finance software. Games are graphics, I/O and event processing heavy. In addition, games are compile once and give it to thousands of people type software. While analysis software is often writen once, but tweaked and updated by the end user very frequently. Common Lisp would be just perfect for this type of two stage explore/optimize usage; the development environment is posh, and the performance can get as raw as you want it to be.
My intentions for playing with the language is to rewrite enough of QuantLib, a large library I feel comfortable with, for myself using Lisp so that I can eventually run an equivalent of the Equity Options Example found in the source download. It's just learning at this point, taking something I know and rewriting it in a different language in order to get to know the language better. It will take some time.
What is the problem with inline assembly? Ever heard of LAP (Lisp Assembly Program)? It appeared in Lisp 1.5 and today every decent Common Lisp has one. The sickest one is in Corman Lisp's, where all I had to do was put parenthesis around Win32 NASM code and the fucker ran it.)
IMO, if you are going to sprinkle ASM thought the program, because it really needs to be that fast then CL is probably not the best LISP dialect for you. It's just a rule of thumb and if you only care about speed for a tiny inner loop than CL is still a great choice, but if most of the app needs to be stupid fast consider your options.
Have you heard of FFIs? Foreign function interfaces? You can call ANY OS system call from Lisp, and for user-mode shared libraries you can just load them and call their functions just as easily.
Look for some applications your code needs to be as fast as possible. When your company is writing the software and spending 50million / year on HW taking a slight speed hit to use your favorite tool is not always an option.
PS: Consider how much money Honda spends on processing power for their engines and how much a 5% speed hit would cost them to fix by buying better HW.
It should be fairly straightforward to implement enough of Quantlib in Common Lisp IF you are able to implement the same algorithms in any other language. The data structures and data types can be mechanically converted (the Lisp numeric tower if far richer than C++'s numeric capabilities and it might obviate some things) however, it's the numeric algorithms that require expertise to reimplement. A 1:1 translation wouldn't produce an attractive result.
By algorithms I mean stuff like the monte-carlo constructors, MakeMCEuropeanEngine, etc.
The rest of the stuff would look far more attractive in Common Lisp. deftype can tidy up type definitions. The lisp pretty printer and the format function look way more compact than those huge blocks of cout, etc.
One way I can think of is to create C wrappers for C++ and call those wrappers from Lisp. You might have to struggle with Boost, templates and other design patterny crap tacked onto C++ though :-( one way I know is to reify template arguments into function arguments. e.g:
new BinomialVanillaEngine<JarrowRudd>(bsmProcess,timeSteps)
The financial engineering is not a problem at all. I just asked the two questions that spawned these posts because I was interested in what type things Lisp was being used for. Google and Wikipedia are good, but not nearly as helpful as a direct answer from some people responding directly to questions I've posted.
I spent a good deal of last year and most of this year ripping apart both GSL and QuantLib in an effort to teach myself numerical programming. My plan is to just keep pace in Lisp with my MSFE program. Since at least the first few months of the program are likely to cover things I already feel comfortable with, the plan is--listen in lecture-->go home and code it up.
Could a modern day operating system be written in Common Lisp? Could highly numeric code (for quant work) run as fast as C/C++?