Negative Sense Fantasy World: Next Big Lisp

Assume for the moment that Common Lisp is dying. Whether or not this is true in real life is totally up for debate, but in this hypothetical scenario, CL is breathing its final death rattle and it's way more trouble than it's worth to write any kind of program in it. In fact, let's go so far as to say that every CL implementation is unmaintained, and in a state of total disrepair.

Also, assume that Clojure is the only real alternative as Lisps go, and that you are completely dissatisfied with it as a replacement for Common Lisp, for extremely valid technical reasons that cannot be ignored or worked around. (This also might be true in real life depending on what kind of program you want to write, but let's all get on the same page.)

Now, let's say you could hire a genius programmer full time to design a replacement for Common Lisp. In this scenario you are a charismatic marketing god like Steve Jobs, so your programmer can be a world-class anuslord from the back alleys of Wichita, but your new language would still be a success because the programmer is only concerned with technical matters.

Who do you hire?

>>16
There's some with small runtimes, like that one that compiles to C. I still prefer those with larger runtimes for overall development - much nicer to work with, but if size is an issue for deployment, considering alternatives is always an option. As for lack of consistency: I've written some medium sized applications/tools in CL, depending on 5-10 systems, and it even included a bunch of unportably things I had tied to SBCL at that time. How much time did it take me to port it to CCL, ECL, CLISP? Under an hour. Most of it was testing that things worked properly. I just had to use a few read-time conditionals to implement about 3 non-portable functions I made used from SBCL internals, and I was able to do it mostly out of the box with the other implementations. Testing/compiling was easy with SLIME/asdf. Yes, there's that initial setup hurdle that you have to go through to get multiple implementations working like you want them to be (as well as Emacs/SLIME/Paredit/Redshank/others), usually involving setting up a central asdf repository that all implementations can use, but after that it's a piece of cake. So far, I was most annoyed by "portable" pathname differences between implementations, but this was hardly a major issue that couldn't be solved by adding another compatibility layer (there are some floating around).

tl;dr: The Common Lisp way - the base language is powerful enough and standardized, implementations usually support it well enough. If you need non-standard behaviour portably, write a thin compatibility layer or use someone else's (available for 99% of things you need, spend an hour to implement the other 1% if you need). So far this approach has served me well, most of my code is compliant with ANSI CL, while the parts that are not are clearly isolated and are easily made de-facto portable by using a few reader conditionals for all implementations I care about (and if using someone else's code, many others which I don't).