Функциональное программирование в примерах.
Язык Haskell: характеристики, история, сильные и слабые стороны, истории успеха и неудач.
Спецификация Haskell’98: синтаксис, компиляторы, интепретаторы, документация, IDE.
Особенности языка: тип Maybe, списки, классы типов, основы монад.
Библиотеки и фреймворки: Parsec, GenXml, HaXml
DSL
На десерт что-то из Existential Types, State Monad, ST Monad, Monad Transformers.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Евгений Зуев, С++ в России: Стандарт языка и его реализацияPlatonov Sergey
Доклад посвящён различным аспектам компилятора С++, созданного с участием автора. В выступлении рассказывается о продвинутой архитектуре компилятора, основных проектных решениях, а также обсуждаются особенности входного языка, повлиявшие на реализацию компилятора.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Функциональное программирование в примерах.
Язык Haskell: характеристики, история, сильные и слабые стороны, истории успеха и неудач.
Спецификация Haskell’98: синтаксис, компиляторы, интепретаторы, документация, IDE.
Особенности языка: тип Maybe, списки, классы типов, основы монад.
Библиотеки и фреймворки: Parsec, GenXml, HaXml
DSL
На десерт что-то из Existential Types, State Monad, ST Monad, Monad Transformers.
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Евгений Зуев, С++ в России: Стандарт языка и его реализацияPlatonov Sergey
Доклад посвящён различным аспектам компилятора С++, созданного с участием автора. В выступлении рассказывается о продвинутой архитектуре компилятора, основных проектных решениях, а также обсуждаются особенности входного языка, повлиявшие на реализацию компилятора.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Сергей Шамбир, Адаптация Promise/A+ для взаимодействия между C++ и JavascriptSergey Platonov
Шаблоны — мощный инструмент, добавляющий в язык новые возможности, а программистам в команде — новые проблемы. Доклад покажет, как тщательно продуманный шаблонный код может не усложнить, а упростить жизнь и дать надёжную абстракцию межпроцессных межъязыковых асинхронных вызовов функций. С помощью шаблонов можно:
адаптировать Promise/A+ из Javascript для C++
автоматически проверять и раскладывать динамический массив аргументов на статичные аргументы функции
сделать аналог std::bind для weak_ptr.
Эти вещи будут показаны на примере взаимных вызовов между C++ и Javascript в одном приложении с помощью CEF3.
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Обобщенное программирование в C++ или как сделать свою жизнь проще через стра...corehard_by
Обобщенное программирование - это подход к программированию, когда алгоритм пишется без указания конкретных типов данных. Используя данный подход можно значительно увеличить количество повторно используемого кода. В C++ данный подход реализуется за счет механизма шаблонов. В данном докладе рассмотрим некоторые возможности по обобщенному программированию, которые предоставляет C++. На конкретных примерах рассмотрим, как они могут упростить нам жизнь и с какими трудностями приходится сталкиваться при их использовании.
Краткое введение в Scala для разработчиков на других языках. Рассмотрены несколько простых программ, написанных с использованием красивых возможностей Scala.
Полухин Антон, Как делать не надо: C++ велосипедостроение для профессионаловSergey Platonov
В докладе перед нами откроется великолепный мир велосипедов и устаревших технологий, которые люди продолжают переносить в новые проекты и повсеместно использовать. Мы поговорим о:
Copy-On-Write
разработке без оглядки на готовые решения и к чему это приводит
force inline
оптимизациях, которые отлично себя показывают на бенчмарках и плохо себя ведут в реальной жизни
бездумно отключаемых оптимизациях компилятора
тонкостях стандартной библиотеки для повседневного использования
супер качественном велосипедостроении
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Не всегда задачи решаются в терминах языка программирования. И когда дело доходит до реализации, иногда "волосы становятся дыбом" от мысли, как это придется делать на конкретном языке. В данном докладе автор "изольет душу" на тему идиом в языках программирования, чем они отличаются от паттернов проектирования, рассмотрит преимущества и недостатки их использования, а также подробно рассмотрит несколько наиболее популярных идиом для C++.
Презентация к докладу на SymfonyCampUA-2012.
В докладе рассмотрены основные вопросы работы с АОП в PHP, даны определения аспектов, срезов, советов, а также рассмотрено реальное использование библиотеки GO! для внедрения аспектно-ориентированной парадигмы в любое приложение.
Сергей Шамбир, Адаптация Promise/A+ для взаимодействия между C++ и JavascriptSergey Platonov
Шаблоны — мощный инструмент, добавляющий в язык новые возможности, а программистам в команде — новые проблемы. Доклад покажет, как тщательно продуманный шаблонный код может не усложнить, а упростить жизнь и дать надёжную абстракцию межпроцессных межъязыковых асинхронных вызовов функций. С помощью шаблонов можно:
адаптировать Promise/A+ из Javascript для C++
автоматически проверять и раскладывать динамический массив аргументов на статичные аргументы функции
сделать аналог std::bind для weak_ptr.
Эти вещи будут показаны на примере взаимных вызовов между C++ и Javascript в одном приложении с помощью CEF3.
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Обобщенное программирование в C++ или как сделать свою жизнь проще через стра...corehard_by
Обобщенное программирование - это подход к программированию, когда алгоритм пишется без указания конкретных типов данных. Используя данный подход можно значительно увеличить количество повторно используемого кода. В C++ данный подход реализуется за счет механизма шаблонов. В данном докладе рассмотрим некоторые возможности по обобщенному программированию, которые предоставляет C++. На конкретных примерах рассмотрим, как они могут упростить нам жизнь и с какими трудностями приходится сталкиваться при их использовании.
Краткое введение в Scala для разработчиков на других языках. Рассмотрены несколько простых программ, написанных с использованием красивых возможностей Scala.
Полухин Антон, Как делать не надо: C++ велосипедостроение для профессионаловSergey Platonov
В докладе перед нами откроется великолепный мир велосипедов и устаревших технологий, которые люди продолжают переносить в новые проекты и повсеместно использовать. Мы поговорим о:
Copy-On-Write
разработке без оглядки на готовые решения и к чему это приводит
force inline
оптимизациях, которые отлично себя показывают на бенчмарках и плохо себя ведут в реальной жизни
бездумно отключаемых оптимизациях компилятора
тонкостях стандартной библиотеки для повседневного использования
супер качественном велосипедостроении
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Не всегда задачи решаются в терминах языка программирования. И когда дело доходит до реализации, иногда "волосы становятся дыбом" от мысли, как это придется делать на конкретном языке. В данном докладе автор "изольет душу" на тему идиом в языках программирования, чем они отличаются от паттернов проектирования, рассмотрит преимущества и недостатки их использования, а также подробно рассмотрит несколько наиболее популярных идиом для C++.
Презентация к докладу на SymfonyCampUA-2012.
В докладе рассмотрены основные вопросы работы с АОП в PHP, даны определения аспектов, срезов, советов, а также рассмотрено реальное использование библиотеки GO! для внедрения аспектно-ориентированной парадигмы в любое приложение.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Netpeak Group продолжает серию образовательных мероприятий — #NetpeakTalks в Одессе.
В рамках этих встреч у тебя будет возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
Тема#3: Масштабируемое приложение на PHP
Краткий план:
1. Теория принципов и паттернов проектирования.
2. Примеры использования принципов и паттернов в коде (разберём какие "плюшки" даёт каждый случай).
3. Важность слабосвязанного кода (IoC).
4. Как "под капотом" работают IOC контейнера.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
FaceBook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
__________
Плейлист с выступлениями на YouTube: https://www.youtube.com/playlist?list=PL8LIMl0TjrcDtSS_lM5jqH-huK5FCq44A
__________
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
— Как развивалась инфраструктура веб-проектов в 2ГИС;
— Как не делать один и тот же функционал 5 раз подряд, или слоистая архитектура и выделение общих сервисов;
— Сборка приложений из базовых библиотек;
— Сложность масштабирования цельной системы и легкость распределенной;
— Зоны ответственности групп разработки.
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...Alexey Neznanov
Лекция на школе учителей 2018-11-05. Название слишком забористое, но в целом это более-менее системное и актуальное рассмотрение того, что происходит с языками программирования. Лекция прочитана перед изучением языка Питон (Python). Много ссылок
Завершающий доклад дня будет посвящён реализации и верификации разработанных алгоритмов обработки сигналов на конечных целевых платформах. Мы продемонстрируем современный подход к решению этой задачи в рамках концепции МОП, подразумевающий активное использование поведенческой модели алгоритма, а также автоматизацию многих этапов разработки и тестирования.
SECON'2016. Сергей Аверин. Javascript-фреймворки: должен остаться только одинSECON
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что хорошо работающий фронтенд — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но и циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Hierarchical free monads and software design in fpAlexander Granin
I invented the approach I call "Hierarchical Free Monads". It helps to build applications in Haskell with achieving all the needed code quality requirements. I tested this approach in several real world projects and companies, and it works very well.
What is the difference between Final Tagless and Free Monads from the Software Design point of view? What is Hierarchical Free Monads approach? How to build real applications in Haskell?
This talk was given on FPure 2019, Kazan.
The Present and The Future of Functional Programming in C++Alexander Granin
Keynote talk for C++ Siberia 2019.
I'm speaking about why Functional Programming is important in C++ world, what is the philosophy of FP in C++, and what features do we have. I'm presenting a connection of constexpr and template metaprogramming to pure FP, and talking about why monads are inevitable. I'm also discussing an upcoming features in C++.
Software transactional memory. pure functional approachAlexander Granin
Slides for C++ Russia 2018
I'm presenting my `cpp_stm_free` library: composable monadic STM for C++ on Free monads for lock-free concurrent programming.
Небольшой доклад о мифах в функциональном программировании для DevDay@2GIS.
Slides for my talk to DevDay@2GIS about functional programming: See the talk here (Rus):
https://youtu.be/jSkYvNqQWqs
Линзы - концепция функционального программирования, позволяющая легко оперировать сколь угодно сложными структурами данных. Линзы решают две проблемы: снижают сложность обработки данных и предоставляют абстракцию над запросами к данным, делая код устойчивым к поломкам при изменении структуры данных.
2. О себе
2
● Продолжающий хаскеллист, исследователь
● LambdaNsk - ФП-сообщество Новосибирска
● Статьи на Хабре о Haskell, о дизайне в ФП
● Haskell pet-projects
● Работаю в Kaspersky Lab (C++, C#)
3. О чем будем говорить
● Проектирование в ФП
● Элементы функционального дизайна
● Кому он в ФП нужен, этот ваш дизайн?
3
7. 7
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
8. 8
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
9. 9
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
10. 10
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
MONADS
STATE State monad
IO IO monad
LIST List monad
ID Identity monad
RWS Read-Write-State monad
Laziness
Immutability
Combinators
Abstraction
D.S.L.
High Order
Functions
11. 11
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
MONADS
STATE State monad
IO IO monad
LIST List monad
ID Identity monad
RWS Read-Write-State monad
Laziness
Immutability
Combinators
Abstraction
D.S.L.
High Order
Functions
14. Дизайн в ФП?
14
SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Inversion of
Control
26. 26
Карта элементов (ассоциативная)
● Все возможности
● Ассоциативные связи
● “Поток сознания” (!)
● Без структуры (!!)
● Легенда
Библиотеки, слои,
подсистемы, концепты,
данные, объекты, типы
53. Оставшиеся вопросы
53
● Типы данных
● Обработка ошибок
● Работа с внешними API
● Важные структуры данных
● UI
● Базы данных
● Потоковый дизайн
● ...
54. Полезные источники
54
Scott Wlaschin
● How to design and code a complete program
● Functional Programming Patterns
● Railway Oriented Programming
Александр Гранин
● Дизайн и архитектура в ФП
57. 2. Взаимодействие подсистем, контроль эффектов
57
● FRP / Event Bus, Reactive Scenarios
+ Низкая связанность (Low Coupling)
+ Независимость подсистем
+ Контроль побочных эффектов
+ Разное взаимодействие == разные сценарии
+ Сценарии: Arrows / Monads / Applicatives
- Зоопарк и сложность FRP-библиотек (Haskell)
- Много возможных моделей Event Flow
- Трудно тестировать FRP-сценарии
58. 58
● Монолитная - объекты описываются типами 1:1
+ Algebraic Data Types
+ Проста в понимании, реализации
+ Pattern Matching
+ Подходит для маленькой предметной области
- Сложность растет экспоненциально с ростом функциональности
- Монолитный код
- Зависимость кода от внутренностей модели
- Трудно адаптировать под изменяющиеся требования
3. Монолитная модель данных
59. 4. Комбинаторная модель данных
59
● Комбинаторная - объекты комбинируются из частей (свойств)
+ Богатые возможности комбинаторного подхода
+ Проще адаптировать под изменяющиеся требования
+ Легко адресовать функциональность к частям модели
+ Сложность растет линейно с ростом функциональности
+ Подходит для большой и сложной предметной области
- Более сложный код обвязки (создание / изменение объектов и т.д.)
- Трудно выделить правильные комбинатоы / свойства
60. 5. Трансформация модели данных
60
● Линзы
+ Работа со структурами любой сложности
+ Богатые возможности по трансформации и запросам к данным
+ Компактный код
- Сложность библиотек для линз (Haskell)
- Вопросы производительности
61. ● Наивный IoC - функции высших порядков
● Monad.State Dependency Injection
6. Inversion of Control, внедрение зависимостей
61
+ Код “сверху-вниз”, от общих функций к частным
+ IoC - привычный способ мышления
+ Подходит для небольших частей / программ
- State & Dependency Injection - Not a FP Way
- “Лобовые” решения типичных задач
- Нет места функциональным идиомам