Comments 13
всегда уделял повышенное внимание именно интерфейсу
Ваши бы декларативные ценности, да применительно к статье. Ибо вот это:
А вот практические примеры применения данных свойств функтора и других теоретико-категорных конструкций я покажу в будущих статьях.
Ну очень плохой интерфейс с читателем. Этот как "Loading..." с неопределённым горизонтом.
Если бы я не знал всё то, о чём тут написано, я бы ничего не понял.
Что это за метод foldL, выглядящий как будто это и не foldL вовсе, а match какой-нибудь? В исходном коде так вовсе используется какой-то левый пакет @devexperts/remote-data-ts, хотя статья вроде как про fp-ts!
По существу, функтор является не более, чем структурой данных, позволяющей применять функции преобразования с целью извлечь значения из оболочки, модифицировать их, а затем поместить их обратно в оболочку
Написано так, как будто функтор — это какая-то конкретная структура данных, а не класс структур данных. Правильное определение должно начинаться как-то так: "Функтором называется любая структура данных, позволяющая..."
ассоциативность — свойство операций, позволяющее восстановить последовательность их выполнения при отсутствии явных указаний на очерёдность при равном приоритете; при этом различается левая ассоциативность, при которой вычисление выражения происходит слева направо, и правая ассоциативность — справа налево
Смешались в кучу математика и синтаксис языка. Под ассоциативностью операции в данном случае понимается именно вот это свойство: h ◦ (g ◦ f) = (h ◦ g) ◦ f. К левой или правой ассоциативности оно не имеет отношения.
Как ни странно, но отличать левую ассоциативность от правой обычно требуется лишь для неассоциативных операций!
Для каждого объекта A есть стрелка, которая будет единицей композиции.
Вы уверены, что это вообще для обычных фронтендеров написано? Вся моя любовь к математике не помешала мне прочитать "единицу композиции" в значении "неделимый элемент", по аналогии с "единицей развёртывания" или там с "единицей функциональности".
Теперь мы можем рассмотреть, что такое функтор в теории категорий. Функтор — особый тип отображений между категориями.
Вот как раз теперь, после всех этих композиций, появилось ощущение, что функтор — это одна из стрелок на диаграмме выше. Что, разумеется, не так: функторов на той диаграмме вообще нет (ну, если только там не нарисована категория малых категорий)
Учитывая, что в этом определении вообще нет упоминания композиции, совершенно не понятно зачем размещать его именно тут. Кстати, определения тут как такового нет.
Функторы между малыми категориями являются морфизмами в категории малых категорий.
Отлично! Тихой сапой появилось сразу два новых понятия: морфизм (если кто не знает — это как раз те стрелочки на диаграмме выше) и "малая категория". Хорошо хоть, дальше эти понятия не используются.
Метод fmap можно рассматривать с двух сторон
Во-первых, это у вас вовсе не метод. Во-вторых, откуда он вообще взялся? Нет, ну я-то знаю, что fmap — основная операция для функтора, но в статье она вылезла из ниоткуда.
Монада возникает при создании целого типа данных по принципу извлечения данных по принципу извлечения значений из оболочек и определения правил из вложенности. Подобно функторам, монады являются проектным шаблоном, применяемым для описания вычислений в виде последовательности стадий, где вообще неизвестно обрабатываемое значение, но именно монады дают возможность безопасно и без побочных эффектов управлять потоком данных, когда они применяются в композиции.
Это уже ребус какой-то. Даже известная шутка про "всего лишь моноид в категории эндофункторов" — и то понятнее как определение монады.
Для того чтобы лучше понять монады, необходимо усвоить следующие важные понятия: Монада. Предоставляет абстрактный интерфейс для монадических операций
Ага, а сепулька предоставляет абстрактный интерфейс для сепуления!
Монадический тип. Конкретная реализация данного интерфейса
А это вообще ошибка. Монадический тип — это любой тип, имеющий kind * -> *. То есть это даже более слабое свойство, чем у функтора!
А вот, кажется, ответ: https://habr.com/ru/company/bcs_company/blog/471170/#comment_20759498
Я один не понимаю зачем тянуть функциональщину в языки для нее не предназначенные?
Что значит "эффективно"?
Кстати много языков сейчас имеет синтаксис, облегчающий использование монад. Но JS\TS в их число не входит.
Очень меметичный пост. 10 буррито из 10.
В исходном коде так вовсе используется какой-то левый пакет @devexperts/remote-data-ts, хотя статья вроде как про fp-ts!
Этот пакет входит в экосистему fp-ts (Heavily based on fp-ts lib)
Написано так, как будто функтор — это какая-то конкретная структура данных, а не класс структур данных. Правильное определение должно начинаться как-то так: «Функтором называется любая структура данных, позволяющая...»
Вы правы, моя формулировка не совсем корректная, спасибо за замечание! (Поправлю)
Смешались в кучу математика и синтаксис языка. Под ассоциативностью операции в данном случае понимается именно вот это свойство: h ◦ (g ◦ f) = (h ◦ g) ◦ f. К левой или правой ассоциативности оно не имеет отношения.
Здесь ассоциативность была затронута для пояснения, а не для примера, поэтому как вы заметили (затронутое в статье свойство, к левой или правой ассоциативности не имеет отношения)
Вы уверены, что это вообще для обычных фронтендеров написано? Вся моя любовь к математике не помешала мне прочитать «единицу композиции» в значении «неделимый элемент», по аналогии с «единицей развёртывания» или там с «единицей функциональности».
В этом цикле статей я хотел попробовать донести для «обычных фронтендеров», что применение функциональных практик возможно, в том числе и при разработке интерфейсов.
Отлично! Тихой сапой появилось сразу два новых понятия: морфизм (если кто не знает — это как раз те стрелочки на диаграмме выше) и «малая категория». Хорошо хоть, дальше эти понятия не используются.
Немного выше есть поверхностное описание морфизма. Малая категория было упомянута, для того чтобы сообщить читателю о наличии таковой.
Во-первых, это у вас вовсе не метод. Во-вторых, откуда он вообще взялся? Нет, ну я-то знаю, что fmap — основная операция для функтора, но в статье она вылезла из ниоткуда.
Вы правы, это не метод, это функция. Моя ошибка — поправлю и заодно поясню.
Это уже ребус какой-то. Даже известная шутка про «всего лишь моноид в категории эндофункторов» — и то понятнее как определение монады.
Я поправлю данное пояснение. (Спасибо за замечание)
А это вообще ошибка. Монадический тип — это любой тип, имеющий kind * -> *. То есть это даже более слабое свойство, чем у функтора!
Я употребил слова «монадический тип» в значении — «тип, для которого можно определить экземпляр монады» Пометку обновлю, спасибо за замечание.
В целом, спасибо вам за комментарии!
Функциональные практики и frontend: монады и функторы