языки программирования для скриптов
Встраиваемые языки: почему Lua?
Этот материал продолжает серию публикаций, основанных на докладах, которые мы сделали на конференции Games Gathering 2017 в декабре прошлого года. В одном из докладов была затронута тема выбора встраиваемого скриптового языка.
Что такое и зачем нужны скриптовые языки
Как уже упоминалось в предыдущем посте нашего блога, в нашей компании написан собственный движок. Сегодня речь пойдёт о том, чем мы руководствовались во время выбора скриптового языка для этого движка.
Таким образом, есть потребность в средстве для описания несложной, но всё-таки логики, без привлечения тяжёлой артиллерии программистов. Сделаем вывод — что такое для нас скриптовый язык? Это средство, которое позволит сделать разработку игр быстрее и дешевле.
Сразу возникает вопрос, а почему бы нам просто не использовать что-то вроде XML? Дело в том, что для наших целей нам часто нужны управляющие конструкции — ветвление и циклы, в то время как XML это декларативное описание.
Ещё одно преимущество скриптовых языков в том, что скрипты в проекте могут быть как кодом, так и ресурсом. И, соответственно, обновлять скриптовую часть игры можно не только вместе с кодом, то есть в ходе обычных обновлений через механизмы магазинов приложений. Но и вместе с ресурсами — то есть вместе с графическими и прочими материалами, с использованием CDN.
Требования к идеальному скриптовому языку
Сформулируем требования к идеальному скриптовому языку.
Python
Python — динамический язык, который пользуется немалой популярностью. Он характеризуется достаточно пологой кривой обучения, его довольно просто выучить. Однако изучить его как следует уже не так-то просто. Как результат, хорошие Python-программисты встречаются редко и дорого стоят. Это противоречит нашему желанию ускорить и удешевить разработку игровой логики.
Python обладает широкими возможностями, отличается хорошей производительностью. Его проблемой является неконсистентная система библиотек. Ещё одна его проблема, которая играет для нас важную роль, заключается в том, что он, на самом деле, не является встраиваемым языком. Это язык, из которого удобно вызывать библиотеки, написанные на C или C++.
По поводу возможностей по встраиванию Python можно сказать, что, например, существует Maya, где используется именно Python. Но тот, кто видел изнутри плагины для Maya, написанные на Python, согласится с нами в том, что выглядят они не очень хорошо.
В итоге можно сказать, что Python, при всех его сильных сторонах, нам не подходит. Теперь рассмотрим JavaScript.
JavaScript
JavaScript — это, без преувеличений, великий язык, который буквально захватил мир.
JavaScript — это популярный динамический язык, отличающийся пологой кривой обучения, обладающий широкими возможностями, хорошей производительностью и обширным набором библиотек.
Если нам, для построения игрового движка, нужен какой-нибудь интерпретатор языка — мы можем найти множество таких интерпретаторов. В реальности же придётся выбирать из двух подобных проектов — V8 и WebKit. И тот и другой имеют достаточно большие размеры. Как результат, если речь идёт о настольных играх, можно было бы рискнуть и включить в игру весь интерпретатор, но в случае мобильных игр нас такой вариант не устраивает.
В компании SocialQuantum есть собственный интерпретатор JavaScript, который проходит 98% тестов, мы планируем перевести этот проект в разряд опенсорсных.
В результате оказывается, что JavaScript выглядит сильным кандидатом на роль встраиваемого языка, но нам он тоже не подходит.
Тут надо отметить, что когда заходит разговор о JavaScript, следующим обычно вспоминают Haxe. Но, на самом деле, о возможности использования этого языка в качестве встраиваемого говорить нет смысла, так как Haxe, по сути, является не столько языком, сколько транс-компилятором в другие языки. А это не то, что нам нужно.
Может быть, нас устроит ActionScript или какой-нибудь другой скриптовый язык?
ActionScript
Если формально проанализировать ActionScript на соответствие вышеозначенным требованиям, то может показаться, что идеальный скриптовый язык найден. На его стороне динамическая природа, популярность, лёгкость изучения, хорошие возможности, производительность, наличие библиотек, лёгкость встраивания. Этот язык любят и помнят в игровой индустрии, на нём написано огромное количество замечательных Flash-игр. Главная проблема ActionScript заключается в том, что язык этот почти мёртв. Поэтому нас он тоже не устраивает.
AngelScript, Squirrel и другие
Помимо ActionScript существует множество скриптовых языков, таких, как AngelScript, Squirrel и другие. Среди них можно найти такие, которые, формально, почти полностью удовлетворяют нашим требованиям, но обычно это — языки, которые привязаны к их разработчику, в них бывают какие-то застарелые проблемы, которые годами не исправляются. Они, скорее всего, не слишком популярны, недостаточно хорошо документированы, по ним мало учебных материалов, у них не очень большие сообщества. Одним из следствий такого положения дел является тот факт, что их сложно изучать — хотя бы потому, что не до конца ясно — что они собой представляют и как работают.
Как видно, идеального встраиваемого языка мы пока не нашли. Что если создать собственный язык?
Создание собственного языка
Вполне возможно, что язык, разработанный внутри компании, будет идеально соответствовать её нуждам и его будет легко изучать. Но, скорее всего, такой язык не станет популярным. У такого языка либо будет минимальное количество библиотек, либо их не будет вовсе. Кроме того, сложно поверить, что в современных условиях можно создать нечто такое, что будет работать лучше, что будет обладать большей производительностью и будет проще встраиваться чем что-то, что уже есть на рынке.
Есть компании, которые разрабатывают и используют собственные языки, среди них есть и успешные игроки игрового рынка, но, скорее всего, это — не очень хорошая идея.
Рассмотрев существующие языки программирования, претендующие на роль встраиваемых и обсудив идею разработки собственного языка, перейдём к Lua.
Lua — встраиваемый язык, который выбрали мы
Lua — динамический язык. Он довольно-таки популярен, вокруг него сложилось большое сообщество, особенно — в сфере разработки игр. Он отличается весьма пологой кривой обучения. Например, в нашей компании сценарии для автотестов пишут на Lua. Стандартный вводный курс для автотестеров занимает примерно два часа, после чего человек в состоянии использовать этот язык. При этом Lua — мультипарадигменный язык. Он поддерживает функциональный стиль программирования и ООП. В результате он подходит не только для решения каких-то простейших задач, но и для более серьёзных дел, которыми занимаются профессиональные программисты.
Lua обладает хорошей производительностью и у него довольно много библиотек. Не так много, как у JavaScript, но, тем не менее, на сайте LuaForge можно найти практически всё, что может понадобиться. И, наконец, Lua очень просто встраивается, более того — он создан для того, чтобы его использовали как встраиваемый язык.
Например, вот как выглядит наша рабочая среда на основе IDE CLion от JetBrains. Здесь можно видеть созданный нами механизм автодополнения для Lua, который планируется сделать опенсорсным. Опенсорсным мы собираемся сделать и отладчик.
Мы выбрали Lua, но, когда речь заходит об использовании его в качестве встраиваемого скриптового языка, обычно приходится сталкиваться с примерно одними и теми же возражениями, которые мы сейчас рассмотрим.
Возражения по поводу использования Lua
Lua предназначен для C а не для С++
Никто не спорит с тем, что Lua — отличный встраиваемый язык. Главное, что считают его минусом, заключается в том, что он создан для использования с языком C, а не C++. Из-за этого, пытаясь применить в Lua что-то такое, что есть в C++ и нет в C, мы сталкиваемся с проблемами. Однако тут надо понимать, что проблемы эти решало множество довольно умных людей. Среди средств, решающих проблемы встраивания Lua в C++-проекты, можно отметить такие, как Luabind, Luabridge, toLua++, SQLuaHost. Это — далеко не полный список. Они обладают разными достоинствами и недостатками, но, тем не менее, скорее всего, всё, что вам может потребоваться, уже реализовано в одном из этих решений.
Рассмотрим, например SQLuaHost. Это — биндинг, который сделан внутри компании SocialQuantum, и который планируется сделать опенсорсным. Это решение представляет наше видение того, как должен биндиться Lua. Поэтому, вполне возможно, что если вы не нашли то, что вам нужно в существующих биндерах, вы найдёте это в SQLuaHost.
Lua — это медленно
Нам часто приходится сталкиваться с мнением, в соответствии с которым Lua — это очень медленный язык. Во-первых — это не так. Lua — это стековая машина, и там, на самом деле, просто нечему тормозить. К тому же надо понимать, что в скриптовый язык мы обычно отдаём игровую логику, бизнес-логику, а не какие-то действительно тяжёлые вещи. В результате, если Lua-скрипты заставляют игру тормозить, то проблема, возможно, кроется в неоптимальном биндинге или в нерациональном использовании каких-то функция языка. Мы, например, проводили синтетические тесты, на которых LuaJIT работает быстрее, чем Mono. При этом никто не мешает писать примерно такой вот неоптимальный код:
Здесь в каждом игровом тике создаётся новая текстура и устанавливается в качестве фона. Конечно, работать такая конструкция будет не особенно быстро, но никто не мешает писать такие вот вещи.
Lua подходит только для маленьких проектов
Следующее возражение заключается в том, что Lua сделан для того, чтобы писать какие-то маленькие вещи и что-то большое на этом языке написать невозможно. С одной стороны это правда. Но у этого языка высокая модульность. И из множества маленьких блоков можно делать достаточно большие и сложные системы. А если вспомнить то, что было уже сказано о мультипарадигменности и об ООП, то окажется, что ООП подталкивает разработчика к тому, чтобы создавать маленькие модули, которые можно использовать при создании больших и сложных конструкций.
При этом зачастую на Lua какие-то маленькие модули пишутся быстро, а в игровой индустрии «быстрее» — значит «дешевле».
Другие аргументы против Lua
Критикуя Lua, говорят о том, что язык это древний, что он, что называется, «из коробки», не поддерживает ООП, что нумерация элементов в его таблицах начинается не с 0, как можно было бы ожидать от любого приличного языка, а с 1.
Говорят, что его минус в том, что в нём нет тернарного оператора. На самом деле, таких вот аргументов против Lua довольно много, но мы не будем их обсуждать, так как полагаем, что они, по большей части, относятся к привычкам и личным предпочтениям разработчиков.
Итоги
Подведём итоги. Если ваша задача — с минимальными усилиями обзавестись встраиваемым языком — возьмите Lua. В то же время, если у вас есть время и ресурсы на разработку собственного языка или собственных биндингов — опять же — обратите внимание на Lua. Почему и в первом и во втором случаях мы рекомендуем Lua?
В первом случае, выбрав Lua, вы выберете язык, который очень просто встраивать и использовать. Существует ровно одна обучающая книга по этому языку, написанная его автором. Других книг нет просто потому, что в первой рассказано абсолютно всё, что нужно знать о Lua, и рассказывать о нём больше нечего. Lua — не идеальный и не самый распространённый в мире язык, но, по сумме критериев, это, определённо, один из лучших языков для встраивания. Он — лучший из того, что есть в нашем распоряжении прямо сейчас. К тому же, существует множество стандартных инструментов для Lua, которые сильно облегчают жизнь тем, кто им пользуется.
Во втором случае, если у вас есть ресурсы на разработку инструментов, вы, выбрав Lua, сможете с толком потратить эти ресурсы, так как Lua, несмотря на его популярность в среде разработки игр, язык весьма недооценённый. Как результат, у вас будет возможность, взяв за основу Lua, учесть свои потребности и получить именно то, что вам нужно.
Есть Javascript. Зачем нужны другие скриптовые языки?
Я долго и честно терпел, но, наконец, не выдержал. Может мы вместе можем разобраться?
Итак, предположим некто решил создать _новый_ скриптовый язык. И, допустим, называет его Ruby. Давайте попробуем понять — зачем вообще это нужно делать? Что мы ожидаем от скриптового языка? Все это, на мой взгляд, достаточно очевидно, но желающие могут и похоливарить, конечно. Например, можно расписать преимущества и недостатки примерно так:
— новый синтаксис, требующий изучения;
— невысокая производительность в сравнении с native-кодом;
— автоматическая сборка мусора;
— синтаксический сахар;
— runtime-типизация;
— runtime-расширяемость объектов.
Примерно так. Таким образом, создатель скриптового языка первым делом _отказывается от производительности_ ради других преимуществ. Это очень важное архитектурное решение и мы вернемся к нему позже.
При создании нового скриптового языка — нужна связь VM (виртуальная машина, испольняющая скрипт) скрипта и внешнего мира. Нужны модули, библиотеки, фреймворки и прочие имплементации, простите мне это старинное русское слово. Рассуждая о возможностях того или иного скриптового языка, приверженцы скриптовых культов могут обсуждать следующие совершенно различные темы:
— о синтаксисе и удобстве самого языка (например, встроенный eval());
— о удобной реализации некоего функционала, который реализуется некоей библиотекой (например, регулярные выражения или встроенный веб-сервер);
— о скорости выполнения вычислений «внутри» VM (например, сортировка массива);
— о скорости выполнения вызовов из VM во внешний мир (библиотеку, ОС) (например, запись в файл).
Так вот. К скриптовому языку имеет отношение только первый пункт. Только он.
Все остальное имеет отношение к реализации. Не к самому языку.
Если скриптовый холиварщик рассуждает не о первом пункте, то ему следует тогда отметить, что он рассуждает уже не о языке, а о платформе: конкретной реализации скриптового языка на конкретной ОС или на конкретной VM.
Первый тезис. Преимуществом скриптового языка не может являться наличие библиотек, которые реализуют тот или иной функционал. Все это зависит исключительно от реализации скриптового языка. Возьмем, например, эту статью:
Здесь описывается реализация www-сервера на Ruby.
Но что здесь, собственно, от Ruby?
Вот смотрите я только что написал www-сервер на JavaScript:
var www_server = new WebServer(‘127.0.0.1’, 3456);
Он принимает запросы и отдает файлы. Верите? А у меня есть такая вот реализация ввв-сервера. И теперь вы знаете, что JavaScript — хороший язык и на нем легко создавать веб-сервера, да? Вы знаете или не знаете?
Кстати, на JavaScript также легко запустить будет Doom 4. Ну, когда он выйдет. Вот смотрите:
var doom4 = new Doom4();
Клево, правда? В следующих бутылках мы продолжим знакомство с javascript, а теперь возвращаемся к нашей теме.
Берем теперь уже конкретно Ruby. Уж, извините, попался мне под руку, но это мог быть и любой другой язык, в принципе.
Вот, например, я читаю возможности Ruby и слегка офигеваю.
»
Имеет лаконичный и простой синтаксис, частично разработанный под влиянием Ада, Эйфель и Python.
Позволяет обрабатывать исключения в стиле Java и Python.
Позволяет переопределять операторы, которые на самом деле являются методами.
Полностью объектно-ориентированный язык программирования.
Не поддерживает множественное наследование, но вместо него может использоваться концепция «примесей», основанная в данном языке на механизме модулей.
Содержит автоматический сборщик мусора. Он работает для всех объектов Ruby, в том числе для внешних библиотек.
Поддерживает замыкания с полной привязкой к переменным.
«
Кхм. А чего из этого нет в JavaScript? Ну разве что переопределения операторов. И? Ради чего весь шум?
«В Ruby есть немало оригинальных решений, редко или вообще не встречающихся в распространённых языках программирования. Можно добавлять методы не только в любые классы, но и в любые объекты. Например, вы можете добавить к некоторой строке произвольный метод.»
«Любая конструкция в Ruby возвращает значение. Например:»
«Работа с массивами — одна из сильных сторон Ruby. Они автоматически изменяют размер, могут содержать любые элементы и язык предоставляет мощные средства для их обработки.»
Ну тут даже говорить-то не о чем. JavaScript просто выносит Ruby.
Тезис намба два. Синтаксис и возможности JavaScript полностью превосходят другие скриптовые языки, причем они _не зависят от реализации_, а уже являются частью языка. Небольшие преимущества, который дает синтаксический сахар конкурентов, быстро оказываются задавленными eval(), JSON, arguments и прочими приятными возможностями JavaScript.
Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python. Есть ли там null, обладающий особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом arguments? Могу ли я создать в них объект с данными и методами, написав:
Пожалуйста, напишите примеры. А то может я что-то упорно не понимаю и есть какие-то секретные знания о секретных возможностях этих скриптовых языков, которых постигли немногие просветленные?
И большая просьба — примеры того, чего НЕЛЬЗЯ сделать в JavaScript. Берем Ecma-262 за основу.
Чего можно написать такого в других скриптах, чего ну никак не сделаешь в JavaScript?
Теперь я просто хамски пройдусь по реализациям скриптовых этих языков. Тут уже JavaScript отдохнет.
Самое интересное наступает, когда вы начинаете выполнять много-много скриптов одновременно. И тут выясняется, что хваленые скриптовые машины быстро или медленно умирают.
При небольших разборках выясняется интересная деталь — разработчики этих скриптовых языков по какой-то странной и загадочной причине положили на производительность. Сразу! Их настолько увлекли эротические фантазии, связанные с удивительным новым синтаксисом, что никто в голову-то и не взял простую мысль: следует с самого начала предусмотреть реализацию, позволяющую выполнять быстро много скриптов.
В результате, читаем:
«Интерпретатор Ruby на сегодняшний день имеет следующие недостатки. Невысокая скорость работы. Ruby 1.8 является одним из самых медленных из используемых в практике веб-разработки языков программирования»
«PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode может быть оптимизирован с использованием необязательного оптимизатора, названного Zend Optimizer. В зависимости от скрипта, он может увеличить скорость выполнения PHP скрипта до 50%.
Раньше, после выполнения, opcode уничтожался. „
Лирическое отступление. Разве не гениально? Ну кто — кто бы во всем мире мог додуматься, что скомпилированные скрипты можно кешировать? Это ж надо быть… Биллом Гейтсом, наверное. Или двумя Гейтсами сразу.
Вы, надеюсь, понимаете над чем именно я иронизирую? Вот на этим: “раньше», «имел недостатки, которые были устранены», «был полным дерьмом до того, как». Я не понимаю — зачем начинать с дерьмовой производительности. Ну поясните мне! Пожалуйста! Ради чего тогда создается новый скриптовый язык?
Ну ладно, допустим Вы предлагаете свой новый супер-модный скриптовый язык для домашнего пользования и написания студенческих работ. Тогда я понимаю — производительность не имеет значения.
А вот если Вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня вот есть сильное такое подозрение, что производительность является _самым_важным_ критерием.
Так что следующий тезис не имеет отношения к JavaScript, это очередная порция яда в отношении прочих.
Тезис намба фри. Реализации новых скриптовых языков изначально не содержали исходного архитектурного решения, позволяющего выжать из них максимум производительности: многопоточное исполнение, пулы разделяемых внутренних структур (контекстов выполнения, например), предварительной компиляции, настроечной компиляции из промежуточного байт-кода. При этом большинство из этих языков предлагалось как раз для сектора, связанного с большой нагрузкой, например, веб-сервера.
И поэтому довольно забавно читать как PHP применяется для обработки веб-запросов. Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…
Вышло несколько сумбурно и местами резковато, возможно.
Надеюсь никто не воспринял мои замечания лично и не обиделся.
Буду рад найти истину вместе с вами.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
9 популярных скриптовых языков для программистов и сисадминов
Выбираем скриптовый язык программирования
Языки сценариев пользуются большей популярностью для автоматизации определенных задач. Кроме того, языки сценариев являются менее ресурсоемкими по сравнению с традиционными языками программирования. Они не требуют этапа компиляции и вместо этого интерпретируются.
Например, программа Java должна быть скомпилирована перед запуском, тогда как приложение, написанное на языке сценариев, таких как Python, JavaScript или PHP, не требует компиляции. В Java-программировании сначала создаются файлы классов, а затем отображаются выходные данные. Напротив, в Python все коды выполняются во время запуска скрипта, поэтому языки программирования компилируются, тогда как языки сценариев интерпретируются.
Языки сценариев относятся к определенному типу, который используется для предоставления инструкций через код веб-браузерам или автономным приложениям. Они делают кодирование более простым и быстрым, поэтому они широко используются в веб-разработке.
Языки сценариев также используются в операционных системах для создания и автоматизации файлов запуска, игр, программного обеспечения статистического анализа, офисных приложений и многих других. Они могут эффективно работать в нескольких средах.
Вот список наиболее популярных языков сценариев, с которых можно начать знакомиться с миром программирования.
1. JavaScript
JavaScript широко используется для создания веб- или мобильных приложений, инструментов командной строки, сетевых приложений реального времени, таких как службы потоковой передачи видео, игры и т.д. Можно сказать, JavaScript является базовой технологией для создания современных веб-сайтов с уникальными функциями.
Ранее JavaScript использовался только для работы в браузере, но теперь существуют фреймворки на основе JavaScript, такие как Node, которые позволяют использовать JavaScript в бэкэнде. Есть несколько популярных JavaScript фреймворков для фронтэнда, вроде Angular и React.
2. Python
Руководство для начинающих с примерами по изучению Python можно прочесть здесь.
Разработчики в основном используют скрипты Python для автоматизации ежедневных задач, создания отчетов, обеспечения безопасности и т.д. Задачу автоматизации с Python можно выполнять за меньшее количество кода, чем в любых других языках программирования, таких как Java, C++.
3. PHP
Даже если это язык, который может делать почти все, что может язык программирования, он в основном используется для выполнения логики на стороне сервера. Когда вы нажимаете кнопку входа на странице входа в Facebook, логика, которая позволяет вам войти в ваш аккаунт, выполняется на PHP.
Руководство для начинающих с примерами по изучению PHP можно прочесть здесь.
С помощью PHP можно создавать динамичные и красивые веб-страницы; можно собирать данные из формы, созданной в формате HTML, и использовать их для шифрования данных. Из множества функциональных возможностей PHP можно использовать PHP для создания простого приложения CRUD, которое расшифровывается как создание, чтение, обновление и удаление.
Такие компании, как Википедия и Facebook, используют PHP, так как он может легко обрабатывать миллионы трафика.
R в основном используется для статистических вычислений и графики. Он широко используется аналитиками данных, учеными и статистиками. Этот язык сценариев используется через интерпретатор командной строки.
5. Ruby
Ruby является одним из самых гибких языков программирования, и он сходит с вашего пути, если вы не кодируете так, как хотите. Создатели Ruby вложили много работы, чтобы сделать его максимально простым в использовании. Ruby может спасти тебя от набора большого количества кода.
Гибкость Ruby позволила разработчикам создать невероятно инновационное программное обеспечение. Есть такие инструменты, как Chef, которые Facebook использует для автоматизации своей конфигурации сервера, или SAS, который помогает обеспечить стиль для веб-сайтов Pandora, и самое главное, Ruby разрабатывает Ruby on Rails, который, возможно, является самым популярным в мире веб- фреймворком. Airbnb и Kickstarter, как и многие другие компании, используют Ruby on Rails, в разработке своих свои веб-сайтов.
6. Perl
7. Groovy
Groovy очень похож на Java. Он имеет Java-подобный синтаксис, и, если вы уже знаете Java, вам будет легче изучать его. Это мощный динамический язык с эстетической типизацией и статической компиляцией. Groovy разработан, чтобы быть менее подробным, чем Java. Синтаксис менее сложен и следует простой структуре без ненужных точек с запятой.
8. Bash
9. PowerShell
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps