Вышел Bun 1.1

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

фронтэндеры вешались постоянно

Видать и вправду нет худа без добра.

«Сделай мир лучше — убей веб-дизайнера!» :) Если б это уменьшало их количество, то я бы был целиком за! Но, к сожалению, они неистребимы как тараканы. Да еще и размножаются методом говнокодирования.

еще и размножаются методом говнокодирования

Я на той неделе щупал кучу софта, и была там одна морда, весьма немолодой версии, на ангуляре вроде. С ынтерпрайз-за-бабло-редакцией, типа не фофан и не лаба. Ух я там наелся «3.0 is not in 1, 2, 3» и ««3» is not an integer» в полях ввода.

Вот они люди, которые форму заполнить не могут.

Она просто непрерывно эволюционирует в процессе валидации, отправки и обработки. Потому что ее писало существо, у которого вместо мозга экосистема с термитами.

Эти проблемы везде возможны. Не скажу, что они прям частые.

Насчет «везде» — это сильно сказано. У приличных систем разработки «экосистема» все-таки устоявшаяся. Как я понимаю., любой язык, который допускает локальную установку пакетов, будь то руби, питон, даже вот теперь Хаскель, будет подвержен тому, что у каждого разработчика рабочий набор библиотек будет немного разным. «У меня работает» не значит, что везде работает.

Бардак у разработчика не способствует стабильности в проде.

Что еще за «приличные системы»? Покажи мне приличную систему. Ты линукс видел?

Это наверно то, что сдохло лет 20 назад - там да, все устоялось.

Бардак у разработчика не способствует стабильности в проде.

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

Ну вкладываться в платформу — тоже дело, но из-за низкого порога входа в мире JS очень многие остаются где-то недалеко за этим порогом на этапе «О! Оно уже работает», значит «и так сойдет». А разобраться, как и почему оно работает, уже требует сильно больших усилий. И что с этим делать я не знаю если честно.

В автоматизированные системы разработки я не сильно верю, а вот плату за вход качеством кода хотелось бы иметь, но как это сделать?... Использовать языки с высоким порогом входа? Тоже так себе идея.

Ну вкладываться в платформу — тоже дело, но из-за низкого порога входа в мире JS очень многие остаются где-то недалеко за этим порогом на этапе

То есть все же проблему того, кто обделен мозгом вы предлагает решать через стек. Давайте пример хорошего?

«О! Оно уже работает», значит «и так сойдет».

Если после систематического подхода такого человека не выгнали на мороз - вопрос к тим(тех)лиду, а не к платформе. На каком языке такого результата нельзя получить?

А разобраться, как и почему оно работает, уже требует сильно больших усилий.

В любом языке и платформе. И не зависит от языка и платформы.

И что с этим делать я не знаю если честно.

Как мотивировать? Проводить ревью, возвращать в работу, наказывать за плохую реализацию.

В автоматизированные системы разработки я не сильно верю, а вот плату за вход качеством кода хотелось бы иметь, но как это сделать?…

Ну вот у Rust большая плата за вход. Мало гонокода?

Использовать языки с высоким порогом входа? Тоже так себе идея.

Плохая. Она бизнес поставит на «стоп». Отсеивать на этапе обучения, такими вещами как SCIP+Scheme и подобными фундаментальными трудами.

Проблема рынка - любая макака, которая способна набрать скрипт уже считается отделом HR программистом. А это не так.

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

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

Вот мои коллеги-фронтэндеры вешались постоянно от такой ситуации.

Профнепригодные? Так это же счастье! Можно выпить, не чекаясь.

С Джавой, кстати, тоже такие грабли были.

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

Я тоже так считаю, что все дело в руках и голове, но, похоже, в мире Джаваскрипта, как голову не включай, а бардак все равно не истребим.

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

Я тоже так считаю, что все дело в руках и голове, но, похоже, в мире Джаваскрипта,

Не аргумент. Я так же могу сказать про Go, Python и еще множества стеков. Но я просто понимаю - я попадал на профнепригодных. И это не проблема стеков.

как голову не включай, а бардак все равно не истребим.

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

Ну а кто сказал, что Go, Python и еще множества стеков. — это хороший выбор для Прода?

Ну а кто сказал, что Go, Python и еще множества стеков. — это хороший выбор для Прода?

А кто сказал, что нет? Ну кроме кучки людей, которые ведут в интернетах священные войны по поводу что лучше - головка сыра или луна?

Есть практика внедрения, применения. По вашей логике - C или Fortran тоже не подходят. От Java надо бежать. Ведь, кто сказал - что это хороший выбор для прода?

Понимаете какая штука, сам по себе Rust или Go не плох и не хорош. Он просто есть. С новыми языками типа Go или Rust пока проблема в том, что каждый новый релиз компилятора ломает совместимость с предыдущим. Что-то там дописывают и доделывают. Не устаканился еще. Устаканится — будем посмотреть. Тот же Фортран или С++ прошли большой путь, но ключ -std=<> спасает нас от неожиданностей. При этом, ABI компилятора не зависит от заданного стандарта компиляции. Как я понимаю, в Расте или Go это не так.

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

Понимаете какая штука, сам по себе Rust или Go не плох и не хорош. Он просто есть.

Я про то же. Это вы считаете проблему с головой - свойством языка.

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

Они вроде как уже стабилизировались. Go так дольше в стейбле. Ну да не важно. С выходом из криокамеры!

Что-то там дописывают и доделывают. Не устаканился еще.

А язык развиваться не должен?

Тот же Фортран или С++ прошли большой путь, но ключ -std=<> спасает нас от неожиданностей.

(поперхнулся кофе) Это С++ устаканился и его вы считаете стабильным? Ну ладо, вопросы все исчерпаны.

При этом, ABI компилятора не зависит от заданного стандарта компиляции. Как я понимаю, в Расте или Go это не так.

За них не скажу. На ржавчине писал только небольшую прогу, на Go - небольшие сервисы.

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

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

И я не могу сказать, что строгая типизация диаметрально лучше. Да - она решает ряд проблем. И то не до конца.

А ряд проблем (уже продуктовых) вполне себе материализует.

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

А теперь вопрос - почему вы проблемы человека пытаетесь переложить на стек?

почему вы проблемы человека пытаетесь переложить на стек?

А у вашего вопроса есть пределы применимости? Так-то про любой Х можно сказать «Х не говно, это вы все его просто неправильно готовите». Но когда-то же надо остановиться.

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

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

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

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

(поперхнулся кофе) Это С++ устаканился и его вы считаете стабильным? Ну ладо, вопросы все исчерпаны.

С точки зрения ABI — да. С точки зрения стандарта языка — нет. Еще бредет куда-то, не факт что в нужную сторону. Мне еще не попадался некомпилируемый плюсовый код при возможности выбора соответствующего стандарта языка.

А теперь вопрос - почему вы проблемы человека пытаетесь переложить на стек?

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

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

К сожалению, мы тут находимся в ситуации, когда неплохо бы решать административные проблемы (в частности, проблему квалификации персонала) техническими мерами. Все эти ваши вышепреведенные и весьма толковые практики разработки решают техническую проблему надежности кода административными мерами. Это всегда хуже. Лучше пусть компилятор даст по рукам разработчику за приведение типов, чем коллега код-ревьюер будет смотреть и думать «что же хотел сказать автор?»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так надо было просто с самого начала всё в докер пихать, а сборка докера уже воспроизводима.

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

Да. Только ст-дегенератам это нельзя доказать. При виде 1 + "2" у них начинает трястись их старческий подбородочек и дряхлые ручки тянутся к клавиатуре чтобы написать очередную херню, что жс не такой. Хотя sql уже 50 лет такой, но этих лицемеров то не заботит.

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

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

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

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

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

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

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

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

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

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

Поправил.

Поправил

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

Я думаю надо на JSDoc уходить. Еще бы появился проект более изящный чем JSDoc

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

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

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

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

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

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

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

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

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

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

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

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

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

на

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

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

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

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

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

Я ruby касался только очень-очень по-касательной, для расширения puppet’а. Так что знаю о нём мало. Но, по-моему, никто никогда не подразумевал использовать ruby для чего-то, где скорость/ресурсы важны. Невозможно сравнить количество ресурсов, влитых в попытки ускорить js, с аналогичной работой для ruby. Собственно, js это единственный язык из скриптоты, который одновременно используется массово и для чего-то более-менее критического по скорости и ресурсам.

JS уникален одним - работой в браузере.

В остальном Ruby это старший брат NodeJS. NPM это копия Gem из мира Ruby. И так далее и тому подобное, фреймворки тестирования как еще один пример, сначала массово стало использоваться в мире Ruby.

Все так.

Скорее в типе мышления. Я как-то участвовал в проекте по ускорению закачки файлов в частное облако. Типа облачное хранилище On Premis с расширенными флагами доступа к фалам. Типа что-то в облаке доступно read-only, что-то можно править ну и так далее. Back-end облака на руби с рельсами, далее какое-то самописное хранилище обезличенных документов на питоне. Трафик типа шифрован. Читаем руби-код:

decrypted = decrypt(buffer)

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

Ну вот, тормоза у нас с передачей фалов, — говорили мне при приеме на работу, напишите нам байпас для быстрой закачки фалов.

И, вроде, не дураки руби-то на рельсы ставили, но такой подход при написании веб-приложений ну сколько угодно. Руби тут виноват? По-моему — нет.

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

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

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

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

А вы уверены, что это проблема JS?

Да.

а не рук и голов.

Честно говоря, надоела дихотомия: js — говнокодерский язык vs на js программируют говнокодеры.

Да.

Докажите. Или очередной слив?

Честно говоря, надоела дихотомия: js — говнокодерский язык vs на > js программируют говнокодеры.

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

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

«программирование для дегенератов»

Как хорошо что я не пил чай в этот момент. Мыл бы монитор и клавиатуру.

как бы меня не тошнило от golang или python - я прекрасно понимаю

Go - это гениальный язык. Он так умно спроектирован, что не решение то в 10ку. Он высокоуровневый, но внутренние механизмы понятны. Получается точно выверенный компромис.

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

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

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

Понятное дело. Go заявлен как простой язык «который можно выучить за 1 месяц», что и привлекает новичков.

«Все гениально просто.»

«Unix is simple. It just takes a genius to understand its simplicity.» – Dennis Ritchie

Докажите. Или очередной слив?

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

Нет языков говнокодерских.

Жалкое, ничтожное оправдание, хотя и так все знают, что js придуман тяп-ляп за неделю. Для сравнения, oberon есть результат размышлений Вирта над дизайном ЯП на протяжении десятилетий.

так все знают, что js придуман тяп-ляп за неделю.

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

Для сравнения, oberon есть результат размышлений Вирта

Вы сравниваете спорткар с карьерным самосвалом. И то и то автомобили, но разных типов.

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

Я сравниваю два языка общего назначения,

Вы сравниваете языки с диаметрально противоположными системами типизации.

которые позволяют решать в принципе одни и те же задачи.

Да. Производить вычисления.

Вы сравниваете языки с диаметрально противоположными системами типизации.

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

Вместо Никлауса Вирта эту работу проделал Юкихиро Мацумото, вы можете оценить результат.

UPD: Ruby как язык лучше JS, продуманней, удобней. Но на практике это ничего не меняет, проблемы те же самые.

вы можете оценить результат.

Боюсь погружение в эту тему потребует больше времени, чем я могу на неё выделить.

позволяют решать в принципе одни и те же задачи

Страничку на обероне мне запили. Любой ЯП - мусор, пока у него не появится применение. Есть браузер - есть js, есть Flutter - есть Dart.

Почему js защищают со словами «Любой ЯП - мусор», «нет плохих языков, есть плохие программисты» и т.п.? Подозрительно это. Всё равно, что если в новостях читаешь напоминание «о мёртвых либо хорошо, либо ничего», значит какая-то отборнейшая сволочь издохла.

P.S. Oberon (операционная система) запускается в виде процесса под линуксом. Т.к. что да, с небольшой дополнительной обвязкой вполне можно сделать из этого браузер и показывать странички на обероне (языке программирования).

Любой ЯП - мусор

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

что js придуман тяп-ляп за неделю.

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

Абсолютно всем известно, что языка лучше, чем js не существует.

Абсолютно всем известно, что языка лучше, чем js не существует.

Моисей с тобой не согласен.

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

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

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

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

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

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

Я такого не видел, может в мире микросервисов и контейнеров такое и возможно, но это признак какого-то легаси или непогашенного технического долга

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

Тогда это современная программа с техническим долгом, сделанная по принципу «тяп-ляп и в продакшн».

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

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

Это не нормально

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

Ну как бы я стараюсь заботиться и о клиенте тоже.

Формируя решения, где им надо страдать, которое еще и будет готово не известно когда? Странное у вас понимание заботы

Да, 95 процентам пофигу, что исполняет их броузер. А остальным?

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

Да и о 95 процентах неплохо подумать. Дешевизна — не единственный критерий.

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

Ну так вот. Решение на JS позволяют достигнуть даже при наличии одних только макак под рукой - 2 из 3 критериев. Ваше решение - скорее всего 1. Вопрос - что выберет бизнес?

Видать, мы просто разными задачами занимаемся.

Может быть, не спорю. Есть области, где за использование JS я бы руки отрывал. Правда таких не так много.

Архитектура и все остальное - клиенту без разницы.

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

Качество — это соответствие требованиям заинтересованных сторон. Тот, кто занимается разработкой и (особенно) поддержкой/развитием — тоже заинтересованная сторона.

Качество — это соответствие требованиям заинтересованных сторон. Тот, кто занимается разработкой и (особенно) поддержкой/ развитием — тоже заинтересованная сторона.

А это уже обеспечивает не язык (хотя есть явное влияние), а те, кто пишет софт. И если человек мудак - он будет на любом языке писать как мудак. Хоть CommonLisp, хоть Rust, хоть JavaScript.

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

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

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

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

Чем плох nodeJS?

Религия. Она такая

Читайте выше. По-моему всем плох.

Так пользуйте NoJS бразуеры. Есть же такие. Да и вообще - links2 вам хватит. Почему не на нем сидите?

Иногда пользую. Не поверите, я и Gemini space читаю. Там как-то глаза меньше устают.

В Gemini space есть что читать?

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

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

Кое-что есть. Я там просто душой отдыхаю, красивый шрифт и спокойный текст.

Звучит отлично. Со временем все больше разработчиков будет переходить. Уже сейчас Mastodon стал из маргинальной среды для двух энтузиастов превращаться в такую себе достаточно популярную сеть. У Gemini протокола есть все шансы так же завоевывать популярность.

Ну пока они там судорожно решают проблему комментариев прикручивая веб рядом с Gemini :)

Сейчас читаю про Gemini. Хотел цитатой поделиться.

Doesn’t the Web feel like it’s overrun by, well, hordes of people lacking even the most basic ideas of civilization and culture?

https://eerielinux.wordpress.com/gemini-faq/

small-entropy как раз цитата в тему новичков-вайтишников.

Комментарии, не нужны по хорошему. Есть почта. Можно письмо так написать.

Ну вот одна из идей как раз и состоит в том, что бы комменты к посту слать почтой.

Голубиной.

Можно. https://www.rfc-editor.org/rfc/rfc2549.txt

Ну, если угодно... :)

Пока были экстеншены в броузерах типа NoScript, я ими пользовался. Потом пропали, к сожалению.

Куда пропали? У меня прямо сейчас он в лисе работает.

И действительно, в Лисе можно. В Хроме нету, вроде.

Дык в Хроме это давно в настройках самого браузера chrome://settings/content. Там можно для всех сайтов запретить жаваскрипт, куки, локации, камеру, флеш, картинки и прочее (разве что для <video> запрета не нашёл), или выборочно для каждого сайта. В частности настройка для жс chrome://settings/content/javascript.

Спасибо, поковыряюсь.

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

Нет же. Всякие вебпаки упакуют то, что нужно.

Ох уж эти людишки у которых библиотеки весят больше кода приложения. У них очень много проблем (в большинстве с головой).

Да блин, посмотри на исходный код хоть этой страницы. Цитирую:

<script type="text/javascript">
  $script('/webjars/jquery/2.2.4/jquery.min.js', 'jquery');

  $script.ready('jquery', function() {
    $script('/js/lor.js?20240320-2016', 'lorjs');
    $script('/js/plugins.js?20240320-2016', 'plugins');
  });

  $script('/js/highlight.min.js?20240320-2016', 'hljs');
  $script.ready(['jquery', 'hljs'], function() {
    $(function() {
      hljs.initHighlighting();
    });
  });

  $script('/js/realtime.js?20240320-2016', "realtime");

  $script.ready('lorjs', function() {
    fixTimezone("Europe/Moscow");
  });

  </script>

Сколько джаваскипта в ней и сколько кода в jquery?

Зависит от сборки. Сорцы открыты - можете посмотреть.

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

И что? Какие-то проблемы из-за этого? В криокамере жпрс интернет?

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

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

https://stackoverflow.com/questions/45283886/using-different-versions-of-dependencies-in-separated-java-platform-modules

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

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