Преимущества функционального программирования

Если из конфига получается код, значит это дсл. Такие дела.

Ну и пусть транслируется в C++, Java, XML, LLVM... Что такого-то? Лисп — платформа для разработки компиляторов. Ежу понятно, что рантайм самого Racket очень мало под какие задачи хорошо подходит. Заточен он под реализацию лисповской макросистемы; поэтому именно в компиляторах DSL его и нужно использовать. А нахрена нужен лисп в рантайме игры? Если только чтобы динамически контент изменять, т.е. нафиг это не нужно на приставках.

Напоминаю, что это тупо конфигфайл вместо многословного XML, а не код.

Напоминаю, что на этих «конфигфайлах» написана вся логика геймплея, анимации, эффектов, звуков и диалогов. Причем написана самими дизайнерами, сценаристами, аниматорами и прочими специалистами.

И транслируется этот конфиг в C++.

А конфиг на C++ в свою очередь транслируется в конфиг на ассемблере.

Опять то же самое ко-ко-ко. Ничего нового в свое оправдание не можете придумать, борщехлебы? Рантайма лишпика в бинарнике нет - следовательно, ничего написанного на скобкоте там нет. Точка. А вот рантайм C++ там очень даже есть, libstdc++ называется.

Ололошечки, Линукс тогда написан на gnu make и bash!!!

Рантайма лишпика в бинарнике нет

А нам и не надо. Напоминаю, что мы говорим про компиляторы DSL'ей. А кто там полы моет, дворы подметает и рантаймы пишет, не наша забота.

Ну я и говорю, линукс написан на gnu make.

В Линуксе, когда мне нужен новый драйвер, я пишу его на C. В The Last of Us, когда мне нужен новый диалог, я пишу его на DSL.

Ололошечки, Линукс тогда написан на gnu make и bash!!!

Ну я и говорю, линукс написан на gnu make.

Программист, который писал систему сборки линукса на Make и Bash, знал, что такое линукс и каким образом следует его собирать. Аналогично: программист, пишущий компилятор из языка X в язык Y должен быть осведомлён о семантике Y, а возможно и об особенностях реализации Y, включая рантайм. Что непонятного?

Помнится, была дискуссия по теме, и кто-то хвастался, что у них там то-ли хеши, то-ли контрольные суммы во время компиляции разворачиваются, не помню в чём суть. Лично я, как начинавший с Си-подобных языков, к макросам в промышленном коде отношусь с осторожностью. Насчёт выразительности - это довольно субъективный вопрос.

Относительно выбора платформы я не владею всеми подробностями, но по поводу конкретно CHICKEN реализации схемы могу отметить: адекватная поддержка ARM и MIPS архитектур; статическая проверка типов и автовывод (ругается во время компиляции на неизвестные переменные, несоответствие сигнатур функций и т.п. - большинство типичных ошибок отлавливает); приличное количество библиотек; очень гибкий FFI - можно писать на Си прямо в теле функции или в одну строку обернуть внешнюю, что значительно облегчает миграцию; такие обёртки практически бесплатны в плане производительности (замеры давали в пределах 5% разницы с чистым Си). Так же, в целом, неожиданно годный для динамического языка оптимизатор. Для примера, плавная закраска текста со сглаживанием, настоящей прозрачностью и тд. на 400 MHz MIPSе выдаёт около 50 FPS. При этом его хватает ещё на декодирование аудио с наложением эффектов.

Racket is particularly strong at developing languages... DSLs. We utilized this to custom build hundreds of languages, large and small, to fit the various needs of the game.

В чем проблема-то?