ну да, почему ж нет

Рантайм у .NET — отличный, OCaml — человечный.

нафига только

Умудрились и спросить и ответить :) Потому и нафига что человечно и null не словишь

если DDD — это та самая древняя идея ООП где в П слито И проектирование и программирование. За которое это самое ООП и ругают ;)

Другими словами, прикольно, вы рассказываете о торжестве функ парадигмы, и тут же вворачиваете тру ООП метод — DDD ;)

Все всегда всех за все ругали и будут ругать. ДОУ свидетель :) А вот хоть DDD и ассоциируется с ООП плотно, в ФП с выраженной DSL у него больше жизни и оно заходит натурально без танцев. Умные дядьки уже и книги написали: pragprog.com/...​modeling-made-functional

слушайте, вот правда.
Вы не в курсе списка из тысяч и тысяч позиций ПО написанного на императивщине? аналогичного, замечу :)

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

в каких это — ваших?

в большинстве реалий — скорость разработки важнее :)
читабельность — один из способов ее обеспечения

Если скорость разработки по временной шкале разложить и допустим вы энтерпрайз делаете, то да, на первых порах скорость разработки будет выше на Пайтонах или Джс, но через пару-тройку лет увы она будет падать, а костыли расти. Вот тогда и заговорите о статической типизации и ФП и т.д.

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

Еще одно заблуждение. Мышление человека ни объективное ни функциональное, а скорее ассоциативное. То что вы потратили годы на изучение ООП и паттернов и сделало вас тем кем вы есть. ООПшник со стажем будет охеревать от ФП и думать что это дикий треш и математика. И это норм. Парадигмы разные. Нужно время на осознание. Другой вопрос что если вы возьмете студента с 0 опыта в ЯП и начнете его учить ФП сразу, то он быстрей зайдет туда чем зашел бы в ООП. У меня интерны заходилы в тему за год и потом плевались на ОО как на дикий треш и мега-сложную диковину. Так что тут вопрос стереотипов скорее

Какой-то полный сумбур. Цены почему-то завышены, но при этом частных клиник нет. Откуда цены-то взялись тогда? Страховка ни разу не помогла, но при этом об очередях написано. Типа не достоял? :)

Не помогла потому что все было в пределах собственного риска — до 385 евро. Т.е. я плачу 235 евро * 12 — обязательная страховка и если болею до 385 евро лекарств — опять же я из своего кармана. Гос-во и страховые имеют всех. Стариков и беженцев много , нужно выкручивать руки своему населению и работающим экспатам

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

Школы тут бесплатные официально. Только нужно платить за обеды и инногда сборы на выездные мероприятия

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

В данном случае SqlGateway это модуль, а getReservedSeats ф-я в нем определенная. Самый простой аналог Dependency Injection в FP — передать ф-ю в качестве параметра. Заглушку можно , но от нее толку мало. Что ты тут тестировать будешь? Я предпочитаю энд-ту-энд тест для прогона всей логики. И тесты на граничные значения для отдельных ф-й

Я вот ни разу не заметил. Просто лепишь интерфейс и все. Как два пальца в розетку. Все равно 95% кода и костылей — это бизнес-логика.

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

Расскажите о своей — практике :)
но сколько не спрашивал о практике ФПистов — либо ничего внятного, либо — страшно далекие от — обычной практики, в лучшем случае в очень специлизированных доменах, или в R&D

Замена C# на F# как языка общего назначения на проекте. Web API, микросервисы с DDD, тулзы генерации данных для e2e тестов. Это конкретный и реальный опыт. Вот статья по результатам успешного внедрения с кодом на Github: danyl.hashnode.dev/...​es-with-fsharp-and-zeromq

А еще больше написано и прямо сейчас пишется — НЕ на ФЯ
при этом и названные бренды — состоят из множества подсистем написаннных не на ФЯ

Думаю там хватает разного. И из их R&D выходят достаточно массовы продукты такие как Kafka или Apache Spark

Вот когда хотя бы это будет достигнуто, то да
Достигли?
А могли, например статически решить Halting problem? ;)
а такого у нас в программировании — ого сколько.

Не юлите :) Halting problem это из разряда неразрешимых проблем в алгоритмической области и мало связанных с конкретными реализациями ЯП

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

разрешать фундаментально неразрешимые проблемы?

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

в каком — домене.

Для большинства доменов годно.

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

Это опять же из серии алгоритмов. ЯП — инструмент. Где-то алгоритм можно выразить более читаемо и математически где-то нет

А швидкість розробки — завжди була головним рушієм розвитку комп’ютерних мов

Скорость разработки это главный двигатель бизнеса, но никак не computer science.

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

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

Тобто мені цікаво дивитись на цей хайп навколо «типізація нас спасе!» саме тому що він — протирічить головному рушію розвитку МП останніх 3 а той 4 десятиліть :)

Это из той же серии :) Она давно уже спасла. На сегодня наверное самая мощная типизация в Haskell и Rust (из того что мне известно) и да, там мантра такая что если оно компилируется — значит работает. Выстрелить себе в ногу практически невозможно. Да, да, сейчас полетят огурцы с воплями так там порог входа большой и это не язык масс. Ну вот тогда и мучайтесь со своими массовыми языками и их болячками и костылями и сетуйте на застой в индустрии все следующие 20 лет.

І я теж вірив тоді що ось він, прорив! І був впевнений що C++ всіх змете.
Ну, тепер нове покоління, з тих же причин віріть у фп, чи що там зараз? Ну, з досвідом за роки будуть дивитись на інше покоління, якє буде вірити у точно великий прорив завдяки X, а не тому древньому гівну мамонта — фп.

Не, не, новое поколение верит в Github Copilot :)

А что такое индустриальные языки? Опять же языки масс или языки индустрии? Какой индустрии, их тысячи? В большинстве случаев действительно, продукты пишутся людьми с недостаточным образованием. Но это не значит что нет качественных продуктов на функциональных и других языках, только они преимущественно в индустрии tech, computer science, fintech, telecom, distributed, ML и т.п. Примеры WhatsApp, WeChat, Kafka, Spark и т.п. Более того все теже Фейсбуки (React) и Эриксоны (Erlang) и иже с ними изобретают свои языки в функционльной парадигме для решения своих задач для которых существующие инструменты они сочли не вполне приемлимыми. В том же FB есть внутренние продукты на Haskell и OCaml. Знаю пару успешных и больших контор в Нидерландах в Эйндховене которые пишут на ф-х языках продукты. В основном manufacture домен. С бумом облак будем видеть все больше и больше функциональщины — AWS Lambda, Azure Functions, etc. Там этот подход заходит на все 100

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

прошли годы, и теперь уже ФП — класссное, идеальное, и та серебрянная пуля, что наконец-то!

вот только — причины то, почему в идеальном — разочаруются — остались :)

Оно-то так, но пока не попробуешь не поймешь. На базе опыта ООП и ФП есть с чем сравнить и не в пользу ООП, к сожалению. Просто констатирую сухой личный опыт.

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

Единственное что сейчас реально свежо идейно — Rust. Когда умудрились и скорость не убить за счет ручной сборки мусора и компиляции в натив код, а соединить парадигмы — FP, generic, concurrent, structured и все это безопасно. Но конечно же будут петь песни что порог входа высок и массам не зайдет.

Думаю что у вас высокий уровень скептицизма и недоверия из-за отсутствия ФП практики.

Из того что слышали и написано на функциональных языках WhatsApp, WeChat, Discord, Facebook Messenger, Spark, Kafka и много другого. В каждой из FAANG компании найдется куча проектов. Много тулзов и опен сорса.

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

А идея использовать компилятор вместо юнит-тестов это же мечта. Система типов Хиндли — Милнера позволяет это. В Haskell, F# вы объективно пишите очень мало юнит-тестов, компилятор дает достаточно гарантий. Что используется так это property-based тестирование на крайние границы, где генерятся абсолютно рандомные данные для входа в функцию и проверяется не ломается ли выход. Это все что нужно.

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

То есть, можно вместо SQL базы подсунуть NoSQL, вообще не трогая код бизнес-логики. Значит — нужны обертки над всеми чужими модулями, которые будут адаптировать модель, используемую чужим модулем (SQL / NoSQL в нашем случае) к модели домена, с которой работает бизнес-логика. FP позволяет эти обертки не писать?

Это все тоже можно конечно же. Можно разные модули в них описать разные имплементации. Главное аргументы входа-выхода, это и есть АПИ.

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

Она и есть. Hexagonal, Onion, Clean — все одни и те же яйца, только профиль разный. Доменные модели это ADT-шки и бизнес-логика чистые функции над этими типами, могут даже быть в одном модуле. Вычитка из БД и обратно, это какой-нибудь database модуль. Пайплайн все это собирает в нужном порядке:

let check capacity reservedSeats reservation =     if capacity < reservation.Quantity + reservedSeats     then Failure CapacityExceeded     else Success reservation

let imp =     Validate.reservation     >> map (fun r ->         SqlGateway.getReservedSeats connectionString r.Date, r)     >> bind (fun (i, r) -> Capacity.check 10 i r)     >> map (SqlGateway.saveReservation connectionString)

Здесь check чистая доменная логика, перед ней лезем в БД проверяем наличие свободных мест, послее нее сохраняем резервацию — пишем обратно в БД. Более подробно тут: blog.ploeh.dk/...​re-is-ports-and-adapters

Все так же и работает. Железяк докидывают и кафку тюнингуют :)

И чем это все заменяется?

Гексагоналка в FP дефолтно — держишь IO снаружи, бизнес-логика в ядре посередине — чистые функции, все разобрано по модулям, пайплайн — сборка. Тут такое называют functional core, imperative shell или impure/pure/impure.
Пример — blog.ploeh.dk/...​/03/02/impureim-sandwich

Далее, ADT для моделирования с встроенной семантикой сравнивания по значениям. В ООП нужно базовый класс ValueObject и переопределять Equals() и GetHashCode(), наследоваться от него. Для Entity типов другая семантика. Потом еще доменная валидация и обработка ошибок и много чего другого.

Ну у нас и область такая, молодая, что универсального рецепта не изобрели. Посмотрите как формируются например комманды под проекты или продукты: на основе единственного тех. стека или субъективных предпочтений, а не исходя из анализа продукта, требований и NFRs. История из жизни в телеком домене: просто потому что техлид знал NodeJs собрали комманду таких же и начали писать сервисы для обработки миллионов sms и сообщений с других мессенджеров, где быстродействие и отказоустойчивость основные критерии системы. Стоит ли говорить что ицидентов уйма и код достаточно падкий. Судя здравому смыслу и инженерному чутью выбор должен был пасть на Erlang/Elixir или на Rust для прогрессивной молодежи, но уж никак не NodeJS. Более того в современных реалиях и комманды должны быть мультипарадигменные.

1. все моделирование предметной области преимущественно — объекто-ориентированное

И очень зря. Как практикующий DDD и в FP и в ООП, скажу что в FP предметная область выражается куда более лаконично и однозначно благодаря более мощной системе типов. В ООП много танцев с бубнами и сложного кода... моделирование value objects, entities, repositories, shared kernel и семантики, разделение на слои по hexagonal/onion стилю требует знаний и усилий. Более того из-за отсутствия discriminated union типов, модельки получаются слегка убогие и их нужно допиливать напильником.

2. состояние в enterprise — персистентно, то есть хранится в БД. и все в память сервера — не влезет. и для эффективности — явно-неявно кешируется в слоях системы

А и не нужно. Есть ORM и Lazy Load для этого. Кэш вообще никто не мешает прикрутить , даже отдельно стоящий. Вот отличный анализ почему ФП лучший выбор для ентерпрайза (на примере F#): fsharpforfunandprofit.com/...​best-enterprise-language
В частности потому что нет null, все таже система типов и возможность создавать доменные DSL эффективно.

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

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

потому что — «а на типы не ложится...»

Так вроде бы мы же за строгую типизацию топим, не? :) Это прекрасно когда ты чего-то поменял в бизнесс-логике, а компилятор тебя томатами закидал, мол слышь, ты иди тут и там поправь, а. Это вам не джс где ждешь сюрпризов в рантайме.

он разный. для лендинг страничек — может ФП и сгодится
для екомерс — см выше про enterprise

Почему тогда ныне так любимые всеми фронтендерами мира реактивные расширения — чистой воды функциональщина (RxJs, Redux)? :)

Про enterprise — fsharpforfunandprofit.com/...​best-enterprise-language

Ой думается мне что далеко не весь тот C++ который в embedded лучше структурирован чем тот же Си :) Но возможно вы и правы

Классика жанра. Можно еще дизайн от поведения для более прикладных художественных жанров :)

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

Поэтому я и говорю что для embedded C++ как лишняя нога :) Вы и не пользуетесь ООП, зачем оно вам там нужно? Фасады и логику напилить для этого ООП не обязателен :)

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

Чем дизайн в виде структур и действий над экземплярами этих структур — отличается от дизайна в виде классов/объектов? Ничем.

Так в чем тогда отличие от дизайна для Lisp или Haskell? Там тоже структуры, только называются по-другому и действия над ними. Так можно и ФП назвать ОО по вашей логике :)

Собственно, принципы СОЛИД использовались для написания качественного сишного кода, до возникновения C++ (тем более жабо-шарпов). Иначе, нереально было бы написать на «си» ту же винду (с кодом размера в сотни человеко-лет).

SOLID это фирмовая сборочка от дядюшки Боба из 2000-х, Design patterns: elements of reusable object-oriented software вышла в 1994, LSP изначально был озвучен только в 1988, а вот C++ родился в 1985, Си и того раньше.Так вот, раньше, когда писали таких слонов как ядро юникса или линукса, пользовались общими принципами модулярности, DRY, KISS и конечно же прямыми руками. Позже когда начали заходить массы, им уже и книги понаписали и хорошие практики в паттерны сложили.