Комментарии 33
Js в прицнипе не очень благородное дело, а еще и для проекта на cpp...
Тащить js ну такое… При этом мы теряем адекватную типизацию. Тогда уж питон взять проще
легкость внедрения в уже существующий код и поддержка C++ вместо C, чтобы не городить забор из ООП-оберток над C-style функциями.
Для Lua нужен ещё какой-нибудь Sol или LuaBridge (когда-то ещё luabind был) ну или самому заботится об обращении из lua к объектам cpp. Интерпретатор JS на сотню килобайт вряд ли сравнится по эффективности с Lua, не говоря уж о LuaJit (а как с этим у Чая?) ну и про маппинг объектов cpp там, опять же вряд-ли кто позаботился — всё ручками.
Есть ещё похожий проект AngelScript, но там статически типизированный язык (не совсем C++, но в первом приближении похож).
Интерпретатор JS на сотню килобайт вряд ли сравнится по эффективности с Lua, не говоря уж о LuaJit (а как с этим у Чая?)
Судя по подобным дискуссиям ChaiScript по производительности всё же ближе к простым интерпретаторам JS «на сотню килобайт» чем к lua. Во всяком случае был.
Прежде всего, он, как и подавляющее большинство скриптовых языков, является динамически-типизированным
Менять тип переменных просто так не выйдет
Все-таки какой-то не совсем динамически типизированный
github.com/vapourismo/luwra
Обертка класса выглядит даже проще чем обертки для ChaiScript
const foo = if (a > 10) { 10 } else { 20 }
В частности для этого подозреваю был придуман тернарный оператор. Особенно это удобно когда для инициализации нужно вычислить ряд промежуточных значений, можно ввести скоуп с помощью {} и вернуть из него одно значение, не замусоривая функцию лишними переменными и четко обозначая, что после определенной точки они не нужны. Ну и из цикла бывает удобно на нужной итерации выйти со значением.
В C++ для этого используют тернарный оператор в простых случаях или лямбды в более сложных:
int const val = [&] { if (a) return 0; else return 1; }();
let y = if 12 * 15 > 150 {
"Bigger"
} else {
"Smaller"
};
assert_eq!(y, "Bigger");
var myLongLong = 1ll // long long int
Ох не зря гугл просит буквы Л в суффиксах только большими писать
В шрифте статьи читается как 111. Пришлось осторожно вглядываться
Странно, что автор сразу зарядил про lua, лично я подумал, а почему это не python или js. Оба два встраиваются довольно просто. А помимо этого имеют богатые библиотеки. Почти уверен, что тот же Js окажется по итогам и более производительным.
Не знаю как с JS, а питон встраивается довольно нетривиально. Причём основная лично для меня проблема — стандартный механизм импортов крайне тяжело взять под контроль. Последнее, что я находил — требуется руками редактировать исходники питона, иначе нет возможности к примеру ограничить доступ к стандартной библиотеке. Даже если вы её выпилите из вашего дистрибутива, клиентский код вполне сможет подгрузить свой модуль, к примеру неизменённую стандартную библиотеку. В отличие от него, Lua и встраивается, и изолируется не в пример проще.
Хм с помощью boost::python например, я делал в обе стороны интеграции (плюсы в python и python в плюсы), не помню, что бы встретил какие-то трудности на этом пути, разницы с lua я практически не увидел, а бустовый сахар сделал процесс даже проще. Но у меня требования об ограничении доступа в стандартную библиотеку не стояли, вполне допускаю что это может быть нетривиально, т.к. обширная стандартная библиотека это один из основных критериев выбора обычно.
Что касается JS — там API чуть сложнее(ну и реализаций минимум 2), но зато стандартной библиотеки — практически просто нет, а потоки хотя бы упоминаются в документации (в том плане что есть re-entrant, что есть thread-safe и какой ценой). По эффективности итогового решения, с включенным jit оно сравнимо или лучше lua (python тут в уверенном хвосте плетётся). Т.е. для конкурентных высоконагруженных приложений я бы несколько раз тщательно взвесил сравнения lua/js и произвёл бы бенчмарки для типовых случаев. Думаю цена интеграции реализаций рассчитанных на встраивание была бы тут ничтожно малой.
Lua — конечно чемпион в плане простоты интеграции и быстрого старта, но это практически единственное его достоинство. Очень узкие комьюнити владеющих этим языком профессионально, поэтому вынести значительную часть бизнесс логики туда — часто выглядит сомнительным решением, даже на фоне чуть более высокой технической сложности для более распостранёныйх технологий. Я не говорю что это совсем не кейс, кейс и ещё какой, т.к. комьюнити имеют место быть, но подумать надо n, а лучше n+1 раз :)
Итого, для себя я сформировал такой чеклист:
- Есть комьюнити, клиент ожидает увидеть lua — берём lua, при условии, что нет необходимости иметь более широкие возможности быстрого прототипирования
- Основная цель быстрое прототипирование и лёгкий вход небольшой и обученной группы, целевая аудитория не связанна с web-frontend, нет высоких нефункциональных требований — берём python
- Есть web-oriented комьюнити, есть высокие нефункциональные требования, требуется широкая аудитория — берём ecma script
Когда я говорю про высоконагруженные решения, я не имею ввиду i/o-bound решения. Там лучше выбирать то, на чём удобней будет писать скрипты конечному пользователю, остальное, в основном, это единоразовые затраты, хотя кейс с запретом импорта стандартной библиотеки таковым не кажется, и может потребовать поддержки.
Наверное это из-за того что в плюсах много нужно писать своими руками. Вот и выработалась привычка писать своё собственное решение вместо использования уже доступного. Скорее всего у Джейсона так и было.
ChaiScript — скриптовый язык для C++