Asm это ассамблер?)

блин. Ну не надо тут игры unless it's not written on Lua.

Го запилим альтернативный клиент ингресса на луа. И пофигу на тос)

Потому что ты больше пишешь на js чем на луа. И знаешь как решать проблемы методами js, а не луа. Или просто любитель использовать библиотеки: один вызов сторонне-библиотечной функции может быть внутри пятью гигабайтами малопонятной простыни, которую ты не писал, потому что её написали за тебя. Да, асм это ассамблер )))

а как же твой пример jquery/react? вот это я понимаю ущербность, хоть на 5ГБ, но 50-100кб непонятно чего, которое жрет неизвестно сколько

Хех, асм может всё что и нода (и даже больше), но в сто тысяч раз быстрее. Правда, писать в сто раз медленнее. Небольшие но постоянно использующиеся программы на асме очень сильно экономят время жизни.

Это если уметь писать на асме.

вне браузера не важно сколько, главное что время твоей жизни экономит

Не факт, что на асме получится быстрее, чем на Си с -O3

скрин кидал - я атомом не пользовался, а на скрине Снусмумрика вроде как атом?

Конечно )) А на ноде можно писать если уметь писать на js. А на луа можно писать если уметь писать на луа. Асм прост. Его можно освоить за вечер, и остаток жизни потратить на изобретение всего того чем мы пользуемся в ноде и луа. На асме будет работать быстрее, если мы умнее тех кто писал сишный компилятор.

> Асм прост. Его можно освоить за вечер, и остаток жизни потратить на изобретение всего того чем мы пользуемся в ноде и луа. Изобрести ноду и луа?

Зато в десятки и сотни тысяч раз быстрее ))) Правда, количество фич будет урезано, и мы будем компилить js в полноценный машинный код.

Го запилим альтернативный клиент ингресса на луа. И пофигу на тос)

Го запилим альтернативный клиент ингресса на тасме. Там макросы есть!

Performance Comparison C vs. Lua vs. LuaJIT vs. Java | Elmar Klausmeier's Weblog https://eklausmeier.wordpress.com/2016/04/05/performance-comparison-c-vs-lua-vs-luajit-vs-java/

К слову

Го запилим альтернативный клиент ингресса на тасме. Там макросы есть!

В crystal макросы круче

c vs asm дайте лучше

не могу найти

К слову

Устаревшая информация. jit 2.1.0 получил резкий буст. Правда, сейчас в бете.

Ну да, и я все равно не вижу десятков и сотен тысяч раз

Ну, я утрирую, конечно. Но не очень сильно. Плюс я про изобретение luaJit на асме! Шоб прям супер-пупер, ни одной лишней процессорной команды!

давайте лучше создавать для луа то, чего не хватает, скорости хватает, никто не жалуется

И все равно скорее всего получится менее оптимальный код, чем сгенерированный шлангом каким-нибудь)

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

зачем нужна ванильная?

Это ж какое самомнение надо иметь, чтоб считать себя умнее разработчиков компилятора, которые вложили в оптимизацию тысячи человекочасов))

Ну, у меня на работе, в базе данных, сидит ванильная. А разрабам базы данных лень портировать всё под жыт.

портировать?

Переписать куски ядра под жыт. Там много переписывать. Инфа сотка. И совместимость с частью старых скриптов поедет: например, lanes-многопоточка. Некоторые библиотеки работают только конкретной версией на жыте, а скриптов - не одна сотня мегабайт, и все нужны. Тут разработка сильно не один год длится.

Это ж какое самомнение надо иметь, чтоб считать себя умнее разработчиков компилятора, которые вложили в оптимизацию тысячи человекочасов))

Человекочасы - это миф. Производительность просто хорошего и отличного программистов различаются более чем в десять раз, а в сравнении отличного со средним - в тридцать-сорок. Но ты смотри: те кто писал компилятор такие умные и крутые потому, что они сделали компилятор универсальным. Для задач очень разного рода. Он не заточен под что-то одно конкретное, иначе был бы перекос в скорости где-то ещё. Если заточить приложулю на асме под одну конкретную задачу (например луажыт))) - это в любом случае будет быстрее чем труд неимоверно умных людей, которые в тысячу раз умнее меня. Просто потому что универсальность = снижение скорости.

И да, предложение "переписать всё на асм" было шутливым. Это я на всякий случай. Всё таки нет времени.

Мне вот никто не запрещает считать себя отличным программистом (я так, правда, не думаю), и вот один интересный факт: так себе чувак сделает быстрее, чем отличный ленивый программист

Пока ботаны пишут компиляторы, боги кода пишут сообщеньки в чатике

Ох, отличный программист не может быть ленивым. Это взаимоисключающие понятия. Коэффициент отличности = "навыки" * "активность"

> Мне вот никто не запрещает считать себя отличным программистом Я запрещаю )) Лучше считай меня отличным программистом, мне будет чуть-чуть приятно )) Боюсь таки что большая часть основных вещей (особенно традиционно-классических) сделаны отличными программистами.

Слушай, как часто ты строишь математические модели своего ПО? Ну, или хотя бы UML-диаграммы, и вообще, сначала рисуешь на бумажке, там же оптимизируешь и только потом - пишешь программку? Нет, это не критерий отличности и способ потешить чсв, мне просто интересно.

Пишу код, просто надо понятный код писать, и тогда все хорошо

Как критерий отличности - гитхаб с человеко-полезными хорошими вещами

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

два кофе

этому программисту

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

Их много, знаешь ли : 3 За всеми не уследишь. И каждый кусок не оттестируешь. Просто нарисовать и закодить быстрее, чем переключаясь между блоками вспоминать, написал ли ты эту штуку или это только предстоит.

модульность.

Да, модульность. Переключаясь между блоками = переключаясь между модулями. Только если ты не нарисовал и не задокументировал всё возможное - до тебя вдруг доходит: "Надо в вызываемом тут модуле дописать эту фигню, пойду допишу чтобы не забыть", "Фу, чёт медленно, надо переписать нафиг" и "Хм, я дописал вызываемую тут фигню, перед тем как переключитья сюда и всё переписывать?" Я пишу понятно если рисую. Потому что не переключаясь между контекстами, имею возможность делать сразу законченные вещи, которые гарантированно работают сразу и правильно. Юнит-тестирование тоже хорошо, потому что ты сразу знаешь весь спектр работ модуля: он не будет дописываться в процессе, ибо документирован, и его матмодель показывает что всё не так плохо как могло бы быть. Попробуй это дело, когда начнёшь возиться с чем-то действительно большим, а не "три строчки на ноде".

Это твой аналог switch-case?

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

for i = 1, #arg do for j = 1, #cas do вот же в коде

таки сори, есть pairs

Только после систематизации. Посмотри, систематизация - переделывает строковые ключи в целочисленные.

будет в следующей версии

Этот вариант свитч-кейса технически хуже чем a = a and b or c and d, потому что отсутствуют великолепные ленивые вычисления, и весь кейс вычисляется единомоментно. Но возможно проще для использования/восприятия непривыкшему человеку.

Имхо, кстати, забавнее такой вариант: handler = {} function handler['yo'](data, ip, port) ... end function handler['chiwawa'](data, ip, port) ... end function handler['ahahahahaha'](data, msg) ... end for i, v in ipairs(msgs) do local type = v.type handler[type](v.data, v.ip, v.port) end Чот такое. Типа, 100500 обработчиков под разнотипне сообщения, в зависимости от внешних обстоятельств. В данном случае - в зависимости от типа. Тот же свитч-кейс. Правда, нельзя пихать логические выражения. Этой же фигнёй сокращается десять тысяч if-then-else'оф. Вроде бы простая методика, но эффективная. И можно динамически добавлять новые if-else, заполняя ключи таблички.

О, кстати, ещё больше запитонил свою ООП-либу, и обрезал мелочи. Довольно долго ей пользовался, и прилично думал о краткости и комфорте пользования. Сейчас оно близко к совершенству. https://pastebin.com/9eDU94Ua Референс внутре.

локальный smt быстрее глобального, проверил, аж на 7 мс за 1000000000 итераций

Ох, какой ты милый :3 Тут для сокращения объёма текста, расслабься. Лучше восхитись краткостью и ясностью вкупе с мощью и комфортом.

я и восхищаюсь!

наследовать то тут как?

В примере написано. Наследуем класс Bar от Foo.

cl = {}, {} cl — таблица cl.__index = cl — индекс — рекурсия

Не рекурсия, подумай лучше.

ERROR: S client not available

smt(cl, mt)

вроде все четко

но как-то слишком компактно, больно подозрительно

Ехехехе, просто я читак. Тут нет рекурсии, зато за счёт cl.__index = cl, есть возможность прописывать function Foo.__add(a, b) ... end То есть, добавлять метаметоды сразу в класс.

эх, я к руби привык просто

методы класса, методы инстанса, приватные методы

Приватные не нужны. Захотят - вскроют. Лучше - локальные функции в модуле, так же как тут - функция C.

для чисто просто методов эта реализация клевая, мунскриптная все же мощнее

А что там? Миксины?

там отдельно таблица для класса, отдельно для объектов

Хм. В чём прикол? В чём объективная необходимость?

ну тк, методы класса, методы инстанса

Методы инстанса - в чём разница? Длинная процедура инициализации объекта? Тут есть Class:init() - возвращает инстанс.

Post.all() - все посты Post.take.all - поле "all" у поста, вдруг такое есть

А, типа лишние цепочечные методы через извращенскую перегрузку __index.

клевая перегрузка

я очень долго делал, не надо, там правда так: Post\take!.column выходит

Неочевидно. Хотя кому как, тем кто сидит на мунскрипте мб норм.

На тему "если есть такое поле" - rawget(table, field). rawget/rawset - две функции взаимодействия с таблицами, не дёргая метаметоды. То есть, добровольно-принудительно.

это значение rawget, а ещё есть методы инстанса, которые через мета

да ладно, годная реализация, но не на все хватит

Ой всё, сложно ))) В реальной жизни такое редко необходимо. Хотелки - хотелками, и сахар сахаром, но слишком много сахара - схлопочешь диабет.

Моя задача дать свободу. Вдруг пользователь захочет перегрузить один из стандартных методов класса. Эту фигню можно перегружать, а запрещённых полей немного: Super, init и Type, Редко вызываемые поля - с большой буквы. Ну, прост сахар в краткости и в отсутствии необходимости помнить что и как, лепить по наитию и чтобы сразу получалось ))) Поэтому же, например, порядок указания имени класса и родителя не важен. А можно и без них. А можно и без метода init, просто вызывать класс как функцию и получать пустой объект. Ваще пофиг. И можно return'ить значения из инициализационной функции, и они пойдут следующими после объекта при вызове класса. Это не очень очевидно, но удобно, и по наитию такое можно случайно сделать и приятно удивиться что прокатило. Вот такой сахар я люблю.

а может ты блог какой ведешь? любишь все время какие-то куски кода генерировать, вдруг когда-нибудь что-то полезное выдашь

Хех, у меня есть pastebin. Думал писать на хабр, но пока лень.

луа комьюнити не хватает

думаю об этом, т.к люблю сайтики писать, вот и думаю и думаю

>вдруг когда-нибудь что-то полезное выдашь Мне нравится твой оптимизм! Прости, не удержался :3

думаю об этом, т.к люблю сайтики писать, вот и думаю и думаю

Вот, смотри какая смешная полезняшка: https://pastebin.com/6K7VWaxZ Массивная либа. И тут же есть реализация смешных стрелочных функций с кешированием (чтобы не пересоздавать каждый раз). Тут, правда, где-то мелкая ошибка в бинарном поиске, надо исправить.

Вот, например, у класса-модели есть метод auth - User.auth(...) который параметры задает, или контроллер PageController.before_action = function, а у инстансов совсем другое