Там складывание строк в цикле, если он больше 10.
Во 1, как бы для такого есть repeat.
Во 2, складывание строк в цикле на язычке с вм, это - оторванные яйца.
Почему lua?
Хорошо набрасываешь, кстати. Как твой тред, так годный срач.
речь про момент до репита. и после скандала с отвалом поделки.
до деприкейтида успели вкрутить O(log n) по времени конструктор заполнителя
- который {если оценивать амортизационо} - почти всегда[т.е на малых] не быстрее чем лобовое str+=ch И так n раз (что для js совсем не stringBuffer :(
- однако при каком то достаточном(хз) N всё таки быстрей ибо заменяет квадратичное{при линейно добавление символа в результате (n*(n + -/+ 1))/n т.е O(n**2)} на лог-квадратичное O(log(n)**2)
Вот за что действительно можно ругать жс, так это за то, что нет stringBuffer'а/stringBuilder'а и больших чисел. А также за то, что есть всратые даты без форматирования.
Ну а как ты живешь на луа? Там тоже нихрена нет. Что из хост-приложения прокинул, то и будет.
Вот именно. Потому что lua не является языком общего назначения. Как и js: что из браузера прокинуто, то и будет. И там сейчас очень много всего уже. Больше никуда не надо это поделие тащить. Как и lua, но его и не тащат к счастью. Я выше писал, что в крайнем-прекрайнем случае можно и нодой воспользоваться. Но по-хорошему, это инструмент для сборки фронтенда, не более того. Короче, границы применимости стоит соблюдать. И еще чем хорош lua, там нет фронтенд-инженегров. Ни единого! А так язык конечно убогий, но для встройки норм.
не каждый стал Марадоной - но успех лат.Америки в ногомяче достаточное доказательство пользы широкого охвата.
js хорош как бейсик во временна оные -
js как серверсайд(на речекряке веб-макак) - а по старому как просто универсальный язык ( wsh не взлетевший ибо так случилось) поэтому node.js а ща quickjs c обычным ffi
Питон создавался как учебный язык и в таком качестве и пошел в народ. Как результат имеем залежи говнокода, написанного джунами без понимания архитектуры, уже местами превратившегося в окаменевшее легаси.
Да все они такие. Один сисадмином сделан на коленке для парсинга логов, другой как шаблонизатор для хомпаг, третий для снежинок. Ничего плохого в этом нет, кроме того, что вдруг начинают на этом писать всё на свете. Я вот работаю с перловым легаси. Вы не представляете сколько понаписали на нём в 90-е. Того, что по уму на жаве надо было писать. Вот и с js сейчас похожая история, и даже хуже. Хотя мало что ли технологий сейчас?
Ну и чем руби не устраивает в консоли? Есть mruby если оригинал сильно жирный. Про перл не спрашиваю, хотя чем он хуже js именно в консоли я не знаю. По-моему всем лучше.
«консоль» извлекает выгоду от того что язык развивается не_последними_(далеко)_людьми_в_теории_компиляции_и_прочего_RS по причине наличия большого рынка фронтенд0макак.
ps. я как раз стороник что-бы система была - бы по максимому в сырцах(т.е бинарь это тень мастер-сырца с прозрачной когерентностью(с правильным резолвом когда бинарь подлочен исполнением) ) и в процессе исполнения jitилось
Ну и чем руби не устраивает в консоли? Есть mruby если оригинал сильно жирный.
Да в общем-то, можно и mruby. Тем более, что код и так уже есть. Но будущее этого языка сильно туманно, а я стараюсь писать такой код, относительно которого не возникнет вопросов как и на чем его запускать.
Может это чисто психологическая заморочка. Но мне иногда приходится собирать код на Си, которому по 20 лет, если не больше, и с мелкими правками он прекрасно работает.
Поэтому:
C
sh
Теперь вот JS
Реально по эксплуатационным характеристикам не вижу между ruby и JS принципиальных различий.
В одном наломали дров с вызовом методов без () и 4-мя разными видами лямбд, в другом с ; и со странным приведением типов. В целом суть та же.
Про перл не спрашиваю, хотя чем он хуже js именно в консоли я не знаю. По-моему всем лучше.
Перлом не владею. Так, на уровне «читал какой-то файл, чтобы отыскать баг». Смысла писать на еще одном ЯП не вижу в виду того, что перл ушел куда-то в область поддержки легаси.
Реально по эксплуатационным характеристикам не вижу между ruby и JS принципиальных различий.
Между языками возможно (хотя я так не думаю). Но у руби есть батарейки в комплекте, а в quickjs я вижу некий огрызок от posix, и всё. То есть это прямой аналог lua с нескучным со скучным синтаксисом.
Аргумент уровня «на Си написано ядро винды! не пишите на Си!!»
А и правда, нужно ли писать на C что-то кроме ядра? Пишут только потому, что аналогов C по большому счёту нет, и раз уж почти всё ПО на C, то и приходится с ним бодаться. Эффект основателя типа. А скриптух как js целый выводок, и за исключением браузера он везде лезет на чужую поляну, где всё утоптано уже другими. Заменить он ничего не заменит, только добавит биоразнообразия нашему зоопарку (хотя там всё разнообразие только на уровне синтаксиса).
зы. почти уверен что есть какой npm модуль(и) с сервисом стрингбилдера (там же по сути вектор менеджить)
Обычно делают тупо join массива строк. Там нужна нативная реализация, чтобы избежать копирование строк вм и создания лишнего. Через вызовы нативного кода хз, насколько это будет адекватно по производительности. bignum тоже, конечно, где-то есть, но сделаны они были через строки/массивы.
типо ленивость/задержка реализации пока нет чтения свойства зависящего от значения (по хорошему get .length не обязательно создаёт полный объект, впрочем как и чтение - но это всё реализация-специфично)
ссыль? на внутреннюю (вероятнее всего сишную) реализацию .repeat(n) (имхо что-то подобное stl vector[])
Ладно, с lua 5.3 vs 5.4 более менее понятно. Вроде. Там в 5.3 совсем простая lua_Unsigned luaH_getn (Table *t) {} буквально пересчёт каждый раз, в 5.4 она намного хитрее написана.
Но вот сейчас погонял его тесты еще и в quickjs - так они даже медленнее чем в lua получаются.
node около 5с, lua54 около 14с, quickjs около 30с.
Или такие тесты вообще не показатель и никак смущать не должны?