Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 7
Есть и на Форт (Forth) похожие проекты. :)

Проект от JohnEarnest — Mako
Mako (VM) — это портативная виртуальная игровая консоль на основе стека. Mako проект был разработан таким образом, чтобы его было легко переносить и внедрять: даже включая дополнительные функции, эталонная реализация занимает всего несколько страниц Java. Все игры и демки, написанные для Mako Теперь можно попробовать прямо в браузере благодаря Mako.JS .


Демо игры проекта запускаемые в браузере Mako.JS
image
Mako on Github

P.S. Тоже похожий проект из затронутой темы статьи jeforth.3we

Отличный выбор языка. Лисп легко разбирать и выполнять. У меня было несколько проектов с лиспом в качестве макро-языка для реализации расчетов по загружаемым извне программам. Правда, после первого проекта я перешел на Scheme, там многое проще и понятнее и спецификация R5RS на тот момент была всего на 50 страниц. Свои наработки я так и не опубликовал, но подумываю об этом.
Например, код на языке с garbage collection и на языке с явным управлением памятью было бы сложно объединить в одном проекте.


И без развернутой аргументации?

Существуют десятки лет успешные движки с подобным объединением.

И сложности объединения в одном проекте разных языков — крайне незначимая (даже можно сказать незаметная) сложность на фоне прочей сложности, что нужно преодолеть при создании игры…

Rust идеально подходит для разработки движка игры: из языков, ориентированных на производительность скомпилированного кода, в нём максимум выразительных средств – enum-ы с полями; pattern matching с деструктуризацией; макросы, генерирующие произвольный код во время компиляции; и т.п. С другой стороны, для описания игровой механики Rust подходит плохо: задержки на перекомпиляцию усложняет подход «подправить и тут же проверить, что получилось»;


По описанным критериям вперед выходит вовсе не Rust, а C++ и C#.

Понятно что автору интересно написать свой язык.
Но аргументация «почему он нужен» — не проработана.
Лучше бы этой аргументации вообще не было.

На этом примере хорошо видно, насколько код на JavaScript перегружен разнообразной пунктуацией и служебными словами, без которых можно обойтись.

Вот уж в первый раз встречаю обвинение любого языка в перегруженности пунктуацией со стороны лиспа :)


Никто вам не мешает указывать собственные рейнджи в виде [25, "i"] и раскрывать их потом как вам нравится, но как по мне вместо


(set-walls (10 40) (i 20) (i 60))

лучше написать


wall({ x: [10, 40], y: 20 })
wall({ x: [10, 40], y: 60 })

или что-то подобное, более читабельное чем набор чисел.

Никто вам не мешает указывать собственные рейнджи в виде [25, "i"] и раскрывать их потом как вам нравится

Раскрытие [25, "i"] в JS наверняка будет объёмнее, чем макрос set-walls в GameLisp.
Это же не внешний API, которым будут пользоваться десять лет, а локальный макрос, позволяющий вчетверо сократить процедуру инициализации уровня, и не нужный больше нигде.

лучше написать wall({ x: [10, 40], y: 20 })

Стены в Nibbles бывают диагональными (set-walls (6 47) (i i)), пунктирными (set-walls (4 49 2) (i 40)) и т.д.
Не могу пройти мимо:
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.