Как стать автором
Обновить

Комментарии 33

НЛО прилетело и опубликовало эту надпись здесь

Js в прицнипе не очень благородное дело, а еще и для проекта на cpp...

Тащить js ну такое… При этом мы теряем адекватную типизацию. Тогда уж питон взять проще

Опять же для прозрачного взаимодействия плюсов с питоном понадобится какой-нибудь Boost.Python (или есть что-то более стильное, модное молодёжное?). А ChaiScript и AngelScript, они нормально взаимодействуют только с плюсами, но зато взаимодействие с плюсами у них «из коробки»…
Ну, автор же всё расписал:
легкость внедрения в уже существующий код и поддержка C++ вместо C, чтобы не городить забор из ООП-оберток над C-style функциями.

Для Lua нужен ещё какой-нибудь Sol или LuaBridge (когда-то ещё luabind был) ну или самому заботится об обращении из lua к объектам cpp. Интерпретатор JS на сотню килобайт вряд ли сравнится по эффективности с Lua, не говоря уж о LuaJit (а как с этим у Чая?) ну и про маппинг объектов cpp там, опять же вряд-ли кто позаботился — всё ручками.

Есть ещё похожий проект AngelScript, но там статически типизированный язык (не совсем C++, но в первом приближении похож).
С производительностью все не так гладко. Так как компилятора в байткод нет, то все вычисления проводятся на AST, что конечно же в разы медленней как минимум из-за разрозненности данных в памяти. Сам Jason говорит по этому поводу тут: discourse.chaiscript.com/t/moving-to-a-bytecode-representation/186/3
Ага, уже сам это нагуглил. Вот AngelScript, похоже, быстрее даже «ванильного» Lua (не JIT), но сам язык больше похож на C++, чем на скриптовый.
Интерпретатор JS на сотню килобайт вряд ли сравнится по эффективности с Lua, не говоря уж о LuaJit (а как с этим у Чая?)

Судя по подобным дискуссиям ChaiScript по производительности всё же ближе к простым интерпретаторам JS «на сотню килобайт» чем к lua. Во всяком случае был.
Прежде всего, он, как и подавляющее большинство скриптовых языков, является динамически-типизированным

Менять тип переменных просто так не выйдет

Все-таки какой-то не совсем динамически типизированный
Да, в принципе я с вамм согласен. Видимо это опять же сделано для совместимости с C++, так как объявленные классы в скрипте фиксированным типом не обладают и соответственно прямого доступа из вызывающего кода к ним нет. Поведение объектов похоже на dynamic в шарпе
C++ обертки для Lua
github.com/vapourismo/luwra

Обертка класса выглядит даже проще чем обертки для ChaiScript
там просто используется макрос. Я тоже так сделал для своего проекта. А вот пушить руками переменные на стек — архаизм
Так и CHAI_IMPORT тоже макрос ))
Не понимаю, почему авторы новых языков не делают их «expression oriented», то есть чтобы все эти if, for, {} возвращали значение, и можно было помечать «переменные» как неизменяемые. Без этого при условной инициализации приходится сначала объявить неинициализированную неконстантную переменную, а потом присвоить ей соответствующее значение в каждой ветке условного оператора. Что при дальнейшем рефакторинге обязательно выльется в ее использование до инициализации. А вот если бы он (if) возвращал значение, можно было бы написать
const foo = if (a > 10) { 10 } else { 20 }

В частности для этого подозреваю был придуман тернарный оператор. Особенно это удобно когда для инициализации нужно вычислить ряд промежуточных значений, можно ввести скоуп с помощью {} и вернуть из него одно значение, не замусоривая функцию лишними переменными и четко обозначая, что после определенной точки они не нужны. Ну и из цикла бывает удобно на нужной итерации выйти со значением.
Кстати такое вроде для GCC есть в качестве расширения компилятора Си (см. Управляющие операторы и блоки кода как выражения) habr.com/ru/post/315676

В C++ для этого используют тернарный оператор в простых случаях или лямбды в более сложных:
int const val = [&] { if (a) return 0; else return 1; }();

Вот и получается, что нужно городить IIFE (immediately invoked function expression), потому что это единственный способ инкапсулировать вычисление и вернуть результат, что, согласитесь, совсем не удобно и не бесплатно (хотя конечно умный компилятор это оптимизирует, но не все языки компилируемые)
И Ruby:

a = if true then 'Yes, I can!' else 'No :(' end

=> «Yes, I can!»
Ну вот когда я написал про возможность возвращать значение из цикла, это и был намек на Rust
var myLongLong = 1ll // long long int


Ох не зря гугл просит буквы Л в суффиксах только большими писать
В шрифте статьи читается как 111. Пришлось осторожно вглядываться

У кого-то косяк с настройками
image

image


я настройки вообще не трогал

не надо вглядываться надо настроить шрифт в браузере =)
image

в коментах шрифт другой, элки вообще в палки превратились


image

В chromium поставил плагин font changer, в firefox через дефолтные настройки сняв «Разрешить веб-сайтам использовать свои шрифты вместо установленных выше».
На всех сайтах, что статьи, что комментарии выглядят одинаково (PT Mono).
Было бы интересно если был бы свой интерпретатор, а так не особо.

Странно, что автор сразу зарядил про 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 решения. Там лучше выбирать то, на чём удобней будет писать скрипты конечному пользователю, остальное, в основном, это единоразовые затраты, хотя кейс с запретом импорта стандартной библиотеки таковым не кажется, и может потребовать поддержки.

«днако, как бы странно это ни звучало, на хабре не оказалось ни одной статьи, в которой хоть как-то бы упоминался этот язык»

Наверное это из-за того что в плюсах много нужно писать своими руками. Вот и выработалась привычка писать своё собственное решение вместо использования уже доступного. Скорее всего у Джейсона так и было.
Очень интересный язык, интереснее чем AngelScript и lua. Но есть вопросы, как с производительностью? Я в своё время выбрал AngelScript потому что он быстрее lua (даже с jit) при активном использовании проброшенных плюсовых классов и методов, что являлось подавляющим юзкейсом. И также не освещена тема многопоточности, имеются ли тут какие нибудь особенности типа того же GIL у питона?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.