Вышел Bun 1.1

В перовом приближении, чем больше выборка, тем ближе среднее значение к матожиданию. Я тут полагаю, что способности жабоскриптеров распределены нормально.

В механизмах социологии эти модели не применимы. Иначе бы работала прекрасна та же теория игры при прогнозировании рынка. 5% от N остаются 5%. И при выборке в 100 человек или в 1000 человек - не играет погоды. Распределение остается +/- одинаковое. И количество выборки не гарантирует, что именно состав тех самых 5% будет выбран.

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

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

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

Внезапно, тогда ей впечатлились многие. А, уж, если копаться в истории - Айк принес интерпретатор схемы, который ему предложили сделать по синтаксису похожим на Java. Он и сделал. Но это не отменяет корней схемы.

/me заинтересованно внимает.

Какой стандарт будем рассматривать? И да - вы не ответили. Если он так прекрасен - почему так не распространен?

С точки зрения ABI — да.

Внезапно, JS с точки зрения этой тоже стабилен.

С точки зрения стандарта языка — нет.

Так тогда как же вышеобозначенный аргумент о предсказуемости? Сегодня есть нечто в стандарта - через Н времени - нет.

Еще бредет куда-то, не факт что в нужную сторону.

У самурая нет цели, есть только путь (с). С++ - это помойка из идей и подходов. Кстати, с далеко не с малым количеством говнокодом обмазанным так же кучей бибилиотек.

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

А код учитывает необходимость использования либ? Скажем - есть либа для стандарта Х, а я пытаюсь собрать компилятором свой код древнего стандарта. И с ним же собираю. Что будет?

Сам по себе молоток не виноват, что 80% людей забивая гвозди попадают по пальцам, и только 10 процентов становятся хорошими плотниками.

Да нет. Вы выше именно это и доказываете. В криворукости кретинов - виновата форма молотка.

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

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

Если есть стек, который в наименьшей степени прощает ошибки пользователям, то им и надо пользоваться.

Что понимать под «прощает»? Говнокод, что на Си, что на JS приведет к утечкам. Просто сейчас из-за количества памяти - стало меньшей проблемой. Не соберется код? В том же Си сборкой занимается компилятор. В JS сборщик так же можно настроить на максимальное выкручивание яиц. Было бы желание.

Без шуток. Простой пример. В одной компании сервис, который занимался скидками/акциями был на Mongo+JS. Дичь не пропускалась.

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

А чем типизация спасает, когда ошибка в алгоритмах? Да, есть ряд тупых ошибок где пытаются к ежу прибавить батарейку и сравнить с числом. Но - это решается банальным метаописанием в коде. JS если очень надо это умеет через ряд инструментов.

Но самые сложыноотловимые и дорогие ошибки как правило не в эту сторону. Они в логических нестыковках.

К сожалению, мы тут находимся в ситуации, когда неплохо бы решать административные проблемы (в частности, проблему квалификации персонала) техническими мерами.

Так стек JS это вполне позволяет. Начиная от банальных JSDoc анотаций или flow и заканчивая транспилерами вроде TypeScript или PureScript (если уж хочется еще и вагон фич и изкаробки).

Все эти ваши вышепреведенные и весьма толковые практики разработки решают техническую проблему надежности кода административными мерами. Это всегда хуже.

Зато это гарантирует хоть что-то. Факт сборки тем же Rust бинарника ничего не говорит. Я могу в unsafe напихать дичи и радоваться тому, что нагнул систему.

Да, пример из Си - указатели смоченные goto. С их помощью можно такие вещи вытворять… сильно вам типизация поможет?

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

Вот пример про Си выше. Компилятор пропустит. А челюсть ревьювера предполагаю будет вывихнута и он не сможет её поднять с пола.

Конечно есть - как только человек перестает критиковать автобус, что оне не бутерброд хотя бы.

И количество выборки не гарантирует

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

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

Для начала - хотя бы детерменируйте какую модель имеете ввиду

Я — никакую, пользуюсь чистым мат. статом. Единственное моё допущение, что талантливость распределяется согласно нормальному распределению.

Какой стандарт будем рассматривать?

Начнём с ANSI Common Lisp

И да - вы не ответили

Повторяю: Какой-то безымянный менеджер впечатлился жабой и обрёк всю индустрию погибели.

А что-нибудь менее субъективное?

Внезапно, JS с точки зрения этой тоже стабилен.

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

Просто вспомнилась история из жизни. Ни на что особо не претендующая.

Вообще-то, гарантирует. Чем больше выборка, тем точнее наша оценка генеральной совокупности. Это можно доказать и давно доказано формально.

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

А в социологии изучают сколько конкретно нужно опросить людей, для достижения уверенного результата.

Что в вашем понимании уверенный результат? И давайте примем еще одно допущение модели - бизнес может и хорошему инженеру сказать сделать «быстро», а не «хорошо». В приведенном примере с SDK - его вес ваша проблема, а не Амазона. Есть открытое API - не нравится - сами реализуйте. Дешевле проблему не решать.

Двухсот тысяч инженеров амазона более чем достаточно.

Для чего?

Начнём с ANSI Common Lisp

Какой именно? ЕМНИП не одна версия.

Но да ладно, не буду дальше под*бывать. Простые примеры - не гигеенические макросы, большое количество синтаксиса, раздутая стандартная библиотека (и сам по себе огромный стандарт), много повторяющихся функции делающих почти одно и то же, временами странный нейминг, не доделанная пакетная система, MOP не успел попасть в стандарт (ЕМНИП). Это если не брать критику «схемеров».

Повторяю: Какой-то безымянный менеджер впечатлился жабой и обрёк всю индустрию погибели.

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

А что-нибудь менее субъективное?

Так аргументы приводимые - пока носят такой же субъетивный характер

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

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

Рили, вот это примеры почему стек плохой? Вот у меня такой же есть пример с генератором XML (кучка документов для обмена между разными системами), который внутри одной большой системы наваяло одно чудо. На вашем любимом (о-боже-ты-мой-не-может-быть) CommonLisp кстати. С учетом обмазывания этого чуда макросами - было еще веселее это все переписывать. Правда мы это сделали. А если у вас не смогли разобраться в конторе как это работает… это многое говорит о квалификации коллег.

Просто вспомнилась история из жизни. Ни на что особо не претендующая.

Да-да. И внезапно на любых других стеках таких историй нет. Вообще никогда не было). Я тоже такое сочинять умею.

При получении выборки по людям - есть большое влияние разных факторов,

Излагайте, обсудим.

Что в вашем понимании уверенный результат?

Результат, который значимо не отличается от реальности.

И давайте примем еще одно допущение модели - бизнес может и хорошему инженеру сказать сделать

А теперь придётся доказать, что в амазоне такое практикуют сильно чаще, нежели в целом по индустрии.

Для чего?

Для составления репрезентативных опросов, а следовательно для репрезентативной оценки состояния дел в индустрии.

Какой именно?

А разница? Вы же ни в каком не разбираетесь.

гигеенические макросы

Оказались академической игрушкой и в целом не дают серьёзных преимуществ, вместе с тем накладывают серьёзные ограничения на исполняющую среду.

большое количество синтаксиса

В лиспе вообще нет синтаксиса. Совсем.

раздутая стандартная библиотека

А была бы она маленькая, вы бы ругались на «маленькая стандартная библиотека».

и сам по себе огромный стандарт

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

много повторяющихся функции делающих почти одно и то же, временами странный нейминг

За всё надо платить. Слово Common в названии не просто так появилось.

Кстати - по закону больших чисел

IT — очень неповоротливая, традиционная индустрия, в которой решения принимаются иррационально или под воздействием моды. Обидно, а что делать?

Молоток плохой инструмент.

А давайте зайдём издалека. Бывают ли, по-вашему, вообще плохие инструменты? Ведь про каждый можно сказать: он хороший, это у вас руки кривые. Или нельзя? А если плохие инструменты бывают, то как мы можем узнать, что это именно инструмент плохой, а не руки кривые?

Рили, вот это примеры почему стек плохой?

Ну, извините, были бы хорошие примеры, я бы их честно-честно привёл. Но почему-то не нашлось.

это многое говорит о квалификации коллег.

К слову, если коллеги глупенькие и они выбрали жабоскрипт, то не следует ли из этого вывод, что жабоскрипт — выбор умственно отсталых?

И внезапно на любых других стеках таких историй нет.

А что вас в этом смущает? У инструмента есть свои особенности. Они обуславливают культуру использования и стандарты. Всё вместе приводит к специфичным проблемам, вотъ в жабоскрипта такие. У C++ например, вместо неподъёмной горы зависимостей было бы 25 реализаций строк в одном проекте. Тоже плохо. Но по-другому.

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

…и стонущие от боли тяготящего бытия веб макаки неровными рядами поплетутся изучать новый фреймворк

Собаки лают, караван идёт.

амазоновские инженеры должны быть лучше средних по рынку. Сильно лучше.

Взоржал :-) Вы с ними работали? Нет, безусловно, там есть инженеры лучше средних по рынку, но подавляющее большинство весьма среднее. Элитарность MAANA сильно преувеличена.

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

В криокамере что ли опять протечки? Весь ui в проде уж давным-давно на js. Альтернатив нет и не предвидится. Все что не js - это косоугольное всратое легаси, которое все стремятся уничтожить (ну да оно устаканилось - факт))

Зато она хорошо вас характеризует как человека и специалиста, а также демонстрирует ваш опыт в области разработки.

Заходишь тут блин и девопсами споришь о разработке…

А они тебе: «Вот, в нашей криокамере так не принято…» Шляпа.

не было бы существования JS и Perl, не былo бы тогда и вeличественного CGI 🤠

Весь ui в проде уж давным-давно на ts

Поправил.

Это называется живой язык программирования. Это вам не трупы вроде qt ковырять.

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

Это российский проект?

https://github.com/oven-sh

United States of America

Я за bun

Поправил

Не фронтендщик, но судя по телодвижениям у фронтов, хайп по OOP в js прошёл и начался откат в сторону функциональщины. Хотя могу ошибаться.

Я за bun

А я за попкорном!!!

Мало того что под js библиотек-однострочников на весь словарь английского языка, так теперь ещё будет 100500 форков ноды. И если сейчас, для сборки «проектов» на js приходится таскать его с node_modules - то что дальше? Обмен имиджами дисков вместе со средой выполнения и всеми третичными зависимостями?

Вы с ними работали?

Моя контора нанимала консультантов оттуда. И это были весьма толковые ребята.

подавляющее большинство весьма среднее.

Меня устраивает этот вывод. Собственно я с него и начал. В крупной конторе большое количество средних инженеров, поэтому по ним можно судить о состоянии отрасли в целом.

Однако можно и продолжить. Если б я был султан, я б нанимал большое количество инженеров несколько хуже (и дешевле) среднего и малое количество очень хороших инженеров, чтобы работала их погонщиками, надзирателями и наставниками. Средненький инженер, под присмотром и с помощью талантливого, обложенный со всех сторон корпоративными правилами хорошего кода и всяческими помогайками, наконец видя вокруг как делать правильно и сам будет кодить лучше, и другим говнокодить не даст. А в маленькой конторе он же будет лишён этой поддержки, никто ему не скажет: «чувак, так не делай, снег башка упадёт, прод мёртвый будет». Соответственно и возможностей для роста у него будет меньше, и результат хуже.

Весь ui в проде уж давным-давно на js.

Поэтому любой блокнот хочет сожрать гигабайт памяти и всё равно тормозит и лагает. Спасибо js большое за это от производителей памяти и их акционеров.

Спасибо js большое

Тут лично JS абсолютно не причем. Любой высокоуровненвый язык с динамической типизацией, лаконичным синтаксисом и менджером пакетов сформирует точно такую-же экосистему потребления ресурсов. Например Ruby.

Менеджерами пакетов и высокоуровневыми языками все равно будут пользоваться, так как софт пишется в условиях давления по срокам. И будут тянуть чужие пакеты на сотни мегабайт, главное что программа запустилась и ее можно было продемонстрировать.

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

Как это утверждение может быть доказано?

Как это утверждение может быть доказано?

Доказана может быть теорема на основании нескольких аксиом. Тут же социология и есть пример языка Ruby. Те же самые проблемы что и в JS, они социальные и психологические, а не технические.

Можно писать читабильный чистый код? Технически да.

Но на практике получается RubyOnRails.

Тогда, если я правильно понял, ваше утверждение следует переписать с

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

на

Любой популярный язык с низким порогом вхождения …

Ну, может и так. Может и так. Однако вопрос в том, помогает ли технология бороться со сложностью или же усугубляет проблему. Можно привести обратный пример. Тот же php выступает в том же классе, однако left-pad’ов там нету.

Ой-ой-ой. Ужас какой. Пойду на делфи писать. Спасу этот чертов мир.

Тут клуб метафористов что ли? Член изменяется во время работы, и ничего, все довольны.

И в node.js и в java эти проблемы решены, правда в Java насколько я понял, никто не хочет изменять пакеты под новую систему модулей, что бы это было возможно. В node.js у каждой зависимости есть папка, куда складываются зависимости зависимостей, поэтому можно иметь 100 копий одной библиотеки разных версий.

Излагайте, обсудим.

Что? Это же вы пытаетесь натянуть сову на гло… в смысле применить математику к социальной сферой. Сначала докажите работоспособность модели. А не «ну все знают». Все - понятие не детерменированное.

Результат, который значимо не отличается от реальности.

Мой тезис не отличается от реальности. Ваша СДК доказывает это. Но тут вопрос - вы объективную или субъективную реальность имеете ввиду? В вашей - да, какой-нибудь Амозон или Майки берут на работу только лучших. И выпускают продукты хорошие только. А если не получилось хорошего - виноват стек.

А теперь придётся доказать, что в амазоне такое практикуют сильно чаще, нежели в целом по индустрии.

А давайте от обратного. Докажите, что нет имея на руках вот эту вашу СДК.

Для составления репрезентативных опросов, а следовательно для репрезентативной оценки состояния дел в индустрии.

С разморозкой! В современной психологии опросы считаются не рабочим инструментом.

А разница? Вы же ни в каком не разбираетесь.

Ваше субъетивное мнение очень важно для меня.

Оказались академической игрушкой и в целом не дают серьёзных преимуществ, вместе с тем накладывают серьёзные ограничения на исполняющую среду.

Докажите или как всегда «потому, что я так сказал»?

В лиспе вообще нет синтаксиса. Совсем.

Спорное утверждение. Не важно что это - оператор, макрос или функция. Для программиста, который учит и использует язык - это будет синтаксис.

А была бы она маленькая, вы бы ругались на «маленькая стандартная библиотека».

Крыть нечем в очередной раз. Поэтому пытаетесь перевести вопрос в плоскость оппонента.

Обоснуйте огромность.

Стандарт языка, который можно разбить на несколько увесистых томов - явно не является компактным. Сравните со стандартом схемы.

Со стороны жавоскриптера это особенно смешно слышать, бо вашим поделием вообще невозможно пользоваться, если не обложиться вспомогательными инструментами со всех сторон.

А для CL вы, простите, в Nano писать будете? Можно, конечно, но - зачем? Любая разработка продукта связана с использованием вспомогательных инструментов. Если они не встроены в ВМ, то это не делает их плохими.

И количество знаний, требуемое, чтобы управиться со всеми этими линтерами-чеккерами-кодесмелами-пакетными менеджерами и пр. бурдой, кабы не больше, чем знание ЯП + стандартная библиотека.

А тут интересно. Давайте по вопросам для начала:

• Как вы можете судить разработке на «жабаскрипте», если постоянно обходите его стороной? «Коллеги сказали» - не аргумент, уже выяснили их уровень.
• Вы не используете для CL пакетный менеджер? А как управляете зависимостями?
• А вы код-стайл проверяете вручную? И в каждой команде «переучиваетесь»?
• А вы код проверять на корректность вручную хотите? На большом проекте будет далеко не 10 файлов.
• А раз «лисп» такой классный, то напишите без JS банальный TODO. Только не компилируя в него, а именно на CL (ABCL не брать, это же не «православно» по вашей логике). И давайте, чтобы поинтереснее будет - пусть это приложение запускается еще и на яблофонах и ведроидах. Ну и, если только стандартная библиотека - давайте еще договоримся не трогать «Александрию» и МОР.
• А вы читали стандарт актуальный EcmaScript, чтобы говорить о его «огромности»? Сразу ваш вопрос присеку - я стандарты CL изучал, когда писал на нем систему генерации REST API по YAML для одной конторы.

За всё надо платить. Слово Common в названии не просто так появилось.

Как-то «схема» без этого смогла обойтись.

IT — очень неповоротливая, традиционная индустрия, в которой решения принимаются иррационально или под воздействием моды. Обидно, а что делать?

Тут согласен. А еще в ИТ обычно становятся не самые лучшие с академической точки зрения решения. Правда это всё не относится к реальному рынку. Задача программистов - проблемы решать, а не академически-верные решения производить. По крайней мере с этим согласен тот же Брукс.

Я знаю это. Но это же бардак! В результате ты тащишь овердохера лишнего кода.

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

Погодите, не пугайте отмо…размороженного. Стресс-то какой будет. Человек пока еще не принял, что все ушло в «эти ваши мерзкие веб-приложения». Пока не началась даже стадия торга.

А вы уверены, что это проблема JS? Вот именно платформы/языка, а не рук и голов. На Qt том же, что - текущего софта мало?)

А есть решение лучше?

В Ruby процент случайных людей (новичков-вайтишников) на порядок меньше чем в JS. Обычно это уже не первый и не второй язык программирования для рубистов. Так же в Руби большой процент «архитекторов» - программистов популяризировавших целые направления в разработке именно черерз Ruby.

Но получился тот же JS по объему потребляемых ресурсов и многомегабайтной кодовой базе средненького проекта.

Следовательно дело не в пороге вхожднеия и не в качестве программистов, а в ТИПЕ языка программирования. И проблемы JS это не проблемы JS, а проблемы высокоуровнего языка с динамической типизацеий.

Погодите. Они еще не пришли к этому. В их стеках нет этих инструментов и есть «пердолигн» вручную, который они считают признаком квалификации. А возможностью писать читабельный и чистый кода - не может обладать стек, где не надо страдать с этим или типами.

Пока еще не пришло осознание, что можно иначе.

А какую проблему вы решаете? Если в итоговую сборку попадает только то, что надо - все хорошо. Если для этого есть инструменты - просто их надо применить.

Я вас разочарую. Вы не знаете 99% кода ОС, которую вы используете.

Надеюсь, все-таки, чуть больше, но не сильно. Но я запускаю этот код добровольно и от себя.

Не все, что было и есть в HTML можно «оживить» без JS. Банальную систему оповещений как собираетесь делать?

Вообще не собираюсь. Не нужно это. Терпеть ненавижу всплывающие окна, которые мне мешают читать текст. Конечно потуги людей, которые придумали сначала Gemini Space, а теперь прикручивают в нем какой-то интерактив хотя бы в виде комментариев на LORe, или ЖЖ, наблюдать грустно. Однако, что ЛОР, что ЖЖ вполне живет и без JavaScript. Вот Фейсбук с его технологией вряд ли выживет, ну да и хрен бы с ним.

В мире джаваскрипта — нет. Опять же, лучшее решение для какой задачи? Я бы придерживался принципа для любой задачи не использовать джаваскрипт, а дальше искать решение.

А причем тут джаваскрипт, эта проблема не относится даже к языкам программирования. Например работающая программа может требовать запущенного сервиса определенной версии, и другой запущенный сервис который требует еще один запущенный сервис другой версии.

JavaScript на клиенте как акваланг. Иногда без акваланга не обойтись. Но чаще всего он не нужен.

Ничего в Java не решено. Модули это вообще не про это.

Я решаю проблему исключения джаваскрипта из моей жизни. Пока не особо получается. Пока были экстеншены в броузерах типа NoScript, я ими пользовался. Потом пропали, к сожалению. Говна типа nodeJs, MicrosoftCode и прочего у меня нет.

Модуль может скрыть от других свои зависимости, разве не так? А то что не решено я знаю, так и написал в своем комментарии.