Тут народ в разных темах любит писать, что Лисп никто сейчас
не использует. Контрпримеров тому масса, но хотелось бы привести
один, так сказать, сидящий у все .NETовцев перед носом.

Если у вас есть Visual Studio .NET 2003, зайдите в папку
Program Files/Microsoft Visual Studio .NET 2003/JavaLanguageConversionAssistant
Запустите JConvert.exe. Обратите внимание на фразу Portions (C) Franz Inc.
Обратите внимание на следующие файлы — acl5016.dll — это рантайм
Allegro Common Lisp 5.0, небольшая часть этой реализации, написанная на
C (внутри содержится строка Allegro CL). VJToDotNET.img — это имейдж
лиспа с самим приложением (native x86).

В Visual Studio .NET 2005 в JavaLanguageConversionAssistant признаков
Allegro CL уже нет, зато есть кое-что другое достаточно интересное.
"Мясо" приложения сидит в JCLA.dll, это сборка .NET, и если посмотреть
её рефлектором, то на проверку окажется, что исходно это был явно
не C# или VB.NET. Там же лежит интересный файл Kablock.Runtime.dll,
который на проверку оказывается рантаймом для некоего самобытного
диалекта лиспа, очевидно, что-то более близкое к Scheme, компилируемое
в MSIL.

Небольшое исследование показало, что это есть творение компании
ArtInSoft (http://www.artinsoft.com/), которая выпускает целый ряд
продуктов для преобразований между различными языками, и у которой,
видимо, Microsoft закупает подобные приблуды для Studio.
Скачав кое что из их репертуара, я убедился, что Kablock.Runtime.dll
там также присутствует. Не знаю точно, что их заставило перейти от CL
к Scheme или чему-то в этом роде — может быть,
политические соображения, Microsoft Certified Partner — тут уж
проблема "dogfood", как же так, .NET не использовать, а следать
свой компилятор Scheme -> MSIL проще, чем CL -> MSIL. При этом
поскольку у приложений-конвертеров интерфейс с внешним миром
минимальный, объектами особо заморачиваться не надо, внешние
библиотеки, не считая парсинга, не нужны, сама задача по сути
натуральный y=f(x), то может и впрямь для этого случая Схема
в чём-то лучше.