После пяти лет разработки доступен релиз Lua 5.4, быстрого и компактного скриптового языка программирования, получившего большое распространение в качестве встраиваемого (например, для определения конфигурации или для написания расширений). Код интерпретатора Lua написан на языке Си и распространяется под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53259
> Тип "userdata", предоставляющий возможность хранения в Lua-переменных любых Си-данныхЧто это значит? Как работает?
Полезная штука https://www.lua.org/pil/28.1.html
На самом деле в userdata удобно хранить указатели на класс, и для lua прописывать метаданные/методы, так чтобы работать с подобными С++ классами как с нейтив типами в lua.
> Подобные переменные могут быть назначены только один раз и после инициализации уже не могут быть изменены.Для чего это на практике?
Для встраиваемых решений (на всяких мелкоконтроллерах, где flash )
Да, скриптовой язык, сборка мусора, на мелкоконтроллерах.Давай тебе такую трансмиссию поставим?
Мелкоконтроллеры давно уже не такие мелкие. Про NodeMCU не слышал?
Про эту не слышал. Про то что есть и мелкие которые не мелкие знаю. Но в нормальных (которые отвечают за что-то серьёзное и критичное) как небыло сборщиков мусора, да и вообще работы с динамической памятью, так и нету.
Со "скриптами внутри" его (сборщика мусора) тоже не появится. Он же будет только внутри виртуальной машины, а весь окружающий нативный код как был статическим, так и останется (а именно он в нормальных системах делает всё критичное). Более того, ресурсы для виртуальной машины тоже делают статическими (с точки зрения вызывающего нативного кода). И если есть часть ресурсов под виртуалку заведомо read-only, то это ещё и ресурсов для нативного кода сэкономит (и уж точно это будет чистая статика).В общем, если знать меру и внимательно "следить за руками" (а во встраиваемых системах без этого никак невозможно), то вполне себе применяют и в серьёзных и условно*** критичных системах.
*** Там больше сложности не в применении скриптования как такового, и тем более не в сборщике мусора внутри виртуалки (при правильной архитектуре вообще довольно пофиг что там внутри) и т. п. Там больше в доказательстве отсутствия влияния всего что связано со скриптами (в основном с самой реализацией и работой виртуальной машины) на тот нативный код, который делает "всю важную работу". Это непросто, поэтому для сильно-сильно критичных штук реально дешевле не использовать совсем. Дешевле в плане всяких сертификаций - не использовать скрипты, дешевле (в некоторых случаях) в плане разработки и всего остального жизненного цикла - использовать скрипты. На сильно критичных штуках удорожание сертификационных моментов запросто может сильно перевесить все "плюшки" от скриптов, поэтому идею скриптования хоронят часто сразу, прямо на уровне идеи.
В общем и целом (в среднем по больнице) вы правы, но дело не в сборке мусора внутри виртуалки...
Почитал что за оно. Для другой ниши. В ту же трансмиссию её не засунут. или какой VCU
Ну да, не для трансмиссии (хотя боюсь гадать, что там будет через десяток лет). Но мелкоконтроллеры ведь не только в трансмиссии, да?
Не для этого встраивания. Для встраивания в программы в качестве скриптового языка для конфигов или "бизнес-логики".
И для такого встраивания тоже! Причем, примерно для таких же целей! Само собой, в микроконтроллеры, которые не такие уж "микро", но ресурсов всё равно слишком много там обычно не бывает.Если весь realtime и всё критичное делать нативно, а именно всякую конфигурацию, сервисные функции и прочее второстепенное (НЕ mission-critical) выносить в скрипты (разумеется, с соблюдением правила, что даже полный отказ всего скриптового не приводит к отказу основных функций системы), то вполне себе делают.
Удобно тем, что писать скрипты в этом случае могут совсем другие люди, с другой квалификацией (ведь нет риска что-то важное сломать), тестировать всё это проще (и существенно дешевле), ну и обновлять скрипты, не трогая основную программу - это приятно. Например, исправляются 100500 мелких придирок по сервисному веб-интерфейсу, бесконечная череда совещаний и обсуждений по поводу цветов, шрифтов и расположения меню, ...а основная программа не меняется - дешево, просто, без участия квалифицированных кадров, не надо каждый раз заново проводить полный цикл испытаний...
нет, имется в виду для встраивания в программы на с/c++
а вот про это все верно "Удобно тем, что писать скрипты в этом случае могут совсем другие люди, с другой квалификацией"
При создании QML использовалась встраиваемая js машина. По поводу JSengines, то их много реализаций, весьма шустрые как пример:
http://chaiscript.com/
http://falconpl.org/
https://github.com/cesanta/v7
> нет, имется в виду для встраивания в программы на с/c++Так нативный код для встраиваемых систем чаще всего и пишут на c/c++. Туда и встраивают виртуалки (js, lua, squirrel,...). В чем противоречие-то? Про прям аппаратное встраивание lua вроде никто здесь речи и не заводил...
И в "железках" тоже бывают конфиги разной степени "умности", "бизнес-логика" и много чего ещё, для чего технически удобно можно было бы использовать скрипты.Встраиваемое в эти железки ПО пишут на с/с++. При наличии достаточных аппаратных ресурсов (память, производительность,...) нет больших проблем встроить во встраиваемое ПО (то, которое на с/с++) движок js/lua/..., создать и запустить виртуалку, закачать в неё байт-код (можно через компиляцию "на месте", можно скомпилированный заранее) и поехали...
Чё-то не понимаю я этих комментариев вида "нет, не для такого встраивания". В чем разница-то?
> Чё-то не понимаю я этих комментариев вида "нет, не для такого встраивания".
> В чем разница-то?ну смотри
из вики
Встра́иваемая систе́ма (встро́енная систе́ма, англ. embedded system) — специализированная микропроцессорная система управления, контроля и мониторинга, концепция разработки которой заключается в том, что такая система будет работать, будучи встроенной непосредственно в устройство, которым она управляет.есть - РАЗРАБОТКА ПО ДЛЯ ВСТРАИВАЕМЫХ СИСТЕМ, т.е пишем прогу, это как правило на c/C++ потому что..
а пишем почему? потому что в железке мы всю логику распаять не можем, все варианты поведения не предвидем, поэтому пишем прогу, которая управляет поведением железки.есть так называемые embedded scripting language
на примере http://chaiscript.com/ там есть такая строчка - exposing a function to ChaiScript, calling it with a parameter and returning a value
т.е. мы втраиваем скриптовую машину в программу (как правило написанную на c/c++, о других вариантах я не слышал) и эта скриптовая машина по отношению к исполняемомой программе, является тем же что и микропроцессор встраиваемой системы по отношению к устройству которым эта втраиваемая система управляет.
Другими словами мы не можем описать в ПО все возможные хотелки заказчика, для этого дается возможность пользователю управлять внутреними ресурсами исполняемой программы на таких простых языках как lua или js. Т.е. заказчику не нужен спец на с++ который как тут любят говорить может выстрелить себе в ногу :) подойдет обычный рядовой контенщик понимающий бизнес-процесс и ознакомленный с API данной програмы.
> подойдет обычный рядовой контенщик понимающий бизнес-процесс
> и ознакомленный с API данной програмы.т.е. я не кого не хочу обидеть, но такое понимане расставляет все точки, и нам бес пены у рта становится очевидно в каких случаях мы используем логику на кристале, в каких случаях пишут на ассемлере, в каких на с/с++, в каких на скриптовых языках.
И на каждый уровень требуются разработчики с соответствующими знаниями.
Я прекрасно понимаю в чем разница между встраиваемым ПО (ПО для встраиваемых систем) и встраиваемым скриптовым движком! Я говорю о встраивании второго в первое!То есть мы пишем встраиваемое ПО (для встраиваемых систем), а в него встраиваем ещё и скриптовый движок для некритичного функционала.
С точки зрения движка lua/js/... ему пофиг куда он встраивается - нет разницы "обычная" это программа или embedded. Его работа от этого не меняется.
А уж что конкретно мы перевалим на скрипты и с чем снаружи позволим им взаимодействовать, целиком зависит от задачи, а не от типа ПО, в которое мы встроили движок.
И цель встраивания движка внутрь встроенного ПО может быть иногда вполне такой же как и при встраивании в обычную программу.
можно да, по сути запилил API для квадракоптера, и уже на луа или жс описать как он дожен именно летать и как реагировать на ситуации, да можно. просто нужно понимать что все критичное лучше на плсах а так скажем абстрактную логику преоставить заказчику на скриптах
для всяких IoT да, на с/c++, но все же добавлять в интернет вещь встраиваемую скриптовую машину не совсем гуд. Лучше будет если часть логики будет переписана на с/c++, т.к. поведение интернет вещи (ну или там микрокомпьютера) все таки ограничено конкретными задачами и реакциями на них. А вот на против десктоп, там функционал может меняться в зависимости от предпочтений пользователя. или вот например нодаjs, это ведь встроенный webserver + встроенный движок js. Т.е вы можете один раз создать реализацию простых операций, сделать видимыми функции, классы для встраиваемого движка и вуаля, вот вам нода js или любая другая модная штука ) пользователи пишут на js логику используя функционал написанный на c/c++.
В нашем случае используют lua для расширения пользовательского функционала по обработки чего либо. ну вот например мы же не знаем за ранее как пожелает обработать заказчик ту или иную ситуацию. Мы предоставляем некий API, а клиент уже сам на lua описывает поведение системы при поступлении той или иной информации.
Это очень удобно уверяю Вас. И это действительно очень мощная штука.
Ну если трактовать термин IoT максимально широко... Есть низкоуровневая логика реакции на какие-то сигналы, автоматическое регулирование чего-нибудь, части функционала, которые требуют какого-либо real-time - в эти области я и не думал предлагать никаких скриптов. А во всякой медленной, высокоуровневой, периодической фигне, диагностике, сервисных функциях, настройке, да в том же чтении всяких "хитрых" конфигов и т. п. - вполне себе гуд если ресурсы и "не технические" ограничения позволяют!Ну как простой пример - домашний роутер (на самом деле подойдёт почти любая железка, имеющая веб-интерфейс для настройки/диагностики/отладки, но не использующий его для основного функционала). Для реализации веб-интерфейса почему бы и не использовать скриптовый движок. Удобно писать (по сравнению с С), просто встраивать, удобно кастомизировать, наращивать и т. п. Даже если всё это глючное, тормозное и дырявое - на основной функционал не повлияет и никак его не сломает (ну если грамотно всё реализовать, естественно).
Да те же самые хитровыделанные конфиги, когда надо одну и ту же железку [пере]настраивать по-разному в зависимости от множества всяких условий (места установки, каких-нибудь статических сигналов, команд управления - там фантазии заказчиков могут быть самыми извращенными - не проводить же ручную настройку каждый раз при подключении на новое место, например). Конфиг вполне может быть lua-скриптом, который отработал при включении с логикой почти любой вычурности, всё настроил как надо и остановился (ну или продолжил чего-нибудь вяло мониторить - зависит от...). Всяко удобней чем извращённую логику тащить в С++ (да ещё и тестировать её потом в составе железа во всех возможных комбинациях...). Вплоть до того, что иногда можно позволить самому заказчику играться с этими конфигами, всякие заказчики бывают ))
В общем, я к тому, что та мощь, которую вы описываете, хотя и с определенными ограничениями, вполне применима и во встраиваемом ПО и иногда это вполне неплохое решение. Главное не применять бездумно для всего подряд (помнить, что "когда в руках молоток, любая проблема кажется гвоздём, но это только кажется").
Все верно говоришь.
На самом деле, это очень круто когда реаизация низкоуровневого функцианала реализована на плюсах, и ты контролируешь памть и все у тебя оптимизироано, и далее ты просто вызываешь функцию из скрипта по событию, и оно работает, а причем сами события твой скрипт получает от того же бэка сишного, ну это вообще сказка ). Но ты контролируешь что под капотом, ты там царь и бог ) и в этом сила скриптов только в связке с механикой )
нет, не для этого. Этот язык в том плане встраиваемый, что встраивается в код с/c++ и може предоставлять в выполняемый скрипт доступ к переменным, функциям, объектам, классам (т.е. динамически создавать объекты на базе классов).
Если это как в си, то это сахарок для просьбы по возможности не изменять автоматически. Для удобства кодера, не более.
это технология позволяющая решать целый класс задачь
Для JIT'a: Constant-folding. Ещё один побочный эффект: упрощение работы GC. Уменьшение криворукости (попробывал Lua Demo 5.4, присвоение к константе выдает ошибку уже при компиляции, а не в рантайме)IPONWEB вообще себе кастомную VM сделали пару лет назад и для них константные таблицы, которые не обходятся GC, увеличение скорости раза 2+ давали. Но константы+таблицы не относятся к ванильному Lua, это так, для примера.
способ защитить себя от ошибок
для расширения функционала программы на с/с++ на более абстрактном уровне. так же для создания "умных" конфигов.
Для написания безопасного кода без необходимости каждый раз копировать значения.
Что только народ не придумает, лишь бы не писать на sh'е
>Что только народ не придумает, лишь бы не писать на bat'е
>Что только народ не придумает, лишь бы не писать на html'е
толсто
А в генту до сих пор 5.1 в stable XD
5.1 ещё долго будет самой распространённой версией Lua, т.к. LuaJIT поддерживает только его (с парой-тройкой обратно совместимых фичей, бэкпортированных из 5.2)
DC-хабы использовали её.Тогда других версий и не было.
Генту уже давно протух. Весь свежак в арче в ауре.
Не совсем. Там есть 9999 БЕЗ немодерируемой ауропомойки с вирусами. Не далее чем вчера, я хотел скачать cppcheck, а есть версия только двухлетней давности. Но это не очень страшно — во первых, ничего критического в новых версиях не случилось, а во вторых, некоторый софт в принципе можно собирать только из дев ветки (где вся движуха). Скажем, на прошлой неделе я собрал smatch из гита, релизов там не было уже 10 лет и свежая версия не имеет релизов.
Весь опенсорц сам по себе помойка.
> Весь опенсорц сам по себе помойка.Но по сравнению с клозетсорц помойкой всё не так и плохо. Зато опенсорс ты можешь в любой момент взять и начать разгребать сам.
Идешь, такой, по улице, видишь кучу дерьма посреди дороги.. начинаешь разгребать сам.. конечно, это мог бы сделать кто-то другой - некто, имеющий бОльшее отношение к дороге в общем и ее чистоте в частности, нежели обычный прохожий в парадном тряпье и спешащих по делам, но не таков был наш анон.Ведь он отлично усвоил главное правило опенсорса - сам берешь и разгребаешь( в т.ч за всеми остальными ).
Парадоксально ли, но иногда по комментам на платформах, посвященных опенсорсу, складывается ровно такое ощущение их "идеального мира".
В клозет сорс ты даже на улицу не выйдешь.
> В клозет сорс ты даже на улицу не выйдешь.В колзет я просто пойду на улицу и даже не буду в курсе, что посреди нее может быть навалено, кто отвечает за поддержку улиц в чистоте и как можно наказать любителя погадить - все это будет скрыто от моего взора, я получу лишь итоговый результат.
>В колзет я просто пойду на улицу и даже не буду в курсе, что посреди нее может быть наваленоОга, в клозете ты даже не будешь в курсе, что наступил в неубранное говно и от тебя воняет.
Я как то не смог без поллитра разобраться с метатаблицами и какой то банальной операцией над ними...ну это я допустим неосилил, хотя зачем мне осиливать, когда куча других более вменяемых встраиваемых скриптовых языков есть? Я лучше раст поосиливаю, если делать нечего будет...Ну и обратная совместимость. Оператор goto, например, только в 5.3 появился. Не знаю даже баг это или фича. В общем, такое себе поделие...
чувак, я не осилил твой поток сознания, пойду в туалет поосиливаю
> Оператор goto, например, только в 5.3 появился.Лучше бы вообще не появлялся. Лучше бы его выдавали по N штук только по специальному запросу разработчикам в виде какой-то библиотеки, это касается любого языка.
По N штук на проект, в смысле
Долго ли ещё придётся использовать https://github.com/starwing/luautf8?
Нормальной многопоточности нет, а библиотеки не под все операционки портированы.
там вообще многопоточности нет (multithreading).в каждой нити (внутри C, куда ты встраиваешь Lua) -- предполагается создание независимого контекста Lua.
каждый контекст Lua работает и знает только про свою нить. ни о каких нитях внутри Lua даже подумать нельзя.
хотя конечно забавно что в самом LuaAPI есть внутреннее понятие Thread -- но оно о корутинах, а не о нитях.
Там есть корутины для асинхронности и кооперативной многопоточность но хз как это вообще нормально ли работает или нет
кстати а зачем тебе все операционки?ты сам-то какую операционную систему используешь?
вот попробуй для неё и сделай годную программу. это не так просто. а уж сделать годную программу под "все" операционки -- вообще почти не возможно.
Сейчас Debian, думаю поставить вместо него одну из BSD систем. Речь не про годные программы, а саму возможность. Хотелось использовать Lua для скриптования своих простых задач, но в BSD не портированы библиотеки многопоточности для Lua.
lua я люблю тебя! Хочу от тебя zlib (лицензию)
На безрыбье и Луа ЯП.
Вместо const лучше бы нативное копирование таблиц добавили, надоел этот велосипед а-ля deepcopy.
А эти где? Которые "Не на расте значит фу, ненадо"
Школу закончили пишут на плюсах.
Подскажите-ка в какой БЗД-е по умолчанию используют Луа? В НетБЗД-е?
> Подскажите-ка в какой БЗД-е по умолчанию используют Луа? В НетБЗД-е?В ядре? А зачем тебе по-умолчанию? Собери для линукса.
Да, в ней, для драйверов.
> Подскажите-ка в какой БЗД-е по умолчанию используют Луа? В НетБЗД-е?В загрузчике фри заменили Forth на сабж.
В общем-то есть Perl.. вот честно, не оценил фичей Lua. Причем это не критика, а любопытство)
> В общем-то есть Perl.. вот честно, не оценил фичей Lua. Причем это
> не критика, а любопытство)На перл ты не заскриптуешь игровой движок. Или весь движок не напишешь, как на луа. Или питоне.
> На перл ты не заскриптуешь игровой движокХм, такой задачи никогда и не было.. но почему нет? И попроще, если можно :)
Потому что делать это будешь не ты, замечательный профессиональный перл разработчик с 30 летним опытом, а обезьянка-формошлёп, нанятая по случаю. Скриптование самая скучная и унылая часть геймдева, которая тем не менее неплохо оплачивается (если это отдельная должность, часто совмещают). Чем проще и примитивней, тем лучше. И луа вполне укладывается в подобную парадигму, где код пишут не программисты.
Ок, с этой точки зрения понятно.
Есть же питон, который тоже встраивается, крайне популярен, имеет дцатиллион библиотек и понятен обезьянкам.
Python хуже встраивается чем Lua.и вообще Python НЕ похож на встраиваемый язык. имеет такую возможность -- да -- но семантика у него другая. на Python пишут программы. в подовляющем большенстве случаев, а не встраивают его. хоть и можно.
Python скорее похож на самостоятельный язык программирования. а не на язык отдельной (вот только что кем-то выдуманной) предметной области.
это как нанять на работу инженера из NASA для того чтобы он лампочки в офисе перегоревшие менял. ну можно, но идея крайне хреновая.
у тебя программа в 100 килобайт, а ты будешь туда 50 мегобайт питоновского интерпретатора запихивать (встраивать) включая его встроенные библиотеки (такие как работа с IMAP-почтовым-ящиком или HTTP-сервер).
при этом ещё и при работе с ним (из C-кода) тщательно учитывать всякую фигню типа "тут мы заимствуем ссылку.., а тут делаем копию.. а тут нужно не забыть увеличить счётчик ссылок, а тут уменьшить"
эта возня просто того не стоит!
Lua -- гибкий как пластилин... как свежее говно!!
он даст ровно то что тебе нужно (именно в качестве встраиваемого языка), не больше. и при этом не создаст ни капли лишней сложности!
Всё что надо заскриптуешь - и даже чего не могут ни луа ни питон.жЫрный Perl просто ... Так запросто не встроишь ...
Питон же встраивают. Даже джаву встраивали (в качестве скриптового языка). А уж жс и подавно. Вот php и perl я не встречал.
Ну например в Civilization 4 питон использовали. В нескольких гигах общего веса игры, питон был как капля в море🤣 подумаешь 100-200 мб +- 🤣
> Так запросто не встроишь ...
Размер имеет значение. У решений на Lua --- сильно компактнее.
Размер - это часто важно, но и помимо размера есть преимущества.Удобная, простая, статическая линковка без внешних зависимостей, без необходимости иметь набор доп библиотек, без необходимости иметь файловую систему с установленной системой модулей/пакетов и т. п.
Не то чтобы для встраивания языков типа perl/python это прям всё невозможно... но даже если и возможно, то НАМНОГО сложнее и более ресурсоёмко. Ну и не очень понятно зачем встраивать такие махины внутрь, может тогда проще наоборот - вынести часть в расширения на С/С++, а основным "запускателем" оставить сам perl/python...
Если именно lua как язык не очень нравится чисто синтаксически, то есть другие варианты с таким же простым встраиванием (js, squirrel,...). Некоторые из них даже по байт-коду совместимы с виртуальной машиной lua (ну по крайней мере раньше, вроде, такие попадались, если не путаю).
Луа намного быстрее и ffi в разы проще, когда надо что-то сишное дернуть.
Народ, объясните мне, если не сложно конечно, почему LUA в разработке игр, как скриптовый язык, прижилась больше, чем Питон например? Что в LUA такого, за что его любят разработчики игр?
потому что для встравания lua в основе достаточно одной dll-ки. И потому что lua самый шустрый из скриптовых.
+ хорошая и стабильная увязка с C в обе стороны.
А можно и вообще без dll-ки - статически влинковать прямо в исполняемый код. А такое гораздо проще, например, портировать на другие платформы (не везде есть dll-ки, so-шки да и вообще файлы в обычном понимании этого слова).
Я могу лишь предположить, что дело в том, что lua исходно создавалась как язык для встраивания в приложения. Python же создавался как самостоятельный интерпретатор. Благодаря этому lua проще воткнуть в свой бинарь и запускать скрипты прям из C'шного кода. Я не думаю, что с пайтоном там какие-то непреодолимые проблемы так сделать, но с lua, мне кажется, проще. И это одна из основных маркетинговых фишек lua, насколько я понимаю.
Встраивать Lua намного проще, т.к. он имеет минималистический api и не даёт шаловливым рукам отстрелить себе ногу (более-менее).Кроме того, если не массировать строки (а в играх их редко массируют), то Lua чаще всего заметно быстрее питона.
Но как язык Lua конечно же говно в сравнении с питоном.
Луа дает кучу возможностей отмотать себе веревки, чтобы повеситься.Как язык луа абсолютно прекрасен. Но не для средних умов, в отличие от питона.
Как язык, Lua, после тесного знакомства, лучше только чем Javascript. Python намного приятнее.Но вот api для встраивания в Lua максимально bulletproof.
Потому что в базовом виде впиндюриваеться за пару часов в си/си++ проекты.
Дебажить куда удобней чем здоровенный питон.
Потому что в геймдеве не используют тормозные языки программирования. Deal with it.
Вот блин почему не луа, а питон? Потому что бразильцы?
Гвидон математик он танцевать не умеет, бразильцы создали Луа под звуки Ламбады.
им дали angelscript - нет, не хотим, хотим жрать деерьмо.
и lua - самое гадкое из всех.
Чем он лучше ECMAScrilt? Если скриптовый язык и встраивать - то его, ибо в браузерах он работает с jitом и нативно.
> им дали angelscript - нет, не хотим, хотим жрать деерьмо.
> и lua - самое гадкое из всех.Вот только lua появился на 10 лет раньше и к тому времени уже плотно занял нишу и был обкатан в тысячах программ. Не все склонны всё бросать и бегом ломиться на новое, модное, блестящее...
Вопрос (был?) не в достоинствах/недостатках языков. Ровно тоже самое и про JavaScript vs Lua. Изначально были совершенно разные ниши и разная доступность. И там те же 10 лет (если не больше) преимущество lua в нише простого встраивания во всё что угодно. Плюс ещё стереотипы про js...
ты бы в вопросе сначала разобрался что-ли. в твоем ангельском скрипте даже колжур нет
интересно посравнивать скорость итп )
http://chaiscript.com/
http://falconpl.org/
https://github.com/cesanta/v7
Посравнивай, разрешаю.
иди попукай в другом месте
Есть шикарный юзкейс применения и сравнения скорости двух языков LUA и Python в одной программе "реального времени" - популярном, почти бесплатном музыкальном мультиплатформенном (MacOS/Win/Lin) редакторе/студии DAW (dig. audio workshop) Reaper, в которой встроена IDE для LUA/Python.API Рипера содержит >1k команд и методов, и т.к. это музыка, - любая задержка DSP-обработки >5 миллисекунд будет слышна как недопустимый щелчок. И очень здорово что оба ЯП абсолютно равнозначны по набору реализованных команд и одинаковы быстры в работе, но LUA грузит ЦП все же меньше на 40%. Потому и репы кода 5:1 в пользу LUA.
Можно сказать что LUA в Reaper стал тем, чем стал VBA в Excel, то есть "волшебным огнем", постепенно выводящим DAW за 60 USD на топовые места по популярности среди других DAW, стоящих от 300 до 3000 USD.
Луа - лучший язык и луаджит пророк его.
Уродливый синтаксис, а тормозной LuaJIT сливает даже интерпретатору JavaScript в Internet Explorer: https://habr.com/ru/post/113250/Зачем эта студенческая быдлоподелка нужна в эпоху Node.js, непонятно.
Будте ли когда-нибудь Promise и async/await?
Когда будут массивы и словари отдельно?
Очень расстраивает реализация tables{}.
> Когда будут массивы и словари отдельно?нет, все через таблицы
Там даже нормальное наследование из JavaScript не реализовано. Быдлоподелка, недоязык as is.
Ребята, есть смысл учить? Работу найти получится? Что вообще можно писать и где его в web применяют?
> есть смысл учить?Есть, хотя — что там учить-то…
> Работу найти получится?
Получится, если хотя бы сишку ещё осилишь.
Если задаешь такие вопросы - в профессии тебе делать нечего. В лучшем случае как-то протолкаешься 2-3 года и перейдешь в менеджеры.
А что не так в этих вопросах?Это совершенно нормальные вопросы которые ничего не говорят о дальнейшей судьбе человека как профессионала на выбранном поприще.
Или человек должен узнать ответы на эти вопросы...каким то чудодейственным способом? Или иметь врожденный инстинкт который позволил бы не задаваться этими вопросами?
Есть смысл cначала выучить Python, как универсальный и c вдесятеро большим числом вакансий и применений. LUA позже зайдет...Python в обычной жизни среднего предприятия заменяет полностью или на 80%:
Bash
CMD
Perl
PowerShell
VBA
StarBasic
1C
SQLПри этом шпаргалка по синтакису Python помещается на 2-х страницах А4, а у LUA - на 1-й :-)
я чтото пропустил этот эпический рывок вперед... а в какой версии платформы 1с был встроен питон нативно вместо родного dsl ?
а оракл в какой версии переполз с pl/sql на питон???
Ни в какой никто и никуда не переползал. Мы же за обобщения и синтез? Следите за руками:Все 100% IT-работ на "среднем предприятии (с)" состоят из 3-х сфер работ (в %% - трудозатраты):
- 50% сисадминства с дотой/CS/хабром/3дньюс/4пда вперемешку
- 30% эникейства/QA c телефоном или сменой картриджей у красивых девочонок в бухии
- 20% прикладной автоматизации (тех самых 1C/VBA/PL)Python как "клей" позволяет самым легким путём автоматизировать задачи из первых двух сфер 50+30=80%. Да и в оставшиеся 20% он отчасти вхож, поскольку в состоянии настолько повысить скорость разработки, что, скажем, приводит к следующим кейсам. Положим мне нужен сводный отчет из трех уже имеющихся в 1С (к это задаче сводится 80% всех хотелок бухов). И есть 2 пути решения:
Путь 1-й: Написать за неделю ТЗ для IT, ждать месяц, исправлять баги 2 недели. Итого 1,8 мес.
Путь 2-й: Написать самому за 1 неделю без ТЗ на Python, исправлять баги самому 1 неделю. Итого 0,5 мес.
И хотя я сам ратую за 1-й путь с ТЗ, но беда в том что за 2 месяца любая острая проблема на "среднем предприятии (с)" утрачивает остроту, потому что обязательно появляется совсем новая, острейшая, и все силы бросаются на неё.
Поэтому 2-й путь хоть и неправильный, но хоть что-то дающий в плане пользы.
На должность ЯП-"клея" претендовали многие языки: Bash, PowerShell, VBScript, Perl - но теперь ясно что они уступают Python. Поскольку из него незазорно дернуть любую консольную утилиту, легко перехватить вывод или файл, организовать перебор файлов в папках с рекурсией, дернуть SELECT из любой БД/AD... То есть дописать все остальное проще и быстрее на Python, чем на зоопарке ЯП.
>Все 100% IT-работ на "среднем предприятии (с)" состоят из 3-х сфер работ (в %% - трудозатраты):
>- 50% сисадминства с дотой/CS/хабром/3дньюс/4пда вперемешку
>- 30% эникейства/QA c телефоном или сменой картриджей у красивых девочонок в бухии
>- 20% прикладной автоматизации (тех самых 1C/VBA/PL)Понятно. вы описали маленькую конторку где всем этим занимается один человек по совместительству гендир. Да, в этом случае вы правы.
В моем представлении "среднее предприятие" в смысле ИТ - с 1С занимаются специально обученные люди которые зачастую кроме 1С незнают даже как сервер перезагрузить. В более мелкой - это приходящие нанятые на разовые работы. в чуть более крупной- собственные. Но в любом случае питон им вообще не уперся никак. Им это ненадо от слова совсем. За серверами следят специально нанятые люди. На оракле опять же разрабатывают люди которые не касаются вопросов 1С.
Питону там делать по большому счету нечего, кроме (в случае) личной блажи сисадмина или разработчиков "с запросами" (тоже блажь, поскольку они пишут на js/php).Картина которую описали вы- это взгляд человека на проблему никогда не работавшего на предприятии в котором есть хотя-бы один ОТДЕЛ занимающийся ИТ, а не просто "человек занимающийся ИТ".
И ваш выбор питона- это исключительно ваше предпочтение, поскольку все достоинства которые вы перечислили - ниразу не исключение в любом из названных вами языков которые вы питоном "похоронили" :)
А вот как вы будете на питоне писать формы для 1С - загадка великая есть.
Эх, ss, я описывал в (50+30+20) почти все предприятия страны, численностью от 100 до 1 млн. чел., коих у нас в РФ 800k, и где трудоустроено 64% работоспособных, т.е. 38 млн. чел. Это не про "маленькую конторку где всем этим занимается один человек по совместительству гендир". И я написал про "80%" в отношении совокупности 10-ти ЯП, не выделяя каждый. А вы меня заставляете оправдывать метрику 80% в отношении одной 1С. Тут я, чессно, пас. Но тем не менее, скажу:Сервера 1С теперь это не просто "железо", а машины с кастомным Postrgres и c кучей "временных, с бюллетеня подписки и диска ИТС" оптимизаций, без которых 1С часто еле ползает. Поэтому занимаются рестартом, апдейтом, бекапом серверов и правкой их конфигов - все-таки сами 1С-ники, а никакие не "сисдомины".
Писать "формы для 1С" с 1998 г., со времен появления платформы 1С8 и её механизма "Произвольных отчетов" - уже не нужно ни на одном языке. Просто вставьте готовый SQL-запрос и получите таблицу, которую из 1С можно сохранить в TXT(TSV)/XLS/XLSX. Потому что абс. большинство отчетов 1С открываются в Excel для последующей обработки/допилинга.
Причина не понятна обывателю. И она трагична: ни один отчет из 1С в её родном формате, скажем "MXL" - никого не интересует, и никто его в таком формате не примет, хотя 1С "есть у всех".
Экспорт в форматы Excel из 1С - ужасен, он сопровождается вставкой рендером десятка кастомных форматов и невидимых пробелов "для красоты", объединениями ячеек с нарушением всех спек OXML и XLS. 1С7-8 неспособна уже 28 лет "искаропки" сохранить любую таблицу с 5k+ строк в формат Excel.
Причем тут Python? Да в основном ни при чем, но уместен по мелочи: в случае с 1С - Питон легко схавает её TXT(TSV)/XLS/XLSX, уложит в Pandas df (IN-MEMORY DB, но на самом деле ещё круче, это TreeIndexed Data in RAM). Ну а главное - добавит "в три строки" к ним данные из лога 1С, который уже как 13 лет в формате SQLite (омагат, он и в Питоне есть искаропки!)
Лог 1С - это не шутка, он содержит едва ли не самое важное в бухучете - сведения "ктогдеклал". Размер этого лога для моей конторы с 15 млрд. руб. выручки - 4GB при размере всей базы 10GB (все цифры - за год). Так что Питону заняться есть чем. 1С он не заменит, но уменьшает кол-во этого яда до разумного.
Ну и чтоб разговор поддержать: с 2015 г. Oracle и Microsoft странными, непостижимыми отказами в продажах и обслуживании, в блокировках серверов обновлений итд (более известными как "поддержка санкций") - сократили число своих клиентов в РФ в ~2 раза.Половина клиентов (это не "средние, а чуть "крупнее" предприятия) - не умерли, не бросили 1С, а перевелеи её на свободный RDBMS PostgreSQL, а там PL/Python, в принципе, делает свои 80% задач.
>не бросили 1С, а перевелеи её на свободный RDBMS PostgreSQL, а там PL/Python,При смене СУБД для 1С формы 1С можно начинать писать на питоне???
Пойду подберу челюсть с пола... :)
При смене СУБД для 1С - "формы 1С" (под этим я понимаю её отчеты/обработки) - переписывать ничего не нужно вообще. Ведь 1С - это серьезное приложение с трехзвенной архитекторой, мировой лидер. В базах данных 1С - сами данные хранятся вполне абстрактно. А вот деньги от перехода от ППО экономятся вполне не абстрактные, а реальные:- До 2015 фирма N тратила на MSSQL 1.5 млн. руб.
- До 2015 фирма M тратила на Oracle 4.5 млн. руб.- C 2016 фирма N тратит на PostgreSQL 0 млн. руб.
- C 2016 фирма M тратит на PostgreSQL 0 млн. руб.Частично ответил уместность Python в 1C в посте #6.114
Более стрёмный синтаксис, разве что, у брэйнфака.