Как стать автором
Обновить

Комментарии 13

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

Ваши бы декларативные ценности, да применительно к статье. Ибо вот это:


А вот практические примеры применения данных свойств функтора и других теоретико-категорных конструкций я покажу в будущих статьях.

Ну очень плохой интерфейс с читателем. Этот как "Loading..." с неопределённым горизонтом.

Если бы я не знал всё то, о чём тут написано, я бы ничего не понял.


Что это за метод foldL, выглядящий как будто это и не foldL вовсе, а match какой-нибудь? В исходном коде так вовсе используется какой-то левый пакет @devexperts/remote-data-ts, хотя статья вроде как про fp-ts!


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

Написано так, как будто функтор — это какая-то конкретная структура данных, а не класс структур данных. Правильное определение должно начинаться как-то так: "Функтором называется любая структура данных, позволяющая..."


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

Смешались в кучу математика и синтаксис языка. Под ассоциативностью операции в данном случае понимается именно вот это свойство: h ◦ (g ◦ f) = (h ◦ g) ◦ f. К левой или правой ассоциативности оно не имеет отношения.


Как ни странно, но отличать левую ассоциативность от правой обычно требуется лишь для неассоциативных операций!


Для каждого объекта A есть стрелка, которая будет единицей композиции.

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


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

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


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


Функторы между малыми категориями являются морфизмами в категории малых категорий.

Отлично! Тихой сапой появилось сразу два новых понятия: морфизм (если кто не знает — это как раз те стрелочки на диаграмме выше) и "малая категория". Хорошо хоть, дальше эти понятия не используются.


Метод fmap можно рассматривать с двух сторон

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


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

Это уже ребус какой-то. Даже известная шутка про "всего лишь моноид в категории эндофункторов" — и то понятнее как определение монады.


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

Ага, а сепулька предоставляет абстрактный интерфейс для сепуления!


Монадический тип. Конкретная реализация данного интерфейса

А это вообще ошибка. Монадический тип — это любой тип, имеющий kind * -> *. То есть это даже более слабое свойство, чем у функтора!

Я один не понимаю зачем тянуть функциональщину в языки для нее не предназначенные?

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

Что значит "эффективно"?
Кстати много языков сейчас имеет синтаксис, облегчающий использование монад. Но JS\TS в их число не входит.

Значит писать позволяет писать программы не тратя слищком много времени на отладку и стыковку разных компонент.

Есть какое-то исследование что монады и ФП помогают совершать меньше ошибок? Или значительно сокращают объем кода? Многие вещи в JS\TS уже достаточно функциональны — массивы, продолжения.
Зачем лепить еще что-то?

Кстати много языков сейчас имеет синтаксис, облегчающий использование монад. Но JS\TS в их число не входит.

Входит. Синтаксис генераторов — монадический.

Но генератор нельзя применять с произвольной монадой.

Ну, почти с произвольной. С-но, какие вы знаете полезные монады кроме list и подобных, которые нельзя реализовать через генераторы?

Очень меметичный пост. 10 буррито из 10.

В исходном коде так вовсе используется какой-то левый пакет @devexperts/remote-data-ts, хотя статья вроде как про fp-ts!

Этот пакет входит в экосистему fp-ts (Heavily based on fp-ts lib)

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

Вы правы, моя формулировка не совсем корректная, спасибо за замечание! (Поправлю)

Смешались в кучу математика и синтаксис языка. Под ассоциативностью операции в данном случае понимается именно вот это свойство: h ◦ (g ◦ f) = (h ◦ g) ◦ f. К левой или правой ассоциативности оно не имеет отношения.

Здесь ассоциативность была затронута для пояснения, а не для примера, поэтому как вы заметили (затронутое в статье свойство, к левой или правой ассоциативности не имеет отношения)

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

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

Отлично! Тихой сапой появилось сразу два новых понятия: морфизм (если кто не знает — это как раз те стрелочки на диаграмме выше) и «малая категория». Хорошо хоть, дальше эти понятия не используются.

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

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

Вы правы, это не метод, это функция. Моя ошибка — поправлю и заодно поясню.

Это уже ребус какой-то. Даже известная шутка про «всего лишь моноид в категории эндофункторов» — и то понятнее как определение монады.

Я поправлю данное пояснение. (Спасибо за замечание)

А это вообще ошибка. Монадический тип — это любой тип, имеющий kind * -> *. То есть это даже более слабое свойство, чем у функтора!


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

В целом, спасибо вам за комментарии!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий