Зачем нужен ЛИСП C программисту?

Например, что вы делаете, когда вам нужно научитья пользоваться программой? Читаете документацию? Или просто запускаете и смотрите что и как? Скорее всего и то и другое. А что если нужно научиться пользоваться новой для вас библиотекой? Документация - замечательно. А как запустить? Если у нас есть DLL'ка, ее нужно сначала загрузить в адресное пространоство процесса, а затем уметь дергать функции в этой DLL'ке с правильной calling convention, передавать правильные аргументы и правильно интерпретировать значания. Кажется, без написания тестовых программ никак.

Но я уже достаточно давно использую для похожих целей python. В начале, я попробовал (на C++) Boost.python и Python C API - хорошо, но можно потеряться в темплейтах если что-то вдруг не заработает c Boost.Python. Затем, юзал SWIG. Тоже ничего, но там такое надо бывает написать в .i файле, придумывать какие-то typemaps для чуть более чем тривиальных случаев. Не хочется такое повторять. Boost.Python и SWIG плохи тем что интерфейс надо оборачивать и писать какой-то код. Быстро поэкспериментировать не получится.

Ничего особо писать не нужно в ctypes, но как-то сложилось, что я его не слишком использовал. А зря.

Сейчас обнаружил, что все варианты FFI в Сommon LISP чем-то похожи на ctypes. Итак, если разобраться в FFI в LISP, что же мы получаем? У нас есть некий процесс, в пространство которого мы можем загрузить любую DLL'ку, подергать ее. При этому это все делается в REPL, плюс под рукой есть мощный язык с помощью которого можно всем этим рулить, прототипировать, экспериментировать. Python с ctypes тоже тут неплох, просто в SLIME получше среда, да и макросами можно весь FFI быстро обернуть. См ранее об libgcrpyt