QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Ухудшение технологий программирования

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

А именно: Наши технологии все сложнее и сложнее! Освоить их все труднее и труднее. все меньше времени остается на личную жизнь. Постоянно изучение этих гадостей плохо отражается на гормональном фоне разработчика.

Я еще помню писал на Джаве 1.4, все норм, ни тебе хибернейта дурного, стратс простой до невозможности. Процессом был простой вотерфолл, никакого сткрама злобного и мучительного. Все было просто, красиво и прельстиво.

Проект билдали мавеном, юзали простой конкарренси, а на фронте у нас был document.getElementById. А сейчас — не успел я сборщик для веба Grunt освоить, так уже еще куча вышли. Технологии успевают устареть до того, как их успевают выучить. Джава туда же, хотя на беке состояние лучше. Мавен — чудесный тул, всем хорош, нет хипстерам подавай Гредл демонический.

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

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

И никакого докера!

LinkedIn

Лучшие комментарии пропустить

Ну як для п’ятниці трохи слабувато, але хоча б щось.

Более того, что я ещё заметил за тоже 15 лет опыта. Всё это развитие фреймворков и технологий на самом деле ничего не даёт. На выходе мы имеем такой же функционал, и такую же сложность бизнес-логики, как 10 лет назад. И я бы не сказал, что кодить типовые задачи сейчас легче и быстрее, чем в середине 2000-х. Всё точно так же. Что раньше я тратил два дня на условную «форму редактирования модельки», что сейчас. Более того — сейчас это делать даже геморнее, так как много возни с ангуларами, мапингами, пакетами, бандлами, реактами и прочей хипстерской ***той, и ты никогда не уверен в том, как всё это себя поведёт, и не чувствуешь контроль над процессом. Заработало, ну и ладно, а что там внутри происходит — да хер его знает.

Всё это бурное развитие/устаревание — это абсолютно пустой процесс ради процесса.

Технологии все сложнее и сложнее — это называется прогресс.
Я еще помню, когда бухгалтерши сидели с деревянными счетами и толстыми гросбухами.

Все было просто, красиво и прельстиво.

Потом им пришлось осваивать калькуляторы и печатные машинки. А теперь им приходится работать с компьютерами и сложными приложениями. Освоить их все труднее и труднее. все меньше времени остается на личную жизнь. Несомненно это отрицательно влияет на демографическую обстановку ...
А если серьезно — то новые технологии должны появляться именно в ответ на возросшую сложность что бы «инкапсулировать» ее и сделать возможным для человека использовать мегасложные модули, не вникая в детали.
Спаять процессор из ламп — была мегасложная задача. Спаять Спектрум по схеме — уже доступно среднему радиолюбителю. Сегодня собрать комп из готовых комплектующий может даже школьник. При этом ни один человек не способен уложить у себя в голове схему современного процессора. Их давно уже проектируют компьютеры и «печатают» роботы. Человек видит процессор как «коробочку с контактами» — ничего сложного.
Почему же новые ИТ технологии не упрощают, а усложняют нам жизнь? Да потому что их в большинстве случаев пилят не инженеры, а «велосипедисты»!
И вместо сделанного по стандартам, прекрасно документированного и совместимого узла, агрегата, микрохемы, или хотя бы банального болта или гайки мы имеем 100500 «болтов» и «гаек» с разной резьбой и столько же разных ключей что бы их крутить!
Предположим нам надо веб-сайт. Казалось бы — типовая задача. Если взять 100500 самых популярных сайтов и сравнить — то можно будет выделить от силы сотню типовых элементов. Мало кому нужен сайт с текстом по спирали или треугольными кнопками.
Так почему вместо одной библиотеки из 100 элементов веб-девелоперы каждый раз собирают френкенштейна из 100500 разных фреймвоков и библиотек виджетов?! Просто потому что ни одна из них недостаточно зрелая, что бы решать хотя бы 90% типичных задач и поддерживать расширение для 10% исключений.
По моему опыту большая часть новых фреймвоков поддерживают только «хэппи пас» — они хорошо работают только в примерах. А 90% всех остальных необходимых задач (обработка ошибок, локализация, поддержка таймзон, аксесисибилити, разные браузеры, разные разрешения экрана и т.д.) — разработчики «выносят за скобки». Потому что сделать один полностью досканальный компонент, который будет поддерживать все — сложнее и дольше, чем склепать 100500 новых виджетов и сразу их продавать!
Главная беда в ИТ что технологии хотят продавать ДО того как они написаны! Какой уж тут инженерный подход, подгонка и тестирование если всегда «надо на вчера». Клиенты уже заплатили деньги — лепите быстрее из говна и палок. Вот современный подход!
Спасает нас только то, что ИТ — это не материальное. Рухнувший сайт — это не рухнувший мост. Ошибки в программе — это не ошибки в конструкции самолета... Но как показывают последние события мы уже приближаемся к тому, что от качества софта будут зависеть человеческие жизни.
И тут уже будет не до модных фреймвоков!

1 Не надо учить все перделки со стразиками подряд, они приходят и уходят., особенно в JS
2 Учи то что будет решать твои\проектные проблемы.
3 Если на проекте годами ничего не меняется то таки придется подучить что-то новое, чтобы зайти на новый проект, но это не сложно и не надо делать постоянно, в адекватных компаниях даже дают преоктное время для этого, за 3 месяца испыталки можно подтянуть все что надо или за время бенча подготовиться к собеседованиям.

Учить на будущее возможно имеет смысл для джуна\мидла чтобы больше знать и понимать, когда вот так вот проработаешь пачку фреемверков и прочих инструментов изучать новое не сложно совсем ибо у всех база одинаковая. Те же паттерны уже сущетсуют лет 30-40 уже. Алгоритмы и структуры данных еще куда старше.

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как я рад, что программисты устаревают вместе с технологиями. Однако, судя по jq, не так быстро как хотелось бы

для фронта — jQuery.

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

Почему же делают новыt фремы? think about it

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

Visual FoxPro и Visual Basic наше все, и не этот богомерзкий .net
А для фронтенда хватит Frontpage
Для баз данных подойдет Sybase или Informix

Интербейз и Дельфи! 😅

Дельфи

для свого часу і можливостей — чудовий інструмент

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

для свого часу і можливостей — чудовий інструмент

Конечно, отличный. Быстро налупашить «формочку» — вот оно, счастье. Только одна проблема — сама среда программирования поощряла нетестируемую и нетестированную код-лапшу, что в соответствии с принципом наименьшего сопротивления породило тонны говнокода и армии людей, не понимающих базовые принципы дизайна ПО.

Сейчас всё тоже с код-лапшой. Ничего не изменилось. А как RAD дельфи был прекрасен.

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

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

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

«програму на Фортрані можна написати на будь-якій мові»

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

Ну... в 1995 году пора тестов ещё не пришла.

Она пришла сильно раньше. Но среди типичных применений Delphi (и большинства аналогичных средств) в те времена в наших краях, да, такое редко применялось.

Поддрежка unit-тестирования в Delphi появилась примерно с выходом книги К. Бека «Экстремальное проргаммирование» (2002), тогда появился пакет DUnit, которые позволял писать unit-тесты и запускать их из среды. Кстати, среда IDE Delphi была расширяемой, вместе с любым компонентом ты мог добавлять код, который выполнялся в design time.

Ну а что было в наших краях на PC в то время? Clipper и FoxPro. Delphi и VB. Разные компиляторы C: Watcom, VC, Borland C++, DJGPP. Плюс некоторая экзотика вроде Turbo Prolog, ... Если кто и хотел использовать тесты — приходилось писать всё самостоятельно ручками.

софт без какого-либо покрытия тестами, в котором «все связано со всем»,

Ну одно с другим особо не связано (покрытие тестами, которое вообще уже для веб-кодинга придумали) и фиговый код, начиная от спагетти и заканчивая бесконечным копи-пастом сущностей.
В целом же поправить и доделать что-то на Дельфи-С-билдере было намного проще, чем в сегодняшних Ангулярах+RoR, например.

это дескопный софт и подкосило

Не только. Много десктопных продуктов за долгие года вылизаны и написать лучше очень и очень сложно.
Но вот сколько раз пробовал новые типа IDE Atom, Visual Studio Code на электроне. Мне неудобно, возвращаюсь или к старым IDE или к xed.

Уж совсем не поклонник настольных приложений на электроне, но VS Code определенно неплох, чего не скажешь о другом продукте MS.

новые типа IDE Atom, Visual Studio Code на электроне

це не IDE, це редактори

думаю в мс задалися таким питанням, коли вирішили викатити ВС Коде

Скоріше вирішили пробитися на нові ринки, популярні нинче

У хіпстерів мода на легкі текстові редактори.

Досить занудствувати. Легкі у порівнянні з айдішками. Все що треба хіпстеру, від чого він пісяється — це текстовий редактор з мінімумом функціоналу і консоль. Вбивати вручну команди це топчик і дуже переможно, не те шо 1 кнопку натиснути в айді.

Хоча айдішки дійсно занадто жирні бувають

Ми ж про Нотепад++? Хз, юзав коли пхпшив, але без плагінів, підсвітка була, в тому числі синтаксичних помилок. Не можу сказати чи можна ним замінити айді навісивши плагінів.

Під мінімум я мав на увазі відсутність запуску, збірки, встановлень пакетів, роботи з гіт, автоматичного рефакторингу(заміни частин коду, перейменування класів), конструкторів шаблонів(забув як зветься, коли тип файлу обираєш і при створенні вже робоча болванка подається). І що там ще в тих айдішках є, я ще не гуру. Хіпстерки все люблять робити руками в консолі, бо це модно, стильно, молодіжно.

А так, забув про головне — про дебагер)) До хорошого швидко звикаєш.

той ще анекдот, для того щоб писати під дотнет треба ставити джаву, Карл!

І що в цьому такого?

Ну с учетом того, что vs code и vs инсталлятор написаны на электроне — не так уж и смешно

Воно ж некрасиве і не модне.

В моем первом варианте так и было Дельфи и вместо конкурренси Application.ProcessMessages :)

Кооперативная многозадачность — она такая :)

Для баз данных подойдет Sybase

до сих пір жиє і здравствує, їх викупив SAP
версія SQLAnywhere доволі непогана в роботі, особливо доставляє Watcom SQL, як мова для процедур

Заместо спринга бины можно вязать джава кодом, в одном месте, джейквери пока между браузерами несовместимость и неподдержка стандартов, заместо мавена один «джаваБилд.класс» и скрипт который его скомпилирует и запустит пока в джаве нет «ранНонКомпайледКласс.ехе», заместо грейдла «собрать-все.жс», заместо скрама туду-лист ( ну или модный трекер ) куда добавляет заказчик, а инженеры пишут это-мое—не-трогать(фамилия) а потом (сделал — 19мин 34 сек)

Вот потому я и не женюсь и джавист на бекенде. Хотя есть тенденции и к упрощению. 10 лет назад не знали про преимущество функционального программирования, а сейчас джависты выучили что private final это добро, а static это зло

Вот потому я и джавист на бекенде

Чувак ти в такому болоті сидиш, ти просто не уявляєш. Джава по інструментам взагалі ніяк не змінилась за останні 10 років.

Спробуй rails базарю ще захочеш )))

не слушайте его, а то геем станете

Вы так говорите, как будто это что-то плохое.

За преимущества функционального программирования знали еще при разработке. Правда, не все. Да и сейчас не все понимают.

Как бы не очень.
Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
ru.wikipedia.org/...​ональное_программирование

Тогда чистых функциональных языков раз два и обчёлся, Haskell, ML не знаю что ещё. Которые, однако, не очень популярны. И да, кроме преимуществ есть недостатки.

Недостатки везде есть. И в императивной парадигме, и в ООП. Lisp еще есть. Бабаян по моему даже компьютер делал на основе функциональной парадигмы. Что-то ему с параллельностью понравилось. Не знаю чем закончилось.

Между мап/редьюсить лист лямбдой (что 95% подразумевает, когда говорит фп). И программировать на чистых функциях, заворачивая IO в монады, фримонады и монадтрансформеры — пропасть.

Я согласен что как-то сложновато. Но, что-то там есть. Я не могу пока сказать что. Императивную парадигму и логическую объединил. Событийную тоже. С функциональной никак не определюсь. Как-то она у меня слишком сбоку. Мне даже функции пока не понадобились. Хотя вроде магия рекурсии. Лямбды, иногда хорошо. Функции в качестве параметров-круто.. Но, больше никак не нахожу место..

Желание использовать фреймворк появляется после того, как native уже настолько хорошо изучен, что упаковки фреймворка понимаются с одного взгляда на них. Ведь по сути фреймворк это и есть набор упаковок. Например, директива v-for="item in items" в Vue.js эта упаковка для некоторого блока инструкций и после того как один раз увидите как она работает уже не сможете отказаться. Итак — противники фреймворков не уверены в своем знании native. И вот еще пример: упаковка let newList = [...list] //клонируем массив по элементно.
Тоже удобно и применяемо. То есть получается, что для того, чтобы фреймворки юзать радостно, сперва надо, чтобы native от зубов отскакивал.

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

Пути 2:
1. Учиться-учиться-учиться. И да, прощай личная жизнь.
2. Смириться, уйти куда-то в поддержку старого легаси кода и радоваться жизнь (пока проект не закроют).

Есть еще путь № 3 — изначально учить не хайповые технологии, а матчасть. Тогда вас будут брать на работу не потому, что вы умеете использовать инструменты X и Y, а знаете как написать совершенно новый инструмент где-то в научной лаборатории (другими словами — R&D).

Есть, конечно, и 4ый путь — уйти нафиг с программирования и заниматься менеджментом.

В точку! Ещё лучше совместить пункты 3 и 4

Это единственный путь остаться на борту.

недавно общался с товарищем, который на белом глазу предлагал 10+ микросервисов деплоить без докера (ибо докер говно) и кубернетеса (ибо ***ня) или аналога.

сервси дискавери? — на***!
ресурс неготиатор? — на***!
CNI — шо?
грейсфуд шатдун? — по***
роллинг апдейт? — шо? на***!
JVM? — тормозит, потому что Java тормозит!!!111111, вот у меня на андроиде все медленно, какие еще доказательства вам нужны?
liveliness probe — напишем приложение которое будет кверять сервисы. кто будет само это кверять это прилоение? а хз.
дженерики, ООП? — на***, раньше на сях писали и все было зашибись (и *** стоял, конечно же).

зато с умным видом рассказывал мне как работет внутренняя сеть в докере. оказывается это ... NAT (видимо, Тони Робинс покусал).

Без большей части перечисленного даже проще. Хотя если jvm, тогда не. А если какойто erlang c let-it-fail — не вопрос.

Или Akka cluster. Давайте попробуем нанять 3 вменяемых скалистов или эрлангистов миддлов.

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

с какой фигней? с тем, что программист не должен быть девопсом?

это луддизм чистой воды.

эрланг — крайне убогий язык в сравнении с нормальными ФП языками. ничего не мешает использовать акторы в Хаскелле.

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

правда в том, что для 99% crud приложений акторная система — гораздо бОльший overkill, чем приложения на Спринге которые контролирует Кубернетес, где де факто поды решают абсолютно те же вопросы, но долее универсально.

Кубернетес можно заменить на что угодно, я абсолютно не фанат этой конкретной имплементации. Можно вообще без контейнеров обойтись, а делать a la Titus — использовать пуллы машинок в тех же целях. Суть от этого не меняется — управление инфраструктурой все больше отделяется от программирования бизнес-логики и я считаю что это замечательно.

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

Дык а сколько оверхеда на дополнительные вычислительные ресурсы сожрёт кафка + кубернетес, в противовес эрлангу? Я раньше работал в компании, где расходы на AWS отъедали половину прибыли.

еліксірщиків можна замість ерлангістів — в еліксір менший поріг входу і більше плюшок, а працює все так же, як і з ерлангом

в еліксір менший поріг входу і більше плюшок

Взоржав...

iex(11)> elem(pref, 1)
"Pre"
iex(12)> elem ( pref, 1 )
** (SyntaxError) iex:12: unexpected parentheses. If you are making a function call, do not insert spaces between the function name and the opening parentheses. Syntax error before: '('

iex(12)> counter = 0
0
iex(13)> counter +1
** (CompileError) iex:13: "counter +1" looks like a function call but there is a variable named "counter", please use explicit parentheses or even spaces
iex(13)> counter + 1
1
iex(14)> counter+1
1

таке синтаксичне лайно ніяк не знижує поріг входу, навпаки.
І якщо ви це називаєте плюшками... у мене для вас погані новини.

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

таке синтаксичне лайно ніяк не знижує поріг входу, навпаки.

наскільки розумію, це наслідки необов’язкових дужок при виклику функцій (я не еліксірщик, але приглядаюсь, тому і обмовки)

shit happens, але хоча би б’є по руках, а не мовчки робить щось інше

І якщо ви це називаєте плюшками... у мене для вас погані новини.

плюшки — метапрограмування

плюшки — метапрограмування

erlang parse_transform був роки тому до elixir.
Єдине що — викликати його треба було окремими правилами.
Можливість на ходу скомпілювати код і виконати його — теж.
А от те, що скомпільовані функції залежать від версії похідного модуля, може бути критичне, а тут воно ніяк не показується.

таке синтаксичне лайно ніяк не знижує поріг входу, навпаки.

до речі
github.com/...​r-lang/elixir/issues/5761

Я так розумію, один частковий випадок?

Ах да... кращий спосіб знизити поріг входу це назвати байндінги змінними. Типу, знайомий термін для зовсім іншого явища — це найкращий метод завлекти новачків

Эликсир идет чуть дальше, чем просто переименовать в документации что-то. В эликсире, в отличие от, можно counter = counter + 1 (хотя под капотом же все равно эрланг, так что никакого «ребайнда» в реале не происходит — насклько я помню просто создается новый байндинг а компилер трекает «алиасы», скрывая от кодерка кишки). Очень спорный дизайн местами, имхо...

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

Ну так написані нормальні помилки, в чому проблеми то? В тому, що є примус до форматування коду?

В дурості конкретних вимог самого примусу. Приклад с +1 це показує.
Варіант, коли пробіл ставити треба завжди, логічний по-своєму. Маємо синтаксис стилю LISP, Forth...
Варіант, коли пробіл не має ролі, теж логічний. Це традиційний синтаксис як у мейнстрімі (від Паскаля і C до Ерланга і Go...)
А те, що бачимо у Elixir, не має ніякої логіки крім одного — засобами типу PEG встановили приорітет розбору, наплювавши на однозначність.

То-то как только испекли ребар, 90% (если не 99%) эрлангистов перебежали на него, наплевав с высочайшей колокольни на возможность выполнить relup и прочие тонкие задумки Армстронга.

Если чтото может упасть, оно падает.
Как бы транзакции не от хорошей жизни придумали.
У меня и на питоне let-it-fail на не-реалтаймовых поточных сервисах. В некоторых случаях так проще, чем потратить х5 времени на учет всех проблем.

Если чтото может упасть, оно падает.

А это независимый вопрос. Что упало — перезапустят. Но если падает 1% от всей функциональности, а остальное работает, то зачем перезапускать всё, если можно ему дать продолжить работать?

У меня и на питоне let-it-fail на не-реалтаймовых поточных сервисах.

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

Перезапускал ручками? ну тогда да,вам надо кучу всего чтоб поправить карму
скрипты которые падают чаще раза в МЕСЯЦ запускаются с резирвированием х2 с помощью safe_xxx.sh и в них ставятся таймауты. Отработал ХХХХ запросов — вышел, перезапустился.
Упал? Положил в лог сообщение о падении, перезапустился.
Так еще с времен до-апача-1.0 сделано везде.

ну тогда да,вам надо кучу всего чтоб поправить карму

Я и поправил — ушёл оттуда :)

грейсфуд шатдун

Grapefruit shutdown... fastfood shutdown...
не, я понимаю, что опечатка, но прикольно же.

JVM? — тормозит, потому что Java тормозит!!!111111, вот у меня на андроиде все медленно, какие еще доказательства вам нужны?

Ну, определённая логика (1-2%) в этом есть. А что он взамен предлагает?

golang, язык, в котором ничего нет

посмотри techempower — там почти по всем категориям джава голанг обходит — (за исключением плейнтекст теста который почти на ровне голанг на 0,03 процента быстрее)
только на джаве писать сильно проще + есть куча готовых либ обкатанных, так что голанг — это не альтернатива джаве, если есть мозг

если есть мозг

А с этим собственно и проблема. Поэтому появилась Java, эти ваши питоны и Go. По последнему это даже не скрывалось — щас не найду цитату, но смысл был в том, что в Google устраиваются выпускники универов, которых учили чему-нибудь и как-нибудь, всяким Java, C++, и всё это не то и не работает. Поэтому вот вам язык, на котором типа невозможно писать неправильно. Даже go fmt есть.
Если бы был мозг, то не нужно было бы вообще ничего кроме С.

Если бы был мозг, то не нужно было бы вообще ничего кроме С.

Ну, если бы кто-нибудь тут не сказал настолько радикальную и феерическую глупость, это был бы не dou.

І правда — нашо той С, коли є asm?

Почитай Кернигана с Ричи и почему появился С. После Страуструпа, почему появился С++.

Табличку SARCASM було б варто вже давно мати на ДОУ :(

Grapefruit shutdown... fastfood shutdown...

Shitfood shutdown еще.

JVM? — тормозит, потому что Java тормозит!

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

память жрет как свинья

В абсолютных величинах — давно ограничивается. В темпе роста — с современными GC это в основном решено. Я удивлялся, почему не сделают ближе к стилю Lua (грубо говоря, следующая сборка запускается по достижении K раз от результата предыдущей), но то, что начинается где-то с 8ки, меня устраивает почти всегда.

выдает не менее свинские логи с эксепшнами, для парсинга которых нужна еще одна машина с еще одной явой (привет ELK!) и так по рекурсии.

Красивое утрирование, и в качестве хохмы пойдёт, но на практике — нет. ELK не обязателен (а лучше сказать — не нужен чуть менее, чем всегда), для логов вылета кода под VM достаточно grep+less. Конечно, если стоит задача хипстерски обосновать выделение ещё 100 VMок, то надо решать наоборот :)

В абсолютных величинах — давно ограничивается.

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

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

Долго стартует.

для логов вылета кода под VM достаточно grep+less

Успехов в вылове ошибки на сервисе с нагрузкой хотя бы в 1000cpm, произошедшей 8-12 часов назад (но точно неизвестно когда). А еще лучше — навесом извне алерта с ее полным описанием.

Поинт не в этом, а в том чтобы стандартный тул на яве с машиной меньше 2 гиг озу лучше не подходить, а лучше с 4мя сразу.

Что-то я такого не наблюдаю. Сколько сервису реально нужно, столько и отдавать надо, только выбрать разумный коэффициент для облегчения GC (типа, 2 раза от суммы всех объектов — где-то минимум нормы, 3 раза — ему чуть полегче, и всё такое). А абсолютные цифры могут быть совершенно разные — где-то 200M хватает, а где-то и 30GB выжирало.

Долго стартует.

Чивооо? При чём тут скорость старта к этому методу?

Успехов в вылове ошибки на сервисе с нагрузкой хотя бы в 1000cpm, произошедшей 8-12 часов назад (но точно неизвестно когда). А еще лучше — навесом извне алерта с ее полным описанием.

Вы контекст-то на ходу не меняйте. Именно лог вылета по исключению — ищется и читается банально. Вот если не стоит задача «есть неизвестное исключение => дорабатываем, ставим явную защиту и т.п.», а надо понять картину в сумме — то да, может быть, и ELK надо вкручивать (хммм), но это уже другое.

А что это у вас за ошибка «неизвестно когда» — это вообще что-то совсем странное. Если вы знаете про ошибку, то как вы не знаете, когда она произошла? Нет, я могу себе представить, как до такого довели, но зачем доводить?

Что-то я такого не наблюдаю.

К-мон, давай любую известную утилиту или софтину на яве. Попробуем ее вместе запихнуть в 512 метров (порядка 300 за вычетом операционки) и дать нагрузку.
Я не говорю, что нельзя написать и посчитать хорошо, я о том что этого никто никогда почему-то не делает все сводится у «если оно падает на -Xmx512, поменяйте на -Xmx1024 или 2048».

то как вы не знаете, когда она произошла?

Может, потому что о ней сообщил клиент? Который, скажем, в Чикаго? Или вспомнил на следующий день (а то и в понедельник)?

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

Cassandra. Как раз под нагрузкой — поток асинхронных insert’ов около 5K/sec, ключи в основном разные. RSS прыгает 470-490M. VSZ 2.2GB, но не показателен, там уже libc’шный malloc способен отъесть гиг на таком старте. Подскажите, как получить данные именно про java heap size, я с ходу не нашёл.

Может, потому что о ней сообщил клиент? Который, скажем, в Чикаго? Или вспомнил на следующий день (а то и в понедельник)?

Так логи-то есть или нет? Если есть, в них ошибка не видна и надо её вычислять? Тогда это не stacktrace.

Cassandra.

Хмм...
«...a minimal production server requires at least 2 cores, and at least 8GB of RAM. Typical production servers have 8 or more cores and at least 32GB of RAM.»
Но это не очень хороший пример, т.к. Cassandra все-таки достаточно уникальный продукт и альтернативы особенно и нет.

Так логи-то есть или нет? Если есть, в них ошибка не видна и надо её вычислять?

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

OK, пусть так. Всё равно утверждение про рекурсивность кажется перебором. Если Elasticsearch будет глючить, есть множество других способов вести логи и находить в них нужные записи. Хотя я бы вообще тогда подумал избавиться от E :)

А указанные пожелания для Cassandra — удивляют — у нас таки на 1/5-1/10 от указанных работает беспроблемно. Хотя если требовать с неё миллионы операций в секунду — может, и нужны такие цифры :)

Cassandra все-таки достаточно уникальный продукт и альтернативы особенно и нет.

Scylla. Теоретически, дроп-ин замена кассандры (и чуть ли «тот же код, переписанный на плюсах» — что бы это не значило).

О, спасибо. Посмотрю на досуге.

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

Вообще же насчёт уникальности — если по фичам, то есть ещё как минимум Riak, CockroachDB...
я-то понял уникальность как в плане дизайна.

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

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

Неужели в других яп ситуация принципиально иная ?

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

одним компактным монолитом на сях

Но зачем обязательно монолит делать. Юзай shared либы.

Ну монолит это обычно не один экзешник, это набор либ в одном солюшине.

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

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

простые IO веб сервисы на сях — ололо. почему не на ассемблере?

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

прекрасный ответ

а какой еще может быть ответ, если есть монолит 7+ лет на php, в который уже давно не невозможно впилить ни одну фичу без боли?

хорошо, что бизнес хочет выйти из подобной ситуации.

А там точно проблема в монолите? Может таки в прокладке между стулом и компом? pbs.twimg.com/...​media/CBr9bynW8AErzIv.jpg Одна из любимых картинок про монолит вс микросервисы

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

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

да где угодно ее завести будет больно.

вы видели legacy на c++ хотя бы раз в жизни? причём на плюсах почти весь код — сразу легаси, если кодерок аутсорсный миддл

Я тащемта о монолите и говорил... Легаси на плюсах видеть увы довелось

вы видели legacy на c++ хотя бы раз в жизни

Тут надо смотреть опять же что за бизнесс задача. Если вы растянули плевую задачу на микросервисы, то примерно у вас картина такая: 5% код который делает реально чтото полезное, 95% кода который отвечает за интеграцию компонент, за решение перефирийных неожиданно возникших проблем. И в данном случае я бы действиетльно предпочел проект в 20 раз меньше который билдится и деплоится с одного солюшина, без вот того всего что упомянуто в стартовом посте.

почти весь код — сразу легаси

А в чем, вообще, проблема с легаси? Чем оно мешает?

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

Я видел много примеров, когда монолит разрезали на микросервисы и проект или умирал или улетал в невероятные эстимейты

«Много» — это сколько? Олсо, то, что у кого-то что-то не получается, не значит, что это что-то неприменимо. Это значит лишь то, что у того, кто попытался применить, не получилось.

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

Проекты не загибаются потому что они монолит или не монолит. Они загибаются, потому что финансирование заканчивается или потребность в проекте отпадает, или потому что какой-нибудь вася не написал хороший юнит тест и 200 человек упали на землю вместе с самолётом, например, и теперь компании, выпускающей проект, никто больше не поверит. Мой поинт в том, что техническая сторона проекта даже на 50% не кореллирует с его внешним жизненным циклом.

«Много» — это сколько? Олсо, то, что у кого-то что-то не получается, не значит, что это что-то неприменимо. Это значит лишь то, что у того, кто попытался применить, не получилось.

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

Проекты не загибаются потому что они монолит или не монолит. Они загибаются, потому что финансирование заканчивается или потребность в проекте отпадает, или потому что какой-нибудь вася не написал хороший юнит тест и 200 человек упали на землю вместе с самолётом, например, и теперь компании, выпускающей проект, никто больше не поверит.
Мой поинт в том, что техническая сторона проекта даже на 50% не кореллирует с его внешним жизненным циклом.

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

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

Это слишком абстрактно. Ваш вывод, что «монолит разрезали на микросервисы и проект или умирал или улетал в невероятные эстимейты» очень контекстный — какой проект, какой монолит, какая сложность, и миллион других условий от менеджмента до уровня девелоперов и архитекторов — всё это влияет на стоимость и эффорт. Может получиться так, что проект на микросервисах в конечном итоге будет гораздо легче сопровождать, чем продолжать жрать монолитный кактус.

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

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

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

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

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

Текущий мой проект. Три команды делало, на 500rps загибалося(по словам клиента).
Я переписал с использованием очередей и параллельных микросервисов — все работает, уже 10к rps и все ок.
когда как.

на такому ж обладнанні?

Почти. Второй SSD только добавлен, чтоб хранить результаты( 50GB в день генерит).
Справедливости ради, изначально там оборудование вида E5-2690 v4 dual(54 ядра по 2.6), 128Gb ram, SSD.

Текущий мой проект. Три команды делало, на 500rps загибалося

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

А фиг его знает. Мне не показывали результат.
Может и кривые, а что это меняет в принципе?

ну если это синхронный код на java с хибернейтом и кучей слоёв абстракций- то 500rps это просто героический подвиг

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

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

Ну и в C++ мало готовых асинхронных решений

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

всё-таки путь C++ это многопоточность

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

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

Хто заважає процесам так спілкуватись через шарену пам’ять?

А про синхронизацию забыл?
Ну а мне в данной задаче через сокет было быстрее написать и удобнее.
А так еще и пайпы можно вспомнить и MPI и т.п.

Так тими ж атоміками й синхронизуватись можна.

Никто не мешает тебе использовать многопроцессность

Я хочу использовать асинхронность, а не многопроцессность/многопоточность. С точки зрения того же Linux разница между процессом и потоком только во флагах, которые передаются в метод clone, так что это во многом синонимы.

Ну а если потоки/процессы работают с одной памятью, то атомики и отсутствие блокировок могут никак не помочь. Из недавнего опыта два потока — в полтора раза медленнее, восемь потоков — в четыре раза медленнее даже с отключённой синхронизацией. Всё съедает обновление кэшей на ядрах, MESI/MOESI, ...

в нас сінйори пишуть в спеках, що мікросервіси ацтой, 1 мікросервіс = 1 процес, жруть, сцуко докуя пам"яті, том тре пихать в моноліт, але з тредами !!!

Позвольте, но это же будет не прикольно! ;)

С софтом то все понятно. Лучше обсудить ухудшение технологий велосипедостроения.

Лет 30-40 назад выпускали велосипеды с планетарными втулками.
Эта такая втулка, где весь механизм переключения передач + тормоз заключен в герметичном корпусе. Итог — планетарные втулки выхаживали до 50 тыс (!) км без вмешательства, а само по себе переключение передач фактически работало как часы десятилетиями. Из-за того, что цепь не скакала по звездам, цепь также изнашивалась очень медленно, она не растягивалась и не убивала звезды.
Также теже велосипеды оснащались усиленными ободами, хорошими стальными спицами и ременной передачей, что фактически делало те велосипеды «вечными».

Что принес прогресс ? Почти все велосипеды сегодня оснащаются перекидками, обода слегка усиленные а то и одинарные, подшипники почти всегда насыпные еще и с мягкого метала.
Но главное это перекидка, это незакрытый механизм, где цепь всегда наискосок, а старт велосипеда идет всегда в натяг цепи, поскольку передачи стоя на месте переключать нельзя. И
того — регламентная рекомендованная замена цепи каждые 1-2 тыс км, поскольку она растягивается, каждые 2-3 тыс км замена звезд, поскольку растянутая цепь убивает звезды +
постоянные ТО с настройкой этого механизма, поскольку пыль грязь и вода быстро выводит из строя достаточно точный механизм.

Тоесть имеем ситуацию, что еще 30-40 лет назад индустрия УЖЕ делала велосипеды, которые могли легко выходить по 50 тыс км и выше в очень плохих условиях и были практически неубиваемы.
Проблема была одна — на таких велосипедах было тяжело заработать.

Нагуглив і ніби і тепер такі є

Есть, но они очень не массового выпуска.

Планетарки есть, бери-нехочу, у той же shimano. Но они неустойчевы к вибрациям и ударам. Потому на mtb их не ставят, а для шоссе они слишком тяжелы. Было бы рентабельно — давно бы появились в более массовом формате. Технологии велосипедостроения шагают весьма уверенно. Другое дело, что маркетинг тоже не стоит на месте: чтобы разобрать, например, вилку lefty (а делать это рекомендуется для сервиса 1-2 раза в сезон) — нужен специальный проприетарный инструмент, который можно приобрести только пройдя сертификацию, колличество мест на которую ограничено. Или вот взять тормоза от shimano, всем хороши, но отсутствие o-ring на мастер-цилиндре уменьшает срок их службы до 1-2 лет. Хотя велосипед, как и пк — расходник. Но надо отдать должное: сервис велосипедов сильно лучше сервиса ноутбукав (хотя всё ещё не так хорош, как сервис автомобилей).

обода слегка усиленные а то и одинарные

Посмотри на покрышки zipp «moto» — иногда одинарность ободов это скорее плюс, чем минус, всё зависит от технологии.

почти всегда насыпные

то же самое, насыпные подшибники от shimano топовых линеек хороши как в сервисе, так и в весе.

делала велосипеды, которые могли легко выходить по 50 тыс км

ну ты и сейчас можешь проехать 50Ккм без обслуживания, а потом просто выбросить трансмиссию. И цепь проживет: современные 11-12-скоростные цепи лучше по качеству чем 7-10-скоростные. Но качество езды будет именно как на тех дедовских велосипедах, соответственно.

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

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

Ну, вот, например, чем не вариант: budnitzbicycles.com/technology (тут даже рубашки, походу, вечные).

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

Планетарки есть, бери-нехочу, у той же shimano. Но они неустойчевы к вибрациям и ударам.

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

то же самое, насыпные подшибники от shimano топовых линеек хороши как в сервисе, так и в весе.

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

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

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

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

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

Они устойчивы

Нiт, так же как и карданная передача. Сочленение шестерня-шестерня плохо реагирует на регулярные удары, неизбежные при прыжках на mtb. Перекидки же, напротив, крайне гибки, и эволюционируют, чтобы трястись и выпирать меньше (shadow, а потом и shadow+ в shimano, и аналогичные им в sram, которые уже перекочевали из топовых линеек в рабоче-крестьянский deore).

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

Вы таки видите профит от облегчения станка? А вот −100грамм неподрессоренной массы это как гантели с ног снять.

ценят старые простые и надежные велы

Если не на трейлах и трассах/треках (где можно и over $10K запросто увидеть), то я почему-то в Берлине и Вене наблюдал в 90% случаев рассыпающиеся от ржавчины китай-велы на восьмерящих ободах. Не совсем ашан, может, но близко. Что-то худо-бедно уровня бюджетного cube видел всего пару раз.

Нiт, так же как и карданная передача. Сочленение шестерня-шестерня плохо реагирует на регулярные удары, неизбежные при прыжках на mtb.
Вы таки видите профит от облегчения станка? А вот —100грамм неподрессоренной массы это как гантели с ног снять.

100 грамм для колеса это вообще ниочем. Одна покрышка может до килограмма весить.
К томуже, накат у промподшипника будет явно лучше, что важнее чем вес.

Сочленение шестерня-шестерня плохо реагирует на регулярные удары, неизбежные при прыжках на mtb.

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

100 грамм для колеса это вообще ниочем. Одна покрышка может до килограмма весить.

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

100 грамм для колеса это вообще ниочем

Це взагалі то дофіга. Я завжди виберу −100 г з колеса ніж −500 г з рами.

+100грам для туристического(идущего ровно по дороге) сильно предпочтительнее прокола.
У меня есть и тяжелые и легкие покрышки(вел легкий), обычно езжу на тяжелых marathon supreme 29(0.7 только покрышки), ибо нет времени на перебортовки колес. а герметик — те же яйца в профиль(вес).

15 мин перебортовка с заклейкой. Но если на соревнованиях ты ездишь, то там выгоднее просто колесо за 10 сек перекинуть новое или на другой вел твой пересесть за 3 сек (за тобой едет машина с запасными велами).

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

Весит 15-30 грамм ремккомплект. Шланг нафиг не упал для этих микронасосов. Посмотри на ютубе, как ими пользоваться, если сам не додумался.

Угу. Только нужен хотя бы карман или сумка, чтоб его возить. Нафиг нужно.
Еще раз, при неагресивном крос-кантри или в городе проще взять покрышки с защитой или кевларовую ленту.
У меня последний пробой на этих покрышках был в 2010м году. Гвоздем с круглой шляпкой, обивочным.

хорошо хоть не на порнхаб послал. Все таки влияет С++ на тестостерон

Про порнохаб вспомнил ты, так что это не С++, а Java.

точно, благодаря Java и физо

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

Ага,ага. А если мороз? А если дождь? А если вся поездка 30 минут
Вобщем если не горы, то стоят тяжелые Supreme, насос можно не возить(ну кроме Одессы осенью, колючки пробивают все).

А если мороз

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

А если дождь

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

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

Это комент был про перебортовать.
А так то в мороз у меня чегото гидравлика работает.
В разы меньше ... НУЛЯ? не, ну если так, то супер. Только я пробывал как бы.

В разы меньше моего опыта на камерах, в т.ч. с антипрокольными покрышками.
Гидравлика до −15 где-то работает более-мение, да и то зависит, масло или дот. Хотя по морозу антипрокольная жидкость — тоже плохая идея.

Не завжди є можливість мати додаткові колеса (бо це іноді $$1000-2000 додаткових грошей) і така розкіш як машина підтримки любителям не доступна. А на тріатлонах так взагалі заборонена.

Я з собою просто маю додаткову трубку в сумочці під сідлом і пару CO2 картриджів для швидкої зарядки. В залежності від того наскільки захекався поміняти трубку займе від 3 до 5 хвилин. Це багато, але серед аматорів, та ще і на довгих дистанціях має сенс продовжувати гонку.

Возити з собою насос та набір для заклеювання? Можна, але у вело-подорожах, а не на тренуваннях та змаганнях.

а не на тренуваннях та змаганнях.

Там за тобой с запасными велосипедами машина едет.

Це коли ти профі і заробляєш цим на життя. За мною, на жаль, машина з механіком і запасними колесами не їздить.

Вообще насыпные подшипники используют только в велосипедах

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

В шимано почти везде во втулках — насыпные. И честно говоря, проблем с ними нет даже у меня(вес 120 и прыжки).

Лет 30-40 назад выпускали велосипеды с планетарными втулками.

И снова ты отсал от жизни.

Куча ща велосипедов с планетарными фтулками. Прокатные уличные велосипеды вообще все 100% таких, какраз по причине износоустойчивости.

xt.ht/phpbb/viewforum.php?f=76
veliki.com.ua/goods_PRIDE_Bullet.htm
veliki.com.ua/goods_Winora_Aruba.htm

Они не-массового спроса, с выпуском всё в порядке, с доступностью тоже.
Ременную передачу может прийдется искать. Но они есть.

За последние 30-40 там прогресс очень существенный. 40 лет назад были 3-ки, 4-ки и 5-ки. Под велы типа Украины, больше никуда. Современные Альфины за недорого заменяют перекидку практически без ограничений для спокойного катания.

См алсо, pinion.eu/en/p-line/p1-18-gearbox

Не знаю, як на мене то цілком собі прогрес. Сам почав кататися на алюмінієвій рамі з Shimano 105. Потім карбонова рама за доступну ціну, потім Ulterga... і так крок за кроком покращувалися технології що я їх використовував за не божевільні гроші чесно кажучи. Зараз пересів на Ultegra Di2, карбонові колеса, гідравлічні гальма — прогрес же! І при цьому велосипеди стають все легшими, затяжні підйоми та довгі мили все легше долати.

довгі мили все легше долати.

До бабусі в село за молоком можна зганяти?

Та можна, у мене на роботу в одну сторону 25-30 км виходить. Єдине що кошик для бутилька молока нема куди прикрутити.

Та ну, крутите на роботу 25км? Навіть якщо так, в Укр це нереально, ні доріжок, на дорогах ями і небезпечно.

Ось буквально сьогодні з ранку — www.strava.com/activities/2441780117. З роботи той самий маршрут мабуть. А коли працюю в офісі в Сіетлі то 34 км виходить в одну сторону.

>>затяжні підйоми та довгі мили все легше долати
це ти сильнішим стаєш

Це теж, але коли пересідаєш на новий байк то різницю все одно чути. Навіть різний за складом карбон рами помітно відрізняється на дорозі (підйоми, спуски, прискорення), компоненти, колеса — все це впливає.

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

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

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

Мы не в плановой экономике живём. Shimano, SRAM и другие делают те переключатели и в том объеме, который покупают. Ни шага в сторону.
Жизнь стала динамичнее и менее привязана к одной локации. Поэтому ценность вещи на века уступает ценности эмоциям и хочу-вот-эту-блестящую-штуку. Т.е. условия жизни влияют на покупателя, а покупатель определяет производство.

У меня ща чаще появляется желание -«хочу уепать

эту-блестящую-штуку

и купить вещь которая прослужит мне тихо и мирно нескольк лет не ипя мозги апдейтами на новые перделки для армии домохозяек и малолеток»

купить вещь которая прослужит мне тихо и мирно нескольк лет

Для деяких речей — так. Для інших (як компоненти вела) особисто я хочу щоб постійно щось було новіше і можливо навіть краще, щоб я міг апгрейдити свій вел і отримувати свою порцію щастя. А комусь телефони з новими фішками ледь не щороку давай, комусь ще — машини, і так далі.

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

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

Згоден. Я про те саме і кажу — в більшості випадків для абсолютної більшості товарів люди хочуть щоб надійно, зручно і на довго. Але все одно у кожного щось таке знайдеться що хотілося б оновлювати постійно. І серед велосипедистів таких достатньо щоб час від часу з’являлися покращення на ринку.

Я не фанат Apple, но вот живой контрпример: iPhone 6s. Пережил обновления iOS с 9 по 12ю, кучу обновлений софта, и до сих пор (тьфу-тьфу) не окирпичился, не тормозит и не глючит.

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

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

Так, котимось. Раніше в нас була мотика і було нам чудово. А зараз трактори, комбайни. І хто придумує цю всю складність!

Угу, в 1900м году придумали трактор который проработал без особого ремонта 50 лет. В 1950 его заменили новой моделью трактора которая проработала 20 лет и была заменена, на новый трактор, который проработал 10 лет, успешно был ушатан и чтобы не капиталить ушел на запчасти. В следующем месяце нам из китая привезут новый трактор .... ой подождите, пока его везли в контейнере у него уже отвалилась фара, помялся бампер из фольги и глюканул бортовой компьютер .....

Трактор треба міняти кожні 3 роки! Тільки так забезпечимо Прогрес! Макбуки он, вже можна щороку змінювати.

І підставку під монітор за штуку баксів.

в 1900м году придумали трактор который проработал без особого ремонта 50 лет.

Дивно, чому ж тоді зараз ніхто не хоче на такому чудовому тракторі працювати? Може справа в тому що наступне вдосконалення в тракторобудуванні якраз і сталося лише через 50 років, а зараз такі трапляються по кілька разів на рік?

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

лол

Вот чувак который один из отцов основателей ООП покаялся, стал на путь истинный и решил написать всю операционку в 20 тыс строк кода,
гуглите keyword STEPS.
По сути его эксперимент доказывает, что оверхед кода у современных проектов достигает 99 % и выше

Это не совсем оверхед. Это код для разных нюансов в основном. Известно же, что 20% кода делают основную работу, а 80% остальных для всего остального, но без него работать не будет.

Вот чтобы написать прототип ты фактически пишешь только 20% необходимого кода. А вот чтобы сделать продукт дописываешь еще 80%.

20% кода генерирует 80% багов :-))) Закон Мерфи-Паретто

И это тоже. Отсюда после море кода и еще больший океан костылей.

Windows XP это 40 млн строк кода. 20% от них это 8 млн строк. А 20 тыс от 8 млн это 0.25% )

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

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

Т.е шаг влево, вправо от того, что он написал — расстрел?
Как академическая игрушка пойдет, но не более.

Я как понял он хочет показать best practices. Когда-то с ООП у него получилось, может и сейчас получится. Но уже вряд-ли получится, поскольку индустрия стала плохо управляемой.

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

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

Вот расскажи, что у него с дровами для всего зоопарка железа, а с файловыми системами? CUDA и OpenCL он поддерживает? AVX, SSE, Neon и остальной зоопарк?
А зоопарк всевозможных платок для всевозможнейшей хрени, что клала с высокой колокольни на стандарты.
Это так с самого верху вопросы.

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

И стоить в 2 раза дороже.
И покупать новую железку при обновлении ОС.

1. Стоить будет также, только для очень дешёвых девайсов разница будет заметна.
2. Новая ОСь не должна затрагивать старые девайсы. Хотя сам девайс может обновить свое ПО с помощью ОС.
3. Больше нет проблем что не нашел драйвера для железки / ось не умеет с этой железякой работать

Ну в S/360...z/Series с её канальной подсистемой где-то так и получается: даём команду «читать» и пусть оно само по себе отрабатывает остальное.

Но всё равно остаются особенности, которые не уложить в эту схему.

У него вроде была идея что сам девайс должен внутри содержать эти дрова.

Хорошая идея. И я ее реализовал.

Вот и пришли к академичности.

Ну эта идея сейчас реализовуется через Service Bus. Но это оправдано в больших системах где зависимости и версионность настоящий ад.

Эта идея реализуется через Actors

Service Bus, Actors, Window Funcs в Win32 и др. это реализации все тойже парадигмы обмена сообщениями.

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

Времени это займёт где-то часов до 80.

Это зависит от от знаний студента.

С учётом библиотек, я думаю, что 80% кода (не удивлюсть и цифре 95% в отдельнх случаях) никогда не будет вызвано вообще (мёртвые ветки if, переопределённые виртуальные функции, ... Из оставшихся 20% да, 4% делают основную работу, 16% для всего остального.

А чего оно умеет?
Есть, к примеру, uC-OS, но оно тебе не линукс.

Переходи на go lang в чистый бекэнд
вот где штабильность прямо ***ительная, выучишь один раз — будешь пердолить сервисы годами.
( ок ок только не суйся в дево песьий зоопарк, там тебя кондратий хватит)

Как только перестаешь учится новому, пусть это новое и выбросят на другой день, становишься отработанным материалом. Never give up! Resist and bite! ( как в песне поется ) Не могу сказать что меня гложет ностальгия по PL, перфокартам, ламповым АЛУ, и памяти на магнитных доменах. Сейчас в IT всё намного интереснее чем 40 лет назад, ИМХО.

Це правда і загалом. Завжди розумом треба залишатися молодим.

Я б не сказал что стало интереснее. Ничего нового за 60 лет. Все эти надстройки и «улучшения» потому и быстро устаревают что нет существенной новизны.

Ну в какой-то мере это верно, в том смысле, что теория была развита уже довольно давно. Практические новшества были связаны исключительно с ростом мощностей процессоров и обьемов памяти, т.е. в основном развитие технологий в 80-90х было обусловлено экспоненциальным ростом мощностей.
Потом это замедлилось, сейчас практически остановилось, десктоп разработка стабилизировалось и ничего не меняется лет 10 уже, и началось — а давайте распределенные вычисления, а давайте вычисления перенесем в облако, а давайте сервисами(микро), а давайте в докер, а давайте на фронте будем делать все десятком равнозначных способов. Отсюда и ощущение болота.
Я лично вижу путь такой — сейчас до упора будут выносить вычисления на корпоративные облака, вплоть до операционных систем.
Будут продолжать автоматизировать все что автоматизируется за реалистичное количество ресурсов.
Ну и все.
Дальше только ждать скачка в мощностях..типа всяких вычислений на квантовых компьютерах, а так только банальное ковыряние из пустого в порожнее.

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

Здесь тоже ничего нового.

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

А вот тут есть как раз проблема о которой я и говорю.

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

Квантовые вычисления это вообще другая тема.

Все так и есть. 20 лет назад если нужно было решить задачу в коде, то решали ее в терминах заюзать if for while. Сейчас тоже самое решают в терминах фреймворк 1, фреймворк 2, фабрика классов 3,4,5.
При этом кричат это реюзабельность кода, но в итоге в 90% все это говно при первой возможности переписывается.
В итоге код в проекте выглядит почти как в том меме, десять менеджеров и один Вася с лопатой.

Бубен, чот ты отстал от жизни,

Сейчас тоже самое решают в терминах фреймворк 1, фреймворк 2, фабрика классов 3,4,5.

это было 10 лет назад.

Щас в моде минимализм Го с минимум фреимворков, где снова решают задачу в терминах

if for while

даже если нужно тыщи строк копипейтить.

короче все покругу ходит каждые 10 лет.

Щас в моде минимализм Го с минимум фреимворков, где снова решают задачу в терминах
if for while

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

Даж в жабе. В моде микросервисы и спринг-бут, который решает 95% архитектурных вопросов, и 100500 фабрик уже никто не городит.

Якщо задовбуйте — просто уникайте занадто наближених до фронтенда галузей. Коли я починав працювати, то встиг за півроку на першій роботі полабати під PalmOS, Symbian, WinMobile — всі ці платформи наразі мертві. Чудово розширює круговид, це корисно, коли в тебе рік досвіду, коли десять — вже трішки замахує. Тому з часом пересів на бекенд, до поближче до лінухи, який народився (якщо рахувати зі світом юніха) до мого народження і, мабуть, мене ще й переживе.

Думаю, Вы переживёте unix time)

Хтозна: швидше за все до 2038 року 64 біта буде вже всюди

У Вас меркантильный интерес. Вам было весело на деньги заказчика переключаться на разные задачи в течение рабочего дня. То контроллер запилить, то запрос в базу подоптимизировать, то на страничку менюшку прикрутить. А теперь приходится быть винтиком в большом и страшном механизме. Выучил фреймворк — работаешь только с ним изо дня в день, пока не появится другой. Скучно. Выгорание. И т.д.
Зато, как любой винтик, Вас можно заменить другим точно таким же, который выучил этот же фреймворк.
И самое забавное — это «западло» Вам приготовили те самые «крутые перцы», чьи портреты у Вас в комнате, и чьи автографы Вы брали на конференциях, чьи книги Вы перечитали пять раз )))

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

SPA дозволило мені не торкатися фронта

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

Ну а еще есть фундаментальные знания... которые часто нафиг не востребованы: не нужна ни дедукция, ни индукция — давай продукцию! Но уж если нужны, то практически не устаревают — из личного примера: освоив матан для quantitative finance мне было нетрудно переключиться на deep learning (а сейчас, кстати, опять на quantitative finance).

*Но не все. На той лекции я привел в контрпример Интел, причем тогда еще не знал их девиза «изменяйся или умри».

P.S.

а теперь подавай докер,

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

Підтримую. Теж це пригнічує.

А именно: Наши технологии все сложнее и сложнее! Освоить их все труднее и труднее.

Хіба це погано? Хіба погано те, що замінити вас студентиком не вийде, і доводиться платити багато доларів щоб утримати? Колись найбагатшими були торговці ринків, що возили продукцію ззакордону. Вони буквально купалися в грошах. Але так як це була не важка праця без особливих знань, через декілька років халява скінчилася. Треба молитися аби айті як мінімум не ставало легшим, а як максимум ускладнювалося.

имхо все довольно и банально просто:
1. лет так примерно по моим наблюдениям 7, последних имеем наплыв людей которые вообще не в теме были, а ставли в теме после «вайти курсорв». Это привлекает всяких самоучек — учителей, стоматологов, врачей. КОторые пилят инфраструктуру, проекты и прочее, левой ногой. Часть из них когда то потом становится пристойными спецами, но кто то разгребает то гавно, которое они оставили после себя в течении отрезка времени «после курсов» и до «реальный технарь, спец».
2. Дикое желание заработать на IT — в итоге имеем зоопарк технологий, колес, фреймворков, библиотек.
3. Тенденция — чем моднее, тем лучше. Отсюда развитие так званных «облачных технологий», девопс, хуепс и прочие бредни, абы платили, а мы придумаем след. поколение модной хуйни — сре например.
Имхо тенденция только будет только ухудшаться.

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

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

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

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

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

Я сильно підозрюю, що ми спостерігаємо несвідомий пошук людством якоїсь навіть не ефективної, а хоча б життєздатної парадигми системобудування, як процесу. Системобудування в загальному смислі. Цей пошук йде у добре знайомий нам з біологічної еволюції спосіб рандомних спроб та помилок. Тулзи/фреймворки виникають, мутують, форкаються, конкурують та виздихують пачками. Окремі вдалі концепції виживають та масово нерестяться, породжуючи кодли нащадків, жахливих, як формально, так і в імплементації, після чого цикл повторюється. Деякі базові рішення виявляються напрочуд життєздатними, як таргани чи нікси, або тцпіп, або 3-тієр, або рсубд чи CLI. Інші або здихають у корчах миттєво, або вкорінюються в вузькоспеціалізованих еконішах, або провалюються у потенційні ями, з яких вже нема жодного перспективного напрямку розвитку.

Всі ці фреймворки, мови, парадигми, концепції, що плодяться без ліку, мають на меті не загальне щастя чи розумне-добре-вічне, а виключно перемогу над конкурентами у доступі до ресурсів у вигляді CFO/CTO. Як вірусам байдуже, що буде з організмом, що вчасно не знищив збудників хайпу, так і трендовим технологіям байдуже, чи виживе ентерпрайз, який вони інфікують. Їхня задача — урвать свій шматок ресурсів у безжалісній війні між- та внутривидової конкуренції. Це метаеволюція, рушієм якої є зовсім не комфорт девелоперів, не КРІ і не SLA, не котування шерів. Технології живуть власним життям, строго за Докінзом, а ІТ та ітшники — це субстрат, в якому вони живуть.

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

Шота в этом есть, реально. Если создателей этого всего трактовать как прародителей, а евангелистов и прочих форсеров этих новых технологий — как «возбудителей» — тогда все части паззла сходятся воедино.

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

А, вы тоже заметили образование цифровых недо-амеб? Броуновское движение обеспечивается кодерами, которые боятся пару раз написать один и тот же кусок кода и вместо этого этот кусок кода называют функцией и выносят из внешней функции. Функции и процедуры зло. Ну и что мне потом менять по всему коду плюс на минус в похожих кусках кода? Зато я не буду порождать цифровые сине-гнойные палочки. Модули страшное зло. Объекты это властелины страшного зла. Фабрики объектов — блин, мне стало страшно.

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

Это лейкоциты в коде. Цифровые сине-гнойные палочки — как раз и есть повторяющиеся куски. Задача лейкоцитов — купировать их.

У кодеров есть ограничения, потому что они люди и у них человеческие мозги. Эти мозги иногда пытаются структурировать вообще все. Не понимая, что структура берется только один раз, уже с давно работающего проекта. Который создавался послойно, заплата на заплате, костыль на костыле. Все эти костыли и заплаты как раз и формируют структуру такой какая оно есть. Потом приходит кто-то и говорит: «ух ты! я где-то уже видел подобное. ну все — это паттерн» Паттерн проектирования. Но это просто так наслоилось случайно. Мечта повторить остается мечтой. Новый проект порождает новые костыли и заплаты. С планирования не получается начинать. Всегда с реализации конкретной. Всегда просто кинуть слой и посмотреть на работу. Потом добавить еще слой. И чем проще — тем удобнее и быстрее. Отсюда вывод: сначала все делать в нативе — работающую модель. На ней править юзабилити. А потом рефакторить во фреймворки и другие чудеса современного закрытия информации от непосвященных. Нет удобства в сложности. Зато может появиться враждебная людям жизнь, а может и разум. Когда все фреймворки объединятся против людей. И начнут писать собственные фреймворки. И заставлять людей учить их.

Власне, нам байдуже, чи еволюція у ретроспективі була наслідком початкового розумного дизайну, панспермічної інвазії, а чи зовсім локального статвибрику. Нас цікавить лише подальший розвиток еволюції, а в усіх випадках він строго тотожній. В гуманітарному смислі питання «як все почалося?» має певний сенс і певний інтерес, але у чисто прагматичному ключі нас має цікавити лише одне: якого розміру клізми потребує поцієнт.

Технології живуть власним життям, строго за Докінзом, а ІТ та ітшники — це субстрат, в якому вони живуть.

і засірают міски

з.п. в манюпаса вже як при пізньому ВФЯ, але ще не як у 2007 при ЮВА

а які вони тоді були ?

окуєннi, правда не ойті,
на ойтішніків дивилися як на задрищів, а не каралєй жизні

Тенденция — чем моднее, тем лучше. Отсюда развитие так званных «облачных технологий», девопс, хуепс и прочие бредни

рукалицо.жпг

:) обожаю такие коммены. Обидно за девопс или сре ?

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

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

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

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

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

Я в IT немного дольше, и само появление Java воспринялось как ухудшение технологий :)

когда жаба появилась только, с нее плевались страшно (большинство ентерпрайз программеров в то время имели бэкграунд в C/C++). глюкавая, тормозная, ненадежная, жрущая память. расплата за сборку мусора и безопасные указатели.

Ті хто робили софт під різні платформи все ж таки мали сподівання що Write once, run anywhere буде правдою. Але через кілька років стало зрозуміло «вам так не буде».

Ну с точки зрения бак-энду жаба таки максимально приближаеться к этому мотто.

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

Нефига. Берешь какойто старый код, вот к примеру vtiger connector for asterisk. Пытаешься его запустить — а нет, не работает он в текущей джаве. ВООБЩЕ. А исходники походу потеряли ;) Так тоже бывает.

Это код, или откомпилированый джарник ?

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

jar конечно. Код потеряли. Случайно ;)
А под виндой оно, кстати, вообще никогда не работало.

так этого никто не обыщал. куча легаси энтерпрайза сидит на 8,7,6 а в особо упоротых случаях на более ранних версиях жвм не спроста. Тут даж наоборот непонятно юзает ли кто 9+ в проде.

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

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

в контейнері, а контейнер в клауді

в сундуке — заяц, в зайце — утка, в утке — яйцо

Игла в яйце, яйцо в утке, утка в зайце, заяц в ШОКЕ!

Но бэкэенд очень часто принадлежит одному владельцу

Очень часто != всегда.

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

Ага, у одного MS SQL, у другого Oracle... И в результате получается продукт, который не может использовать преимущества платформ (потому что раз это преимущество, значит оно где-то да отсутствует), и не может перейти линию самого худшего всех платформ.

плюсовоки так досихпор и думают.

А что это не так? Write once, run everywhere — булшит. С выходом 9-й джавы с совместимостью кранты и дальше все хуже. Вчера скачал Бамбу, установил, а он не работает под JDK 11. Пришлось ставить 8-ю Джаву

Та там і без дев’ятої... Як плюсовик, я з нею стикався перш за все через JNI на Android — і там це тупо окремий світ. На десктопі з іншого боку я з нею стикався як юзер. Я хз як там воно влаштоване в середині, але що Eclipse глюкає на OpenJDK й більш менш працює на колишній санівській яві — факт.

Скоро майкрософт випустить реальний кросплатформ з уніфікованою апішкою під мобайл, десктоп, веб.

Майкрософт это каждый год делает — все никак.

Да, да. Мы верим в них.

З.Ы. Только вот уже линкедин говнять начали. На мобиле требует апдейта, а при попытке апдейта грит, что телефон уже не подход.
Похоже он в ближайшие пару лет отправиться в сплав по Днепру, как и скайп.

скайп фор бузинесс вічно живий

мазохистов в мире много

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

для фронта — jQuery

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

а какой тогда фронт фреимворк должен быть стандартом ?

А зачем один стандарт? Мне нравится Ember.js, тем что много есть из коробки и задает некоторую структуру проекта. Другим нравится vue/react, за противоположные качества. Есть ещё требования к проекту и какой-то проще будет делать на определенном фреймворке.

А жквери вообще не фреймворк, это библиотека для работы с DOM и ajax. Как раз в Ember.js он доступен из коробки по умолчанию (хотя вроде бы можно вырезать при желании) и вполне успешно можно использовать в отдельных компонентах.

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

та ладно, в джава мире спринг с хибернейтом 100 лет как стандарт — зарплаті не падают.

И никакого докера!

Неистово плюсую!

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

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

А что не так с микросервисами?
может быть вы не умеете их готовить?

А что не так с микросервисами?

Да и про докер спорно.
Это разве что с точки зрения кодера, когда горизонт видимости ограничен коммитом в гит, а что там дальше — «черная магия».

докер к микросервисам ортогонален.

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

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

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

что тут дает применение контейнеров?

Думаю Вам нужно почитать немного о том что такое контейнеры и как они работают.
Контейнеры — не являются лишней прослойкой. Контейнеры (докер)- это просто библиотека/обертка предоставляющая удобный доступ к функциям — namespaces, cgroups,

и что тут дает применение контейнеров?

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

Для пхп сайта на 10 пользователей, который апдейтиться раз в год, это все конешно не нужно.

...серебрянная пуля на данный момент для большинства веб/мобайл/ML приложений...
...большинство стартапов умирают в первый год существования...

Совпадение? Не думаю!

«Если автоматизировать бардак, то получится автоматизированный бардак» © Как меня учили в 90-х годах.

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

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

Ось такий російський віршик, його можна легко переписати про побудову сайту на JS, PHP

Мы с братишкою моим
Птицам домик мастерим.
Небольшой, опрятный внешне.
Называется скворечник.
Окон нет. Есть только лаз,
Да жердинка — напоказ.
Прилетят весной скворцы,
Скажут: «Ай, да молодцы!»
Будет радость и веселье,
Птицы справят новоселье,
Натаскают пух, солому.
К своему привыкнут дому.
Будем с братом наблюдать,
Как птенцы начнут летать.
А потом сойдутся в стаю
И простятся, улетая.

chto-takoe-lyubov.net/stixi-pro-skvorechnik

Почему у меня в голове этот стишок прочитался голосом братишки из зелёного слоника?

чем сложнее технология тем больше работы тем больше зарплаты програмистов и их востребованность. Поэтому никто не будет писать на jquery если можно написать на ангуляре или реакте.
Конечному пользаку конечно пофиг на чем там написано, главное впарить заказчику что если его сайт не будет иметь SPA страницы и web APi то он будет выглядеть как лох.

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

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

пять програмистов на яваскрипте там где справится один на PHP

Там где справится один на пхп, справится один на жс.

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

В ноде нет никакой сложности в наше время, кроме понимания асинхронности и возможно замыканий. Во всем остальном все равно на чем писать АПИ — на пхп или на жс.

Там где справится один на пхп, справится один на жс.

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

Во всем остальном все равно на чем писать .АПИ — на пхп или на ж

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

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

Любому более-менее серьёзному приложению необходима тонкая настройка сервера, а не шаред-хостинг.

они заняты своим бизнесом

Каким например? Очень интересно, какой бизнес такой в айти не требует вложений в разработку собственно софта

Очень интересно, какой бизнес такой в айти не требует вложений в разработку собственно софта

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

Кому-то и сайт-визитка «проект»

то он будет выглядеть как лох.

:)
Вот и вся мотивация

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

Grunt умер года лет 5 назад, а он его все выучить не может.

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

а зачем учить то что умрет через пару лет как только на него пройдет мода? человек выучил бы grunt а тут уже грунт ацтой есть гораздо более крутой Gulp. А зачем учить галп если уже есть покруче и помоднее вебпак? А зачем учить вебпак который нужен как и все эти галпы и грунты только чтобы разруливать проблемы возникшие исключительно изза яваскриптового безумия захлеснувшего веб разработку.
Мода на это может так эе пройти как прошла например мода на nopsql решения когда оказалось что даже обратная сортировка результата на серьезных данных уже проблема. Сам недавно переводил решение с CouchDB на MSSQL после идиотов которые думают не головой а тем что в интернете рассказывают Соловьевы и Киселевы от IT.

Это ты объявил, что мода на nosql прошла?

Я так не думаю.
Киселев от айти

От как сейчас помню волну статей на хабре в 2012-2013 гг, я тогда еще ходил туда, как все поливало овном эту монгу и подобные nosql, так что да, мода прошла, даже прошла волна когда было модно ее ругать. А через пару лет могда добавила джойны ;-)

та все еще есть проблема, продалжают пихать монги с каучбейзами с касандрами и почемуто ожидаю от них «„бесплатного“» оракла.

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

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

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

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

Давайте-ка ссылочку на цитатку.
Вы переврали его слова.

Та чого ж. Все так і було. Правду пише.

То доволі давно було, чувак перейшов на го, потім повернувся на ноду і зараз іншу фігню розробляє, діно якщо не помиляюсь, що є щось типу ноди без її проблем і з типами(ніби typescript юзається)

Просто всі то сприйняли як от, нода вмерла, а людині потрібно було щось змінити, скільки можна над одним проектом працювати

nosql решения хорошо справляются в своей нише где им и место

Да никто не знает где их ниша и где их место.

Гонзо-програмування — наше все!

В случае с Grunt-Gulp-Webpack это не мода, а просто выход лучших инструментов, которые вытеснили старые. Для большинства задач их знать нужно на уровне «знаю, что оно делает, могу добавить лоадер, найдя решение на StackOverflow». Так что, если человек не способен в таком разобраться, он или даже не пробует это делать, или дебил.

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

Сидеть на жопе ровно и хвататься за условный jQuery 14 лет — идиотизм, как и бросаться учить всё подряд. Я вам открою секрет — не обязательно прям всё-всё знать, чтобы работать в современном мире разработки на хорошем уровне.

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

Отличие в том что фронтенд фреймворки не решают никаких задач.
Большинство приложений (кроме каких нибудь браузерных игр) сводятся к тому чтобы взять у пользака данные положить их в БД а затем по запросу выдать в отфильтрованнгм и форматированом виже. С этим вполне справляется бекенд.
Перенос логики и рендеринга на фронтенд только лишняя работа поскольку бекенд все равно приходится писать.
С точки зрения пользователя тоже никаких преимуществ. В начале нулевых помню была мода на всякие флешовые заставки и прочее но ща интернет прост рабочий инструмент и прыгающая и дергающаяся за каждым движением мыши страница только раздражает не говоря уже о тормозах браузеров пытающихся перелопатить мегабайты скрипта в отличие от бекенда который рендерит на быстрых и дешевых серверных решениях
Я как то пытался разобратся в яваскриптовых фреймворках с точки зрения того какие преимущества это даст в моих проектах мне как разрабу и пользователям сайтов и так и не нашел где мне это прикрутить с пользой — jquery и bootstrap закрывают все вопросы с головой. Конечно нужен верстальщик и дизайнер но это и так нужно по любому.
Понятно что для вас это работа и зарплата но я подхожу к вопросу как технарь с многолетним опытом программирования и практический складом ума.
Недавно мой заказчик начитавшись инета решил блеснуть умом и сказал заменить таблицы на сайте на Datatable мол там же уже есть и пагинация и сортировка и экспорт ничего не надо програмировать. В результате страница загружалась 4 минуты пока яваскрипт перелопачивал тысячи строк данных. А на мобиле даже комбики с select2 тупят

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

Это означает лишь, что или вы так и не поняли их преимуществ, или у вас такие проекты, что они действительно излишни. Так что не стоит экстраполировать своё мнение на всё разнообразие задач и вызовов современных приложений.

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

собирающихся через раз из-за очередных апдейтов можете

таких примеров привести не могу. всё нормально собирается

Т.е., если у вас проект на ангуляре 4.1.2.1, а потом вы его проапдейтили на ангуляр 4.1.2.2 и у вас ничего-ничего не посыпалось при сборке? Ну оооок.

Лично я использую Vue и у меня таких проблем за 2.5 года работы с ним не возникало.

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

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

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

у вас проект на ангуляре 4.1.2.1, а потом вы его проапдейтили на ангуляр 4.1.2.2

Внезапно обновили? Нравится стрелять себе в ногу?

Апдейт должен проводиться планово, на это нужно выделять время, и это должно идти отдельной таской (кроме случаев когда апдейт необходим для выполнения текущей). После апдейта вы запускаете тесты (если они есть) и руками тестирует основные фичи. И потом, после устранения всех «посыпалось», обновленный package.json и package-lock.json коммитятся в гит.

Если у вас кто-то просто так что-то обновляет, у вас нет процессов. Если у вас в package.json не зафиксированы версии зависимостей (присутствуют ^ и ~), значит вы сами себе виноваты.

Внезапно обновили? Нравится стрелять себе в ногу?

Вот! В этом-то и вся писечка. Апдейт не должен все ломать. Даже в .NET-e перевод проекта с версии 3.5 на версию 4.5 нихрена не ломает и проект билдится с первого раза, тесты не валятся, а проект запускается с первого раза и работает так же стабильно. Таска да, заводится, но она не занимает неделю, а всего лишь полдня, со всеми перекурами и кофепитиями.

Ага, апдейт должен стимулировать.

Вот! В этом-то и вся писечка. Апдейт не должен все ломать.

Да ну, правда что ли?

Даже в .NET-e перевод проекта с версии 3.5 на версию 4.5 нихрена не ломает и проект билдится с первого раза

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

Да ну, правда что ли?

Прикинь!

Значит фреймворк или не развивается, или тянет за собой легаси по 10 лет.

Нет, это значит, что фреймворк умеет в обратную совместимость.

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

«Кароч, мы получили много багрепортов, нам это тоже не понравилось, мы решили переписать все нафиг, читайте, что мы выср@ли в этот раз»

Нет, это значит, что фреймворк умеет в обратную совместимость.

ну и сколько клиентам на дорогом мобильном интернете будет стоить эта обратная совместимость? Ну и зачем оно тогда надо? Не путайте бэкендовый дотнет с фронтом.
Такое можно будет заявлять когда то же самое получит широкое распространение в WebAssembly и когда от .Net фронт-приложений (Blazor) на этой платформе не откажутся из-за непомерно большого веса из-за непомерно тяжёлого рантайма (из-за bw-compat) который приходится с собой тягать.

ну и сколько клиентам на дорогом мобильном интернете будет стоить эта обратная совместимость?

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

простецкая страничка нынче легко выжирает пару мегабайт трафика

И почти всю память.

«Кароч, мы получили много багрепортов, нам это тоже не понравилось, мы решили переписать все нафиг, читайте, что мы выср@ли в этот раз»

в нас накопичився такий технічний борг, що ми не взмозі його оплатити, тому прийняли рішення переписати з нуля

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

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

и приводить код к нужному виду

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

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

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

Если человек сходу не увидел их преимуществ, то может этих преимуществ действительно и нету?

Преимущества есть, так как другие разработчики их видят. Я их вижу, мои коллеги их видят, тут в теме есть люди, которые их видят.

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

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

Если б писали на Angular, а не Vue, возможно мнение было бы другим.

Я не вижу критического влияния какого-то одного фреймворка на вопрос «сложности» технологий в целом.

Влияние в том, что конкретная команда пишет на каком-то конкретном фреймворке, и они смотрят на все фреймворки через призму одного. Никто не говорит, что moment.js «сложен», это огромная либа, но большинству нужно знать API из 2 методов.
А вот фреймворки, могут быть сложными, особенно когда вводят тонну абстракций, не свойственных веб-приложениям в целом. Тоесть Vue не «сложен», и если что-то идёт не так, его исходники довольно легко читаются в отличии от Angular2.

это огромная либа, но большинству нужно знать API из 2 методов

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

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

Тут смотря как на «сложность» смотреть, если так сказать дискретно, типа вот сел типок за клавиатуру задачу делать, день сидел, два сидел и не смог сделать (false), или сделал (true).
Если, например, на одном фреймворке, задача занимает 150 строк кода, а на другом 2 строки, то там где 150 кажется реально сложными, хотя большинство строк простые, но писать это сложно.

Когда в одном фреймворке, есть 1000 интерфейсов, создающих абстракции, которые сложнее в разы, чем вещи под их капотом, а в другом этого просто нет, то да — это сложно в одном и просто в другом.

Либо есть варианты, в стиле когда к тебе приходят и говорят: а сделайте ка, чтобы у нас был билд 100 kb первоначальный, а потом lazy шло, и вот на одном фреймворке, ты такой «тю, да легко», а на другом писец сложно, а скорее не возможно, и ты такой «нет, Вам это не нужно». Тут и про холодный старт 200 ms.

И чтобы билд билдился не минуту, сложно ли чтоб билд билдился минуту, для нервов — сложно.

Только вот экскаваторы из года в год не выпускаются таким образом, что раньше ковш находился впереди, а теперь сзади, а рычаг, который отвечает за зачерпывание земли не становится внезапно рычагом, поворачивающим, допустим, направо. И экскаваторщик уверен, что сев из экскаватора Comatsu-2 в Comatsu-3 не будет методом тыка опять изучать расположение органов управления. А пересев из Comatsu в Caterpillar будет уверен, что максимум трудностей, с какими ему придется столкнуться — это эргономика органов управления, ну и может, фидбэк ковша и кабины.

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

Это как если бы в автомобиле передача R внезапно начала бы означать Rocket Speed, а не Reverse. Не, нуачо? В документации же написано!

Ну и сколько примеров таких изменений во фреймворках вы способны озвучить?

Обычно это голословные заявления, которые основаны на мифах и шутейках, и первое что приводят в качестве аргумента — Angular.js / Angular, что вообще не катит как таковой.

и первое что приводят в качестве аргумента — Angular.js / Angular, что вообще не катит как таковой.

«Ваш аргумент не аргумент»?
Я услышал.

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

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

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

Даже Дорожко так не отжигает. У меня такое впечатление, что тут или шизофреники (они просто к психиатру не сходили) покруче его, или просто дураки.

В моем представлении плюсы довольно стабильный и не быстро развивающийся язык. Очевидно ошибался. Про пайтон уверен :) Но думаю с таким персонажем как ты продолжать диалог бессмысленно

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

Именно. там сначала думают, прежде чем дурь внедрять.

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

Не продолжай. Продолжай с такими как ты.

Очевидно ошибался.

До 2011 ты был прав. После — нет.
Плюсы наконец-то начали развиваться, и то, как у них это происходит, не так и плохо.

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

Тебе — безусловно.

Безусловно плевать на твое мнение ;)

То есть единственным вашим примером был Angular.js / Angular ? Ну ок, очень констуктивно пообщались, спасибо))

Да потому что дальше идут вариации на тему этого аргумента.

До сих пор вспоминаю, как заполучил книгу по Angular4.x.y.u, а скачал свежайший на тот момент Angular4.x.y.u+5. Так даже сраный хеллоуворлд по той книге не захотел нормально запускаться. Зато скачанный с гитхаба по той книге с той же версией пример прекрасно запустился. Внимание, вопрос: а нах оно мне надо тратить время на переобучение практически с нуля, ковыряние в интернетах на предмет новых подводных камней вместо вникания в предметную область? Не, если у заказчика бюджет неограниченный и на галере поставлен process-oriented development, тогда ОК, но серьезные дяди умеют считать деньги и им нужен результат.

Всё понятно. Спасибо за разъяснение

Перенос логики и рендеринга на фронтенд только лишняя работа

Не просто лишняя, а даже вредная. На то он и сервер, чтобы данные обрабатывать.

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

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

Я как-то лет 5 назад делал на datatables.net таблицы. Для пагинаций и сортировок пришлось помню свои mvc биндинги писать. Но все получилось — на фронт я не тянул все данные с бекенда. Экспорт там конечно как был гавном так и остался — тут по другому никак.

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

И вы согласились? И не попытались объяснить заказчику что идея говно?

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

Жестко, но метко

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

В С# вон сколько всего было, и в принципе всё еще есть и даже работает(Silverlight, WCF, WebForms, EntityFramework, etc)- но мода двигает все вперед
В Java- тоже много чего было и есть (JSF, JSP,Swing, AWT).

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

Очень редко где что то написанное остаётся нетронутым годами.

В С и фортране не так. BLAS и LAPACK уже дохренища лет не меняются, разве что новые возможности процессоров в них добавляют внутри — снаружи ты этого не видишь.

Люди постояно переливают из пустого в порожнее переписывают системы.

Я переписывал потому что nosql сервак не справлялся с выборкой данных. Там система логистики складов где некоторые репорты даже mssql ложат — приходится делать денормализацию и прочее.
hfphf,s ljvfkb xnj jyb cajhvbhe.n byajqcs b jhlthf d оыщт yf rkbtynt засунут его в CouchDB где json это как раз формат хранения там же будет делать выборки встроеным яваскрптом и все будет в шокопаде. Шоколад закончился после месяца работы складов на первом же серьезном репорте по аналитике
В этом и проблема — в описаниях в инете все выглядит класно — вот вам фронтенд и бекнд на яваскрипте ничего больше учить не надо — обмен данными в json вот вам Nosql с ключ значение никакого дремучего SQl. Новичкии, особенно те кто прищел в IT потому что тут хорошо платят а не потому что у него есть хоть какие то способности, на это подседают пишут проекты потом проекты проекты оказываются более трудоескими но куда уже деватся, нанимаются новые фронтэндщики и т.д. К меня ра работе проект на реактие я один на бекенде клепаю им API почти копипастом а на фронтенде 3 человека. Если бы регал я а не «продвинутый» прожектманагер — вместо трех на фронтэенде сидел бы только верстальщик

В этом и проблема — в описаниях в инете все выглядит класно — вот вам фронтенд и бекнд на яваскрипте ничего больше учить не надо — обмен данными в json вот вам Nosql с ключ значение никакого дремучего SQl.

Ну голову-то надо включать, а библиотеки для работы с реляционными БД есть.

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

Они по-хорошему сами не должны писать проекты.

К меня ра работе проект на реактие я один на бекенде клепаю им API почти копипастом а на фронтенде 3 человека.

И? Это либо сложный фронт с простым бэком, либо менеджер-дурак. При чем здесь технологии?

Если бы регал я а не «продвинутый» прожектманагер — вместо трех на фронтэенде сидел бы только верстальщик

И че бы он наверстал? Неповоротливое нечто в стиле 90х? Или вы там огромной командой блог пишете в виде SPA?

Вы попробуйте взять дизайн этого проекта и самому сделать фронт, используя только jQuery. Потом приходите и расскажите о своём опыте.

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

Работаю несколько лет только с Ember.js, что я делаю не так? Ну кроме того что не вписываюсь во все вакансии, но мне во все и не нужно.

Не знаю ни одного фронтендщика, который бы гонялся за новым фреймворком. Все сидят на тех фреймворках, которые им нравятся: React, Angular, Vue.

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

И такие люди «с практическим складом ума» даже не задумываются о том, что современные фреймворки во многом ещё и ответ на новые вызовы UX-дизайна. О дизайне такие люди не задумываются в принципе и считают, что как было в 90-х всё «легко» и «красиво», так оно и осталось.

В С# вон сколько всего было, и в принципе всё еще есть и даже работает(Silverlight, WCF, WebForms, EntityFramework, etc)

Кое-что из этого тоже протухло. MS даже на официально уровне перестала это поддерживать. Хотя другие вещи вполне себе развиваются. Вообще, мое ИМХО, с новым СЕО MS начала идти верной дорогой (привет, .NET Core)

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

Сейчас по прежнему трепыхается webassembly, который до сих пор не может нормально в DOM, я жду, не дождусь, когда он станет востребованным, поскольку решаются следующие проблемы:

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

В ідеалі сам дум з хтмл ксс костилями випилити. Для чого тягти цього динозавра в васм.

1. Повышается порог вхождения, что автоматически отметает детей от ИТ

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

Якби все було так просто, то всі дотепер би писали на джейквері. Життя показує що технології становляться складнішими і поріг піднімається, а за ним і зарплати.

Конечно становятся, кто ж спорит — когда возросшая сложность задач заставляет (или уперлись в ограничения старого тулинга, что в общем одно и то же). Но новые более сложные инструменты не становятся менйстримом ни по приколу, ни чтобы ЧСВ почесать, ни чтобы «отмести детей от айти»...

WebAssembly, смотря на Blazor (Client и Server), довольно скоро дропнет многие frontend команды.

Если в деталях, то с начала 2000-х enterprise искал пути сделать front быстро работающим и одновременно не писать js.
Первые попытки этого были в ASP.NET AJAX UpdatePanels и других подобных IndirectAJAX реализациях, Silverlight как один из ответов, GWT, VWG.
Все эти решения были далеко не идеальны, и поэтому они сдались и начали использовать JS фреймворки, дававшие более качественный UI. Но на самом деле все эти лет 13 им был нужен серверный Blazor. Это новая реинкарнация UpdatePanels, то как оно должно быть.

А я забил на JS, сижу на бэкенде и только. Если будет критично то подтяну фронт, а так... Пусть другие этим JS-ом мозги сушат. ))))

Так ведь JS не нужен.

Че это не нужен? А фронт писать на чем? Ну есть TypeScript, но он все равно компилится в JS, в браузере JS-у замены нет.

Так и фронт не нужен.

человек выучил бы grunt а тут уже грунт ацтой есть гораздо более крутой Gulp

А зачем учить что-либо из них, кроме как ради баззвордов в резюме и объявлениях? Я grunt вообще не знаю, gulp использовал пару раз и ничего там не учил. Чтобы написать конфиг достаточно документации и статей в интернете, это всё гуглится на раз. И не забыть в корень положить README.md, в котором указать как это запустить. Всё.

Во во. І не скромничати додати то все в резюме))

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

гит какраз не элементарен. и немного покрутить его не помешает. Ато 90% проектов и девелоперов юзают его как модная замена SVN, и сами не знают зачем.

его как модная замена SVN

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

Гит дико навороченный и сложный, а 99% используют всего 3 основных его функции, как использовали в CVS, SVN и не более. Не используют просто потому, что нафиг не нужны им эти функции для работы. Фактически микроскопом забивают гвозди.

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

За TFS можно в минусы записать, что он любил тупо глючить и делать криво то простое, что ему сказали. Но за CVS, SVN такого не наблюдалось.

В TFS ще класно було мати build server і запускати збірки прямо зі Студії. Але цим мало хто користувався.

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

А еще там как в sql можно было запросы делать по таскам прям в вижуал студио и добавлять в дескрипшен комита линк на таск и он будет кликабельным.

У меня так: TFS >> SVN >>>> моча >>> говно >>>>>>> Git

Нафига мощный гит

В гите главное не что мощный, а что распределённый.
Делал работу, каждые 3 минуты фиксировал полученное, если нравится, и откатывал, если не нравится, потом пересобрал историю в логически связные коммиты и отдал коллегам или просто напрямую в основную репу.
Реально больше никто так не умеет, всё сплошь костыли.
А централизованное дерьмо вроде CVS или SVN — вообще чихнуть нельзя, чтобы не внести какую-то кривую тошнотворную ерунду, по которой ещё 20 лет потом будут вспоминать, какой ты дурак и какое у тебя хреновое настроение было в этот день.

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

каждые 3 минуты фиксировал полученное

Но зачем?

Чтобы полезный результат не испортить.
Ну, может, не 3, а даже 10. Главное, что есть локальная история, которая не для экспорта, и есть экспортная, которая уже логически завершена.

Разный. Может быть полезный, может вредный.

Чтобы полезный результат не испортить.

Ты меня убиваешь? Смузи обпился? Зачем его портить?
Да и что можно написать за 3 минуты?

Зачем его портить?

Не зачем, а почему.

Написал кусок кода, а затем решил его непоправимо улучшить. Оказалось, ошибся. Значит, откатился назад и пошёл дальше экспериментировать.

Да и что можно написать за 3 минуты?

Иногда — очень много чего.

Я так не умею и к счастью учиться такому не хочу.

А никто от тебя и не требует.
Но это только один вариант вкусных возможностей. Другой — когда по результатам ревью легко и просто подправляешь какие-то мелочи в коммитах и перевыкатываешь (один коммит или цепочку).
И пробная цепочка показывается теми же методами, что и постоянные коммиты.
В разных костыльных поделках вроде SVN ты такого не сделаешь: или отдельной тулзой послал на ревью (мы таким страдали, было что-то от Atlassian), или закоммитил уже навечно и получаешь тумаков.

В TFS был кодревью на одном проекте, опять таки — скидваешь «полку» коллегам, они ревьювают, переделываешь сколько тебе влезет, потом когда уже все тип топ, делаешь коммит и не срешь в хистори, и потом изварщаешься чтобы ее чистить.

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

скидваешь «полку» коллегам

Зачем отдельная сущность «полки»?
И почему ты всё время говоришь про один коммит? Может, мне сейчас нужно 20 в цепочке?

А главное что когда делают ревью могут накатить твою «полку» у себя локально и даже подебажить у себя и потом отправить тебе фидбэк, и при этом никто не срет в свою хистори.

В Git точно так же. Вытянул себе состояние по голове цепочки коммитов и работаешь с ним.

При этои у тебя не просто два уродских ошока «было» и «стало»

Что такое «ошок»?
И тут полноценный коммит, или цепочка коммитов.

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

Реальная полезность гита, это переключение между бранчами — переключение между тасками без вреда друг для друга, но это используеться в 5 % случаев.

А хто не вміє перемикатись між бранчами? CVS?

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

Ну то есть они сделали свой закат солнца вручную? Я ценю их настойчивость, но что они решали?

И обрати внимание, что в случае Git эта самая локальность истории это всего лишь вариант использования. Я могу все эти «progress!» и «ааа! мои руки!», если надо, скинуть в Gerrit (например, задачу аварийно передали другому, и ему надо всего лишь красиво оформить уже сделанное), pull request на github, gitlab или что там сегодня в моде, работать в другой IDE или вообще без IDE, если не хочется или невозможно... они ничем не отличаются от «постоянных» коммитов. Зато их точно так же можно переразобрать и собрать во что-то в другом виде.

А ещё есть «индекс» и возможность аккуратно гранулированно его набирать — и без этого, конечно, можно работать, но это будет или в 10 раз больше усилий, или тотальная грязь в репозитории.

Реальная полезность гита, это переключение между бранчами — переключение между тасками без вреда друг для друга, но это используеться в 5 % случаев.

Вот это как раз ничем не выделяется на фоне аналогов. Или ты с чем-то совсем странным сравниваешь?

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

— Я, кстати, пил сок лука. Ещё чеснок выжимал. Капусту. Зелень (меня почему-то стошнило, много не пейте). Пил сок огурца, свеклы, даже сырого картофеля. Всё это пил.
— ЗАЧЕЕЕМ?
— У меня была соковыжималка.

даже сырого картофеля

это уже за гранью

сок огурца

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

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

Хороший лагер лучше идет. Например, Урквел. В РБ сейчас отличные пильсы мелкие пивоварни наварили под жару.

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

В Украине.

Делает каменный стояк

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

В TFS есть такая штука как «полка» shelf, это комит который можно отправить коллеге, можно сохранить, можно откатить и накатить его, так что этот финт ушами не супер фича git-а. А главное не надо дрочиться в консоль с магическими переменными слепливая комиты в один.

В TFS есть такая штука как «полка» shelf, это комит который можно отправить коллеге, можно сохранить, можно откатить и накатить его

Ну и зачем его логически отделять в отдельную сущность?

А главное не надо дрочиться в консоль с магическими переменными слепливая комиты в один.

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

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

а потом когда ревьювают то оно комиты новые из дева(те что накомитали в дев пока я в своей ветке сидел) показывает как мои

Как это ты такого добился?
Само оно так не получается, это я даже не знаю, куда копать, чтобы такое получить.

вот нахера такое делать?

Не знаю. Это ж ты получил, у себя и спрашивай...

Вот мы и пришли к тому что гит перегреуженная перделками вундервафля которая выносит мозг там где надо и не надо.

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

Пан не знає різниці між merge й rebase? Не знає що це два різні інструменти під різні задачі? Чи не вміє ними користуватись?
Ну тоді то так звичайно — шайтан-гіт винен.

Никаких магических переменных, всё банально.

Ага щщаз банально, тьма переменных в консоле для команд.

Именно _переменных_?
Перейди на стандартную терминологию, если хочешь, чтобы тебя поняли.

Another way to squash all your commits is to reset the index to master:

git checkout yourBranch
git reset $(git merge-base master yourBranch)
git add -A
git commit -m “one commit on yourBranch”

stackoverflow.com/...​ash-all-commits-on-branch

Где тут хоть одна переменная, которую надо выставлять?

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

Это опции.
Переменные это если бы надо было писать что-то вроде export GIT_ZUKA=M22, или столь же магические значения в самих командах.

Ну а если вы не хотите учить опции (причём самые стандартные), ну, вперёд гуй-клиенты применять. Там всё то же самое галочками с описаниями. Вполне почтенное желание и реализуется реальными софтинами.

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

Гуй клиенты отваливаются часто с ошибкой в стиле «я хз как это сделать заебошь очередной набор символов в консоли».
Так недавно было когда вдруг решили отказаться от https на гите и пришлось вводить очередную порцию меджик команд чтобы клиент смог работать, а не падать с ошибкой «unauthorised»

Теперь ты вдруг решил подключить сюда проблемы левых кривых клиентов?

Так недавно было когда вдруг решили отказаться от https на гите

Git не отказывался от https. Ты опять про какие-то левые тулзы? Прекращай курить шишки.

НА проекте нашем убрали. Сам упоротый штоле, Как можно менять сам гит?Переписывать его самим?

Ога левые клиенты, а они есть какие-то официальные у гита? Гитхаб десктоп, сорс три, вот что у меня на компе.

Как можно менять сам гит?

Не, твои шишки таки слишком смолистые. Что значит «менять сам гит», откуда ты это взял?

НА проекте нашем убрали.

Ну и почему остальные виноваты, что на вашем проекте кто-то решил отказаться от https?

Ога левые клиенты, а они есть какие-то официальные у гита?

Да. Те что поступают c git-scm.com.

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

Ну и кто из них налажал? И покажи STR. Я на 90% уверен, что пока ты будешь его записывать, поймёшь сам, что сделал не так. Но если воспроизводится — ты найдёшь, куда слать PR.
Мне лично проблемы обоих как-то слабо интересны.

Ну вот ты и сам доказал что гит это 100500 спообово острелить себе ногу, и еще столько же сопособов острелить не правильно, это я и пытался тебе обьяснить, потому что по закону Мерфи, если там есть 100500 способов острелить ногу, то ее таки отсрелят 100500 раз. Окуенная тула, ппц просто.

Второе — инструменты созданы чтобы автоматизировать и упрощать работу, а не создавать новые способы для изврата, отстрела ног, курения мануалов, поиском правильных команд, правильных UI, правильных дополнительных тулов...

Ну вот ты и сам доказал что гит это 100500 спообово острелить себе ногу

У тебя логика типа «Windows это 100500 способов отстрелить себе ногу, вот берём диск „300 лучших программ“ с Петровки и запускаем под администратором — смотрите, сколько вирусов появилось!»

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

Окуенная тула, ппц просто.

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

а не создавать новые способы

Не вопрос. Закажи Apple единственный нормальный VCS... ой, а почему это Apple в основном использует сейчас Git? Ой беда-то какая...

Ну если ты считаешь что SVN и TFS это уровень

Петровки

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

Петровки
проблемы левых клиентов
Apple в основном использует сейчас Git?

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

Ну если ты считаешь что SVN и TFS это уровень Петровки

Не хочешь или не умеешь читать. Петровка это как источник левых клиентов.
TFS не видел. А SVN — уже говорил: плохо покрашенное ржавое дерьмо.

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

А. То есть таки юзеры не тянут? Вообще-то использовать Git на уровне SVN может даже junior-обезьяна. Вот для результата поприличнее, да, нужно день поучиться.

Вотэва, гит это лишний гемор, ин эни вей. Мне надоело спорить.

Наоборот, всё остальное сейчас — лишний гемор. OK, не спорь :)

це не змінні, це запуск сабшелла і використання його результатів у команді git reset

не сквош и все авторы коммитов останутся под своими именами

Весь разговор за то что гит переусложнен херней которая не нужна и часто мешает.

Здесь как раз было ровно то, что нужно. И -A для add, и -m для commit.

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

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

stash тоже использую, но он тут ни при чём.

и сами не знают зачем.

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

ведь прикольно скачущие символы на консоли — это ж так романтично, сразу напоминает дух старой школы.

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

ведь прикольно скачущие символы на консоли — это ж так романтично, сразу напоминает дух старой школы

Что, таки прикольно скачут? В духе такого? Где раздают? Хочу (опциональным модом) :)))

Слава яйцам, на Виме не заставляют работать.

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

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

для тех кому не хватает мозгоепства на работе, с женой, рукой

Ты прям какого-то супермена написал, которому всего этого не хватает... мне аж завидно стало. Наверно, есть и монстры уровня Чака Норриса среди пользователей консоли, но я как раз слаб по сравнению с ними — и поэтому не использую гуй там, где от него только проблемы.

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

Но для диффа или мержа лучше, как мне кажется, гуёвая тулза.

Ну смотря что она даёт.
Например, Gerrit показывает диффы, расцвечивая двумя уровнями зелёного и красного — полностью добавленный/удалённый код и перенесённый. Это да, реально полезно. В принципе можно и в консоли такое сделать (в ANSI расцветке есть задание фона, 2 уровня интенсивности окраски и т.п.), но как-то не настолько адекватно эстетически.

Переключаться легко между режимами показа unified diff (с цветом или без) и side-to-side — тоже очень вкусно.

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

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

Как уже говорили с тем что даёт IDEA не сравнить.

«Уже говорили» без единого примера или хотя бы описания, куда смотреть — это не говорили.
Можете внятно рассказать STR, чтобы понять, что там такого? IDEA есть, воспроизвести на ней смогу (если описание будет не туманное).

Именно в том посте я писал о фиче Resolve simple conflicts button option

Но это я привёл скорее для сравнения. Достаточно стрёмная фича когда видишь её в первый раз. Я бы ей не пользовался если бы не был уверен что с самим гитом я на ты.
Начните изучение лучше с более простых и понятных нативно-гитовых тулзовин типа rebase, cherry-pick, etc.

С нативно-гитовыми проблем нет, с rebase и прочим — тоже.
Я задавал вопрос конкретно по IDEA и тому, что такого якобы даёт её GUI, чего не даёт консольный клиент.
Не тороплю, но хотелось бы услышать ответ по сути.

Писал же:

Resolve simple conflicts

кнопка выглядит так: https://www.jetbrains.com/help/img/idea/2019.1/icons.diff.magicResolve.svg@2x.png
Это то чего именно нет в консоли.

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

Это то чего именно нет в консоли.

Ну, кнопки с такой иконкой, да, нет. А вот команда git mergetool, которая может вызывать команды нескольких разных стилей — есть. И большинство этих команд умеют резолвить «simple conflicts» без помощи человека в тех случаях, когда встроенный в git резолвер слишком робок и не решается выполнить слияние.

Итого, вы просто не в курсе реальной возможности. Ещё попытки будут?

People don’t know that vi was written for a world that doesn’t exist anymore

©, Bill Joy, vi creator (www.theregister.co.uk/...​/bill_joys_greatest_gift)

Зато vim сделан для современного мира и активно развивается и сейчас.

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

В ISD заставляют.

Не удивлен. Ведь ISD — это заповедник совка.

Контора специфическая, но я б не сказал, что заповедник совка. Хотя и много бюрократии.

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

Беручи до уваги, що автор нібито джавіст, трохи тонше, ніж зовсім товсто вийшло.

Мне вот тоже не понятно, сейчас модно прлклинать jquery, но ей богу не каждый сайт это Энтерпрайз приложение со сложноц бизнес логикой, и иногда все намного проще сделать старым добрым jquey

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

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

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

Где я сказал, что не бывает сложных? Просто большинство — простые, jquery достаточно.

Це усе грёбани жидомасони

На деле ВСЁ что натворили в программировании — сделано БЛАГИМИ намерениями, дабы упростить написание программ.

Глобальная ошибка в том, что написание-то упростили (разумеется каждый по-разному). Резко повысив затраты на обучение. И просто катастрофически ухудшив ЧИТАБЕЛЬНОСТЬ кода.

Тот случай, когда программы на ассемблере уже проще современного ЖабаСкрипта.

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

Не кажи Гоп. Монополия браузеров случилась снова, многие ресурсы иначе как в Хроме уже не работают. Когда Хром откажется от JS, этого будет достаточно.

Не знаю что и где у вас там не работает, но на всех проектах, где я работал, требовалась поддержка ИЕ 9-10-11, не говоря уже о Сафари и ФФ

Расскажи это конторам Хуякхуякпродакшен

Хром откажется от JS...Судя по тому как гугл закрывает/открывает сервисы свои, мне кажется js там будет еще очень долго, ну или заменят на еще одну поделку от гиков и похоронят свой «гугл IE» как и микрософт свой IE.

Когда Хром откажется от JS

Когда наши танки войдут в город ©

Чтобы хром отказался от джс, гугл должен отказаться от джс.
А для этого нужно выполнить 3 условия:
1) иметь альтернативу (ее нет)
2) переписать ВЕСЬ фронт гугла на эту альтернативу (которой нет, + лярды долларов работы)
3) придумать, для чего это было нужно (по факту ни для чего)

Итого — шансов нету.

Для Гугла звучит как челлендж
1) Создать с нуля, и сделать так чтобы без неё Ютуб не работал.
2) Не переписать, а интегрировать, чтобы надо было и то, и другое, и по итогу отстрелить 100500 тем и приложений, не говоря уж о том что работало по API. Не сломать серверное API — это ж так тяжело!
3) Зачем тебе смысл, когда есть Гугл? Даёшь стопиццотыщ проектов на кладбище!
4) ??????????????
5) PROFIT! Через пару лет на кладбище. Потому что большая популярность, а миллиардов не принёс.

PS. На этих граблях уже сплясал Файрфокс, зарубив огромнейшую библиотеку дополнений, включая выпиливание её с серверов. Собственно, это была его единственная ценность. Рынок он выигрывал только против Internet Explorer, и долгое время кормился спонсорством Гугла. У Гугла выигрывал долю рынка будучи экономнее по ресурсам — забудьте.

Твои 1, 2, 3 и 4 — глупость, сорян.
Гугл потому и могуч что может стартовать 100500 проектов, а потом закрыть 100497, оставив 3 золотых идеи. Но идеи базируются на том, что они закрывают какую-то потребность. Или создают ее, и закрывают. Новый веб никому не нужен.

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

Да, хром еще не раскрыл свой потенциал, это будет новый, легендарный IE 6, только еще масштабнее :-)

В смысле жырнее и прожорливее. Где между делом можно вместо вируса невзначай скачать новую операционку, или притащить её с очередным апдейтом — разумеется ткнув галочку «согласен» не читая новую версию соглашения.

Извини, но глупости это не мои. Гугл не стартовал многие из этих проектов а купил/отжал и просрал.

Говнеца уже хлебнули. И несколько лет уже прошли.

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

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

Разве что конкурент появиться в стране, на которую патентное законодательство США не будет распространяться.

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

ПХП тоже писался как примитивный шаблонизатор. Это не помешало ему вырасти в то, что есть сейчас

ПХП тоже писался как примитивный шаблонизатор.

PHP/Fi — да. PHP3 — нет. Насколько я помню.
Кроме того, конкурентом у PHP тогда был только Perl :)
Нишевые закрытые технологии типа coldfusion — не в счет.

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

грёбаное получение файла по URL

Вообще нужно запрещать. Для этого есть curl.

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

Куда по-твоему создаёт CURL временные файлы? Когда он по-твоему их чистит, если запрос отвалился?

Аминь! Хотя у кого не спрошу, толком ответить на вопрос: почему так плох JS никто не может.

Почему говно плохо — попробуй толком ответить

Мені свого часу довелося 3 роки попрацювати на JS де для неосяжних розмірів e-commerce ми переписували фронт на ванільному JS, а бек — на Node. Поки вчив і розбирався з усім цим новим для мене було наче не так і погано, але коли вже почалася рутина то я почав дивитися куди б зіскочити з цього проекту. Рятувало лише те що там також було неймовірно багато legacy на С++ яке треба було «осучаснювати».

Мої особисто претензії:
— Мова в цілому виглядає як щось зліплене на коліні за короткий час дуже розумною людиною. Наче і все продумано, але якісь речі просто не стикуються ніяк — це суб’єктивно звісно.
— Ідіотизм з unknown типом чи об’єктом чи значенням приводить для того, що постійно треба писати щось в стилі «якщо такий об’єкт існує і у нього існує така властивість і її значення теж існує...». Як все це не обгортай — виглядає потворно.
— Прототипи як заміна об’єктно-орієнтованій моделі — дуже сумнівне рішення, і приводить до того що велика частина коду є шаблонним в тому сенсі що ніколи нема ніяких гарантій про типи та об’єкти які він буде обробляти. І починаються потворні фокуси з this, that, self... Також ця схожість на ОО є джерелом великої кількості помилок та багів від початківців які навіть не підозрюють що в начебто очевидному коді все буде працювати не так як вони думають.
— неминучі колбеки поверх колбеків, а ще зверху притрусити це this і виходить код який завжли легше переписати ніж пофіксати.
— різні реалізації у різних движках примушують писати код трошки по іншому кілька разів, а для нерозпізнаних движків просто сподіватися що він буде працювати.
— синтаксичні помилки (наприклад не там закрита дужка) може привести до того що код буде все одно працювати, але зовсім не так і не той що сподівається програміст — дуже часто інтерпретатор просто проігнорує неправильний код якщо зможе.
— нескінченна гонитва фреймворків коли кожні пів-року з’являється абсолютно нова і революційна річ що вирішує усі проблеми, але абсолютно несумісна з існуючими. І навіть наймаючи JS програміста треба знати що такий вміє писати лише на певних фреймворках певних версій. Тому ми після кількох спроб почали наймати С+±ників, вчити їх за кілька днів і кидати в роботу — для них не проблема вчити (і швидко вчити) щось нове, в той час як JS-ники закочують істеріки що їм виключно X версії Y потрібно по роботі.
— чисто технічні проблеми: модулі, версійність, late binding, логічні оператори, та сама this, неможливість специфікувати/обмежити тип, незрозумілі performance вибрики коли, наприклад, for можна переписати як while що йде від останнього до першого елемента колекції і отримати швидкість в СОТНІ разів вищу.

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

З 2014-го по 2017-й. Тільки не кажіть що треба було заюзати якусь дуже специфічну версію/фреймворк/іншу магію щоб було щастя — бо щось більше за vanilla js не надто і працює в гетерогенному оточені на старих браузерах, ОС та інших спеціалізованих (і мобільних в тому числі) платформах.

Може тоді було потрібно підтримувати застарілі браузери, бо претензія щодо різних імплементацій зараз не настільки поширена, щоб доводилось із нею постійно зтикатись.

Інші претензії більш схожі на необізнаність, ігнорування лінтерів та погане структурування коду

У нас до кожної команди було прикріплено js guru які якраз і почали з того що прикрутили лінтери, тести та «структуру» до проектів. І весь код був новий.

Щодо застарілих браузерів — так, але відкидати їх не можна. Бо як у клієнта зі старим чи кривим браузером не працює e-commerce то і контора ніяких грошей не отримує.

Тоді я не розумію, чому ви пишете

— синтаксичні помилки (наприклад не там закрита дужка) може привести до того що код буде все одно працювати, але зовсім не так і не той що сподівається програміст — дуже часто інтерпретатор просто проігнорує неправильний код якщо зможе.

Бо лінтери вас би попередили про це.

Можливо я занадто драматизую, але один такий випадок пам’ятаю доволі точно. У нас весь код був покритий юніт-тестами на jasmin, tea, chai, такоє от всьо. Ну і в подібному коді дуже багато вкладених дужок як круглих, так і фігурних. І от хтось якось дужку не на те місце вліпив і значна частина тестів просто тупо перестала виконуватися бо інтерпретатор їх більше не бачив. І лінтери нічого не сказали — мабуть подібний код для них занадто складний щоб парсити.

Помітили лише через кілька днів коли робили якесь рев’ю і побачили що code coverage впав на третину. Звісно після того зробили щоб мерджі реджектилися якщо кавередж падає, але осадок лишився.

Добре хоч був не продакш код.

Я, звісно, не бачив вашого коду, але мені здається, це потрібно було примудритися, щоб ані IDE, ані linter вас не попередили. Або просто проігнорували, що більш реалістично.

Не було ніяких IDE (причини як релігійні так і гетерогенність платформ на яких велася розробка), але це тема окремої розмови.

Лінтери, до речі, для JS теж не надто якісні. Принаймні були на той час. І ми навіть парочку одразу використовували.

Не буду сперечатися. Бо звісно якщо знати зарані то і робили би по іншому. Просто як кажуть «ложки знайшлися, а от осадок лишився».

І лінтери нічого не сказали — мабуть подібний код для них занадто складний щоб парсити

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

А что, что-то поменялось?

$ node --version
v8.10.0
$ node
> 0 == ""
true
> {} + []
0
> [] + {}
'[object Object]'

Яке відношення це має до списку претензій, наведених вище?

Опять эти примеры из серии «код идиота». Вот какой нормальный человек будет складывать объект с массивом и ожидать адекватный результат? Первый пример не лучше. Любой линтер в наше время отметит == как ошибку. Это сравнение с приведением типов, оно именно так и задумывалось. Чтобы не было неожиданностей, приводить типы нужно самому и использовать ===.

Это вот все равно что я полезу в яву или с++ и буду с позиции человека, который всю карьеру пишет на жс/пхп, доказывать что всё у вас в языке неправильно и не так как я ожидаю.

какой нормальный человек будет складывать объект с массивом и ожидать адекватный результат?

Так проблема то в тому що для уникнення таких ситуацій треба буде ледь не кожен рядок обгортати в перевірки «а чи не масив це», «а чи друга складова не об’єкт». І на рядок коду JS вийде пару десятків рядків перевірок на типи, unknown і тому подібне. Звісно ніхто так не пише і подібні проблеми колись та вилізуть.

Так проблема то в тому що для уникнення таких ситуацій треба буде ледь не кожен рядок обгортати в перевірки

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

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

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

Для этого есть хорошие библиотеки

Звісно є, і у кожного захисника JS чи будь-якої технології взагалі знайдеться набір магічних пігулок та рецептів з якими має прийти безмежне щастя. Але, повторюся, далеко не все можна і має сенс використовувати — конфлікти залежностей і версій, розміри, споживання ресурсів, несумісність з малопоширеними платформами/движками/браузерами і таке інше.

несумісність з малопоширеними платформами/движками/браузерами і таке інше.

С какими платформами/браузерами/итд может не работать валидатор объектов? Базовые технологии, необходимые для валидации, придуманы много лет назад и поддерживаются наверное везде

і у кожного захисника JS чи будь-якої технології взагалі знайдеться набір магічних пігулок та рецептів з якими має прийти безмежне щастя

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

Не буду сперечатися про правильність рішень і підходів в JS і всього інструментарію навколо. Для себе я визначився що не хочу з ним мати справу як з основною технологією більше ніколи.

При цьому погоджуся що комусь може бути дуже до вподоби все те що там є. І до того ж є такі задачі і проекти де JS у різних варіаціях буде привильним вибором на якийсь час.

При цьому погоджуся що комусь може бути дуже до вподоби все те що там є.

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

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

И как-то я сильно остыл в любви к JS.

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

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

Якщо ви не знаєте що в вас в коді за змінні та якого вони типу, то ви написали гівнокод. Дані, що приходять зі сторонніх джерел перевірити не проблема. Та таких даних на весь застосунок багато не буде.

Яким чином можна гарантувати тип (чи навіть наявність) вхідних параметрів у JS в загальному вигляді крім як перевіряти тип та наявність значень кожного разу?

Каким образом в жаве доказать компилятору что из текстового поля в форме придет число?

OMG, ти правда не можеш придумати?
З текстового поля приходить текст, який ми перетворюємо на число.
Якщо перетворити не вдалось, то отримаємо ексепшен, який ми можемо обробити — вивести юзеру повідомлення або прийняти якесь дефолтне значення.

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

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

Тим, що потім це число можна передати кудись вглиб в бібліотечний код і вони не мають перевіряти, а чи число це прийшло? Чи не null це часом?
Є інтерфейс, є типи параметрів — ми знаємо, що там буде. На все решта компілятор настріляє нам по руках.

Натомість, у JS код бібліотеки має перевірити тип і валідність параметрів, щоби часом чого не вийшло.

Натомість, у JS код бібліотеки має перевірити тип і валідність параметрів,

Не обязательно. Является хорошим тоном, если библиотека будет публична и использоваться сторонними разработчиками, но вовсе не обязательно. Есть документация (по-хорошему, JSDoc), тот кто вызывает библиотечную функцию должен обеспечить верный тип. Кстати не знаю умеет ли линтер работать с JSDoc, IDE умеет и выделяет как warning если где-то передаешь параметр явно не того типа.

Можно TypeScript использовать, если хочется интерфейсов и типов параметров.

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

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

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

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

Щодо наявності, є така річ, як дефолтне значення параметру.

Щодо типу... це ваше завдання передати функції те, що їй потрбіно. Інші мови що, магічним чином перетворюють нуль на об’єкт із потрібним інтерфейсом?

Інші мови що, магічним чином перетворюють нуль на об’єкт із потрібним інтерфейсом?

Ну типо JS це як С де усі параметри передаються виключно як void* і можуть вказувати на будь-що? Таке собі задоволення писати всі ці перевірки на кожен рядок.

Що заважає подивитись що в цю змінну поклали при її декларації? якщо оголошувалась через const, вона як була свого типу, так і залишиться. Якщо через let — подивитися як вона змінювалась.

Якщо на проекті хтось оголошує змінні як строки, а потім змінює їх на масиви чи щось... відірвіть йому руки, киньте за борт і візьміть нормального розробника

Що заважає подивитись що в цю змінну поклали при її декларації?

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

При строгой не надо. Я что, спорю с этим? Но js не строго типизированный. И ожидать от него этого — минимум тупо.

Но и писать код, как тут пытаются выставить некоторые, с «проверкой на каждую строчку кода» нет нужды

Що заважає подивитись що в цю змінну поклали при її декларації?

Те що декларація можливо ще і не написана, а якщо і написана то не доступна автору фунції чи бібліотеки.

Я вже незлічену кількість разів написав, щодо бібліотек і хороший тон з перевірки у них.
У своєму коментарі я пишу про власний код, який ви контролюєте.

Тобто якщо ваша бібліотека має виключно внутрішню утилітарну функцію, в ній можна не перевіряти дані, бо ви вже написали перевірку в публічних методах.

Опять эти примеры из серии «код идиота».

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

Вот какой нормальный человек будет складывать объект с массивом и ожидать адекватный результат?

To err is human, слышали?
Ошибка может быть на любом уровне, и язык должен защищать от её последствий, а не усиливать и маскировать их.

Первый пример не лучше. Любой линтер в наше время отметит == как ошибку. Это сравнение с приведением типов, оно именно так и задумывалось.

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

Это вот все равно что я полезу в яву или с++ и буду с позиции человека, который всю карьеру пишет на жс/пхп, доказывать что всё у вас в языке неправильно и не так как я ожидаю.

Это то, что есть общие принципы, которые должны соблюдаться везде, чтобы результатом можно было нормально пользоваться без тысячи защит и обложек.
А так — можете лезть. Да, известно, что в Java или C++ свои идиотизмы. Но тут вспоминали не их.

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

Нихрена себе ошиблись, сложили массив с объектом!

псевдокорректное поведение

Найдите спеки жс, наверняка там это поведение подробно описано

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

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

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

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

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

Есть разные виды языков программирования, которые по-разному себя ведут. В частности, они различаются типизацией. И в них разные принципы. Ещё у каждого языка и свои спецификации, они не обязаны работать абсолютно одинаково (иначе зачем столько языков). Вы хотите чтобы язык со слабой типизацией работал по принципам языка со строгой типизацией. А если нет — язык плохой. Это уже неконструктивно.

Нихрена себе ошиблись, сложили массив с объектом!

Ось так в JS не можна ніколи:

function sum(a, b) {
return a + b
}

Щоб завжди і кругом працювало треба якось так:
function sum(a, b) {
if (a != null && b != null && typeof a == typeof b) {
return a + b
}
// шось пішло не так — все підірвати!
...
}

Ось так в JS не можна ніколи:

function sum(a, b) {
return a + b
}

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

У вас так получается молоток виноват что неумелый работник себе по пальцу стукнул или алкаш жену забил. Молоток должен ломаться о человеческий череп!

це вже навіть не смішно...

все одно ще залити в кофемашину гівна та зерен кукурудзи та очікувати, що вона зробить вам макіато.

ви от коли викликаєте sum... ви це навмання робите чи що? рандомом пхаєте до неї все що завгодно, а раптом вона новий гугл побудує, так?
ви не в курсі що вона робить та які параметри потребує? чи вам важко подивитись, що це додавання і мабуть що потрібні числа для цього?

подивились на функцію, на її документацію, якщо є, подивились що в тих перемінних, які ви до неї передаєте та вперед. в чому проблема?

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

Тобто ви вважаєте, якщо в документації написано «передати число», а розробник пхає масив і нічого не виходить, то це проблеми мови ?

В документації ще має бути написано яка буде поведінка коли передано тим що не підтримується, null/undefined і різні типи.

Ні, не має. Документація має містити інформацію про те, які параметри функція очікує, та який результат повертає.

Це проблема розробника передавати правильні дані.

Якщо ви будуєте бібліотеки для стороннього використання, вважається хорошою практикою робити «захист від ідіотів» і перевіряти вхідні параметри, кидаючи попередження якщо щось не так. Але це це не робить перевірку проблемою мови, це просто захист від ідіотів

Вибачте, але це якийсь діаметрально протилежний підхід ніж той що я вважаю правильним. Замість робити функцію надійною і гарантувати її поведінку примушувати того хто викликає робити перевірки і конвертації знову і знову? Я подібну функцію або одразу ж обгорну у свою власну з усіма перевірками і конвертаціями, або напишу свою.

Замість робити функцію надійною і гарантувати її поведінку

Ну простите, жс на идиотов не расчитан

Самому не смішно? Написати функцію яка працює лише в тепличних умовах з певним набором параметрів і вважати що так і має бути написаний код?

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

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

Для того щоб складати щось з чимось це щось має як мінімум бути придатним до складання. До того ж можна специфікувати конкретні типи для яких складання має сенс.

Те що в JS пропонується на С переписати якось так:

void* sum(void *a, void *b) {
return guessTypeFrom(a, b) = guessValueFrom(a) + guessValueFrom(b);
}

що очевидний ідоітізм.

Эксепшн за валидное решение не катит.

Це чому раптом? Якщо з аргументами щось не в порядку то треба повідомляти клієнту про те що операцію виконати не можна. А ексепшн там, чи код помилки — це вже деталі реалізації.

У загальному вигляді можна щось таке уявити:
template
R sum(const A& a, const B& b) {
static_assert("ніззя для таких типів!");
}

template<> int sum(int&, int&){...}
template<> double sum(int&, double&){...}
template<>vector sum(vector&, int&){...}
...

Це чому раптом?

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

Ексепшн це не щось погане, і використовувати їх коли треба це не значить писати поганий код. У випадку коли у поточному контексті продовжити виконання не можливо, як не можливо виправити проблему — ексепшн буде логічним і найпростішим рішенням.

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

за вас кучу проверок делает компилятор

Ні, не робить. Компілятор робить рівно те що йому сказали робити.

за вас кучу проверок делает компилятор

Мене бомбить від того, що хтось може так довго і серйозно виправдовувати очевидні косяки і поганий дизайн в мові.

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

Ні, тільки в тому коді який буде використовувати в реальному житті реальними користувачами.

достаточно проверить входные данные там, где они приходят и обрабатываются

Але ж в JS данні можуть прийти куди завгодно і звідки завгодно. Більше того — зміна прототипу, декларацій та створення об’єктів ніяк не покаже код який після таких змін припинить правильно працювати. Тому так — або писати код який усе перевіряє перед кожною операцією, або при будь-якій зміні сідати і перевіряти кілометри коду які можуть бути поламані такою зміною (включкно з усіма бібліотеками). Наче ж очевидно що лопатити всю базу коду знову і знову не надто ефективно і простіше писати код з перевірками?

Але ж в JS данні можуть прийти куди завгодно і звідки завгодно.

Значит у вас говнокод.

Та я вже зрозумів що писати на JS — значить писати говнокод.

Если пишут такие «специалисты», у которых неизвестно что откуда приходит и как преобразуется — да

Яким же чином вам відому що і звідки приходить?

Мене бомбить від того, що хтось може так довго і серйозно виправдовувати очевидні косяки і поганий дизайн в мові.

А меня бомбит от того, что люди, которые не умеют писать на JS, и никогда этого профессионально не делали, бегают и доказывают что JS говно. Вы не научились использовать технологию правильно — вас никто не заставляет её использовать вообще.

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

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

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

Повторю вдруге — компілятор не робить ніяких перевірок (принаймні таких про які ви думаєте), він просто компілює написаний код.

вы не знаете что у вас откуда приходит и куда идет

Нема ніяких гарантій звідки і куди, і не може бути. Звісно якщо ми не заховаємо код у обмежену область видимості, але ж наче говоримо будь-який код взагалі.

и надеетесь только на то что сам по себе вылетит эксепшн

Не сподіваюся, і не сам по собі вилетить. Коли виникає умова (це вже втретє пробую пояснити) за якої продовжити виконання не можливо і обробити помилкову ситуацію теж не можна — код генерує ексепшн. Не якось десь магічно він викидається, а прямо так і пишемо — кинути ось такий ексепшн.

и надеетесь только на то что сам по себе вылетит эксепшн если что пошло не так.

Это сторонники слабой типизации думают, что в сильной типизации везде просто вставляются «эксепшны»? Вы серьёзно?

Ну пусть вас и дальше бомбит от своих странных предпосылок.
Вы считаете себя такими уникальными в своём подходе, не предполагая, что все те же грабли пройдены неоднократно c теми же последствиями.
Perl — такая же слабая типизация с теми же граблями, хотя в JS они в разы извращённее.
Tcl, sh — тоже слабая типизация, но другой стиль.
Python, Erlang — сильная, но динамическая типизация.
Это те, что лично я на них писал или пишу. И от того, как отличаются формы накладок у грабель, грабли остаются такими же.

Вы блин такие смешные с желанием показать уникальность своего опыта в оседлании «технологии», где в любой момент любому может быть передана любая херь и от этого никто не защищает... да с перлом проходил это много раз — начинает поступать неизвестно что, тогда расставляем проверки и форсирования типов в 30 местах... ой, 31-е забыли... ой, а почему это у нас тут undefined вылезло? А что это за ключ, такого вообще тут не должно быть?
И так по кругу...

Реально, со всеми плюшками IDE, со всеми линтерами: динамика => умножай время разработки чего-то серьёзного на 2-3. Слабая типизация => ещё минимум на столько же. Откровенно деструктивные подходы в работе с типами => ещё умножай. Мне лично жалко потерянного на всё это времени.

Але ж в JS данні можуть прийти куди завгодно і звідки завгодно.

Ахахах))) Звісно, дані просто сипляться з неба до файлів із кодом. На яку функцію впало, туди й передалось.

Ще один з логікою basic-програміста. Запитаю ще раз, мабуть вже в останнє — яким чином у функції ви можете енфорсити те хто і як її викликає?

Це таки не BASIC, це JS :(
В BASIC хоч частково була типізація.

Я більше про те що BASIC вчать як першу мову (принаймні так було за моїх часів) і саме в ті щасливі часи і виникають ідеї типу «щоб не було помилок треба писати без помилок», та «цю функцію будуть викликати виключно так як я це задумав».

В BASIC хоч частково була типізація.

бгг
5470 GOSUB 47500

При чём тут это?
Я говорю про то, что A (A!) — вещественное, A$ — строка, A% — целое.

A (A!) — вещественное, A$ — строка, A% — целое.

щодо A% не знав, у версіях бейсіка, з якими я стикався, було тільки A — числа і A$ — рядки

Моя задача як розробника бібліотек та функцій забезпечити правильне поведіння функції

В рамках заранее заданных/оговоренных ограничений, которые указываются в документации. Если перед вами стояло ТЗ чтобы функция умела складывать массивы или проверяла типы и кидала исключение — делаете это. Иначе не делаете.

Вот все что у вас должно быть написано:

/**
 * Adds two numbers
 *
 * @param {Number} a
 * @param {Number} b
 * @return {Number}
 */
function sum(a, b) {
  return a + b;
}

IDE даже покажет неправильное использование: screenshots.gennady.pp.ua/...​nshot_20190615_023711.png

В рамках заранее заданных/оговоренных ограничений, которые указываются в документации.

Тобто щоб ваш жесе вівся ЛОГІЧНО, треба перед цим зазубрити документацію, і весь час провіряти очима свій код чи не допустив ти чи ще хтось тупо синтаксичну помилку? Знаєте, в нормальних мовах цим займається компілятор, а розробник думає над завданням а не д###ть документації. Мені дуже шкода вас, що у вас все працює на палках закріплених святим духом і що будь який чих все поламає а ви це навіть не помітите. Нічого, скоро це недорозуміння скриптове опиниться на свалці історії де йому і місце.

Мова програмування яка замість того щоб допомагати розробнику писати правильний небагований код, приховує баги і робить ідіотські конверсії — є хрінова мова. І ніякими спеками це не оправдати, припиняйте цю рашкологіку «всьо по закону!». Хрінові у вас закони, з ставанням в позу по суботам.

скоро це недорозуміння скриптове опиниться на свалці історії де йому і місце.

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

В рамках заранее заданных/оговоренных ограничений

І коли клієнт цих обмежень не дотримується ми теж маємо робити щось осмислене, а не просто підривати все нафіг.

Тема перешла в переливание из пустого в порожнее. То за клиента, то за библиотечную функцию. За клиента я давно пояснил — нужно валидировать входные данные. За библиотечные функции тоже пояснил — не нужно валидировать параметры и нужно писать документацию. Что ещё непонятно, я уже не знаю.

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

Видно тому мені JS і не зайшов. Ну та і грець з ним.

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

Не знаю что вам мешало или мешает с самого начала писать надежно

Та нічого не заважало, просто, як я вже пояснив, писати перевірки на null/unknown/тип на кожну операцію з будь-яким об’єктом швидко набридає і виглядає код доволі шизовазно.

Це на додачу до інших проблем які я перелічив вище.

писати перевірки на null/unknown/тип на кожну операцію з будь-яким об’єктом

Зачем? У вас в проекте говнокод?

Весь код на JS — гівнокод.

Я вже вкотре спитаю — як код JS функції може знати тип і навіть наявність значень у переданих параметрах без перевірки?

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

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

Код жс функции знает что его должны вызвать с нужными параметрами.

Яким чином в JS це енфорситься?

Если какой-то идиот вызовет с неверными параметрами

Цим якимось ідіотом може бути інша бібліотек (просто новіша чи старша), якийсь з мільйонів колбеків на колбеки якому передали параметри не в тому порядку, чи пропустили один і так далі.

почему вы не можете понять материал уровня трейни

Тому що в мене достатньо досвіду і знань, щоб розуміти дурість подібного підходу. Може на JS-трейні подібне і діє, але я знаю що в реальному житті подібний код працювати не буде.

Яким чином в JS це енфорситься?

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

я знаю що в реальному житті подібний код працювати не буде

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

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

Знову повртаємося до того що перевірки треба робити тим хто викликає функцію? Не легше їх написати в самій функції, замість примушувати кожен виклик обгортати у перевірки параметрів? Нагадаю що функцію може викликати інша функція, яку викликала інша функція, ... І кількість перевірок які має здійснювати код клієнта росте пропорційно.

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

Ну злив, так злив. На тому і розійдемося.

Я вже просто катаюсь від вашої нездатності осмислити яку нісенітницю ви несете...

Розробник знає, що функція очікує числа і пише:
```
import {sum} from ’someLib’;

const a = 5;
const b = 2;
const result = sum(a, b);
```

Якщо розробник в цій ситуації напише
```
import {sum} from ’someLib’;

const a = [5,8];
const b = {num: 2};
const result = sum(a, b);
```
то він дебіл і ніхто йому в тому не винен.

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

У внутрішньому коді проекту таке не робиться, бо розробник завжди розуміє, що і звідки береться. Перевірки будуть лише при взаємодії із вхідними данними.

Наведені приклади такі прості виключно для демонстрації — в реальному житті функції викликають інші функції, які в свою чергу викликають інші функції і так далі. До того ж в JS колбеки один поверх іншого ще додають прошарок хаосу до коду. І зміна порядку, або кількості параметрів у функції, або того які у об’єктів/прототипів властивості та їх зміст може призвести до побічних ефектів десь глибоко в коді, а проявляться вони зовсім в неочікуваному місті. І дізнатися про це вчасно нема ніякої можливості. Саме тому код на JS легше переписати ніж пофіксати.

Може для фронтенда це і не така велика проблема, бо там просто нема де і нема для чого писати велику кількість скільки-небуть складного коду. Але коли у вас бекенд на node обростає хоч-якоюсь функціональністю і має більше кількох сотень рядків коду — тут усі недоліки і невдалі моменти JS і вилазять.

Це вже ви пишете про питання організації коду, яке слід підтримувати на рівні, щоб хаосу не було чи було по мінімуму.

бо розробник завжди розуміє, що і звідки береться.

«Завжди», ага.

«Блажен кто верует, тепло ему на свете». Вибачте, повторююсь.

Ну, якщо розробник не може віддебажити код, подивившись що він наробив ге так, то хто йому доктор?

Цікава точка зору.
Зійде для компанії з Наполеоном, Цезарем та прибульцем з Альфи Центавра, що прилетів купити альбоми Винника.

У многих людей работает

Да-да, видели.
«Такси номер undefined прибывает через NaN минут.»

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

А когда и для чего требуется знать тип?

Щоб виконати осмислену операцію, отримати доступ до властивостей, провести корректні порівняння, зробити серіалізацію/десереалізацію і так далі.

Не. Это тогда не будет js. В js слежка за типами это почетная обязанность и вкусность для самого программиста. Поэтому TypeScript меня немного смущает. Можно даже сказать js с этой стороны слегка низкоуровневый.

слежка за типами

Це нажаль повсякденність і значна частина роботи коли проект на JS переростає розміром «Hello world!». Припускаю що комусь може і таке подобатися.

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

Веслування — вкусность для моряка. Долой енжінс! У нас свій, особий підхід.

До речі, в js нема типу unknown, тож на нього ви можете не перевіряти ;)

Усек. Кто пишет API тому не все равно на типы. Если прикладной программист всунет таки не тот тип а подходящий может случиться страшное (Боинг рухнет или вроде того) и кому тогда платить за Боинг? Кто будет виноват? Всунувший или в API все досконально не проверивший. Но кто пишет API на js ??????

Но кто пишет API на js ?

Ті хто пишуть ліби, фреймворки, обгортки різні та сервіси.

От чого в JS нема — так це цілісності і послідовності. Кому прийшло в голову що мати в мові null, undefined і ’unknown’ або ’undefined’ як результат операції typeof — хороша ідея?

Unknown це єресь від IE. Нема в мові такого

В тому проекті над яким я працював (близько 20 мільйонів активних користувачів і до 100 тисяч унікальних відвідувань щодня) не те що ІЕ, деяки вибрики ще більш маргінальних браузерів не можна було ігноруват на фронт-енді — бо це були кастомери які б інакше заплатили гроші конкурнетам хто підтримував і ІЕ, і Safari під Windows, і інших п’тижопих мавп.

не нужно валидировать параметры

То есть внутренний код у вас весь идеален и в нём ни одной ошибки, даже в самых маргинальных случаях и тёмных местах. Тестами с проверками типов и значений покрыли на 100%, и даже те варианты, что покрытие не берёт — отловили.
Блажен кто верует, тепло ему на свете...

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

А вы упорно это игнорируете.

Никто не пишет, что проверок быть не должно, но и не соглашается, что они нужны в каждой функции «на каждую строчку кода»

А вы упорно это игнорируете.

Потому что знаю, что полагание на «нормального разработчика» работает для кода ну экранов в десять. У особо везучих — двадцать.
После этого без линтеров и тестов с максимальным покрытием — начинается бардак, а с ними — всё равно что-то вылазит.

но и не соглашается, что они нужны в каждой функции «на каждую строчку кода»

Не «каждая строчка кода», а как минимум все входы и выходы и 100% покрытие всех веток.
И то — не хватает.

Уточните, «входы-выходы-ветки» в вашем понимании это что?

Нихрена себе ошиблись, сложили массив с объектом!

Да. Только оно возникло из того, что где-то в другом месте сделали, например, if и в одной из веток забыли снять «оболочку» в виде объекта.
Линтер это может опознать, а может и нет — его возможности не безграничны, если язык в принципе позволяет диверсию, она может случиться.
И против этого нужны уже внутренние защиты с контролем и форсированием типа значения, в большом объёме кода недостаточно это делать на границах.

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

В обоих было добавлено, когда поняли, что натворили.

Вы хотите чтобы язык со слабой типизацией работал по принципам языка со строгой типизацией. А если нет — язык плохой. Это уже неконструктивно.

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

Да. Только оно возникло из того, что где-то в другом месте сделали, например, if и в одной из веток забыли снять «оболочку» в виде объекта

Эммм... Какую оболочку в виде объекта вы забыли снять?
Расскажите подробнее, если у вас был реальный опыт складывания массива и объекта.

Эммм... Какую оболочку в виде объекта вы забыли снять?

Например, вместо [1,2] поступает {’name’: ’foo’, ’value’:[1,2]}.

Расскажите подробнее, если у вас был реальный опыт складывания массива и объекта.

Реальный опыт, да. См. выше.

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

Хотя всякие numpy, наоборот, стремятся дойти до варианта «мы можем умножить что угодно на что угодно!» и при отладке полученного надо логать или ассертить конкретный shape и другие свойства типа данных. Там это зверски нудно ловить — почти как в JS :(

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

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

Именно.

А зачем вы пытались сложить массивы плюсом, можно поинтересоваться?

Вы про то, что в JS сложение массивов не плюсом?
В данном случае я имел в виду именно то, что Python мне отказал в сложении списка со словарём. Извините, разговор получился немного бардачным.
Как аналогичная ситуация выглядела в коде для JS, я не помню. Но результат получился аналогичный — неуместная конверсия.

Собственно на простейшем примере для JS это видно, например, так:

> a = [1,2]
[ 1, 2 ]
> a.concat([3,4])
[ 1, 2, 3, 4 ]
> a.concat({'x':[3,4]})
[ 1, 2, { x: [ 3, 4 ] } ]

ну вот почему оно решило, что объект надо прибавлять как массив из одного элемента?
(хм, наверно, этот concat и был применён. судя по форме лап и хвоста.)

У меня вопрос получше: зачем вы в concat передаете объект и при этом ожидаете, что js догадается о том, что вы хотите на самом деле сконкатенировать не с самим объектом, а с массивом в свойстве x этого объекта?

У меня вопрос получше: зачем вы в concat передаете объект

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

при этом ожидаете, что js догадается о том, что вы хотите на самом деле сконкатенировать не с самим объектом, а с массивом в свойстве x этого объекта?

Потому что вы уже начали врать. Я нигде не говорил, что ожидаю, что JS догадается извлечь поле из объекта. Наоборот, я ожидаю, и явно говорил, что он просто откажется выполнять недопустимую операцию.

В смысле вру? Может неправильно вас понял. Вы тут пишете:
a.concat({'x':[3,4]}) [ 1, 2, { x: [ 3, 4 ] } ]

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

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

Потому что где-то кто-то ошибся. Несмотря на документацию и намерения (вроде бы благие)

Ошибся... бывает. Пусть исправляет свою ошибку.

Потому что язык, вместо того, чтобы способствовать ограничению ошибки, способствует её распространению.

Вы что прикалываетесь? Какой ошибки?
Язык в своей документации говорит: «Ребята, вот concat метод у массива. Всё что вы передадите ему, я добавлю в массив».
Язык сказал, язык сделал. В чём он ошибся, если он выполнил ровно то, что и обещал сделать?

В смысле вру?

В утверждении, что я ожидаю, что JS поймёт это за меня.

Вы что прикалываетесь? Какой ошибки?

Ошибки программиста. Из-за которого пришло не то, что может быть добавлено в массив.

Язык в своей документации говорит: «Ребята, вот concat метод у массива. Всё что вы передадите ему, я добавлю в массив».

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

всё понятно, было иногда приятно с вами дискутировать. спасибо

Зрозумійте що в concat можуть передаватися параметри ззовні коду який і робить виклик concat.

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

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

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

Представь что было бы если вместо вот этого был бы «Хороший код на несколько строчек». Была бы нечитаемая каша.

effects.flatMap{fromEffect}.foldLeft(Balances.empty){(balances, transfer) =>
val Transfer(agent, counterAgent, sendAmount, sendCode, received, receivedCode) = transfer
balances.addReceived(agent, receivedCode, received)
balances.addReceived(counterAgent, sendCode, sendAmount)
balances
}

То, что вы написали — нечитаемо

Не зная языка и конекста, — мб. Зная контест и язык, писать цепочками лямбд раза в 3 сокращает код, не теряя при этом понятности. Просто при этом тыкать мутабилити и AbstractSingletonProxyFactoryBean не нужно, от этого надо напрочь избавится. Кейс классы и лямбды. Мутирующее состояние в топку, циклы — в топку в след за ним. Переменные которые использутся в функции из внешнего блока — тоже в топку, всё через параметры. Классы с данными у которых есть методы — их количество к минимуму, да и ещё много всего. Тогда этот подход можно успешно использовать.

писатьцепочкамибуквразав3сокращаеттекстнетеряяприэтомпонятности

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

но.
блять.
как.
не.
работало.
так.
и.
не.
работает.
ихуйпоймигде

.это
.всё
.потому
.что
.ты
.забыл
.точку
.между


.хуйпоймигде

скобок<круглая>().маловато()

Ты еще не переписал event loop без циклов

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

Не доставай его. Все люди разные и не могут то, что могут другие.

с точки зрения кода легко, хвостовой рекурсией. (то что оно скомпилируеться в цикл, это другой вопрос)

ИМХО Тут ситуация такая: а что вам нужно?
Если нужно код зашифровать — ну не хотите вы, чтобы его украли или использовали повторно без вашего ведома — вы пишете не заботясь о стиле.
Более того (как я например) сознательно его запутываете так, чтобы хрен кто распутал. Вполне себе коммерческий прием. И очень правильный. Мой продукт труда. Я его создал. А если надо код для кого-то, тогда стилевое оформление и рефакторинг и комментирование и документирование и написание тестовой обводки. Только разве это все еще не тонна работы дополнительно? Поэтому нет ни плохого кода ни хорошего а есть требования заказчика — иногда мошеннические. А что? Написал чоткий код, который используется повторно на ять, а заказчик тебе копейку заплатил и кышнул. Так тоже не годится. Отсюда мне видится код трансформируемый — с нерабочего в рабочий только после оплаты убитых на него часов. Плюс к этому можно набрасывать на код сеточку ошибок — исправление которых дело search and replace for file my_loved_errors.txt Ибо если при капитализме способность «отбери у них все их деньги» решающая для выживания то нужно прокачивать этот скилл всеми возможными способами.

Хехе, я видел результат работы обфускаторов. После годов разгребания спагетти из говнокода, обфусцированный машиной код разруливается на раз-два.

Я думаю wasm и map и стрелочные функции в промисах это просто желание разработчиков закрыть код от непосвященных. Цеховое братство рулит. Хотя нет — не рулит. Каждый сам за себя — как удобно для «рептилоидов»

Нет это уже просто вусмерть залюбило писать руками локи и прочую лабуду, вот они и пытаются притулить монадические вычисления к джаваскрипту на асинхронщину, просто потому что эти монадические вычисления очень хорошо эту тему описывают, посмотрите на cats Effects или же Haskel IO как это там сделано.

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

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

Нет. Тут за каждым хитрым методом стоит одна вполне конкретная математичная конструкция. Вот например, для cats там вот такая иерархия

camo.githubusercontent.com/...​3616368654275737465723d33

Для хаскеля есть вот такая: wiki.haskell.org/...​peclassopedia-diagram.png

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

мутируемые балансы — нетру совсем.

Я знаю об этом. Обычно мутации я на пишу. В этом конкретном случае там была мапа на 100500 элементов и я сделал исключение.

добавить чутку форматирования, оно все гораздо красивей становиться.

effects.flatMap{fromEffect}.foldLeft(Balances.empty){(balances, transfer) =>
val Transfer(agent, counterAgent, sendAmount, sendCode, received, receivedCode) = transfer
balances.addReceived(agent, receivedCode, received)
balances.addReceived(counterAgent, sendCode, sendAmount)
balances
}

А теперь РУССКИМ языком, что здесь написано? С указанием что есть что и что ты где взял. Выучив весь код и дурак поймёт. А ты по фрагменту попробуй понять, представив на минуточку что этот код ЧУЖОЙ. Начни с переменной received — и объясни, почему я не должен подходить со ссаными тряпками к автору, если мне принесут такой код? Даже если джуны.

И как ты это намерен проверять на ошибки, окремя как писать громоздкие тесты на сотни возможных комбинация. Я предполагаю, что тесты будут «для галочки», хорошо ещё если не автогенерируемые [полезность = 0.0]. А реально ты просто ВЕРИШЬ что код работает правильно.

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

А теперь РУССКИМ языком, что здесь написано?

Вот остальное необходимое для понимания pastebin.com/pqfnRafS.
Что тут непосредственно написано. Мы берём и одним махом в виде флатмапа выковыриваем все эффекты из которых можно вытащить трансфер(без введения ненужной промежуточной колекции и ручного выковыривания что дофига строчек и полезной информации не несёт). Дальше пробегаем по всей коллекции и складываем все отосланые ассеты, и принятые ассеты, надеюсь код в Balances и Balance понятен.
val ИмяКласса(аргументы конструктора ) = экземпляр класса — это синтаксис unapply чтобы не писать через точку, ибо это громоздко. Что делают методы Balances и Balance я думаю понятно.

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

А ты по фрагменту попробуй понять, представив на минуточку что этот код ЧУЖОЙ

Ну я как бы работаю, и регулярно читаю чужой код такого вида, и никогда с этим сложностей не имел прямо вот никогда. Не важно насколько сложный синтаксис там используется(хоть higher kinds, хоть многострелочные лямбды, хоть тайп лямбды, хоть тайплевел-рекурсия, хоть path-dependednt types, хоть newtypes), его можно освоить главное чтобы , важно сколько там строчек накорябано, потому что много строчек тупо долго читать.

Хотя эта штука и не полностью функциональна (там должен по хорошему стоять immutable map и копирование, а ещё лучше написать для Balances инстанс моноида и сделать котиковский фолд комбайн), но без flatMap и foldLeft писать совсем печально.

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

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

И как ты это намерен проверять на ошибки, окремя как писать громоздкие тесты на сотни возможных комбинаций

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

хорошо ещё если не автогенерируемые [полезность = 0.0]

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

А реально ты просто ВЕРИШЬ что код работает правильно.

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

И связь между избыточностью кода и защитой от ошибок для тебя не очевидна

Это тут не работает. Кодобаза это не база данных и не хадуп где живучесть данных обеспечивается репликацией. Чем меньше кода тем быстрее и легче его пересмотреть и проверить. Если этот код ещё и проверяется тайпчеком — то он ещё надёжнее если ты этот тайпчек умеешь использовать.

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

в Scala как раз с этим, если писать всё правильно, то всё хорошо:
— есть implicit’ы что служат evidence’ами о возможности выполнений операций над типами
— есть tagged types что можно использовать для ограничений значений типов
Так что хорошо написанный в таком стиле код можно даже пруверами и фазерами проверять. Фазеры даже одна из самых частых либ для тестирования поддерживает. Но, с другой стороны — кто ж так пишет, с evidence’ами-то?

кто ж так пишет, с evidence’ами-то?

Я пишу, и ещё людей знаю.

Нужно делать так, как нужно. А так как не нужно — делать не нужно.
©Винни-пух