Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Функціональне чи об’єктно-орієнтоване програмування: що обрати і чому варто звернути свою увагу на Clojure. Поради для початківців

Серед розробників програмного забезпечення постійно тривають дебати стосовно того, яка парадигма програмування має більше переваг: функціональна чи об’єктно-орієнтована. Маючи на меті розробку гнучких програм, вони відрізняються своїми підходами до вирішення тих чи інших проблем.

Мене звати Андрій Стабрин, я Team Lead в компанії Agiliway. У цій статті розглянемо основні принципи та переваги функціонального програмування, а також поговоримо про те, чому Clojure, як одна із ключових мов цієї парадигми, є альтернативним методом традиційному ООП.

Однією з основних ідіом програмування можна вважати принцип Don’t Repeat Yourself (DRY), коли задля скорочення частотності повторення коду в програмі, а також ефективного оперування сутностями предметної області, використовують абстракції. Якщо на початку за допомогою 0 і 1 оперували напряму з фізичною частиною, то згодом винайшли ассемблер, що уможливив символьне представлення інструкцій (закодованих різними варіантами мов ассемблера) в двійковий код. Саме це можна вважати першим рівнем абстракції, який дозволяє писати програми і оперувати даними з предметної області, не вдаючись в деталі реалізації.

Чому функціональне програмування

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

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

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

Щодо мов програмування, то до функціональних відносяться Lisp, Hope, Haskell, ML, Erlang, а Java, Python, C++, Ruby, Swift, Objective-C, Vala — об’єктно-орієнтовані.

Імперативний підхід vs. Функціональний підхід

Імперативне програмування описує стиль програмування, що моделюється як послідовність команд (імперативів), які змінюють стан. Традиційний цикл for є чудовим прикладом імперативного стилю програмування, наприклад: встановити початковий стан і виконати серію команд для кожної ітерації циклу.

Скажімо, у вас є список імен, деякі з яких складаються з одного символу, і вам необхідно повернути рядок з іменами, розділеними комами, з вилученими іменами з однієї літери, а також кожним іменем з великими літерами.

На конференції Strange Loop творець Clojure Річард Хікі у своїй доповіді «Simple Made Easy» заново представив термін complect: приєднувати, сплітати разом; переплітати.

В об’єктно-орієнтованому програмуванні доволі часто доводиться сплітати, ускладнювати завдання, аби мати змогу обробити їх всіх у єдиному циклі. В такому випадку необхідно виконати наступні кроки:

  1. Відфільтрувати (filter) список, щоб виключити окремі символи.
  2. Перетворити (transform) список, щоб капіталізувати кожне ім’я.
  3. Конвертувати (convert) список в один рядок.

На імперативній мові необхідно використовувати той самий низькорівневий механізм (ітерація над списком) для всіх трьох типів обробки.

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

Вищевказані категорії (filter, transform і convert) представлені як функції, які реалізують перетворення низького рівня, але покладаються на розробника, щоб налаштувати машину низького рівня з функцією вищого порядку, що передається як один із параметрів.

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

Мови функціонального програмування віддають перевагу кільком ключовим структурам даних (таких як list, set і map) з високо-оптимізованими операціями на цих структурах даних. Ви передаєте структури даних плюс функції першого класу, щоб «підключити» ці операції і налаштувавши їх для певного використання.

Функціональне програмування

Об’єктно-орієнтоване програмування

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

Складові функціональної парадигми

Серед основних компонентів функціонального програмування виділяють:

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

Clojure як одна із ключових мов функціонального програмування

Розроблена у 2005 році, Clojure належить до мов родини Lisp, яка є однією із найстаріших груп мов програмування. Річ Хікі, творець Clojure, зазначив, що хотів створити сучасний варіант Lisp, що зможе працювати на Java Virtual Machine (JVM) та володітиме функцією паралельного програмування.

Clojure — це функціональна мова програмування, яка підтримує функції як об’єкти першого класу, незмінні і, так звані, ліниві дані. Clojure має доступ до бібліотек, що розробляються для JVM, завдяки своїй сумісності з цією платформою. Така взаємодія дозволяє викликати код і реалізовувати класи, що використовують Java або інші JVM-сумісні мови. Іще однією особливістю взаємодії Clojure з Java є те, що Clojure ефективно працює з масивами Java. Позаяк масиви — це не колекції, то Clojure може створювати масиви, взаємодіяти з їхніми окремими частинами, конвертувати дані, і т.д.

Те, що структури даних на Clojure — незмінні, значно спрощує процес виконання завдання програмою. Якщо говорити про багатопотокове програмування, то використання Clojure теж буде значною перевагою, оскільки ключові структури даних можна з легкістю «шерити» між потоками. Що ж до використання змінних структур, то, при потребі, можемо використовувати Software Transactional Memory (STM).

Серед основних характеристик Clojure, які приваблюють розробників, варто зазначити:

  • динамічність — завдяки використанню циклу читання-обчислення-друку (REPL (Read-evaluate-print loop)) Clojure дозволяє відобразити результати обчислень відразу ж після введення виразів.
  • генерація байткоду для JVM
  • ліниві послідовності
  • рекурсія
  • паралельне програмування
  • мультиметоди, і .т. д.

Які недоліки Clojure

Оскільки Clojure дещо відрізняється від інших поширених мов програмування, то розробнику знадобиться трохи більше часу аби вивчити цю мову і звикнути до специфіки роботи з нею. Також, через великі об’єми пам’яті необхідні для коректної роботи, Clojure може працювати дещо повільніше.

Якщо ви не використовуєте такі платформи як JVM або JS, то ви не зможете використовувати Clojure на своєму проєкті.

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

Для яких проєктів найкраще використовувати Clojure

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

  • маркетплейси;
  • стрімінгові платформи;
  • FinTech;
  • Machine Learning;
  • Data Analytics.

Серед іменитих компаній, які вже використовують Clojure, є Adobe, Amazon, Apple, SAP, Oracle, Microsoft, Capital One, Clubhouse, eBay, Facebook, Grammarly, Netflix, paper.li, Salesforce, Spotify, Walmart, та інші. В Україні — маркетплейс Kasta, а також оператор супутникового телебачення Viasat.

Висновки

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

Серед ключових мов в парадигмі функціональній варто виділити Clojure як сильного опонента Java. Завдяки своїй багатогранності, мова Clojure показала себе як гнучкий та динамічний інструмент у роботі з великими об’ємами даних.

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ну первым реально нужно изучить ооп, если твоя задача грести бабки лопатами. Но если ты вдруг сомнительной ориентации, и тебя вместо денег и женщин, интересуют computer science, научная работа, а также математика, и понты когда непонятно что ты сказал: матюк или что-то на хаскельском, то да там нужно ФП. В теории и с помощью ФП можно грести неплохие деньги, но чаще всего у таких людей за плечами нехилая математическая база, с которой он бы грёб деньги просто нашкрябав что-то на глиняной табличке в пещере.

Якщо хочете легко знаходити оффери на 7к$+ то ООП звісно. Та й взагалі — якщо хочете мати великий вибір. У крайньому випадку поєднання ФП та ООП, на кшталт Scala

А что на счёт ФП в Scala и прочей биг дате?

apache storm: 1я версия была на clojure, 2 — переписали на java
apache flink: 10% scala, 85% java
apache spark: 65% scala
akka: 60% scala, 40% java

Scala — мультипарадигменный язык, как постоянно повторяет Одерски, и в одном интервью мне показалось что даже несколько раздраженно, в ответ на что-то типа: «а что насчет ФП, вот в Haskell/Idris/Agda вот такое есть, а в Scala — почему нет, когда будет?»

Конечно, использовать Scala только как улучшенную Джаву, особенно когда есть Kotlin, по моему микроскопом гвоздезабивание. Но и ставить знак равенства — проект на Scala? значит там ФП! — тоже — не стоит.
мультипарадигменный означает что будет там всего. Пропорции в общем случае — неизвестны.

Конечно, использовать Scala только как улучшенную Джаву, особенно когда есть Kotlin, по моему микроскопом гвоздезабивание.

Да, но Kotlin используют преимущественно в Android разработке и довольно-таки эффективно. На счет как замены для остальной Java, насколько слышал от джавистов, пока еще нет той поддрежки по библиотекам и остальному.

По тому что пишут на Scala — в основном сложные распределенные системы и платформы. Не знаю насколько много in-house софта и бизнес-ориентированных систем на Scala, но наличие ADT и ф-й с композицией должно позволять красиво делать DDD со всеми сопутствующими штуками а-ля event sourcing, CQRS и т.п. Другое дело что не все разрабы/конторы готовы осваивать этот швейцарский нож с его 88 версиями :)

все так.

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

а кто сказал что DDD — основной тренд, признак тру проектирования? ;)
помнится, и как-то в последние несколько лет наткнулся опять на большое обсуждение на rsdn года 2009го, о его серьезных недостатках :) Сам Эванс тоже в последние годы сказал что-то об ограниченности применения DDD. не нагуглю скоро.

и я тут откопал один прогноз на 2022, из 2012го, поместил в соот теме

там коммент есть, не мой, но активно согласен:

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

redp • 9 лет назад
цинично вспоминает

начало 2000х — в ближайшие десять лет функциональное программирование станет более
популярным. Уже сегодня мы можем наблюдать рост интереса к таким языкам как ocaml, dylan & K

начало 1990х — в ближайшие десять лет функциональное программирование станет более
популярным. Уже сегодня мы можем наблюдать рост интереса к таким языкам как common lisp & scheme

начало 1980х — в ближайшие десять лет функциональное программирование станет более
популярным. Уже сегодня мы можем наблюдать рост интереса к таким языкам как lisp & sml

Dmitry Popov • 9 лет назад:
И ведь все сбылось, оно каждый раз становилось более популярным! :)

redp • 9 лет назад:
ну да, ну да
еще лет 40 буквально — и таки догонит php, бгг

eax.me/world-2022

P.S.
и совсем неверно понимать что я против стат типизации, DSL, ФП и т.д.
адепты и их верования — вот что меня обычно интересует в холиварах :)

а по серьезному — то вполне правда от одного хаскелиста в лондонском банке:
На предыдущей работе у меня произошла интересная история с Haskell. У стартапа был Node.js-сервер, которым занимались десять разработчиков. Они написали 300 тысяч строк кода и 600 тысяч строк тестов. Это такая особенность JavaScript — тестов нужно очень много, поэтому их получилось вдвое больше, чем полезного кода. Но компания не могла платить людям конкурентные зарплаты, поэтому их хантили другие работодатели и JavaScript-разработчиков не хватало.

Однако новый техдиректор решил переписать всё на Haskell. Сначала он написал небольшой сервер — и за два года в нём ничего не сломалось. После этого он нанял двух разработчиков (одним из них был я).
Вместе мы за полгода переписали весь JS-код на Haskell.

Как другое, тоже — правда:
Мы попросили нашего лидера бэкэнд разработки, рассказать о том, как они с командой параллельно с поддержкой основного продукта собрали новую модульную структуру сервиса на базе PostgreSQL, перенесли бизнес-логику в базы данных(на ХП) и провели миграцию с миллионами пользователей.
...
Я пришёл в Х в Dt руководить бэкэнд разработкой. Тогда бэком занималась команда из 8 разработчиков и 2 админов, которые обслуживали монолит на 1 миллион строк кода преимущественно на PHP. Чтобы внедрить даже небольшую новую фичу, уходило 2 месяца. А затраты на инфраструктуру на 10 000 активных пользователей превышали 1 000 $ в год.
(конец цитат)

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

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

P.P.S.
Почему так происходит? Просто создавать доказано корректные программы слишком дорого, долго и непонятно, кому это поддерживать. В общем и целом, непрактично
... иногда разработка доказанного алгоритма/приложения не только непрактична, но и попросту невозможна.

Почему людям не нужна корректность и на 100% рабочих программ, похоже, вообще не бывает

Это все только подтверждает то, что есть инструмент и есть руки его держащие — не все те руки знают как инструмент работает :)

а кто сказал что DDD — основной тренд, признак тру проектирования? ;)

Никто. Смотря какие системы строить, часто оно и нафик не нужно. Все таки DDD позиционируется для сложных доменов и как по мне, помогает разрулить сложность и читаемость кода (хотя и привносит другую сложность).
Кстати все тот же Эрик Эванс уже долгие годы сожалеет о том, что он поместил Entities, Value Objects, Repositories и прочее в начало книги, т.к. читатель дальше не осиливает, а все интересное как раз дальше — про то как готовить слона, стратегии, дизайн, трансформации и поведение.

Про поплуярность FP я тут противоречий не вижу. В последние годы вот позапихивали кортежи, record types, pattern matching и прочее ФП в C# с которым я работаю уже лет 13. А LINQ так вообще в 2008 туда впихнули. Вместо C# можно смело подставлять Java, Python и т.п. Вопрос, зачем и как это коррелирует с популярностью ФП? Можно ведь и без этого обойтись, делать все по Бучу и паттернам банды 4-х, ведь классика OOD

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

Адепты они везде отдают привкусом религиозности. Разве адепты ООП или DDD другие?

Кстати все тот же Эрик Эванс уже долгие годы сожалеет о том, что он поместил Entities, Value Objects, Repositories и прочее в начало книги

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

чего да, вообще не замечают когда говорят о DDD :)
поэтому и с адептами DDD нет смысла серьезно обсуждать — DDD
они со страрта: «Эванса не читали» :)

адепты ООП или DDD другие?

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

кортежи, record types, pattern matching и прочее ФП

хотя и кортежи, и record types — это универсальные структуры данных, на которые адепты ФП «почему-то» наложили «монополию» :)
а pattern matching — развитие «микро DSL»

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

Вопрос, зачем и как это коррелирует с популярностью ФП?

никак. оно ж непопупярно, да и все :)

Про поплуярность FP я тут противоречий не вижу

а как вы как адепт можете увидеть это? никак.

но будет популярным, да. скоро. вот-вот.

хотя и кортежи, и record types — это универсальные структуры данных, на которые адепты ФП «почему-то» наложили «монополию» :)
а pattern matching — развитие «микро DSL»

Уже вдруг стали универсальными? :) Вот смотрю топ-лист фич C# 9.0:

    Records
    Init only setters
    Pattern matching enhancement
    Lambda discard parameters

В C# 11 обещают завезти discriminated unions. Тоже станет универсальной структурой данных внезапно? :) А как на счет LINQ? Или extension методов которые вообще ни разу не ООП а больше напоминает mixins в JavaScipt? А те же records которые вы назвали универсальной структурой почему-то идут в наборе с non-destructive mutation и read-only семантикой и по оператору сравнения. А имьютабилити так все и пропитано, это ли не одна из главных фич ФП?
Так что все выглядит как раз до наоборот — ООП ребята уверовали что это универсальные структуры данных и развитие микро DSL :) Лет через пяток так вообще будут веровать что ф-и высшего порядка это всегда была фича ОО :) Вон как молодые японцы например уверены что на Хиросиму и Нагасаки ядерные бомбы сбросил СССР

Там где вы видите только разговоры о популярности ФП, я вижу что синтаксис и стиль написания кода на чисто ООП-шных некогда ЯП давно мигрировал в мультипарадигму (чаще это микс ФП и ООП) и сейчас уже найти код в классике OOP/OOD становится все сложней — очень уж все разбавлено extension methods, LINQ, pattern matching и это только будет продолжаться. А в том же JS вообще никогда не было дизайна по классике ООП с его прототипированием и ф-ми возможностями — он всегда был миксом.

а pattern matching — развитие «микро DSL»

Да ладно, не юлите... а в контексте ЯП что есть DSL? :)

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

Да, F# в Microsoft долго был в R&D, там обкатывали идеи и внедряли в C# и успешно делают это до сих пор. Последние лет 5 F# активно стали двигать и развивать как самостоятельный продукт, даже у VB.NET такой вот поддержки почему-то нет. VB оставили в основном для устаревших веб-форм и язык не развивается.

Как я уже говорил, мейнстрим он не из-за его высокой эффективности таковой, а потому что так сложилось. Через N лет C# 20 или Java 20 будут возможно слегка отличаться синтаксисом от F#/Scala при этом будучи полноценно мультипарадигменными ЯП с охеренным уклоном в ФП, но адепты ООП и любители динозавров все так же будут рассказывать байки о непопулярности ФП и эффективности учений Карла Маркса Гради Буча при этом не замечая что у них в коде почему-то рекорды заменили классы, switch/case волшебным образом превратился в паттерн-матчинг, а чтобы войти в режим классики ООП/ООД им теперь нужно явно входить в режим legacy-compatibility :)

Уже вдруг стали универсальными? :)

да. такими были от рождения.

Кортеж — упорядоченный набор фиксированной длины
В математике корте́ж или n-ка (упорядоченная n-ка) — упорядоченный конечный набор длины n (где n — любое натуральное число либо 0), каждый из элементов которого x_i принадлежит некоторому множеству X_i

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

LISP, появился в 1958

смотрю топ-лист фич C#

а C# - не универсален. Это — конкретный ЯП, в котором — мало ли как они поддерживались и не поддерживались

Тоже станет универсальной структурой данных

утрировано, все что можно выразить, и выражалось, и использовалось в LISP в 60ых — универсально.

А как на счет LINQ?

а что с ним не так? насколько помню основную идею — затянуть деклративность SQL, ее принципы внутрь ЯП

почему-то идут в наборе с non-destructive mutation и read-only семантикой

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

ООП ребята уверовали что это универсальные структуры данных

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

и это же все описано и у Буча, и у Бека, и в большинстве книг 80ых и 90ых

но адепты не читали ж Эванса, а потому древние идеи и то что на них базируется — мнят как свежее.
Другими словами низвергли одних динозавров, чтобы молиться другому же такому же(!) динозавру :)

Вон как молодые японцы например уверены что на Хиросиму и Нагасаки ядерные бомбы сбросил СССР

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

Там где вы видите только разговоры о популярности ФП

разговоры — видит статистика

и сейчас уже найти код в классике OOP/OOD становится все сложней

а был ли он, в классике то когда-либо? ;)

А в том же JS вообще никогда не было дизайна по классике ООП с его прототипированием и ф-ми возможностями — он всегда был миксом.

ну да, и?
вы как истинный адепт создали себе жупел, и пытаетесь с ним сражаться?
ну как ярко например евангелисты скрама сражаются с «водопадом», которого никогда не было. и в статье Райса — тоже :)

а в контексте ЯП что есть DSL? :)

Когда вы определяете набор функций или классов для работы в определенной предметной области, вы тоже создаете DSL... Всякие ORM — это тоже DSL
(http eax.me/tag/filosofiya/)

Когда вы называете осмысленно переменную — вы уже двигаетесь в сторону DSL :)

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

ну вы еще теорию заговора приплетите :)
это ж главное в адептовости — нефальсифицируемость.

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

Через N лет C# 20 или Java 20 будут возможно слегка отличаться синтаксисом от F#/Scala

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

любители динозавров все так же будут рассказывать байки о непопулярности ФП

а адепты о — популярности :D

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

вообще-то структуры с прибитыми к ним методами обработки — делались и на plain C
адепты конечно слишком молодые, чтобы успеть забыть что

Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.

и уверенно вещают о динозаврах, яйца которых при этом и сейчас едят почти каждый день :)

switch/case волшебным образом превратился в паттерн-матчинг,

а идея у обоих вещей — универсальна :)
хоть if-elsами ее запиши

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

некогда ЯП давно мигрировал в мультипарадигму (чаще это микс ФП и ООП)

ну да, про это постов 10 или 20 тому и написал:
добрался постмодерн и к нам
ему, постмодерну, уже около ста лет где-то :)

очень свежая идея — мультипарадигменность, да.

LISP, появился в 1958
утрировано, все что можно выразить, и выражалось, и использовалось в LISP в 60ых — универсально.

Ну не комильфо адепту ООП ссылаться на Lisp в таких количествах :)

Когда вы определяете набор функций или классов для работы в определенной предметной области, вы тоже создаете DSL... Всякие ORM — это тоже DSL

Когда вы называете осмысленно переменную — вы уже двигаетесь в сторону DSL :)

Посмотрел бы я как вы используете ORM на одних только осмысленных переменных :) DSL без полноценной поддержки на уровне системы типов и/или компилятора это ни о чем.

ну вы еще теорию заговора приплетите :)
это ж главное в адептовости — нефальсифицируемость.

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

Конечно. Ведь религия не позволяет пойти по ссылке с видео в моём 1-м камменте о том Why Isn’t Functional Programming the Norm? от Richard Feldman с достаточно скурпулезнеым анализом вопроса. Ведь это ж тоже адепт какой-то. Наверное ваша база более обширная и правильная :)

вообще-то структуры с прибитыми к ним методами обработки — делались и на plain C

Возвращаемся к структурным языкам? Давайте еще фортран с коболом помянем. Бьерн Страуструп смотрит на вас с неодобрением... Cи не есть C++, не надо только вот на структуры данных оттуда ссылаться, там ни наследования тебе, ни конструкторов с деструкторами , ни полиморфизма без напильника через vtable :)

а идея у обоих вещей — универсальна :)
хоть if-elsами ее запиши

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

А вся western музыка базируется на 7 нотах (12 если с хроматизмами). Но тут и рэпчик и попса и джаз и классика. А девятую симфонию Бетховена можно и битбоксом сыграть при отсутствии скрипки и контрабаса :)

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

Он же по другому не может, поэтому уверен что и остальные не могут :)

Далее про имена — демагог всегда от идей перейдёт к тому что какой-то дядя аяй скажет, а какой-то нет.

Насчет 7ми нот — то ясно, понятно, вы — не в курсе разницы между способом описания и самого описываемого.

Ох уж эти адепты...

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

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

Далее про имена — демагог всегда от идей перейдёт к тому что какой-то дядя аяй скажет, а какой-то нет.

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

Насчет 7ми нот — то ясно, понятно, вы — не в курсе разницы между способом описания и самого описываемого.

Это вообще мимо.

Ох уж эти адепты...

Ну вот опять... :)

Поищите по текстам где я уже рассмотрел постулаты вашей веры

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

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

Мимо о 7ми нотах — это вы приравняли способ записи к виду музыки.
Теософы на рубеже 19го 20го веков ух теории на этом строили.

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

Функціональне чи об’єктно-орієнтоване програмування

Почему обязательно «или»? Почему не «и»?

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

А що, на кложур щось уже написали велике? Ну хоча б там редактор тексту? років тому на кложур катали якийсь редактор, який так і помер нікому не потрібний )))) чи, ну чатілку якусь, типу скайпу чи зума? Чи за межі пророцтв Річа так далі і не вийшла мова 👉😂 так навіщо переходити на те, на чому нічого не написано за 14 рокік (і не буде написаним) 🧐

Два тижні тому спитав в сотий раз адептів ФП і ліспу показати якісь прикладні апи накатані на їх парадигмах та мовах: youtu.be/sRAwe3kIHQQ чомусь так ніхто і не відповідає. Як і 5 років тому. Так і через 5 років 👉🥳

Згадав, LightTable. Автори теж віщали, як ФП крутіше за ООР, як ООР це по факту іго розробників... зараз за два роки зроблять революцію розробки...

В ітоге...Річ закешив кложур банку, а ви далі слухайте і лапшу нюхайте від чергових месій 👉🔥🥳

Серед іменитих компаній, які вже використовують Clojure, є Adobe, Amazon, Apple, SAP, Oracle, Microsoft, Capital One, Clubhouse, eBay, Facebook, Grammarly, Netflix, paper.li, Salesforce, Spotify, Walmart, та інші. В Україні — маркетплейс Kasta, а також оператор супутникового телебачення Viasat.

також на оф. сайті згадуються декілька прикладів: clojure.org/...​community/success_stories

Якось сумно для мега мови, яка заміняє цілу парадигму і підходи ООР (на якому написано все). Хочеться прикладів типу: фотошоп, КАД, ігровий двигун по типу юніті, редактор ворд, екселька. Мова ж така крута, що можна за 50 рядків все зробити...

А по факту: можна конвертать жсони тікі і продавать кросівки онлайн 👉🙄

підходи ООР (на якому написано все).

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

Дадада. Відкриваєш Юніті: class A : MonoBehavior. Відкриваєш флатер: class B extends StatelessWidget. А от де ФП? Кложурі 14 років уже як. Ціле покоління виросло

github.com/...​MonoBehaviour.bindings.cs

github.com/...​rc/widgets/framework.dart

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

стоп. ти розповідаєш, що ФП І кложур це прямо лікі від хвороб ООП. При цьому на ООР пишеться ВСЕ, що фундаментальне. А не як на кложурі — магаз для бариг чи якась тула по процесінгу жсонів. Я привів приклади величезних фундаментальних програм, так і нових колосальних проектів. Якщо в команді з трьох програмістів кложур заходить (ну там в базу покласти жсончік, потім викласти назад в ДОМ), то це як раз і є свідчення ущербності всіх ліспнутих мов. Херак-херак не дарма ж головний кложурист України придумав ))

з твоїх же лінок сам доводиш, що фундаментальні речі в новому фреймворку для хплатформи і ігровому рушії Unity (який на 5 років молодший за кложур лол) всі написані в ООР стилі.

При цьому, кложур старший на 5 і 10 років відповідно від цих програмних продуктів, але на ньому досі нічого немає (і не буде) навіть близько. Якийсь порт в реакт (у якого теж class A extends Component), який ледь живий є, але це просто лол.

Это плевок в сторону Kasta? )))) Я про кроссовки...

ні. слухав наче на айті борода, чи схожому каналі інтервью з СТО якоїсь е-комерц шараги з росії )))

Так это не шарага, а kasta.ua, не рашка, а вполне себе такой Киев и не СТО какой-то, а такой себе Соловьев, всея кложурист Украины))))

Я з ним 5 років учився :))

Я слухав подкаст айті борода російський, там якийсь апологет функціональщини розпинався за F#, яке це майбутнє. Потім виявилося він СТО е комерц шараги і пишуть на рагулярі, ноді і C# :)))

Когда всплывает Closure, всегда вспоминается этот доклад:
www.youtube.com/watch?v=bR-sJAI2Mts
Кстати, «чик, чик и в продакшн» это оттуда )

«Что лучше, ООП или функциональщина? И почему именно Closure»

Не «що краще». А що обрати для конкретного проекту/задачі

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

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

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

потом, встретил что они ломанулись из хаскеля на скалу.
понятно почему — платят лучше за ЯП на JVM

Сейчас на джинне висят десятки для Раст + Блокчейн.
Правда, в Линке для джавистов тоже публикуют десятки в ленте.
А вот С++ и эмбеддед отстает — разве что по передаче видео бывают позиции.

А вот С++ и эмбеддед отстает — разве что по передаче видео бывают позиции.

Похоже, не там копаешь. Меня по европпкам заваливают предложениями на эмбед (впрочем, в основном, германские автомотив и медицина). Никогда такого за последние лет 10 не видел.

Так ты же не в Украине сидишь?

Так ты же не в Украине сидишь?

Ну да. Зачем же ограничивать себя Украиной? :)

P.S. Впрочем, там и удалёнка временами проскакивает...

Не на кого оставить родственников.
А если хорошая удаленка с возможностью из Украины — сбрасывай. На 10k net или народ найду, или сам возьму. Тут сейчас 7-8к верх волны, думаю, на десятку большинство согласится. И без локального менеджмента)

BTW если скучно, или надо народ в помощь t.me/embeddedkyiv

BTW если скучно, или надо народ в помощь t.me/embeddedkyiv

В «телеграме» меня нет, но буду иметь в виду. :)

Сейчас все уползли в него из скайпа.
Какие еще варианты?

Какие еще варианты?

Доу? :)

Но я законтачил тебя в Линкедине.

Я когда-то выучил питон, увидел аж 3 вакансии, и переучился на С++.
А сейчас Питон — модный.

А мог выбрать сениор фронтенд девелопер на реакте и вдруг оказывается, что зарплаты в топе, а сам реакт + редакс — это вполне себе ФП, а если накинуть сверху рамду, то от хаскеля не отличить))

выбираю сениор девелопер на хаскеле и вижу цифру 0 в графе зарплаты.

Так это и показывает реальный уровень нужности фп для всей сферы іт

До C++ был C with Classes, который никто не знает и который не взлетел. Т.е. сама по себе ОО как концепция не сделала бума в истории программирования. По словам Бьерна Страуструппа, только после того как он добавил уйму других фич и на базе C with Classes создал C++, тогда взлетело. Но это было не потому что ОО. Тогда еще никто не понимал как это все вот использовать, а авторы ныне бестселлера Design Patterns: Elements of Reusable Object-Oriented Software тогда еще в школу ходили. Далее была Java, которая была направлена изначально на C++ аудиторию, ибо самая большая популяция и монетизация. Далее .NET версия Java и теже мотивы. Brad Cox стремился к модулярности и все что он знал на то время был Smalltalk по стечению обстоятельств. Так и вышел Objective-C. Опять же, не из-за популярности ОО. Прекрасный исторический анализ почему ФП не являектся дефолтом сейчас в этом видео: www.youtube.com/...​q0v7Z4&ab_channel=Metosin

От себя добавлю, будучи 15 лет ООП евангелистом, преимущественно C++ и C#, я только сожалею о том что так поздно подсел на ФП. Последние 3-4 года в теме и хочу сказать что это в первую очередь парадигма которая позволяет писать действительно архитектурно чистый (onion, hexagonal, clean по дефолту, без костылей), поддерживаемый и сжатый код, а главное не выстрелить себе в ногу на продакшне. ФП со строгой типизацией такие как Haskell, Scala, F#, позволяют уже на уровне системы типов описывать домен с помощью ADT, а компилятор как правило куда более строже чем в том же C# или Java.

А ФП был всегда, Lisp был еще задолго до первых попыток ОО.

Смешались в кучу кони, люди...

До C++ был C with Classes, который никто не знает и который не взлетел. Т.е. сама по себе ОО как концепция не сделала бума в истории программирования.

В смысле, не взлетел? Именно этот «С с классами» — и есть самый нормальный/портабельный и работающий вариант «плюсов». Поэтому он и используется в наиболее мишн-критикал вещах, типа эмбеда (если уж вообщe используются «плюсы»).

А что касается ООП — в этом стиле программы писались и до «плюсов». Скажем, вся винда включая ХП — была написана на C. Виндовый АПИ это тоже C. Но стиль написания — вполне себе ООП.

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

В смысле, не взлетел? Именно этот „С с классами” — и есть самый нормальный/портабельный и работающий вариант „плюсов”. Поэтому он и используется в наиболее мишн-критикал вещах, типа эмбеда (если уж вообщe используются „плюсы”).

Из интервью с Бьерном.

CUJ: When/how did you notice that C with Classes was becoming something that was going to consume much of your time, if not your career (in other words, not just a temporary interest)?
BS: Somewhere in 1982, I realized that support of the C with Classes user community was becoming an unacceptable drain on me. As I saw it, the user population had become too large for one person to serve well while also doing research, but too small to support an infrastructure. I had to decide whether to develop C with Classes into a more flexible and expressive language, or to drop it. Fortunately, I didn’t think of a third alternative — which people point out is the conventional solution — which is to gather more users through hype. Through C with Classes, I decided to further develop the combination of valuable ideas from C and Simula that I had experienced. The result was C++. I tried to "escape’’ to other work on several later occasions, but always the growth of the C++ community and the challenges of new applications kept me involved.

C с классами трансформировался в C++, где оброс многими фичами и после чего обрел свою популярность, но не благодаря классам в первую очередь. Иначе бы C with Classes был бы в топе. А то что где-то в embedded его еще используют об этом мало кто знает и опять же вопрос зачем? Там чистый C куда эффективней. Мнение Линуса Торвальдса думаю тоже всем известно, все линуксы и юниксы и иже на Сях.

Сейчас все заточено чтобы писать в ООП парадигме, даже когда в этом нет смысла. Только сейчас началась движуха в осознание этого, например в последних версиях C# появилась такая штука как top-level statements — больше не нужно писать static void main() {..} и все это обрамлять классом Program. Можно one лайнером: Console.WriteLine("Hello, World!"); Опять же из примеров как развивается C#, то в последних 4-5 релизах они в основном тягают фичи из F#... ибо нечего более предоставить ОО парадигме.

Сейчас все заточено чтобы писать в ООП парадигме, даже когда в этом нет смысла.

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

Собственно, поэтому ООП-подход использовался для создания софта, задолго до появления ОО-языков.

ОО дает весьма так себе абстракции для моделирования сущностей реального мира и в довесок кучу велосипедов чтобы как-то это склеить. Domain-driven-design куда тяжелее делать на ООП чем на ФП, благодаря их алгебраическим типам данных.

Вот вам пример кода для описания типов в карточной игре:

module CardGameWarDomain =   type Suit = Club | Diamond | Spade | Heart   type Rank =     | Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten     | Jack | Queen | King | Ace   type Card = Suit * Rank   type Deck = Card list   type PlayerName = string   type Player = {Name:PlayerName; Deck:Deck}   type Pile = (PlayerName option * Card list) list   type Deal = (Deck * Player list) -> Player list   type Battle = Player list -> (Player list * Pile)   type War = (Player list * Pile) -> (Player list * Pile)   type PickPile = (Player * Pile) -> Player   type Game = (Deck * Player list) -> Player

Имплементация самой игры с раздачей карт на руки из колоды, логики и подсчета еще 100 строк.
Теперь удачи вам в ООП сделать тоже самое с классами, иерархиями и т.п. :)

Собственно, поэтому ООП-подход использовался для создания софта, задолго до появления ОО-языков.

Вы сами поняли что сказали? :) Как можно использовать несуществующий подход? До ОО было только процедурное (fortran, algol, cobol) и ФП (lisp)

Удачи в имплементации системы управления на ФП. Примеры:
* Кнопочный телефон
* Калькулятор
* Рендерер (например, браузера)
* Робо-собака

Что ваc смущает в калькуляторе-то или телефоне? С состоянием в ФП тоже можно отлично работать и моделировать, если намекаете на это. Есть полно примеров калькуляторов тех же

Возможно где ФП пока не очень хорош это интенсив десктоп ГУИ с интерактивностью и где очень много стейта. А для того же embedded на арену вышел Rust , многообещающий и мультипарадигменный.

В телефоне реал-тайм, в калькуляторе — работа с состоянием. Реакция на нажатие кнопки зависит от истории. Чем тут ФП удобен?
Rust уже много лет одинаково многообещающий. А эмбеддед все равно на С.

Ради перформанса, я бы в embedded c ФП не ходил. Одним кейзом меньше. Опять же с тем же Rust так же быстро как С++ но еще и безопасно

Но для 90% остальных случаев вполне более удачная замена ООП: web-dev, cloud, APIs, microservices, enterprise, machine learning и т.п.

В С/С++ основная идея — ручная коробка передач. Хочешь — разложи данные в памяти так, чтобы кеш лучше работал. Хочешь — кинь структурку с информацией об ассерте в область, которая при ребуте не обнуляется, и будешь помнить, на какой мине подорвался. Хочешь — отслеживай таймлайны и подстраивайся под дедлайн.

Думаю, разница в control flow vs data flow.

Control flow — это ООП, как бильярд — чуть-чуть не так пнул, и покатились вообще не те шарики и не в ту сторону. Обработка данных минимальна, и 100500 вариантов разных событий в ответ на один стимул. Simula же.

Data flow — тут FP может работать, потому что для всей входящей информации одинаковые правила игры. Задал правила, запустил — и оно побежало. Сиди, пей чай. Пайплайны.

enterprise

ФП неудобен:
1. все моделирование предметной области преимущественно — объекто-ориентированное
2. состояние в enterprise — персистентно, то есть хранится в БД. и все в память сервера — не влезет. и для эффективности — явно-неявно кешируется в слоях системы
3. с развитием системы — бизнес-логика — постоянно будет меняться, при — неизменности персистентных данных. на практике — изменяться костылями и заплатами. которые еще и требуется написать быстро, а не заниматься перепроектированием доброй трети всех алгоритмов, потому что — «а на типы не ложится...»

web-dev,

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

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

В ООП много танцев с бубнами и сложного кода... моделирование value objects, entities, repositories, shared kernel и семантики, разделение на слои по hexagonal/onion стилю требует знаний и усилий.

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

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

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

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

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

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

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

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

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

ValueObject

Очень малая часть кода. Основное — это наросшие годами костыли из-за постоянных изменений бизнес-логики. if ... else if ... for ... if ... полотна

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

Она и есть. 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

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

В статье автор пишет:
It’s possible to implement a Ports and Adapters architecture with object-oriented programming, but it takes so much effort. Does it have to be that difficult?
Я вот ни разу не заметил. Просто лепишь интерфейс и все. Как два пальца в розетку. Все равно 95% кода и костылей — это бизнес-логика.

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

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

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

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

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

Оригинал гексагоналки alistair.cockburn.us/hexagonal-architecture как раз указывает возможность протестировать бизнес логику, не используя базу или сеть, как один из основных плюсов. Быстро, качественно, воспроизводимо.

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

И чем это проще, чем в ООП?

И чем это проще, чем в ООП?

В той же статье автор и намекнул :)

The problem with this architecture, however, is that it seems to take a lot of explaining:

    My book about Dependency Injection is 500 pages long.
    Robert C. Martin’s book about the SOLID principles, package and component design, and so on is 700 pages long.
    Domain-Driven Design is 500 pages long.and so on...

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

В ФП обычно ADT кратко и сжато выглядят, семантика сравнения по значениям дефолтна, DI это передача ф-й или partial application чтобы зашить агрументы и т.п.

Вот тут все объяснили за 3 страницы alistair.cockburn.us/hexagonal-architecture и это — оригинал. Где архитектурная сложность?

DI, SOLID и даже DDD — мантры, их люди покупают в надежде не думать, а следовать правилам.

По синтаксису со стороны гексагона нужен класс, со стороны адаптеров — интерфейсы и классы. Вы у себя ввели модули и функции в них. Чем это отличается от интерфейсов (класс + методы)?

«Обертки» — это адаптеры? Так Вы же как раз хотите абстрагироваться от конкретной базы, к примеру. Как это сделаете без обертки? Или думаете, что функциональная обертка проще ОО?

«Переопределение семантики сравнения» — вообще не вкурил что значит. Можно в ОО терминах?

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

Я о чем? О том, что гексагоналка с акторами пишется на голом С++98 & pthread за пару месяцев одним человеком. Без сторонних библиотек. Без следования SOLID/DI/DDD. Здравый смысл + понимание, где грабли лежат.

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

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

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

я к чему.
в холиварах по ФП я уж не помню сколько лет :)

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

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

Оригинал гексагоналки alistair.cockburn.us/hexagonal-architecture как раз указывает возможность протестировать бизнес логику, не используя базу или сеть, как один из основных плюсов. Быстро, качественно, воспроизводимо.

В этом и прелесть портов и адаптеров. ФП по умолчанию тестируемо без явных архитектурных подходов. Есть функция и ее агрументы: вход. Есть результат — выход. Если ф-я передается в качестве параметра (high-order functions) то ее можно подменить — аналог stub, mock

Есть функция и ее агрументы: вход. Есть результат — выход

называется — процедура, в процедурном программировании :)

Если ф-я передается в качестве параметра

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

это — функциольная парадигма? ну то есть ее топовая киллер-фича?

А когда у Вас там надо передать 200 функций — Вы из по-одной передаете? Ну тогда это классика спагетти.
Или Вы их объединяете? Ну тогда это — интерфейс по определению. Мы вернулись в ООП.
А функции в качетсве параметров — так в линуксе драйвера этим сделаны. На С. Процедурное программирование всегда называлось.

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

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

if ... else if ... for ... if ... полотна

а другого — и не получится :)

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

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

и тут вдруг вводная
если гипотенуза — красного цвета, то площадь этого треугольника:
1/2 (a × h) + h / 8.3

почему? откуда 8.3?
с Небес. Маркетологи так сказали — делайте как велено!
что еще у нас посыпется следом?

и это — не только в бизнес-логике так
бац и setTimeout (func, 200)
почему, что? а эмпирически выявили что группа серверов (железяка) отдупляется для второго запроса не раньше чем через 100 мс

то бишь — эти if ... else if ... for ... if ... полотна — продиктованы эмпирическими данными, которые появляются после проектирования и создания системы.
а перепроектировать систему, в связи с изменениями в «ТЗ», ну...

и если в систему невозможно вставить if ... else if ... for ... if ... без перепроектирования, потому что она вся така типизированная претипизированная, и так правильно спроектирована что хоть доклад на xxxConf делай — то все. не жилец эта система в проде.

...слышал байку что великого Грема, Пол который, лиспер, погнали ссаными тряпками с Yahoo и команду его. и все великое его — вынуждены были выбросить
но — неточная информация, в каком-то обсуждении где-то кто-то обронил мнение, может все было совсем и не так. но — очень коррелирует с моим практическим опытом :)

И очень зря. Как практикующий DDD и в FP и в ООП, скажу что в FP предметная область выражается куда более лаконично

а лаконичнсть — не тот критерий для качественности выражения чего-либо :)

COBOL и Джава — признанные многословы.
И ничего, на COBOL и сейчас крутятся весьма сложные системы.
Оказалось — даже там где деньги есть — инженеры с математиками не могут предложить как переписать с COBOL на что-то правильное :)

Читабельный код — не обязательно лаконичный. А бывает как раз наоборот.

В ООП много танцев с бубнами и сложного кода...

есть такое дело. ФП просто никто не проверял, сколько там будет сложного кода, и времени разработки :)

Да и ООП — это не обязательно DDD.

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

естественно. но лучше такие — чем никаких. А «математика» — никаких не предлагает :)

Есть ORM и Lazy Load для этого

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

Вот отличный анализ почему ФП лучший выбор для ентерпрайза (на примере F#

не нужен никому анализ.
покажите — результат.
Первейший критерий — скорость разработки увеличилась на десятки процентов.

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

Покажите систему где это подтверждено — практикой.
Magento на php — да, расширяема быстро
Как и презренный Wordpress — даже малоквалифицированными программистами

Покажите на практике системы на ФП, которые с такой же скоростью позволяют добавлять новый функционал :)

Вот представьте как пайплайн работает, это будет ваш бизнес-воркфлоу.

бизнес-воркфлоу завтра поменяется. не поменяется, так обрастет исключениями «из правил».

Так вроде бы мы же за строгую типизацию топим, не? :)

Я? наоборот — нафик ее.

В английском же мы не рассуждаем
call — это существительное или глагол?
а понимаем смысл из контекста употребления

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

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

тесты надо писать. они и свалятся.

Это вам не джс где ждешь сюрпризов в рантайме.

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

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

потому что Цукерберг — пхпист.
И идея реакта — такая же. Генерим все по новому, а не пытаемся точечно изменить состояние.
Это следом уже появился Redux.

Но мне лично MobX больше нравится, в сочетании с React.
А RxJs — вообще, в действительности мало кто использует.

Просто мода такая — поговорить о том какой он крутой.
Втяни в проект — узнаешь цену этой крутизны :)

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

Или что — веб проект? а, ну понятно, это значит он у вас в амазоновском облаке крутится.
угу. Про кафку кругом говорят, и вакансий где она упоминается — ого. Ну все, значит она кругом в проектах? ;)

Оказалось — даже там где деньги есть — инженеры с математиками не могут предложить как переписать с COBOL на что-то правильное :)

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

ам другая проблема

случайно вышло, встретил пару подробных обзоров причин.
это ширнарамассное заблуждение о «создатели на пенсии, тестов нет»

такое же как и
та пхп это ж всего лишь темплейт язык генерации HTML

Во многих случаях — нет даже исходников

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

А если хоть один костыль пропустить

так аналитики ж с математиками то не пропустят! ни одного костыля! Они у-у-у, они о-о-о!

штраф впаяют за бухгалтерию.

а система писанная на устаревшем COBOLе, без авторов, исходников и тестов — работает.

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

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

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

давайте их — правильными программистами заменим, а?

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

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

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

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

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

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

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

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

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

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

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

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

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

В смысле? Бизнес уже давным-давно переписывает кобольное. Думаю, как минимум, с 2000-го (когда заодно массово расколупали кобольные программы насчёт «Y2K»-проблемы). Многие начали и раньше.

Собственно, сейчас кобольных ваканcий практически не встретишь — а если и встретишь, то это как правило переписывание.

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

да. потому что это — реальная его проблема
и? когда ж наконец будет финал?

Собственно, сейчас кобольных ваканcий практически не встретишь

у нас? ессно.
IBM — курсы открыла. 2 years ago, интересное обсуждение например
www.reddit.com/...​_cobol_next_week/fn2k6h6

и? когда ж наконец будет финал?

Что такое «финал»? Это ведь чисто корпоративные вещи, которые каждая компания/банк решает со своей скоростью.

Скажем, я ещё в 1998-м в Киеве работал на нескольких кобольных проектах (авиа-системы по тикетам/резервированиям, расписаниям и всему такому, амерской авиакомпании из топ-3 тамошних авиа-перевозчиков), которые готовили к переписыванию на «плюсах». Думаю, уже давно переписали.

Что такое «финал»?

Когда — там на COBOLе система? да ну нафик, не верю.

Это ведь чисто корпоративные вещи, которые каждая компания/банк решает со своей скоростью.

Разумеется все считают деньги, и переписывать ради переписать то что работает — не будут.

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

А я — не думаю, что на плюсах переписали :)
А если бы и думал — то это не аргумент, что я думаю.

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

Дешевле — находить тех пару человек что нужны для саппорта.

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

Более того, в переписывании заинтересованы все (от менеджеров конкретного проекта, до директоров) — т.к. переписывание это бюджеты/баблос т.е. жирные зарплаты/бонусы. А оплачивают собственники (как правило, акционеры).
Так что, наверняка переписали — другое дело, что скорее на жабе, которая где-то тогда появилась и набрала популярности.

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

Дешевизна — это не аргумент.

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

Так что, наверняка переписали — другое дело, что скорее на жабе, которая где-то тогда появилась и набрала популярности.

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

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

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

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

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

Ми в 2006-му писали source-to-source транслятор з COBOL в Java.

Дуже нетривіальна задача.

(Кінцевий замовник — американські приватні тюрми).

Угу. Ще розповідали що взагалі код не треба буде писати: CASE-системи все замінять — сидиш, малюєш абстракції на UML, потім «легким движением руки, брюки превращаются ...брюки превращаются... превращаются брюки... в элегантные шорты».
Так-би мовити ідеальний waterfall: описав процеси — отримав код.
По факту з корисного вийходило тільки доменну модель накидати і знегерувати структуру бази. Ну і реверс-інжиніринг готової бази в красиві картинки.

Не тільки розповідали а й продавали за добрячу ціну uk.m.wikipedia.org/wiki/Rational_rose та подібні.

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

Мені більш цікаво — чому прорив не можливий. Чинників багато, але які топові. І може — як що топові отакі — то все ж можливий?

А хайпуюча молодь, то такє. Завжди так було і буде.

А що є прорив?
Підвищення продуктивності?

От скриптики на пітоні значно швидше написать, ніж на С++, і його простіше вивчити, аніж шелл з усім зоопарком. От і прорив в написанні тестів.

От stackoverflow піднявся — і час на компіляцію нового С++ коду сильно зменшився. Також прорив, я вважаю.

Та й, зрештою, на Джаві ж не марно пишуть — бо ж не треба думать за пам’ять, вказівники, та батарейки велосипедить. Хіба не прорив для ентерпрайзу? На С++ мав би довше писатись і сильніше смердіть.

Сильніше/слабше смердіть? Я б сказав — «по іншому». )
«Талановитий» програміст завжди знайде спосіб вистрелити собі в ногу. Що б там йому не підказували IDE і різні статичні аналізатори. )

В кількамільйонному легасі на підлозі з пів-метра граблів, і усі виставлені гостряками догори)))

А про IDE: не усі проекти вони можуть розпарсить(

Підвищення швидкості розробки йде постійно. Не тим так іншим способом.

Проривом бы я назвав те що вирішить проблеми у програмуванні що були озвучені ще десь у кінці 60их/початку 70их.

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

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

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

Спасти ж — все одно не зможе бо до цього ж — не спасала :)

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

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

так.
якщо у ядрі лінукс для операцій
с = a + b
буде генеруватись маш код
який перевіряє властивості a, властивості b, вибирає дію «+» враховуючи ці властивості
то сплата за електроенергію у дата центрів чимало збільшіться

іншими словами — стат типізація — то і є «ручна оптимізація». так колись було з LISP vs C, Smalltalk vs C++
одной з причин перемоги С та C++ — можливості на рівні мови займатися ручною оптимізацією, але щоб не дуже страждати
а у LISP та Smalltalk ціх можливостей — не було

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

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

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

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

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

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

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

я никогда не занимался computer science

я — разработчик ПО.

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

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

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

На сегодня наверное самая мощная типизация в Haskell и Rust

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

но я — разработчик ПО, и не занимаюсь computer science

Ну вот тогда и мучайтесь со своими массовыми языками

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

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

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

Хаха, классный пример :)
Так а кто мешает определить тип водка, подгузник, презерватив, детское питание? Можно из базы разлаживать в discriminated union типы в рантайме по такому же принципу как ОРМки раскладывают в иерархии с наслоедованием, а ф-я которая скидки насчитывает явно имеет правило что если в товарах присутствует водка (тип) и презервативы (список типов) то f(скидка) = (кол-во презервативов * номинальную цену) * 0.1

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

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

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

Так а кто мешает определить тип водка, подгузник, презерватив, детское питание? Можно из базы разлаживать в discriminated union типы в рантайме по такому же принципу как ОРМки раскладывают в иерархии с наслоедованием, а ф-я которая скидки насчитывает явно имеет правило

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

там мантра такая что если оно компилируется — значит работает

Вот оно и работает. Но заказчик почему-то недоволен. А времени на новую типизацию неделя ушла (или месяц?). А в ООП это делается парой костылей без типизации за день. С таким же результатом.

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

Да поздно уже изучать что-то. Разве вдруг предложите 10k net на новых технологиях с оплатой времени обучения. Без оплаты обучения висят такие позиции по крипте с растом, но не думаю, что возьму там максималку сразу после смены стека.

А по поводу парадигм — прошу внимательнее присмотреться к процессу написания адаптера на ФП:
1) У нас есть база, она на выделенном сервере или в облаке.
2) Мы пишем к ней адаптер. Если у нас хоть какая-то нагруженность, то адаптер будет держать пул открытых сессий, чтобы не устанавливать сессию и соединение на каждый запрос.
Вывод: у адаптера появилось состояние
3) Если мы хотим иметь возможность подключать разные базы — то нам надо написать несколько адаптеров, по одному на базу. И они должны предоставлять одинаковые функции.
Вывод: появился полиморфизм между адаптерами
4) Начинаем писать адаптеры для разных баз, и обнаруживаем, что у MySQL и у MariaDB очень много общего, даже установка сессии. А вот с PostrgeSQL уже меньше, но функции по созданию и разрыву сокетов и шифрования — одинаковые. Мы же не хотим код дуплицировать? В результате у разных адаптеров появляются общие функции.
Вывод: у адаптеров теперь иерархия с наследованием

Итого: как только мы затянули архитектурный паттерн (Ports and Adapters aka Hexagonal Architecture) из ООП мира, он нам отравил наш ФП проект. В результате мы на ФП языке заимплементили ООП ручками (для иерархии адаптеров выполняются все 3 принципа ООП, и у адаптера есть состояние) вместо того, чтобы положиться на поддержку в компиляторе.
Вывод: применение старых паттернов натягивает сову ФП на глобус ООП.

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

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

адепты ФП говорят что за таким программированием — без памяти=состояния — будущее!
ну ок.

Похоже два ООПшника убедили себя в ущербности ФП и нашли себе агрументы :)
Конечно же это состояние, оно ломает парадигмы :) Поздравляю! :) А вот детей и интернов не трожте, они умней чем вы думаете :)

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

в реальном мире знаете ли у треугольника сумма углов никогда не равна 180 градусам

А вот детей и интернов не трожте, они умней чем вы думаете :)

давайте обсудим, как вы им ФП даете, детям :D
и через сколько времени они могут что-то сделать самостоятельно.
про годы и годы изучения ООП вы уже сказали
на ФП — дети у вас уже когда змейку на условном «питоне(+Pygame)» могут сделать?
есть набросок вашего учебного плана для детей, интересно бы посмотреть — когда там выхлоп, с кривой обучения более пологой чем у ООП

А в Scratch вже можна створити N монстрів одного типу з різними параметрами?

Бо вони релігійно колись захищали необхідність копіпасти.

О, нарешті!

en.scratch-wiki.info/wiki/Cloning

А в Scratch вже можна створити N монстрів одного типу з різними параметрами?

так. Спрайт — то як клас та одночасно об`ект
хоча звісно все простіше, клони мають в prototype спрайт чи клон
тобто від клона теж можна робити клон

інша річ що там немає pointerів на клони

для студентів є Snap!
snap.berkeley.edu/snap/snap.html

от там багато що є з дорослого програмування

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

ось тобі Snap!- ти його в перший раз бачиш — чудово!
Зроби кнопковий калькулятор та формульний, з кнопками перемикання режимів між ними

як на мене — це покаже набагато більше ніш задтротство задачок з літкоду.

На Snap! також дивився, але з дітей один переконаний гуманітарій, один бізнесмен, а один ще не доріс.

Scratch було в них в школі, але якогось особливого захоплення ні в кого не викликало.

Ну нічого, якщо доживу до внучок, то доберуся з тим всім побавитися...

дітям вистачить Scratch
Школа — то такє, відбивання інтересу до всього що там вивчається :)

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

але з дітей один переконаний гуманітарій

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

Бо новачкам і комп грамотність даю тихенько, а не тільки Scratch :)

а один батько написав — ви за 12 занять дали те, що в школі ще чіпали, причому син нудився отим шкільним Scratch, а тут — та прямо не відірвати

Вы тут смешали и людей и коней...

2) Мы пишем к ней адаптер.
Вывод: у адаптера появилось состояние

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

По остальному вы просто не знаете других способов проектирования кроме ООП. Архитектурный паттерн не прибит гвоздями к парадигме. В Хаскелле например, ты должен стремиться к увеличению чистых ф-й, отодвигая весь нечистый код (инетакции с базами, файлами и т..п) на края системы. Хороший ФП код имеет большое ядро чистых ф-й и оболочку с IO кодом. Звучит на что-то похоже? Т.е. система типов Хаскелла заставляет писать код архитектурно идентичен портам и адаптерам. Это же и причина того что интерны быстрей осваивают ФП с правильными архитектурными парренами по дефолту даже не зная их название. Если откроете любую ИДЕ в ООП ЯП по дефолту ее шаболны заточены на лееред для легкости вхождения масс, она вам не даст писать Ports and Adapters моментом, нужно почитать что это и разобраться во всем что вы перечислили: наследовании, интерфейсах, полиморфизме, паттернах и т.п.

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

Пул сессий к конкретной базе — тоже в рантайме? Если захотите поработать с новой базой — будете ждать, пока в языке сделают к ней поддержку?

Даже если сильно нужно адаптер это детали имплементации

ООП и ФП — это тоже детали имплементации. А вот гексагоналка — это архитектура.

а состояние можно экстернализировать хоть в кэш хоть хоть еще куда.

 и это все бесплатно? То есть, Вам в коде будет удобнее дергать внешний кеш, чем переменную?

По нижнему абзацу — многобукв без конкретики. Есть контрпримеры к тому, что адаптер базы (с адаптером внешнего кеша, если хотите) ведет себя как объект? И что когда Вам надо поддерживать несколько баз — появляется полиморфизм и наследование? Расскажите, как Ваши адаптеры будут работать иначе, и чем это лучше. Сам принцип работы адаптеров баз без ООП?

Поліморфізм в ФП через параметризацію.

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

Стан — це просто кусок даних (структура).

Чисті функції на С++ — ті, що з const в кінці.

Я не бачу великих протиріч.

Архітектурно ми пишемо приблизно так, як вчив Alan Key.

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

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

Это же и причина того что интерны быстрей осваивают ФП

а деньги платят — за освоение чего либо, или за — решение проблем к дате Х?

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

ну так вы же знаете!
вот и расскажите :)

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

Там же где платят за SOLID, DDD и ООП.
А вообще если вы все меряете деньгами то нигде. Самообразование оно зачастую из собственного кармана. Все с теми же мотивами чтобы стремиться решать проблемы к дате < X

а деньги платят — за освоение чего либо, или за — решение проблем к дате Х?

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

ну так вы же знаете!
вот и расскажите :)

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

Там же где платят за SOLID, DDD и ООП.

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

А вообще если вы все меряете деньгами то нигде.

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

Самообразование оно зачастую из собственного кармана

утешили. мне никто еще не оплачивал мое самообразование.

Ну вы же освоили Буча, SOLID, DDD и другие полезные вещи.

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

Думаю эта дискуссия уже не конструктивна.

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

Судя по вашим высказываниям о том что всё доменное проектирование удел исключительно ООП, все персистентное состояние в enterprise нужно грузить в память сервера, а измненения в логике вызывают перепроектирование алгоритмов я уже осознал всю глубину ваших познаний почерпнутую от истинных функциональщиков. Щёки надувать с умным видом оно конечно действует сильно и убедительно...особенно на тех кто уже программирование в Scratch освоил :)

Судя по вашим высказываниям о том что всё доменное проектирование удел исключительно ООП

пока вы не продемонстрировали — другой способ проектирования :)
я про него, про этот другой способ постоянно спрашиваю адептов.
в ответ — они предлагают все тоже ОО проектирование :)

предложите вы — другой способ :)

все персистентное состояние в enterprise нужно грузить в память сервера

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

Щёки надувать с умным видом

ну так не надувайте. кто ж вас неволит их надувать :)
а то бульк про орм фигню сказали например — по которой сразу видно отсутствие серьезного опыта :)

как и в теорию ударятся :)

в Scratch освоил

вы в смысле и его ни асилили?
Да, кривая обучения в ООП ого крутая....
Это вам не какое-то там ФП, бац, и все, ваяй, без багов, без тестов, потому что на стадии статик чекинга типов все выловится.
переполнение массива например ;)

пока вы не продемонстрировали — другой способ проектирования :)
я про него, про этот другой способ постоянно спрашиваю адептов.
в ответ — они предлагают все тоже ОО проектирование :)

предложите вы — другой способ :)

Глухой да услышит, слепой да увидит. Уже и ссылочки были и примеры. Ну чтобы еще раз не обвиняли в отутствии... ООП — классы (в понятиях ФП — product type) и методы работы с ними, наследование, композиция. ФП — алгебраические типы данных (Sum и Product типы), паттерн-матчинг для работы с ADT и flow control, вывод типов. Комбинируя sum & product создавать типы которые более аккуратно (к реальному миру) моделируют бизнес-домен. Отсутствие discriminated unions (sum type) в ООП и делает его менее точным в моделировании при всех песнях о его якобы заточенность на объектное мышление человека и симуляцию реальных объектов. DUs есть пока что только в TypeScript насколько мне известно, но т.к. паттрн матчинг не завезли еще то выглядит проход по ADT убого через switch/case. Да и DU пока через интерфейсы в основном и синтаксис разляпистый.

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

Сами написали в оригиале, к чему не понятно. В чем здесь фундаментальная разница в ООП vs FP?

по которой сразу видно отсутствие серьезного опыта :)

как и в теорию ударятся :)

Вот ни разу не сомниваюсь что вы орденоносец и почетный энтерпрайз гуру. Не просветите ли убогого как же таки ORM решают N+1 иначе чем через eager loading и его вариации с лимитированием результата? Можно на примере Hibernate или Laravel. Вы же заслуженный пыхыпышник.

вы в смысле и его ни асилили?
Да, кривая в ООП ого крутая....
Это вам не какое-то там ФП, бац, и все, ваяй, без багов, без тестов, потому что на стадиии статик чекинга типов все выловится.

Не-а, ни асилил, куда мне до вас. Все тестами покрывать видно от хорошей жизни нужно. В ФП Illegal states are unrepresentable — гарантии компилятора, а тесты на граничные значения, интеграции и e2e это конечно же нужно писать. Но фанатов 100% покрытия даже в лагере ООП со статитической типизацией нынче все трудней отыскать.

Ну чтобы еще раз не обвиняли в отутствии...

опять в теорию ударились?
ну, ну ;)

Не просветите ли убогого как же таки ORM решают N+1

никаким. максимум что она может — предоставить доступ к своим внутренностям.
потому что это фундаментально неразрешимая проблема.
обобщенные методы обхода, в зависимости от ...
1. отказ от DDD и прочей тру ООП гадости — в напрвлении от rich model к anemic model
2. спуск на дно ОРМа и расширение его возможностей, вынос средств для оптимизации на прикладной уровень
3 реорганизация порядка выборок и заполнения данными на прикладном уровне, некие аналоги построения «плана запросов к орму» , переход к bulk операциям

Можно на примере Hibernate или Laravel.

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

Не-а, ни асилил, куда мне до вас

ну ничё, бывает. пойдите на курсы 3месячные, для вайтишников, там помогут.
для ФП да, курсы не нужны, там все куда проще и понятней :)

Все тестами покрывать видно от хорошей жизни нужно

уровень покрытия зависит от проектов
но да, я услышал, в ФП тестов не пишут. Типами все ловится.
Ждем переориентацию отрасли. уже какой год...

с таким порогом входа — ощутимо ниже оопшного, и без тестов — скоро, очень скоро кругом будет сплошное ФП

Но фанатов 100% покрытия

«Если один считает другого кретином, то один из них точно кретин.
Может и обое»

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

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

уровень покрытия зависит от проектов
но да, я услышал, в ФП тестов не пишут. Типами все ловится.
Ждем переориентацию отрасли. уже какой год...

с таким порогом входа — ощутимо ниже оопшного, и без тестов — скоро, очень скоро кругом будет сплошное ФП

А это показательно. Услышали то что хотели. Все упоминания мной о property-based тестах, интеграционных и энд-ту-энд мимо уха. Браво :) Теперь можно всем заливать о том что в ФП тесты не пишут :)

Услышали то что хотели

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

только прикалываться, да троллить :)

Теперь можно всем заливать о том что в ФП тесты не пишут

я про ФП вообще никому ничего не заливаю. ни хорошего ни плохого.

любому достаточно пообщаться с адептами — и решить все для себя самостоятельно :)
ФП в антирекламе не нуждается. ее успешно делают адепты
тем более что оно ж проще ООП, бери в проект, делов то!

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

только прикалываться, да троллить :)

Ну да ну да... а sum и product типы, ADT и моделирование это не по делу, а теория по-вашему :) Даже с кодом с примерами :)

любому достаточно пообщаться с адептами — и решить все для себя самостоятельно :)
ФП в антирекламе не нуждается. ее успешно делают адепты

Так что же вы тут делаете в ветке по ФП, адептов отбиваете? Так они и так все сами поймут :)

это не по делу,

вопросов по делу было рассыпано — вы их даже не заметили :)
то есть — либо и не читали, либо вообще не понимаете о чем речь :)

говорю ж — восторг адепта как мультипликатор его малой осведомленности и в том что он проповедует :)

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

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

ак что же вы тут делаете в ветке по ФП, адептов отбиваете?

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

вопросов по делу было рассыпано — вы их даже не заметили :)
то есть — либо и не читали, либо вообще не понимаете о чем речь :)

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

говорю ж — восторг адепта как мультипликатор его малой осведомленности и в том что он проповедует :)

Та не, восторг был года 3-4 назад. Ну ладно обо мне убогом. Расскажите свой опыт ФП, шишки и проекты какие?

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

Это само собой. Все ищущие ответы получают, а вот вы их на форумах ищите среди адептов и не находите :) Вот диво. А ведь еще там всякие книжки есть по ФП.

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

Так если вы бы слушать хотели... :) Не знаю меняется мир или нет но вот списочек книг по функциональному Джаваскрипту намекает что интерес есть и если покопаться то до чертиков библиотек и фрейморков можно будет в джс найти написаных в ФП: www.amazon.com/...​ship,137&ref=nb_sb_noss_1

Видимо мало одного адепта на вашу боль и вопросы

вы как самоуверены, считая за годы вялотекущего хайпа по ФП — себя единственным адептов которого я встречал :)

вы больше были увлечены доказательством того что никакого разительного отличия от ООП и нет то.

а вы его заметили, отличие? ;)
это ж и спрашивалось — и в чем оно?

Та не, восторг был года 3-4 назад

и вы все равно не можете его показать, разительное отличие?
через 3-4 года — практики?

Расскажите свой опыт ФП, шишки и проекты какие?

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

Все ищущие ответы получают, а вот вы их на форумах ищите среди адептов и не находите :)

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

Так если вы бы слушать хотели... :)

разумеется всегда тот неправ кто не встал на твою сторону :D

вот списочек книг по функциональному Джаваскрипту намекает

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

одна из них — функции как объекты первого класса. и в помощь — легкость их объявления и захвата контекста

но «проблемка» с ним — он ЯП с динамической типизацией. (по той же причине и авторы Эрланга не вводили статическую типизацию — нафик она нужна для основного домена применения)
вторая — как понимаю семантика не позволяет написать для него транслятор который будет учитывать одну из главных фич ФП — иммутабельность данных. на малых объемах это копирование — незаметно. но на приличных — требуется поддержка на уровне транслятора, как то в тру ФЯ — Haskell и OCaml. Про F# не знаю, не копал, может и там сделано правильно.

то до чертиков библиотек и фрейморков можно будет в джс найти написаных в ФП

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

а вы его заметили, отличие? ;)
это ж и спрашивалось — и в чем оно?

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

и вы все равно не можете его показать, разительное отличие?
через 3-4 года — практики?

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

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

Ахаха, а вы мне рассказываете про шишки набил :) Все понятно с вами. За сим и откланиваюсь.

дну из главных фич ФП — иммутабельность данных. на малых объемах это копирование — незаметно. но на приличных — требуется поддержка на уровне транслятора, как то в тру ФЯ — Haskell и OCaml. Про F# не знаю, не копал, может и там сделано правильно.

Чисто для прикола, посмотрите вот fable.io

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

В общем-то, для оценки оптимальности подхода — нужно понять, насколько подход справляется с проектированием/разработкой крупных систем, командами из хотя бы 10+ чел.

ООП себя хорошо показал в проектировании и реализации гигантских «монолитов» — это стандарт корпоративного софта, где-то с 80-х и по сейчас.

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

Лично я в отношении микросервисов и их преимуществ перед «монолитами» скептичен. Но в них функциональщине хотя бы есть место.

по сервисам ОО-подходом,

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

и в итоге мы и приходим к тому же самому проектированию

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

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

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

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

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

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

Со всеми недостатками обычного «монолита» + намного более тормознутый (т.к. удалённые вызовы вместо обычного «call/ret»), намного более сложный в отладке, в деплойменте, в сопровождении.

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

и горящие вакансии девопсов, «за любые деньги! срочнАААА....»

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

ессно.

мне известны два основных преимущества, ради которых стоит идти на такое усложнение=удорожание системы
1. горизонтальное масштабирование, особенно динамическое, когда нагрузка вечером в пятницу выше обычной на порядки чем в остальное время
2. выделение ядра, движка системы, и слой кастомных приложений пользователей, в SaaS например (аналогия — закладки браузера в отдельных и главное изолированых потоках)

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

Но по цене серьезного усложнения архитектуры и оркестрации.

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

В общем-то, для оценки оптимальности подхода — нужно понять, насколько подход справляется с проектированием/разработкой крупных систем, командами из хотя бы 10+ чел.

ООП себя хорошо показал в проектировании и реализации гигантских «монолитов» — это стандарт корпоративного софта, где-то с 80-х и по сейчас.

Тут можно тенденцию отследить, беру для примера F#: строк кода меньше, читаемость выше, внесение изменений в логику как минимум не сложней чем в C# codebase, перформанс тот же — байт-код с оптимизациями ранится .NET.
Допустим делаем проект с нуля. Все пакеты и библиотеки .NET доступны. Вопрос тренйинга людей. Насолько я знаю в Украине есть компания DraftKings, где ребята активно применяют F# коммандами.

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

Смотря как декомпозицию делать. Я предпочитаю от сценариев и поведения системы, а модели будут уточняться по ходу. Если интеракции определены то можно и по сервисам разбить и определить границы. Между границами доменные ивенты бегают. Опять же каким способом модели делать — через ОО или ADT — не суть важно. В одном сервисе может быть ОО rich модельки и C# в другом ADT и F#, в третьем Elrang или что хотите и не DDD вообще.

Замовник хоче систему в якій він може мишкою в гуї задавати знижки.

А знижки — річ хитра...

Дві системи такі робив колись — зарплату і магазин.

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

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

Github Copilot

а, ну да :)
то есть фп — уже не нужен, есть же Copilot!

Вона працює, поки не виявиться, що працює не зовсім.

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

Добре що хоч якась документація лишилася. Юзер менюал.

Переписувати таке з нуля в 00-х. Досі працює.

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

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

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

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

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

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

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

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

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

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

А идея использовать компилятор вместо юнит-тестов это же мечта.

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

Система типов Хиндли — Милнера позволяет

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

В Haskell, F# вы объективно пишите очень мало юнит-тестов, компилятор дает достаточно гарантий

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

В статически-типизированных часто тоже непредсказуемое поведение проскакивает

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

но что может проверить компилятор когда и теории нет?
только если — создавать DSLище уровня фантастического романа «Вавилон 17», когда сам язык не позволяет высказать некоторые (неверные) утверждения.

другими словами, очередная мечта о создании «компьютера пятого поколения» конечно заманчива.
вот только — на каком уровне сейчас находятся исследователи в идрисах с агдами, что «практики ФП» обещают УЖЕ золотые горы?

Расскажите о своей — практике :)
но сколько не спрашивал о практике ФПистов — либо ничего внятного, либо — страшно далекие от — обычной практики, в лучшем случае в очень специлизированных доменах, или в 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 это из разряда неразрешимых проблем в алгоритмической области и мало связанных с конкретными реализациями ЯП

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

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

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

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

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

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

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

Замена C# на F# как языка общего назначения на проекте.

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

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

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

микросервисы с DDD

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

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

такие как Kafka или Apache Spark

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

Не юлите :) Halting problem это из разряда неразрешимых проблем

это вы не юлите :)
проблемы разработки ПО лежат по бОльшей части в другой сфере.
Из-за которой де Марко даже предложил
software заменить на peopleware

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

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

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

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

Конкретный результат — безопасность и скорость разработки

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

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

для большинства доменов — НЕ годно
чем это мой такой аргумент слабее вашего? ;)

ЯП — инструмент

инструмент — для чего? вот в чем вопрос :)

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

не юлите ;)

Вот статья по результатам успешного внедрения с кодом на Github

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потому и нафига что человечно и null не словишь

да, наслышан о этой «страшной проблеме» от пуристов :)

Умные дядьки уже и книги написали:

ну это понятно, что отсылка к авторитету — главный арумент.
демагога :)

оно заходит натурально без танцев

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

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

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

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

но вот у вас да, все по другому :)

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

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

Мышление человека ни объективное ни функциональное, а скорее ассоциативное

печка горячая — красная
значит красное — горячее
помидор — горячий!
да, так учится ребенок

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

то есть учить по атрибутам определять — то самое состояние(!) объекта(!!)

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

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

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

То что вы потратили годы на изучение ООП и паттернов и сделало вас тем кем вы есть.
и начнете его учить ФП сразу, то он быстрей зайдет туда чем зашел бы в ООП.

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

Это если бы да кабы — кто-то проверял? ;)

Нужно время на осознание

а почему вы решили что я не осознал? ;)

У меня интерны заходилы в тему за год и потом плевались на ОО

то есть у вас критерий — если кто-то плюется на ОО — то он осознал нечто лучше, чем тот кто не плюется?

и мега-сложную диковину

я вот на DDD плююсь, и энтерпрайзный ООП.
какой диагноз мне?

Видимо у нас с вами разный опыт и взгляд на вещи. Да, я плююсь на ООП (но не на объекты) и объективно сейчас затрудняюсь найти отрасль или задачу где оно покажет эффективность лучшую чем в процедурном или ФП. Если выкинуть наследование это уже не совсем ООП, а объекты можно юзать и в том же Си в виде структур или в F# если нужен контекст, но это не ООП а скорее ОП или Объектное Программирование, а точнее программирование с объектами. В том же F# в зависимости от задачи я использую и объекты и ф-ии, но там все равно фунцкциональная архитектура. Но как всегда выигрывают не чистые концепции а сбалансированный их микс.

Видимо у нас с вами разный опыт и взгляд на вещи.

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

Если выкинуть наследование это уже не совсем ООП

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

а скорее ОП или Объектное Программирование, а точнее программирование с объектами

и т.д. и т.п.

Но как всегда выигрывают не чистые концепции а сбалансированный их микс.

ну да ж. всегда так и было :)
и ООП да, провалилось, как кажется еще году в 2001ом назвал свою статью кто-то с архитектов в IBM
Ну дык и ФП не взлетало никогда, и не взлетит :)
А гибриды и мутанты обоих пород — будут себе жить припеваючи :)

мультипарадигменность в ЯП — тренд последних лет 10 точно.
добрался вобщем постмодерн и к нам :)

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

Это же набросок концепта, я ж не буду вылаживать код с прода. Зачем миллионы строк? Сейчас все раскладываем по сервисам и по bounded контекстам домен разбиваем. Я кидал ссылку на анализ ентерпрайза в корреляции на года и размер кода (F# пример).

В Вашем анализе энтерпрайза, кажется, 250KLoC. Это примерно размер SIP<->(DECT, FXS) gateway (телефонная станция в прошивке роутера), которую я почти водиночку написал на коленках за 6 лет. С несколькими внешними релизами по дороге, и переворачиваниями требований, вплоть до поддержки нового железа, работающего по другому принципу, в процессе.

Энтерпрайз — это десятилетний проект на миллионы или десятки миллионов строк, и те, кто его писали, уже уволились. 250KLoC — это реально на коленках писанный средний проект.

machine learning

Взагалі ні, от прям таки навпаки. По перше, мл будується на постійному тесті гіпотез для котрих обов’язково мати стейт(наприклад, статистики із різних тестів у вигляди матриць та векторів), по друге — майже ніхто не тренує моделі на сирих данних, їх треба процессити, агрегувати, робити фіча інженерію над ними і лише тоді — тренування та крос-валідацію. А для цього просто необхідний стейт. Я не уявляю своєї роботи без нампай матриць та пандас дата фреймів. Більше того — не візьму на роботу людину, котра не володіє нампаєм хоча б. Взагалі, мл — дуже стейтфулл штукенція. Я вже мовчу про самі МЛ моделі із їх вагами. По суті навчання МЛ моделі — це підбір такого стейту, при якому можна знайти пояснення між ознаками та таргетною змінною. Ці пояснення — лінійні або нелінійні математичні паттерни.

Мимо — мл євангеліст.
P.S. Ненавиджу коли фпшники лізуть із своїм фп у мл, породжуючи страшні костилі та слабкі моделі

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

Математические аргументы: colah.github.io/...​osts/2015-09-NN-Types-FP

Практические примеры ML библиотеки: github.com/originrose/cortex

Не единым TensorFlow и PyTorch. Здесь как раз смотрят на ФП в первую очередь за такими штуками как safe(типы) и performance (параллелизм).

а компоненты не мутабельны?

Шта?!!! Це які такі компоненти не мутабельні? Ваги? Чи баєси? І мл нейромережами, якщо що — не обмежується. Використовувати компоненти фп у МЛ — та я й сама використовую(благо вкраплення ФП зараз майже усі ОО мови мають), але і без об‘єктів тут ніяк.

Математические аргументы: colah.github.io/...​osts/2015-09-NN-Types-FP

МЛ не обмежується нейромережами. А навіть там де обмежується — там багато де потрібен стейт. Наприклад — у енкодерах/декодерах

Практические примеры ML библиотеки: github.com/originrose/cortex

 — Звичайна, пласка нейромережами прямого розповсюдження(багато-шаровий перцептрон), такі здебільшого для прикладів студентам зараз використовуються для классифікації котів/собак. У реальній практиці — згорточні, рекуретні або навіть спайкові

Как можно использовать несуществующий подход?

Ещё раз: ООП-подход существовал и использовался задолго до появления ОО-языков. Такой вот парадокс.

Чем подтвердите?
Smalltalk, вроде, 1972 года.
PS еще Симулу забыл habr.com/ru/post/345944

Smalltalk, вроде, 1972 года.

Те же сложные кобольные программы — вполне себе объекто-ориентированные. Сложный сишный код (типа, ядро юникса) тоже.

Впрочем, достоинства ОО-подхода стали понятны очень быстро (как только сложность программ переросла «hello world») — и начали появляться ОО-языки.

Ну кагбэ вопрос курицы и яйца. Были ли эти сложные программы распространены до 62 года. (Юникс на 10 лет младше)

Те же сложные кобольные программы — вполне себе объекто-ориентированные. Сложный сишный код (типа, ядро юникса) тоже.

А можете привести примеры объектной ориентации в коде ядра линукса например? Я конечно могу себе представить структуры, указатели, dispatch таблицы и много другого интересного. Но где там ОО?

структуры, указатели, dispatch таблицы и много другого интересного. Но где там ОО?

Это и есть ООП. Или чем вы это назовёте?

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

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

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

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

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

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

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

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

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

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

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

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

Еще банда четырех писала, что надо предпочесть композицию наследованию.

Они появились уже в конце 90-х. А до этого лет 10 был сплошной Буч — у которого всё решать наследованием и наследованием наследования.

Ну так и не зря появились, видимо)

Ну так и не зря появились, витдимо)

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

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

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

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

Зачем наследовать от обработчика, когда его (обработчик) можно аггрегироватъ?

Собственно, aгреггирование потому и предпочитается, что это "high cohesion"/"low coupling" (т.е. выполнение тех же принципов «S», «O», «I» в SOLID) — в отличиe от наследования, которое все эти принципы нарушает.

Затем, чтобы в движок можно было передать указатель на любой виджет, и он откастился в обработчик событий, или на нем можно было бы вызвать метод Draw() или Invalidate(). Интересно, как такое предлагается через аггрегацию?

Интересно, как такое предлагается через аггрегацию?

Точно так же. Единственное, вызывать обработчик.Draw(), обработчик.Invalidate()

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

нельзя заменить, потому что реализация внутри фреймворка. А гемороя в коде станет дофига вот с этим лишним текстом:

if(myButton.обработчик.IsClicked()) {
    for i : widgetsList {
         i.обработчик.disable();
    }
myButton.обработчик.Hide();
interface IStateProcessor
{
  bool IsClicked() const;
  void Disable();
  void Hide();
}

interface IWidget : IStateProcessor
{
}

class Button : IWidget
{
   IStateProcessor m_pStateProcessor;

  bool IsClicked() const
  {
    return m_pStateProcessor->IsClicked();
  }

  void Disable()
  {
    m_pStateProcessor->Disable();
  }

  void Hide()
  {
    m_pStateProcessor->Hide();
  }
}

скажем, как-то так...

typedef IWidget Window;

Копай, чем отличается интерфейс от класса. :)

Ничем в С++

В «плюсах» нет интерфейсов. Но (очень приблизительным) аналогом интерфейсов — выстyпают полностью абcтрактные классы («pure abstract class»).

Окошко из такого — тоже получится абстрактное (т.е. без какой-либо собственной реализации).

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

Все равно движок один, и ты туда ничего другого не подставишь.

Подставишь. Когда у тебя зависимость лишь от интерфейса — подставляешь, что хочешь.

Но если зависимость от класса (читай, наследование реализации) — тогда уже фиг.

Что ты подставишь? Сам Qt заново напишешь? Так напиши, и назови свои интерфейсы как у них классы названы. Будешь совместим по компиляции.

Что ты подставишь? Сам Qt заново напишешь?

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

Если бы не наследовала реализацию — что бы ты туда подставил?

Если бы не наследовала реализацию — что бы ты туда подставил?

Для примера выше:

interface IWidget : IStateProcessor
{
  void SetStateProcessor(const IStateProcessor* pStateProcessor);
}

class Button : IWidget
{
  Button()
  {
    m_pStateProcessor = new DefaultStateProcessor();
  }

  void SetStateProcessor(const IStateProcessor* pStateProcessor)
  {
    m_pStateProcessor = pStateProcessor;
  }
}

скажем, как-то так...

Вот где ты возьмешь код этого MyBraveNewStateProcessor? И так, чтобы не наружить инвариантов внутри движка Qt, которому в кишки твой процессор пойдет?

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

Вот где ты возьмешь код этого MyBraveNewStateProcessor? И так, чтобы не наружить инвариантов внутри движка Qt, которому в кишки твой процессор пойдет?

Сам напишешь. Или где в других местах позаимствуешь.

Публичный интерфейс у тебя есть — его нужно выполнять, тогда всё работает.
Если публичный интерфейс выполнен, но что-то не работает — это баг фреймворка.

Нет)))
Фреймворк на то и фреймворк, чтобы скрывать от использующего реальную сложность задачи)
Если не влом — посмотри, как там это самое окошко расползается внутри кода Qt и где какие его члены дергаются. Прикинешь сложность задачи, и какой % кода Qt тебе надо переписать, чтобы сделать свое кастомное окошко.

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

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

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

Где легко можешь заменять одни детали другими.

Есть сложность домена. И с ней «легко» не работает. Посмотри размер WinAPI. Сможешь «легко» подменить реализацию? А WinAPI — это как раз интерфейс.

А WinAPI — это как раз интерфейс.

WinAPI — это конкретная реализация интерфейса.

The Windows API, informally WinAPI, is Microsoft’s core set of application programming interfaces available in the Microsoft Windows operating systems. The name Windows API collectively refers to several different platform implementations that are often referred to by their own names; see the versions section.
en.wikipedia.org/wiki/Windows_API

Боюсь, даже у Вайна своя имплементация WinAPI есть.

Тому що імплементовані різні види мессаджів (вверх-вниз, всім хто підписався і т.п.) і є логіка коли подія може перехоплюватись — у ієрархії parent -> child1 -> child1.1 ->... подія яку згенерував parent може не дійти до child1.1 і навпаки.
У Win16 з цим наслідуванням від класу вікна були цікаві приколи, тому що кожна кнопка була по-суті вікном, а кількість дескрипторів вікон нерезинова. )

Magic the Gathering тормозив, коли вулики з осами. Бо кожна карта була вікном)

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

У меня получился забавный кейс, когда иерархия сообщений (через наследование) скопировала иерархию бизнес-логики (через композицию). Например, если есть логика приложения, в ней внутри кусок А, а внутри него — подкусок А1, то у нас тут композиция классов. Но чтобы отправить сообщение на А1 мы наследуем A1Msg : AMsg; AMsg : Message. Получилась иерархия через наследование.

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

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

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

Первым выходом было — выделение интерфейсов. Вторым — композиция. На оба способа — разработчик на дин ЯП и смотрит как на танцы вокруг непонятно чего — да дерни ты метод у того что тебе прислали. Если он есть — будет ок, нет — свалится в рантайме. Тесты отловят.

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

Поэтому про аналитиков, которые обязаны прозревать будущее, и поэтому «не должно быть непредусмотренных изменений в будущем» — не надо :)

Наследование — это из проектирования, объектно-ориентированного. Причем косвенно — это один из способов обобщения типов.

Наследование это вполне конкретная реализация обобщения

С жестко типизированной системой — тоже самое, выраженная типами модель — не даст так просто выразить ею то, чего на этапе проектирования никто в мире не знал. Даже когда ЯП отличает uint от int — уже ой бывает. А когда система типов поддерживает проверку на допустимость применения бизнес правила к типам товара?

Так в этом и суть DSL и хорошо спроектированной системы типов.
[<Measure>] type m // meters [<Measure>] type cm // centimeters // Conversion factor let cmInM = 100<cm/m> let distanceInM = 1<m> let distanceInCM = distanceInM * cmInM // 100<cm> // Conversion function let cmToM (x : int<cm>) = x / 100<cm/m> let mToCm (x : int<m>) = x * 100<cm/m> cmToM 100<cm> // 1<m> mToCm 1<m> // 100<cm>

Через систему типов и ф-и можно выразить любые бизнес правила, причем система типов специализирует допустимые значения, а компилятор проверяет на этапе компиляции... unit <> int, cm <> m, только через явные ф-и приведения типов (которые могут быть вполне доменными типами как категории товаров вместо int, cm)

Так в этом и суть DSL

хайп по DSL уже был. молодые просто не помнят.
были даже грандиозные идеи о появлении отраслевых DSL.
давайте хайп посвежее, а не этот лежалый :)

Через систему типов и ф-и можно выразить любые бизнес правила

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

и словами, обычным языком — можно их выразить.

а компилятор проверяет на этапе компиляции...

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

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

О какой бизнес-логике вы говорите где есть неразрешимые проблемы? Бизнес следует вполне определенным правилам и алгоритмам.

Опять же вы сейчас путаете проблемы из науки и computer science с реальной разработкой ПО. Halting problem или P versus NP problem это из другой истории.

95.9% бизнеса в if-else, стейт машинах и поведении

О какой бизнес-логике вы говорите где есть неразрешимые проблемы?

о — любой.

Бизнес следует вполне определенным правилам и алгоритмам.

у меня в прошлом — около 10ти лет 1Сничания. сертификат даже есть, полученный в моск уч центре № 3
вы точно мне хотите что-то рассказать о бизнесе и его потребностях в информационных системах?

Опять же вы сейчас путаете проблемы из науки и computer science

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

95.9% бизнеса в if-else,

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

вы расскажите как вы типами такие if-else заменяете.
то есть как вы неизвестную «halting problem» в бизнес логике решаете. тупиковый выбор бизнес процесса, быстрый вечный цикл, SELECT N+1, и т.д.

а не о computer science — который придет и спасет от этого

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

Да ну елки-палки, что же вы прицепились к halting problem. Это задача из теории алгоритмов, не разрешима на машине Тьюрига. Все. Ключевая фишка что не существует общего алгоритма решения этой проблемы.
То что вы написали это вообще из серии как уронить сервис или если красиво сделать то как сделать сервис fault-tolerant

вы расскажите как вы типами такие if-else заменяете.
то есть как вы неизвестную «halting problem» в бизнес логике решаете. тупиковый выбор бизнес процесса, быстрый вечный цикл, SELECT N+1, и т.д.

Это все разные проблемы! SELECT N+1 разруливается в ORM-ах eager loading-ом, остальное вообще от винта

Ключевая фишка что не существует общего алгоритма решения этой проблемы.

Нет, это практика. Watchdog может слышали термин. Даже в железо встраивают.

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

Да ну елки-палки, что же вы прицепились к halting problem.

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

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

Ключевая фишка что не существует общего алгоритма решения этой проблемы.

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

Это все разные проблемы!

это — ежедневная головная боль разработчика.
это, а не «несоотстветствие типов»

SELECT N+1 разруливается в ORM-ах eager loading-ом,

да ну нах. ясно, понятно, по ормам вопросов больше к вам нет.

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

Конечно не существует. У всех есть свои + и -. Мне нравится когда я по максимуму опираюсть на типы если они позволяют и компилятор.

Зачем уходить в демагогию и теорию. Конкретная система типов на базе Hindley—Milner. en.wikipedia.org/...​indley—Milner_type_system
Все, достаточно. Теперь, сколько ЯП и какие ее имплементируют? Меня они вполне устраивают.

да ну нах. ясно, понятно, по ормам вопросов больше к вам нет.

Зачем ко мне? Я не разраб ORM-ов. Я сказал что эта проблема так решается там, в большинстве из них.

Конечно не существует

тогда что «рекламируете»? :)

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

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

Зачем уходить в демагогию и теорию

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

Я не разраб ORM-ов

я тоже. просто постоянно с ними сталкиваюсь. перевидел, использовал много всяких. есть у них и плюсы конечно, поэтому выкидывать — еще подумать нужно
но в боевых условиях наивное — SELECT N+1 разруливается в ORM-ах eager loading-ом,
не работает.
пороху значит не нюхали, а потому — и мнение ваше об ормах — как у ребенка о том за что деньги папе с мамой на работе дают

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

ну значит я такой невезучий, не помню чтобы она так просто решалась.
тем более что eager loading даже когда его нет — на коленке пишется «в десяток строк». это достоинство ОРМ — как — ух ты, у двери есть ручка!

Ну я розробник ОРМів, цілих двох.

В двох випадках підняли швидкість розробки на порядок. Без проблем зі швидкодією.

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

Досі шкодую, що перший з них не вивели в окремий продукт. Але це ж 1997-98...

Ну я розробник ОРМів, цілих двох.

а я їх латальник :)
не рахував у скількох випадках піднімав швидкодію :)
було правда взагалі — окремо щось прикручувалось, коли ну ніяк не влізти

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

ОРМи у ERP то взагалі жах з точки зору ефективності роботи з БД. Бо там в пріоретах — надійність, та високий рівень абстракції для програмістів, консалтерів на тих ERP.

Досі шкодую, що перший з них не вивели в окремий продукт

недавно обговорювали нюанси з автором орму: він затянув Eloquent у Magento та виклав. Навряд чи він заробить з того грошей, але, може на консультаціях

такє постійно з’являється, зазвичай принципово нового там немає, а є просто зручна реалізація для деяких нюансів, якої нема у поширених ормах

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

В нас було багато цікавих фіч. Писалося для себе, тому думали. І робили, щоб було зручно і достатньо швидко. На першому зроблено три комерційні проекти. В локалці на 20 машин з одним сервером БД працювало ідеально.

Навіть не уявляю, як на дельфі можна було писати без того (тим більше на MFC).

Якщо коротко, за схемою БД генерувалися COM-інтерфейси. Підтримувалося дочитування на ходу тих полів, яких не було в оригінальному селекті. Підртимувалися відношення один-до-багатьох.

Бізнес-логіка виглядала дуже чистою, писати її можна було дуже швидко.

Все звісно ж здохло давно і десь лежить в бекапах, але спогади є.

но в боевых условиях наивное — SELECT N+1 разруливается в ORM-ах eager loading-ом,
не работает.

Могли бы вы развернуть мысль? Ибо другого способа решения SELECT N+1, кроме eager/explicit loading, я не видел. Даже на проектах без ОРМ, когда данные для объектного графа загружаются хранимкой, это делается так же, как в ОРМ — либо джойн нескольких таблиц, либо несколько отдельных запросов к связанным таблицам и возврат нескольких resultset-ов для материализации.

Могли бы вы развернуть мысль?

мог бы, но это долго
потому что надо пересказывать причины появления SELECT N+1 в объектно-реляционным преобразовании.
потом снабдить эту информацию выхолощенными примерами.
потом добавить реальные, типичные сценарии использования известных ОРМ. вобщем — книгу надо писать, даже пары статей не хватит

конечно использование eager/explicit лучше чем его отсутствие. и может вполне приемлимо решить проблему.

кроме eager/explicit loading, я не видел.

просто меня там не было, вот и не видели :)

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

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

конечно, а как получить данные из БД без запросов к ней?

После этого ответа конкретики не добавилось... Для меня, «нерабочесть» eager loading-а остаётся недоказанной. Ладно, оставим это.

После этого ответа конкретики не добавилось...

так я ее и не добавлял. с чего бы она — добавилась?

Для меня, «нерабочесть» eager loading-а остаётся недоказанной.

а для меня многие годы — очевидна :)
и что с того?

Ладно, оставим это.

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

у меня в прошлом — около 10ти лет 1Сничания. сертификат даже есть, полученный в моск уч центре № 3
вы точно мне хотите что-то рассказать о бизнесе и его потребностях в информационных системах?

Давайте отнесем 1С к бухгалтерии, а бухгалтерию определим в fintech домен. Математика, расчеты и статистика это вообще с чего ФП заходит в массы. Ну сейчас еще machine learning

serokell.io/...​al-programming-in-fintech

хайп по DSL уже был. молодые просто не помнят.
были даже грандиозные идеи о появлении отраслевых DSL.

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

Что уже с ним не так?

с кем — с ним?
с хайпом?
прошел просто.

Его не используют?

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

Если ЯП позволяет их выражать на раз-два то это только в плюс.

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

Ну SQL взлетел все-таки. Чуть ли не единственный распространенный DSL. Ну shell еще.

То есть, они есть, но выживших мало, и все — старички.

Ну SQL взлетел все-таки.

2мерные таблицы — естественное структурирование информации
как и эл таблицы — взлетели.
так, колонками — располагали информацию давно.
Лука Пачоли(1445—1517). Трактат о счетах и записях, например
Глава 1. Об условиях, которые необходимы настоящему купцу, и о порядке, в каком ведется Главная книга с Журналом к ней как в Венеции, так и во всяких других местах

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

в этом причина, а не в самом ЯП работы с таблицами

так как у меня есть практический опыт работы с БД до sql времен — то могу сравнивать преимущества и недостатки.

Чуть ли не единственный распространенный DSL.

regular expressions еще — все плюются, а поди обойдись без него :)

Кабанчик (Designing Data-Intensive Applications) считает, что SQL пошел потому, что размышления о том, как эффективно выполнить запрос к данной конкретной схеме с данными конкретными индексами переложили с головы программиста на движок базы. То есть, перешли от императивного в декларативный стиль, и прикладным программистам (и даже аналитикам) жить стало проще и веселее.

как эффективно выполнить запрос к данной конкретной схеме с данными конкретными индексами

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

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

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

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

Я не знаю на какой дичи вы пишете, сейчас каждая уважающая себя библиотека/фреймворк идет с DSL на борту в виде fluent syntax как минимум. У нас был проект лет 10 назад, мы для наших QA написали DSL для тестирования нашего продукта, который был сервис реал-тайм синхронизкации между аутлуком и проприетарной црмкой. Они накатали кучу сценариев и это все запускалось через движок юнит тестов и они себе дописывали сценарии по мере добавления новых фич. Профит

Я не знаю на какой дичи вы пишете
... сейчас каждая уважающая себя библиотека/фреймворк идет с DSL на борту в виде fluent syntax

Гы. это блин проблема, сваять себе fluent syntax когда у дичи его нет?
ну блин, а что еще — проблема?

что его там — делать то такой — какой тебе нужно?

не, для выпускника ойтикурсов да, великая задача, это ж О-о-о, паттерны ООП...

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

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

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

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

Поэтому я и говорю что для embedded C++ как лишняя нога

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

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

что такое ООП не уходя в философию

нелепое требование :)

ООП и есть — философия. Прикладная :)

Для меня ООП предполагает некую стадию дизайна от классов

Не уходите в философию!
дизайн от классов — философичнее некуда.

И философией оно было изначально, как Кей выкатил Smalltalk, так и в процессе понимания как его готовить, что в рецептах Буча, что на конференциях OOPSLA, что сейчас от Эванса (DDD), что в неиссякающих холиварах про его паттерны

ООП — не уходя в философию — это какой-то нонсенс. абсурд :)

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

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

P.S.
из свежего, очердноq гвоздь в уже гроб инженерии вона — в соседней теме:
дженерики в Go. Пайк, как олдовый и pure инженер всю дорогу плевался на них, чуть ли «только через мой труп!»
но, комьюнити филосфствуя — положило таки на тру инженерность Go :)

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

История из жизни в телеком домене: просто потому что техлид знал NodeJs собрали комманду таких же и начали писать сервисы для обработки миллионов sms и сообщений с других мессенджеров, где быстродействие и отказоустойчивость основные критерии системы. Стоит ли говорить что ицидентов уйма и код достаточно падкий.

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

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

Ну у нас и область такая, молодая,

она уже не молодая, в действительности

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

а не исходя из анализа продукта, требований и NFRs.

а потому что разработка ПО и программирование — уже давно не одно и тоже
и поэтому:

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

очень правильный выбор, и правильный техлид :)

Судя здравому смыслу и инженерному чутью

а программирование уже — не инженерия :D не говоря о разработке
а та самая — прикладная философия.
поэтому инженерерное чутье — в топку истории.
кочегары могут сколько бурчать что никто уголь в топку уже бросать не умеет :)

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

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

Идеалисты могут сколько угодно хейтить что 1С, что пыху, что джс, и рассказывать про Rust
а будет делатся на том на чем будет — успех продукта. Часть которого была, есть и будет в
скорости разработки
а не в точности «подогнанности деталей».

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

так что про

должен был пасть на Erlang/Elixir

можно долго рассуждать.
делаться все равно будет на ноде, пыхе, ну, или джаве :)

Драйвер когда подгружается — ядро знает, что это конкретно за драйвер? Если нет — то вот наследование (конкретный драйвер имплементит интерфейс абстрактного драйвера), энкапсуляция (ядро когда компилили не знали о коде этого драйвера) и полиморфизм (все драйверы равны)

Драйвер реалізує інтерфейс абстрактного дрйвера.

В COM, до речі, були лише інтерфейси і агрерація.

В нас на цьому в 90-х був досить нефіговий фреймворк побудований.

А потім почався аутсорс...

1) пишутся прикладные вещи, с использованием сущностей реального мира

а практика показывает — что абстракции текут всегда, и наивное воплощение сущностей из предметной области в классы — приводит к архитектруной астронавтике

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

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

т.к. люди так мыслят.

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

Собственно, поэтому ООП-подход использовался для создания софта, задолго до появления ОО-языков.

Да, структуры с указателями на функции, принимающие первым аргументом — ссылку на такую структуру в С при разработке GUI на нем — было обычным делом.

Но классы в ООП — это уже проектирование.

Когда я в джс делаю:

fooFunc.bind({args, opts})
это ОО программирование, потому что я превращаю функцию в объект с состоянием.
Но не ОО проекирование, потому что всех «китов православного ООП» мне для этого — не нужно.
Когда я в джс делаю:

init.bind({args, opts})

это ОО программирование, потому что я превращаю функцию в объект с состоянием.
Но не ОО проекирование, потому что никаких «китов сурового ООП» мне не нужно для этого.

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

Но в джс this это особая магия

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

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

const allConnections = Object.create({
  add: function(conn) {
    this[conn.id] = conn
  }})

Тут смешение понятий. Последние лет 25 под «C with classes» имеется в виду сабсет С++, в котором есть классы и перегрузка операторов, но нет исключений и STL. В результате оно не тяжелее С для железа, но дает все ООП абстракции. Поэтому используется в эмбеддеде и хай-лоад — бесплатный апгрейд по сравнению с С.
ithare.com/...​sdoms-and-common-wisdoms

std::vector<> цілком ок як масив. Як і std::unique_ptr<>. Ну і достатньо іншого нормального там є. Просто треба розуміти, коли контейнер алокується.

Ексепшини — зло. Під QNX в нас вони були відключені на рівні компілятора. Зараз під Linux просто в нашому коді не використовуються (поки не виведемо повністю закриту реалізацію API до камер одного стороннього виробника — бо ABI).

std::vector<> цілком ок як масив. Як і std::unique_ptr<>. Ну і достатньо іншого нормального там є. Просто треба розуміти, коли контейнер алокується.

Вектор повільніший, бо зберігає дані в окремому шматку пам’яті. Себто

class A {
    char type;
    char data[];
}
буде в більшості випадків (можливий виняток — лінійний менеджер пам’яті) швидшим за
class B {
    char type;
    std::vector<char> data;
}
тому що для роботи з А в нас усе що треба закешовано (1 cache miss для доступа), а для роботи з B потрібно один раз підтягнути сам інстанс класу, а друге підтягання — тої пам’яті, де вектор зберігає дані (2 cache misses).

Це зрозуміло. Думати про розміщення даних в пам’яті треба завжди.

В нас критичний цикл під optical flow на асемблері під ARM NEON написаний — бо інакше ніяк.

Але в більшості випадків попередньо зарезервовані контейнери STL цілком ок.

По этой же причине — не взлетел и Лисп

Причины это опять же история... популярность C++, Java, C#, Ruby из-за относительной легкости изучения для масс и набора тулзов, библиотек и фреймворков.

Хотя вот вам Clojure и есть осовремененный Lisp

Хотя вот вам Clojure и есть осовремененный Lisp

И тоже не взлетел.

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

У Кложи уже был свой пик — года 3-4 назад. Но с тех пор, популярность языка улетела обратно в 0.

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

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

Эриксоны (Erlang)

динамически типизированный ЯП на основе модели акторов.
Эдакий Smalltalk современности

Знаю пару успешных и больших контор

а я знаю десятки тысяч успешных и больших контор где джава/С#

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

С бумом облак будем видеть все больше и больше функциональщины — AWS Lambda, Azure Functions, etc.

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

ну ок, тогда PHP — торжество функционального программирования!
Состояния нет — каждый запрос — новенькое приложение
html — тоже рендерится с нуля, каждый раз!
потоков — тоже нет, раньше параллелил веб сервер — сейчас AWS Lambda

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

Enter 1C:Бухгалтерия

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

Серед основних характеристик Clojure, які приваблюють розробників, варто зазначити:

динамічність — завдяки використанню циклу читання-обчислення-друку (REPL (Read-evaluate-print loop)) Clojure дозволяє відобразити результати обчислень відразу ж після введення виразів.
генерація байткоду для JVM
ліниві послідовності
рекурсія
паралельне програмування

мультиметоди, і .т. д.

Все це є в Java.
Тож питання — як мотивувати джавіста перейти на Clojure?

Зачем мотивировать, ФП это как стать бисексуалом, к этому самому нужно прийти.

В житті треба все спробувати

Якщо Clojure — така крута мова, чому на ДОП для неї 12 вакансій, а на Java — 1325?
Де світові компанії, які шукають в Україні програмістів на Clojure для своїх проектів?

Если бугати такая крутая машина почему их всего 10, а ланосов тысячи?)
Разница лишь в том что джава более ширпотреб, а как известно в Украине в основном именно такие проекты.

Ок спробував шукати роботи на indeed.com, де вакансії в основному в США.
На Java більше 250 штук, на Clojure 0.
То де там загубилася ваша Бугаті?

Т.е вы считаете что на доу есть 12 вакансий, а в США нет на нее вакансий? вопрос скорее в руках :)
Я лишь говорю о том что кложур в целом штука не такая популярная да и порог вхождения отличается, с этим и связан такой разрыв.

PS jobs.braveclojure.com/?page=1 например

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

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

Почали за «здравіє» закінчили за «упокой». Як завжди все перетворилося на рекламу чергової мови пограмування. Пічаль.

чого ж його пхати, як воно не лізе? ©

Функциональщина не взлетела в 70-80-х, когда коденьем занимались лишь нердo-фрики с машиной Тюринга головного мозга и вот этим всем.
А уж сейчас-то, когда в написанном коде должна уметь разбираться каждая, переученная в ИТшника домохозяйка...

Щодо мов програмування ... Python — об’єктно-орієнтовані.

False. В Python включена возможность писать объектно-ориентированный код. Но это не требование и можно писать код вообще не используя классы.

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

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

Наявність класів != ООП;
Відсутність класів != ФП;
Але так, стаття як мінімум не відповідає заголовку.

А що тоді — наявність класів?

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

Так мы про программу или про язык?

К примеру, на С вполне возможно писать ООП код. Хотя это и не особо поддерживается языком.

Точно так же, с классами — вполне можно писать не ООП программы.

На асемблері також можна. І на форті.

Але воно якось так огидно виглядає.

А от ядро лінукса приємно почитати.

Усі пункти з розділу

Складові функціональної парадигми

підтримуються в старому доброму С
ЗІ можливо крім анонімних функцій — не знаю терміну «функції визначення»

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

То что адаптируют ооп языки из фп это мелочь, само фп они адаптировать не могут — попробуй на ооп языке с открытыми иерархиями и полиморфизмом скомпоновать типичную конструкцию фп программы — с композицией pure функций без карирования, partial application и прочей фп специфики языков, где фунция будет first class citizen. Там где компилятор ориентирован на ооп язык будет вечно ад недетерминированного скрытого поведения проявляющего себя в рантайме и запутанные цепочки взаимодействия обьектов через side effects, с которым статическая типизация мало поможет, в противовес статически типизированные функциональные языки, что могут на этапе компиляции сделать на порядок больше в плане type safety и предусмотреть все возможные варианты поведения еще на этапе компиляции.

В паскалі були вкладені функції.

А от в ранніх С і С++ мені їх бракувало — до лямбд (це С++11, чи раніше?).

Ніколи не потребував. Може, у Вас там забагато усього з колбеками.

Колбеки один випадок.

Інший — структурувати велику функцію. Нема сенсу виносити на верхній рівень (і в хедер) те, що буде викликано один раз. Замість того, щоб писати один великий switch, приємніше розбити на локальні функції.

Отличная статья!

Несколько лет назад я игрался в Repl с DA, ML кложуровскими библиотеками, точное название которых сейчас уже не приведу без гугла. Смотрю на «The Top 38 Machine Learning Clojure Open Source Projects on Github» awesomeopensource.com/...​-learning?categoryPage=11 Выглядит неплохо, но насколько активно это используется в вышеупомянутых компаниях или вообще? Есть ли в кложуре что-нибудь такое же популярное и используемое, как, например, tidyverse и связанное с ним семейство библиотек в R?

Функціональне чи об’єктно-орієнтоване програмування?
Так!

Підписатись на коментарі