You linked to Rainer's home box on a DSL line, I hope you're happy parenthesis :-/
Folks, please please don't crawl that site. If you see a document you like wait a few days and download it then, or just browse it there slowly.
[Edit: He is running good ole CL-HTTP on LispWorks it seems. Rainer also has the occassional Lisp machine serving pages sometimes; that I wouldn't want slashdoted ;-]
The page is lightweight with a reason. The documents are linked to another server with more bandwidth (but with a slight disk problem, I hope it still survives a bit).
More 'problematic' was comment of mine on reddit where I linked to some pages with images. If it is slow, then it is more especially when somebody looks at such a page.
Well, when Clinton was president, two Symbolics XL1200 and then later two DEC Alphas running Open Genera were serving the White House Publication Server (a part of Clinton's web presence). Those two machines did get a lot more hits than my home site does. I had the chance to look at the live logs during the monica levinsky scandal. ;-)
Anyway, don't crawl the site. It is for reading, not for crawling. It's up in this way since 2003 and I hope it stays this way. Thanks. ;-)
What motivated me to revisit it again is Naughty Dog's presentation on their "new" version of Scheme scripting engine they use in Uncharted 2 (similar to GOAL, but new, based on PLT-Scheme).
What I'm wondering is, now that we have multicore power, huge amount of RAM and stuff like that - why are people so dispersed into other functional languages when LISP has such a rich heritage? IMO wouldn't it be trivial to run Scheme or any other LISP if you stick to functional programming? Of course, on the other hand there is a problem of parallel algo's, but that is another topic.
Some of the other languages have capabilities that Lisp doesn't, and while some argue that one can theoretically graft anything onto Lisp via macros, there's something to be said for having them planned as part of the language. Really diving into another functional language (I'd suggest OCaml or Erlang) will influence your programming just as much as learning Scheme has, whichever you use more in the long run. OCaml will get you thinking about when static typing is a useful tool, and Erlang has a refreshingly sensible take on concurrency.
The people who designed those languages weren't ignorant of Lisp, by the way. For example, ML (i.e., SML and OCaml) was originally designed because Lisp's dynamic typing kept leading to subtle errors in an automated theorem prover, IIRC. The influence of Lisp on Haskell and Erlang is also pretty obvious, particularly in the terminology. Lisp is not the end of programming language evolution -- Scheme is just one of the most concise designs so far.
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.
Folks, please please don't crawl that site. If you see a document you like wait a few days and download it then, or just browse it there slowly.
[Edit: He is running good ole CL-HTTP on LispWorks it seems. Rainer also has the occassional Lisp machine serving pages sometimes; that I wouldn't want slashdoted ;-]