Umka. Жизнь статической типизации в скриптовом языке

[richman5]

Наконец, родился более реалистичный пример использования Umka по его основному назначению, т. е. как встраиваемого языка.

На какой базовый ЯП (чтобы в него встраивать) ориентируетесь?

[Tereshkov]

Сейчас это C/C++. Другие языки — при наличии совместимого ABI вызова динамических библиотек. Поскольку многие языки хотят так или иначе работать с DLL, это не должно быть препятствием.

[richman5]

Разумно… Может ваша шутка про интерес игроделов к скорости вашего ЯП не такая уж и шутка.

Вы наверняка много знаете про проблемы и пути развития встраиваемых ЯП. В этом контексте кмк будет очень эффективно (и эффектно) делать пиар для Umka.

[Tereshkov]

А кстати, как бы вы обозначили эти проблемы, помимо быстродействия? Для большинства программистов проблем, кажется, и вовсе нет, когда под рукой Lua/LuaJIT (с последним только та проблема, что Майк Полл перестал им заниматься).

[funny_falcon]

Так что у вашего языка есть шанс: прикрутите MirJIT и будете вторым после LuaJIT (а это уже круто. Учитывая, какой противный язык Lua, многие мечтаю о вменяемой альтернативе).
https://github.com/vnmakarov/mir

[Tereshkov]

Интересный проект, не первый раз о нём слышу. Но беглый просмотр вызывает некоторые сомнения (поправьте, если я заблуждаюсь): документация скудная; нет разобранных примеров; нет готовых дистрибутивов в виде DLL; непонятно, откуда импортируются функции стандартной библиотеки C (нужно тянуть за собой libc/msvcrt?); непонятно, что делать с нетривиальными частями виртуальной машины — например, сборщиком мусора.

[richman5]

Я не настоящий сварщик, поэтому просто читаю об этом 1, 2, 3, 4, 5

[Tereshkov]

Спасибо, очень понравилась первая ссылка — взгляд на проблему с другой стороны баррикад. Хотя некоторые утверждения там весьма поверхностные:

Lua — это стековая машина, и там, на самом деле, просто нечему тормозить.

На самом деле, начиная с версии 5, Lua перешла от стековой машины к регистровой и получила от этого большой прирост быстродействия. У меня один и тот же численный алгоритм на Lua 5 работал в 2-3 раза быстрее, чем на Lua 4.
Добавим сюда всякие задержки на сборке мусора, поиску метода по цепочке наследования — и окажется, что тормозить там есть чему.

[richman5]

Да, это парадокс какой-то: вроде бы для целей встраиваемого ЯП скорость не должна быть критичной (обычно есть места вовне, где можно и поболее затормозить программу), но это и есть первый вопрос, который задают про эти ЯП ))