Я никогда не видел столь убогого языка. По-моему, даже бейсик, на котором я писал в школе на БК-0011 был круче, чем факамаза lua.

Мне приспичило написать аддон для клиента wow 1.12. Древнего-древнего клиента. Причём как всегда, просто так взять и написать, чтобы минимумом усилий получить 90% функционала я не смог. Я взялся по полной программе. Парсеры combat-log'а, перелопаченный интерфейс, нечёткая логика и прочая, и прочая. Первое, обо что я споткнулся -- это собирание символов в строку. Задача была -- скомпилировать несколько десятков форматных строк типа как у printf'а в regexp'ы, для парсинга. Причём перед глазами моими было два примера кода, делающих именно это (я заглядывал в другие аддоны), но один пример был вырвиглазный пиздец, писанный индусским быдлокодером, который кроме пхп никогда в глаза ничего не видел, и вдруг с какого-то хуя взялся писать на lua, второй пример был гораздо лучше, но мне показалось, что если вместо использования regexp'ов для разбора форматных строк по-быстрому налабать посимвольный парсер, то будет гораздо короче, красивше и понятнее. Окей, сказано сделано. Реально компилятор получился буквально строк двадцать-тридцать. Но встала проблема: я обрабатываю форматную строку посимвольно, и посимвольно же собираю новую строку-регексп. Как эффективно это сделать? В C++ есть string_stream, в lisp'е есть with-output-to-string, в pure C я бы создал на стеке массив, которого бы хватило за глаза и за уши, собрал бы в нём строку, после чего выделил бы память из кучи и скопировал бы туда, либо, в качестве варианта, выделил бы из кучи сразу, а потом бы перевыделил, если бы понадобилось. И, в принципе, я ожидал от lua, что в нём будет не сложнее чем самый сложный способ с перевыделением памяти в pure C. "Авотхуй," сказал мне lua. Единственный простой способ выглядит так: str = str .. char, то есть конкатенация строки с символом. Этот способ подразумевает создание новой строки длиной на один символ больше чем исходная строка str, и копирование туда всего содержимого str. Есть способ чуть сложнее: можно создать массив (точнее ассоциативную табличку с ключами типа int) символов и закидывать туда символы, после чего сделать table.concat. Говорят это быстрее, но тоже ведь пиздец. Ещё кто-то упоминал извращённый способ, который как я чуть позже понял -- нормальное явление для lua. Способ заключается в том, чтобы сделать парсер рекурсивным, возвращающим переменное число аргументов, то есть "список" символов, и затем скормить этот список символов в функцию strconcat, которая уникальна для WoW. Способ ебануться и не встать, но он не прокатил, поскольку в версии вов 1.12 такой функции нету. Я был вынужден прибегнуть к первому, самому тормозному способу, думаю впоследствии, если припрёт, можно будет просто кешировать разные наборы регекспов и при загрузке аддона их подгружать из файла. Тем более, что я сомневаюсь уже, что до оптимизации в этом месте дело когда-нибудь дойдёт: на горизонте видны гораздо более неприятные проблемы с производительностью.

Второй косяк lua выглядит так: таблицы. Ёбаные таблицы. Пидерастические таблицы. Все туториалы и документация прямо-таки пестрят похвалами в адрес этих таблиц. Но встала проблема: мне надо проитерировать по sparse array (разреженному массиву, или как принято переводить?) причём от конца к началу, то есть начиная с бОльших значений ключей (которые все целые числа) к меньшим. И ведь ёптваюмать, плюс-минус эффективный способ это делать -- создать вспомогательную отсортированную табличку ключей. Со всеми, блядь, накладными расходами на вставку элементов в эту сучью табличку. Причём, ну естественно, ни сортированных деревьев, ни чего-нибудь ещё подобного в lua нет. Вот сижу и думаю, а может ну его на хуй, эти sparse arrays, может не париться из-за глупостей, и работать с нормальными массивами, даже несмотря на то, что лишь процентов десять элементов будет нести смысловую нагрузку? С другой стороны, по всем этим элементам придётся итерировать каждый раз. И количество элементов, будет порядка десятка тысяч. И проделывать это хотелось бы раз по 100 (плюс-минус порядок) в секунду. Другой вариант -- итерировать в прямом порядке, но с параллельным созданием новой таблички, которая заменит старую. Короче, учитывая тупую интерпретируемую и мусоросборочную природу lua, быть может проще убиться об стену.