Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Полковник
  • Функціональне чи об’єктно-орієнтоване програмування: що обрати і чому варто звернути свою увагу на Clojure. Поради для початківців

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Глухой да услышит, слепой да увидит. Уже и ссылочки были и примеры. Ну чтобы еще раз не обвиняли в отутствии... ООП — классы (в понятиях ФП — 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% покрытия даже в лагере ООП со статитической типизацией нынче все трудней отыскать.

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

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

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

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

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

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

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

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

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

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

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

    Конечно не существует. У всех есть свои + и -. Мне нравится когда я по максимуму опираюсть на типы если они позволяют и компилятор.

    Зачем уходить в демагогию и теорию. Конкретная система типов на базе Hindley—Milner. en.wikipedia.org/...​indley—Milner_type_system
    Все, достаточно. Теперь, сколько ЯП и какие ее имплементируют? Меня они вполне устраивают.

    да ну нах. ясно, понятно, по ормам вопросов больше к вам нет.

    Зачем ко мне? Я не разраб ORM-ов. Я сказал что эта проблема так решается там, в большинстве из них.

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

    Я не знаю на какой дичи вы пишете, сейчас каждая уважающая себя библиотека/фреймворк идет с DSL на борту в виде fluent syntax как минимум. У нас был проект лет 10 назад, мы для наших QA написали DSL для тестирования нашего продукта, который был сервис реал-тайм синхронизкации между аутлуком и проприетарной црмкой. Они накатали кучу сценариев и это все запускалось через движок юнит тестов и они себе дописывали сценарии по мере добавления новых фич. Профит

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

    у меня в прошлом — около 10ти лет 1Сничания. сертификат даже есть, полученный в моск уч центре № 3
    вы точно мне хотите что-то рассказать о бизнесе и его потребностях в информационных системах?

    Давайте отнесем 1С к бухгалтерии, а бухгалтерию определим в fintech домен. Математика, расчеты и статистика это вообще с чего ФП заходит в массы. Ну сейчас еще machine learning

    serokell.io/...​al-programming-in-fintech

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

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

    Да ну елки-палки, что же вы прицепились к halting problem. Это задача из теории алгоритмов, не разрешима на машине Тьюрига. Все. Ключевая фишка что не существует общего алгоритма решения этой проблемы.
    То что вы написали это вообще из серии как уронить сервис или если красиво сделать то как сделать сервис fault-tolerant

    вы расскажите как вы типами такие if-else заменяете.
    то есть как вы неизвестную «halting problem» в бизнес логике решаете. тупиковый выбор бизнес процесса, быстрый вечный цикл, SELECT N+1, и т.д.

    Это все разные проблемы! SELECT N+1 разруливается в ORM-ах eager loading-ом, остальное вообще от винта

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

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

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

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

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

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

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

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

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

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

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

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

    хайп по DSL уже был. молодые просто не помнят.
    были даже грандиозные идеи о появлении отраслевых DSL.

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

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

    О какой бизнес-логике вы говорите где есть неразрешимые проблемы? Бизнес следует вполне определенным правилам и алгоритмам.

    Опять же вы сейчас путаете проблемы из науки и computer science с реальной разработкой ПО. Halting problem или P versus NP problem это из другой истории.

    95.9% бизнеса в if-else, стейт машинах и поведении

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

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

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

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

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

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

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

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

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

    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 чтобы зашить агрументы и т.п.

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

    Наследование — это из проектирования, объектно-ориентированного. Причем косвенно — это один из способов обобщения типов.

    Наследование это вполне конкретная реализация обобщения

    С жестко типизированной системой — тоже самое, выраженная типами модель — не даст так просто выразить ею то, чего на этапе проектирования никто в мире не знал. Даже когда ЯП отличает 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)

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

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

← Сtrl 1... 345678 Ctrl →