Комментарии 22
Зато в награду за наши страдания мы получаем гарантированное отсутствие
race condition (состояние гонки) при параллельной обработке (безо всяких мутексов и borrow checker'ов)
Ну хорошо. А как на имутабельных объектах сделать такую элементарщину, как общий счетчик?
От ответа на эти вопросы зависит способ (в крайнем случае — через эффекты).
Вот если бы этот счетчик как-то хотели использовать в работе самого приложения — тогда ситуация чуть сложнее, но тоже разрешима.
Суть в том, что низкоуровневая работа с эффектами строго ограничена библиотечной функцией. Остальной код не видит этого.
Тут важно только заметить, что речь не о потоках исполнения, а потоках данных. Сколько реально потоков исполнения обрабатывают этот поток данных — это вопрос отдельный. Может по одному на data-flow, а может по 20… Может вообще один на всех.
При большом желании в хасткеле вы можете использовать MVar (это аналог volatile). Но это верный способ рано или поздно выстрелить себе в ногу.
Предположим, у вас есть клевая библиотека по сериализации и есть другая не очень клевая легаси библиотека ORM, которая фигачит вам кучу POJO объектов. И вам стало нужно эти объекты сериализовать первой библиотекой. Но вот беда: ваши POJO объекты не реализуют нужный интерфейс MyCoolSerializable.
Если я вас понял, то у в этом примере у Вас есть библиотека с тайплкассом, библиотека со структурой и вы реализуете тайпкласс из одной библиотеки для структур из другой. В Rust это называют Orphan Rules, которые заключаются в том, что либо нельзя реализовать "чужой" трейт (==тайпкласс) для "чужой" структуры. Что кажется печальным и, на мой взгляд, снижает гибкость.
Вопрос: а как с этим обстоят дела в более труЪ ФП языках, таких как Haskell, Scala итп? Насколько это реализуемо и насколько это распространенная практика?
В хаскеле — язык позволяет так делать, но это не рекомендуется. В скала все проще, насколько я понимаю. Там тайпклассы эмулируются через implicit. И уже правила разруливания implicit помогают выбрать конкретный инстанс тайпкласса.
Что касается GoF, и частично SOLID, то если у вас скажем функции поддерживаются как first class citizen в языке, то вам многие паттерны GoF просто тривиально не нужны. С SOLID там чуть иначе, они (некоторые принципы) просто более общие, чем ООП, и применяются к ФП точно так же. А некоторые нет, или применимы — но результат выглядит иначе. Но опять же, тут нужно понимать, что SOLID это не более чем общие принципы, в явном виде в коде они практически не видны.
Ну если такие выводы делать, получается что я за последние 15 лет только один раз решал бизнес-задачи — потому что UML применялся ровно один раз (и тот раз я бы не назвал полностью успешным). При этом реально вся работа была на бизнес, причем достаточно разный.
Ну то есть, что это удобнее (местами) — я согласен. Те же ER диаграммы — частный случай UML, и наверное самые распространенные.
Но вопрос же был — можно ли писать без UML? На мой взгляд ответ очевиден. Есть куча других способов представления моделей данных, и в виде кода, и без диаграмм, и без UML.
Ну и наконец, а почему в ФП парадигме нужно писать без UML? Ведь очень часто диаграммы используются как средство для генерации кода. А генерировать код можно и в ФП парадигме, уж этому-то точно ничто не мешает. И взять тот же BPMN, если уж хочется, и встроить его в ФП снова — тоже почему нет? То что большинство реализаций на ООП — мне кажется не более чем «так сложилось».
Поэтому чаще всего в реальных применениях встречается foldLeft, который более предсказуемЯ вообще не в теме, но всё же понимаю, что тот, кто нуждается в этих версиях fold, «делает что-то неправильно» в смысле чистоты функционального подхода
У моноида есть младший братПравильно, спросите википедию«Полудурок»«Полугруппа». Только не спрашивайте меня, почему его так назвали
P.S. дочитал до оговорок по этому поводу
вам показать не удержусь и свой JS'ный The Life код:
codepen.io/impfromliga/pen/pyBJvM — в размер до 256b
codepen.io/impfromliga/pen/qZwbQN — с коментариями
Не хотите сделать продолжение? Например, разобрать простенькое приложение и показать, где какой инструмент стоит применить?
Ваша серия из двух статей - лучшее, что я прочёл по ФП для чайников. Спасибо.
Глубже в дебри ФП