Если плейщики стоят 3600, то сколько будут стоить zio/sttp/http4s -разработчики?

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

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

на это уходит каждый раз много времени, в никуда.

что оно никому не впилось, на практике.

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

с теорией функций

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

боюсь от тестов (в одном или ином виде) не убежать

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

когнитивная цена далеко не нулевая.

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

Composability дело наживное

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

Они описали часто используемые шаблоны

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

как в классической среде

классическая среда это как раз конструктивная математика из которой выросло ФП. Оно появилось задолго до тех кто выдумал паттерны.

Вы описываете реализацию паттерна в частном контексте фп подхода и языка. Как это противоречит тому, что я написал?

я уже описал почему это не паттерн и чем отличается, просто вброс или не читал.

стратегия будет обычной функцией, фабрики и декораторы так используются, chain of responsibility вшит в ивенты, паб саб тоже повсеместно. Это все тот же ГОФ, только без рецептов для джав

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

узнаваемости их при общении

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

узнаваемости их при общении, а не в форме исполнения

. Это раз. Во вторых — в паттерны не заложена ни soundness, ни completeness, ни composability, я не могу наверняка сказать какими свойствами будет обладать фабрика декораторов стратегий, и даже не могу наверняка сказать, будет ли в действительности названая страхолюдина а не что — то на неё похоже. А вот какими свойствами будет обладать стрелка/монада/клейсля/моноид — я знаю, ведь у них есть формальные законы. Кроме того, я вполне могу писать код поверх этих абстракций и описывать какие-то их преобразования, которые бывают полезны. Самый простой и банальный пример — перестановка F[G[_]] в G[F[_]] aka метод сиквенс, в скале это ровно один def в котиках, в ооп — каждый раз переизобретается в точке использования. Паттерны этого не могут. Вообще, совсем, от слова никак.

А всё почему? Потому что паттерны слепили Expert Beginner в области построения теорий. Люди которые клепали прикладные системы и нащупали какие-то абстракции но в силу отсуствия культуры построения теорий не смогли сделать из них что — то стоящее(но побежали продавать и тыкать в каждого программера на перевес и быстрее всех).

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

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

Лицо рука. Паттерны сами по себе не дают

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

. Это достигается за счёт обобщающей способности системы типов. Вот без хкт вы не сможете сделать абстрактную монаду без хаков системы типов через касты/дейнемик или рек бойлерплейта. Вам нужно будет на каждое F[_] и T рисовать свой отдельный инстанс монады(читай делать кодоген, что жутко гимор и ломко вбольшинстве языков, а ещё комбинаторно сложно потому что покрытие, скажем всех коллекций джавы монадой для каких-нибуть там 1000 бизнес сущностей это будет уже десятки тысяч классов из пустого места) и подставлять его через di или кодоген снова, что обысно ненадёжно. Точно так же и с вашими паттернами — вам нужно изобретать велосипед в точке его применения — переписывать заново каждый раз. Но у вас просто нет другого выбора — ваша система типов и отсуствие вменяемых макросов/кодогена и стейджинга делает свое дело. Безхктшные системы типов и полиморфизм через инвазивную реализацию хорошо работает только на мутации, да и то очень ограниченно. А как мы с вами все хорошо знаем, что код с беспорядочными мутациями в асинхронном контексте = забыть о возможности понять что там творится. Это кстати, причина если не всех то почти всех флаки тестов — беспорядочна недетерминированная асинхронщина.

Потому что эта деформация конкретно ограницивает ваш кругозор.

можно написать рабочее, поддерживаемое читаемое и масштабируемое приложение БЕЗ использования ГОФ паттернов. Особенно на TS/Пурсе.

Экспоненциальная кривая сложности, гораздо проще чем логарифмическая для новичков.

Я не зовсім розумію, де ви знайшли про бухгалтерію

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

Problem solving skills

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

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

 Люди это не ресурсы, но вы торгуете их временные ресурсы на средcтва, так вот цена по которой вы их продаете/покупаете и есть софтскилл.

Вміння працювати з такими людьми певний час — далеко від

Почему же, при подстановке такой образ := не травил команду и делал свое дело до тех пор пока необходим всё становится на место.

Тут у вас в статье терминологическая неувязочка нарисовалась.

Корисність технічних навичок, або як їх називають hard skills, спеціаліста визначають лише щодо конкретного проєкту чи навіть конкретного завдання.

Увы но нет. Problem solving skill — хардскилл, не поверите, но именно он описывает то насколько вы хороший инженер для каких — то абстрактных, отвлечённых задач в вакууме. Этот перк очень полезен и он как раз таки тренируется в процессе работы, и он полезен во всём о чём вы дальше пишете.

Пов’язувати будь-які погони вище Middle/Junior тільки з hard skills, тобто технічною експертизою інженера, — короткозорий підхід. Так здебільшого вважають мідли та джуніори. Але таке сприйняття може бути у будь-кого: і сеньйор-інженера, і архітектора, і менеджера, і CTO. Технічні навички — звісно, необхідна складова, але цього недостатньо, щоб бути професіоналом своєї справи.

Пассаж очень обтекаемый но не очень смыслоёмкий.

Senior, Principal, Lead, Architect — всі ці звання вимагають не просто кодити швидше, знати більше фреймворків чи мов і парадигм програмування, а вміти оцінювати й планувати час і ресурси наперед — свої та команди.

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

знати більше фреймворків чи мов і парадигм програмування

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

Хтось може заперечити, що планувати — то справа не розробника, а PM’а, але я відповім, що кожен Senior має бути трошки PM’ом. Планування — спільна відповідальність.

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

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

Про остальное пожалуй промолчу, потому что очень много всего.

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

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

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

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

«Если гора не идёт к магомеду, тогда магомед идёт к горе», нет магомед сидит на месте и говорит что гора — неприступная.

дайте 5 ссылок на новый подход к архитектруре в ПО, и все.

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

там ничего об архитектуре.

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

там ничего об архитектуре.

softwarefoundations.cis.upenn.edu вот один, остальные надо приводить?

Мне вот очень интересно, а как

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

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

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

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

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

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

ТО в школе нигде в мире не учат, потому что оно там не нужно.

СТО на уровне программ ВВС — учат.

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

но это всё ковбойские unsound поделки для победятл-драйвен девелопмент.