Вышел Node.js 19.0

Ну спастил ты эту чушь - дальше что? Лишь показал своё невежество.

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

процедурное программирование - удачное

30-и летней давности

Не понял о чем ты.

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

Покажи, как выглядит с классами.

Ты не нужен. У жс минимальный бойлерплейт среди другой скриптухи.

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

Они там всегда были. Через объект с функцией можно сделать практически всё. Сделали другое объявление, чтобы жаба-свитчеркам было сухо и комфортно.

Потому, что ООП это неудачное изобретение

Какое ооп ты имеешь ввиду? Жаба-ооп? Ну да.

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

это называется костыли

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

когда вы класс объявляете кусками у вас весь код

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

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

Так что в итоге? Вот у тебя оопота:

Класс X делает A
Класс Y наследует Х делает B (и A из класса X)
Класс Z наследует Y делает C (и B, A из родителей)

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

И

т.е. доработать или пофиксить становится проблематично

Если вы там уже понаследовались от X,Y,Z т.е когда надо для Z делать C,B,A,D - вообще забей.

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

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

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

Злоупотребление чем? Это обычное наследование. Метод, где в каждом классе (X,Y,Z) делается какой-то код (A,B,C), вот сделали эту иерархию, сделали еще всяких классов, которые наследуются от X,Y,Z. Теперь половине из них надо чтобы в X делалось A,D, а другой половине не надо. Ничего такого, обычная хотелка. Покажи, как ты это сделаешь нормально.

так и не понял, что значит «надо чтобы в X делалось A,D», вы можете переопределить метод на любом уровне и сделав его пустым или таким как вам требуется. Если делать глубокие иерархии действительно можно столкнуться с какими-то сложностями, особенно если у вас нет возможности делать множественное наследование или в языке усложнено позднее связывание, поэтому такое обычно не рекомендуется, что впрочем не мешает выстраивать 2-3х уровневое наследование и решать этим 80% потребностей переиспользования кода.

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

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

так и не понял, что значит «надо чтобы в X делалось A,D»

В класс X надо добавить код, который будет работать для классов E,F,G но не будет работать для классов H,J,K. Сами эти классы в свою очередь наследуются от Y или Z.

вы можете переопределить метод на любом уровне и сделав его пустым или таким как вам требуется

И как будет работать код из Y или Z, если я его полностью переопределю?

что впрочем не мешает выстраивать 2-3х уровневое наследование

Оно уже на 3-м уровне не работает.

и решать этим 80% потребностей переиспользования кода.

И что делать с остальными 20% кода? Пастить?

множественное наследование

Даже если есть, то что? Таким же образом есть методы в X которые должны работать F (наследование x->y->z->f) и не должны в Е. В общем случае всё выродится к тому, что у тебя будут классы из одного метода, где-то отдельно структура и ты будешь всё это множественно сношать, а твой код будет на 80% состоять из объявлений классов.

Ага, удачи что-то написать без классов.

Современный ui на react обходиться без классов, только функциональные компоненты

Да и жаву во многом косплеит тс.

ts про структурную типизацию, чего общего у него может быть с java?

Вместо нормального.

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

Современный ui на react обходиться без классов, только функциональные компоненты

Сразу видно эксперта. ui на реакте - говно. Кстати, ретрансляторов пропаганды очень хорошо видно про базворду «функциональные» - это говорит лишь о стандности и невежестве. Потому как это компоненты-функции.

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

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

В основном все более-менее понимающие тему - пытаются как можно дальше держаться от реакт-говна и хранить всё где-то с боку, где этого мусора не будет. А после уже натягивать на него. Эта схема +/- работает.

ts про структурную типизацию, чего общего у него может быть с java?

Всё начиналось с интерфейсов. Ну и много фичей как раз таки касаются классов. А так всё. Генерики, extends, интерфейсы. Конечно, жс это не жава и сюда сложно натянуть что-то. Но с поправкой на реалии - жавы в тс достаточно.

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

Без мусора. В целом в базовом жс это невозможно. Хотя были попытки с файберами, но они сдохли.

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

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

Это проблема не только жс. В целом асинка - он ядовитый. Заюзал где-то - это говно загадило тебе всё. Сломался и язык и контексты и в принципе всё.

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

может лучше наоборот выполнять каждый script или даже эвент в отдельном потоке отдельно от рендеринга и пусть оно хоть заблокируется;)?

Ну каждый скрипт - это мусор. И await и так блокирующая операция. Её эмуляция.

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

А так да. Лучше сделать как в гошке. Там в скриптухе косплей на нормальную модель. Те же node-fibers уже была реализация. Как следствие весь мусорный асинк сдохнет на помойке.

В нормальной модели, конечно, тоже есть свои маня-проблемы. Но +/- там паритет с асинк/авейтом. Только та модель не такое говно ломающие код.

Отличный сборщик фронтенда. На сервер я бы такое не потащил, даже для SSR.

люди его и в бэк и в фронт, и ничего - нормально

Мы вас не осуждаем, но детям показывать такое нельзя

Ну каждый скрипт - это мусор. И await и так блокирующая операция. Её эмуляция.

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

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

Даже матом ругаться не хочется.

а ты умеешь?

Ты не нужен. У жс минимальный бойлерплейт среди другой скриптухи.

Не нужны такие икперды. Ты забыл про луа.

Злоупотребление чем? Это обычное наследование. Метод, где в каждом классе (X,Y,Z) делается какой-то код (A,B,C), вот сделали эту иерархию, сделали еще всяких классов, которые наследуются от X,Y,Z. Теперь половине из них надо чтобы в X делалось A,D, а другой половине не надо. Ничего такого, обычная хотелка.

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

процедурное программирование - удачное

30-и летней давности

За 30 лет ничего лучше не придумали, знак качества, можно сказать.

когда все аргументы запихиваются в одну структуру это ничем не отличается от глобала

Это очень сильно отличается от глобала. Тут вообще ничего общего с глобалом нет.

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

Зачем писать функции, которые требуют 50 аргументов? Функция должна помещаться на экране. То бишь занимать 20-50 строк максимум. За редкими исключениями. И принимать 3-5 аргументов от силы. Если ты пишешь функции в 50 аргументов, ты что-то делаешь не так.

Процедурный код не может понимать даже программист, который когда-то его напейсал.

А может понимать.

За 30 лет ничего лучше не придумали, знак качества, можно сказать.

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

Тут вообще ничего общего с глобалом нет.

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

А может понимать.

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

значит вы что-то коряво напроектировали

Да. Наслушался бездарных преподов в шараге и писал ООП - код с наследованием.

кроме наследования можно и даже нужно использовать агрегацию

Показывай, как нужно это делать.

процедурный код это тоже нагромождение goto

/0

ООП решает проблему нагромождения if else и всяких switch по типу.

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

Не помойка, это когда написал класс и больше его никогда не трогаешь, как я понимаю? Из этой ситуации у тебя есть 3 выхода: не реюзать и копипастить D, сделать в X признак и свитч в A с вызовом D, сломать иерархию. Все 3 выхода - мусор, как и твоя ооп помойка, где, куда не плюнь, делать нихера нельзя, а если пытаться делать правильно, то получиться fuzzbuzzenterprise.

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

ООП решает проблему нагромождения if else и всяких switch по типу.

Это не проблема. И ООП её не решает, а переводит в нагромождение типов.

Решает проблему мульти-диспатч. Но его почему-то делать стесняются в популярных ЯП. Использовать ООП для мульти-диспатча можно, но глупо.

не решает, а переводит в нагромождение типов

А должна быть одна кнопка «Сделать ЗБС»? Хоть какой диспатч предполагает, что код который будут диспатчить, должен быть написан. ООП хоть и является самым тривиальным вариантом, но, внезапно по известной теореме покрывает 90% случаев. Остальные 10 могут запердолиться в мультидиспатч на коленке, или взять CLOS, или ещё какую-нибудь эзотерику. Если это реально нужно, уровень проблемы и решальщиков должен быть достаточным, чтобы разобраться в инструментах и подходах без vbr.

Ого какой всеобще-агрессивный токсикоз. Вам бы даму завести, ну или аквариум с котами. А что никто не обратил внимание на такую шутку-юмора JS?

> typeof NaN
'number' 

На всякий: NaN - Not a Number

JS нужен , чтобы снежинки анимировать на сайте

дед выйди из 2007 года, на дворе 2022, я сам в шоке. js на сервере уже давно

то что не смогла сделать java разумеется. просто работать. везде.

а чем так плох синтаксический сахар кроме как по идеологическим причинам? разве развитие языка и обратная совместимость это что-то плохое? ааа ну потому что это сразу снимает налет илитарности и «высокого порога вхождения»

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

И на каком сервере у тебя java не заработала?

Я сейчас рефакторю процедурный код на pg/plsql. Вообще, это даже интересно - как город из спичек собирать... Проблема в том, что я его перевожу на чистый SQL, и он становится менее читаемым (зато с векторной алгеброй)

Чувак, на сервере и brainfuck давно. А как давно перловые однострочники!

вечные проблемы с зависимостями, вечный половой акт с версиями jdk. а про мусорный Gradle я вообще молчу. вечером все работает, закомитил, с утра на работу приходишь - проект весь красный. ты представить не можешь сколько проклятий я посылал в его сторону пока писал на java. пока в докер все не обернули нормально работать просто отказывалось.

может просто мне попался проект плохой, но это был ад)

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

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

тащемта js тоже не без изъянов, но если ты не совсем дурачек то typescript это лучший javascript

чисто из любопытства… а что этот код вообще делает? pg/plsql, векторная алгебра… звучит как что-то мега муторное

Есть такое понятие: байтоепство, этим любят страдать сишники и крестовики, а тут дрочево на данные: текст, цифорки и всякие sql процедурки, это когда часть кода ты забубениваешь из бекенда в нутро свой субд и она пережёвывает все эти данные вот этим кодом перед тем как выплюнуть их. Изменяет в зависимости от курса бакса, к примеру, короче, SQL это тоже крайне узкая ниша… большинству достаточно знать 5 sql операторов))

У меня друган в одном ру банке; до сих в проекте грит есть код на java 6, o java 11 они могут только мечтать!

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

А так обычный BI - прогноз-план-факт, анализ тонких мест и ошибок.

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

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