Конференция Lua in Moscow 3 марта

Взять бы вас всех и заставить доделать

Больше языков хороших и разных! </sarcasm> Уже сейчас расплодилось столько ЯП, которые по сути мало чем друг от друга отличаются, что просто их названия сложно запомнить, не то, чтобы хоть поверхностно их изучать.

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

С языками программирования как с обычными языками - после пятого дальше легко. Из принципиально различных по синтаксису и семантике можно выделить несколько семейств: постфиксные (Forth, PostScript), где сначала кладутся аргументы на стек, затем передается команда (так работают и стековые виртуальные машины), префиксные - Lisp, scheme где и функции и данные представляются в виде списков, традиционные императивные, так же традиционно делящиеся на остро- и тупоконечников, то есть c-like и pascal-like, от которых ответвляется мейнстрим ООП (Java,C#), ну и немного в стороне функциональные ML-языки (Окамл, Хаскель). Из скриптовых достаточно знать пару из: Python, js, scheme, ну и lua, например. Все остальные ЯП, кроме самых эзотерических, похожи на один из вышеперечисленных.

Я в программировании почти двадцать лет и понимаю, о чём ты говоришь. Но считаю, что есть некие пределы в количестве языков. Сначала их становится достаточно много, чтобы из головы вылетали разные нюансы, потом их становится так много, что начинаешь путать, где какая конструкция или ключевое слово используется... дальше я не дошёл. Но суть в том, что как бы становишься умнее, но переключиться с одного языка на другой и писать на хорошем уровне уже не получается. И приходится в работе концентрироваться на одном или нескольких языках, а в десятках других - ориентироваться, но не знать.

Вообще, срач про глобальные переменные по умолчанию наверное такой же старый как Lua.

Про local-by-default http://lua-users.org/lists/lua-l/2005-08/msg00139.html ; аргументы сторонников http://lua-users.org/wiki/LocalByDefaultRant .

Мнение самого Иерусалимски почти пятнадцатилетней давности: http://lua-users.org/lists/lua-l/2006-10/msg00056.html

>>Would Roberto maybe admit that if he was redesigning Lua from scratch
>>today variables would be local by default and global by declaration? If
>>not, why not?
>
>No. It is simply wrong.

What is wrong? What John wrote? The old design choice?

«Local by default is wrong. Maybe global by default is also wrong (as David just wrote), but the solution is not local by default.»

Кто будет на конференции, можно поинтересоваться, что изменилось...

Ага, а ещё nil означает логическое false. Вы можете получить nil из середины разреженного массива, а можете при выходе за границы массива. Различить эти ситуации по возвращаемому значению невозможно. То же самое при возврате кода ошибки из функции - есть неоднозначность, nil это код ошибки или логическое значение «ложь». Семантика None в питоне определена гораздо лучше, а также исключение при выходе за границы массива или несоответствие поля слотам объекта (ну хоть это можно эмулировать в lua).

А зачем их знать? Что значит знать? Синтаксис Java простой, зато библиотек на нем понаписано - жизни не хватит чтобы всё изучить. Достаточно прочитать книжку и попробовать какие-нибудь стандарные задачи на нем поделать, чтобы понять, есть ли у ЯП какие-то киллер-фичи. Иногда можно просто интересные алгоритмы и подходы к решению задач подсмотреть, которые можно примерить в другом языке. Например, я двухтомник «Мир лиспа» прочитал - интересно про всякие лямбды, функторы, макросы узнать. Но как применить это в текущей работе было непонятно. Забыл до поры. Зато потом в Pythone все эти лябды, map, reduce без проблем зашли. Или узнал, что в Эрланге все переменные readonly, а если нужно поменять значение, то форкается этот процесс с новым значением. Вроде не очень эффективно. Зато задачи типа поиска выхода из лабиринта решаются очень красиво - проходятся все возможные пути одновременно, как Николас Кейдж в фильме пророк на заминированном корабле. Вот что ценного есть в изучении новых ЯП, а не скобочки с запятыми.

Ну для баш-файлов это нормально. Для сколько-нибудь универсального ЯП - нет. Опять-таки непонятно, что он имел в виду - объявление локальной переменной без слова local по факту присваивания? Да, ведет к таким же ошибкам, как глобальные переменные по умолчанию. Лучшее решение - явное объявление всех переменных без исключения.

Лучшее решение - явное объявление всех переменных без исключения.

Ага. Вот только прежде всего ЦА lua — инженеры-нефтянники (изначально) и прочие геймдизы. Непрограммисты. Не поймут-с.

Приведённый вами пример очень похож на перебор элементов массива не просто неидеоматическим для lua способом, но и достаточно чуждым природе той структуры данных, которая выглядит в lua как массив (ну вот не просто так в lua цикла for достаточно долго не было).

APL-семейство забыл.

Ещё Prolog есть. Синтаксис которого (но не семантику) заимствовал Erlang, ксатати.

Куда уж идеоматичнее?

a={1,2,nil,4}
print("pairs(a), #a=", #a)
for k,v in pairs(a) do
  print(k,v)
end

print("ipairs(a)")
for k,v in ipairs(a) do
  print(k,v)
end

вывод:
pairs(a), #a=	4
1	1
2	2
4	4
ipairs(a)
1	1
2	2

Какие нафиг нефтяники. Бурильшики что ли? Наверняка инженерный тех.персонал. И это было 20 лет назад. Р.Иерусалимский никогда не позиционировал lua как ЯП для нефтяников. Геймдевы и WOW-щики сейчас им пользуются и прочие около-ололо-айтишники.

Геймдизы. То есть, по сути, гуманитарии от IT (писатели-сценаристы). А дело именно геймдева луа к движку прикротить и базовую прослойку между обеспечить.

не позиционировал lua как ЯП для нефтяников

Ну бурильщики-нефтянники к слву вспомнились. В Бразилии (впрочем, не только в Бразилии) это такие заказчики с деньгами. Вот и lua в рамках их заказа делался.

Однако Иераусалимский всегда позиционировал язык как язык не для профессиональных программистов.

Да, действительно, ipairs — ломается. Можно конечно про суровых сибирских лесорубов вспомнить, но массив с «дыркой» посередине — не такая уж и рельса.

http://www.lua.org/history.html

В 1997 году Брет Могилевский, ведущий программист LucasArts решил заменить старый скриптовый язык SCUMM на Lua в игре Grim Fandango.

Due to its small size, good performance, portability and ease of integration, Lua has gained great popularity for extending games.

Там много интересного, описано почему получилось так, как получилось. Но непонятно что делать с этим дальше.

http://www.lua.org/history.html

Читал.

Там много интересного, описано почему получилось так, как получилось. Но непонятно что делать с этим дальше.

А в чём проблема-то? Совсем даже неплохой язык. Компромисс, да. Между производительностью, простотой и мощностью. Понятностью для непрограммистов и гибкостью в руках программиста. Но результат уж всяко не хуже жабоспрута и питона.

там ещё статья есть The evolution of Lua до 2006 года. Цикл for появился в версии 4.0, а booleans - 5.0. Понятно, почему такая путаница с nil/false - совместимость со старыми версиями. Хотя какой смысл её поддерживать, если C API несколько раз переделали. Даже vm со стековой на регистровую.

По js не знаю. А питон просто в другой весовой категории. Как ЯП гораздо лучше спроектирован. Сравните хотя бы nil, None, булеву логику и итераторы здесь и там. Последние годы Lua стагнирует. Стареет Роберто наш Иерусалимский. 58 лет ему, скоро на пенсию. Версии 6.0 можем не дождаться.

Ну во первых не вижу прямой связи между C-API и устройством ВМ, и особенностями языка для тех, кто на нём пишет (а не встраивает). А во вторых, даже если это самое nil как false — жуткий пережиток, от которого было бы лучше избавиться, в языках-конкурентах legacy-слой явно толще.

Куда уж идеоматичнее?

Луа в первую очередь стремится к технической простоте и элегантности. Иногда это идет ценой очевидности для программиста. Ну и батарейки в комплект не входят.

Возвращаясь к примеру: в Луа ведь нет массивов, есть только таблицы. То, что обычно в Луа называют «массивами» - это реализация массивов с помощью таблиц. Эта реализация простая, в подавляющем большинстве случаев ее достаточно, но в некоторых специфических случаях она ломается.

Когда программист четко понимает задачу, то может сказать, будут ли у него встречаться специфические случаи и насколько часто. Если их будет мало - можно ограничиться простой реализацией массивов с помощью таблиц и принять какие-нибудь меры предосторожности. Если это будет неудобно - придется написать свой модуль, который реализует корректную обработку массивов с дырками.

Мне кажется, это иллюстрация подхода Луа с его достоинствами и неудобствами. Примерно по такому же принципу сделана, например, поддержка регулярных выражений и еще какие-то куски стандартной библиотеки.

Если нужна скорость написания и можно использовать неспециализированные под задачу сторонние библиотеки - лучше брать Питон. Если четко понимаешь задачу, есть время подумать и в конечном результате не нужно ничего лишнего - Луа.

Ну как бы это сформулировать. Есть такая цитата, приписываемая Эйнштейну - «Все надо делать так просто, как только можно, но не более того». Вот с Lua постоянно ощущение, что какие-то вещи чрезмерно упрощены и постоянно нужно где-то что-то доделывать чтобы как-то эти проблемы обойти. Метатаблицы, декораторы, assertы. Этакий конструктор «сделай сам». Со временем это надоедает. В последнее время пробую moonscript. Этакий макроязык с синтаксисом, напоминающим питон и функциональные языки. С классами и try/catch обработкой исключений. Компилируется в pure Lua код. Ну как typescript/javascript. Ещё использую модуль annotate. Он позволяет добавлять в виде декоратора функции описание типов переменных. На luajit работает быстрее, чем написанный на си модуль checks.c, описанный здесь http://lua-users.org/wiki/LuaTypeChecking .

Но результат уж всяко не хуже жабоспрута и питона.

Результат может и не хуже, а процесс малоприятный. Постоянно натыкаешься на какие-то «особенности». Где там не-такие-как-все хипсторы, для вас идеальный просто язык, гораздо круче жабаскрипта.

По js не знаю.

Ну с JS всё общеизвестно. Good Part, Bad Part и «здесь водятся драконы». При том, что Good Part изначально на Lua достаточно похожа, а реализации бывают либо простыми, либо эффективными, вместе это никак не получается.

А питон просто в другой весовой категории.

К сожалению объёма и сложности поддержки исходников это тоже касается. Вот положить на одну чашу весов luajit, на другую — PyPy…

Как ЯП гораздо лучше спроектирован. Сравните хотя бы nil, None, булеву логику и итераторы здесь и там.

Как учебный, «как оно должно быть» ЯП — точно лучше. Как практический, «как это сделать с минимальным бойлерплейтом, и чтобы мог программировать любой маркшейдер» — ну это не в ту степь.

Вот я больше чем просто не уверен, что чёткое деление на Nil и None — это именно то, чего нам не хватает в скриптовом языке. А если в каком-то случае вылазит что-то, вроде вашего (это ведь вы писали) примера выше, дело того, кто пишет прослойку между ядром/движком, и условным геймдизом, так переопределить операции, чтобы это от пользователя lua припрятать.

Стареет Роберто наш Иерусалимский. 58 лет ему, скоро на пенсию. Версии 6.0 можем не дождаться.

Ну, Гвидо «Я тут болшьше не главный» уже заявил. Lua в подобном случае, подозреваю, сегментации не избежать никак (маленький язык форкнуть легче). Но, наверное, в конце-концов, основной форк как-то выделится.

В последнее время пробую moonscript
как typescript/javascript

Тоже вариант

Ещё использую модуль annotate

Спасибо за наводку

Вот я больше чем просто не уверен, что чёткое деление на Nil и None — это именно то, чего нам не хватает в скриптовом языке.

Две разновидности null это фейспалм и многое сообщает о дизайне этого «четко продуманного» языка. То же касается и жабаскрипта.

Постоянно натыкаешься на какие-то «особенности»

В lua они хоть простотой и эффективностью реализации (в основном) оправданы. В JS особенностей, как по мне, куда больше. Единственное, что там как бы «не особеннное» — с-подобный синтаксис. Который на самом деле, для непредвзятого человека — та ещё особенность.

Вы не поняли. Nil в Lua, None в Python. В Lua есть некоторая путаница c использованием nil как 1) отсутствующего значения, 2) кода ошибки 3) эквивалента false в логических выражениях. В Python такой путаницы нет.

Mea culpa. Это я питон плотно забыл. Но ок, вот я вcё ещё не уверен, что чёткое разделение этих трёх сущностей — это именно то, что нужно от скриптового языка.

Unreal Engine Blueprint так умеет. Ну и вообще все скрипты, если

разобраться в их апи.

Разобраться недостаточно. Нужно движок перепиливать.

кстати, а что не так с мухами?

Может на медовушек намекают?

Нумерация с 1 добавляет пачку багов на ровном месте. Просто потому что кодеры не привыкли к этому. На луа пишут не учоные-моченые, а в основном обычные сишники. Какой дебил придумал такую подлянку, я поражаюсь.

На Lua пишут скрипты непрограммисты. Расширяют нужные им программы до нужной функциональности.

Ладно, к нумерации можно приноровиться (хотя зачем), но про локалы не ври уж. Это грандиозный риф, на который напарываются даже самые опытные и внимательные. Можно конечно не заметить этот баг, и всё будет даже работать если повезет.

Скрипты для расширения программ обычно не в единственном экземляре.

Обрубать интуитивно понятную глобальность переменных для общего доступа из разных модулей расширения - кхмм... гнать ссаными тряпками таких менеджеров и программистов.

Далее, таблицы lua, которые неявно внутри могут быть как массивами, так и хеш-таблицами. В результате никогда нельзя быть уверенным, что именно вам передали в виде параметра. Плюс возможность создавать разреженные массивы с пропусками в нумерации с которыми встроенные итераторы работают не корректно.

Возможность - это плохо?

Если программист нормально обработает варианты использования, то пользователь сможет гораздо проще делать свои конфиги, где поля могут указываться именами, а если таблица огромная, то и без имен, по положению.

Какие нафиг нефтяники. Бурильшики что ли? Наверняка инженерный тех.персонал. И это было 20 лет назад. Р.Иерусалимский никогда не позиционировал lua как ЯП для нефтяников. Геймдевы и WOW-щики сейчас им пользуются и прочие около-ололо-айтишники.

А как вам такой вариант?

https://ru.wikipedia.org/wiki/LuaTeX

Не нефтянка, но расширение системы печати научных статей.

Сейчас, наксолько я знаю, он везде поумолчанию.

https://ru.wikipedia.org/wiki/LuaTeX
Сейчас, наксолько я знаю, он везде поумолчанию.

Насчёт «везде по умолчанию» это ты, видать, с LaTeX'ом перепутал.

Хотя нет, это я неправ. Действительно, LuaTeX входит в texlive, проверил у себя.

Замена доклада: вместо «Processing FEA data with Lua» Роберто прочитает ещё один доклад — про луашный GC.