Комментарии
25
На удивление, определение моноида показалось на порядок проще определения монады — особенно, если провести аналогию с уже знакомыми операциями из математики — сложения или умножения.
Вот тут даже улыбнулся — пока не заглянул под спойлер, казалось, что разобрался, а в синтаксисе хаскеля сломал себе мозг.
В целом хочу сказать спасибо за интересный материал. Читалось довольно легко, даже удивился, когда увидел сетования на раздутость статьи — пришлось пролистать к началу, чтобы убедиться, что статья действительно объёмная.
С синтаксисом хаскеля эти законы воспринимаются куда проще
Вот тут даже улыбнулся — пока не заглянул под спойлер, казалось, что разобрался, а в синтаксисе хаскеля сломал себе мозг.
В целом хочу сказать спасибо за интересный материал. Читалось довольно легко, даже удивился, когда увидел сетования на раздутость статьи — пришлось пролистать к началу, чтобы убедиться, что статья действительно объёмная.
Спасибо большое, жду продолжения.
Отличная статья, спасибо! Жду продолжения)
Ссылки на литературу не помешали бы также, спасибо за статью
Литературы по ФП на TS мало — в обсуждении предыдущей можно найти ссылку на https://dev.to/gcanti и https://dev.to/ybogomolov. Если хотите русскоязычной, то и того меньше — на ум ничего сходу и не приходит. Если же говорить в целом — красная книга из мира Scala это одно из лучших введений во взрослое ФП, как по мне.
Книга с енотом хороша как базовый уровень, да. Про нее не вспомнил сходу, потому что Брайан Лонсдорф дает код на JS, а не TS. Гайдов по чистому функциональному TS почти нет.
Все ищут в ТS то, что раньше искали в ActionScript 3 — технологичность кодирования. Нет этого там. Повторю свою мысль, что классы это зло. И в целом TS это дауншифтинг
Автокомплит и рефакторинги кода на TS работают предсказуемее, по сравнению с обычным JS. В именно чем вы видите дауншифтинг?
В усилении императивности и функциональщины. Ну кому как. Некоторые себя позиционируют как функциональные программисты (ой кто это?)
С таким подходом мы всё дальше отгребаем от декларативности и автоматизации. Линтеры хороши для ручного кодирования. В JS собственно два типа — object и не object. На key:value можно смотреть как на интерфейс: имплементация. Ну и сами ответьте где тут тип?
В JS собственно два типа — object и не object
Типы они, в первую очередь, в голове. А уже потом в коде, потом в интерпретаторе, потом в CPU. И чем дальше, тем меньше вариативности. В конечном счёте это просто бессистемный набор битов.
А вообще в JS побольше типов, чем два. typeof вам в помощь :)
В усилении императивности и функциональщины
И того и другого одновременно? :) Это как?
мы всё дальше отгребаем от декларативности и автоматизации
Именно TS код подвержен большей автоматизации. Все самые вкусные линтеры работают именно с ним, так как у него куда больше контекста. Декларативности TS вообще ни разу не мешает, наоборот позволяет её лучше систематизировать. В языке многое сделано для этого. Тот же самый авто-вывод типов по структуре констант.
Вы выше про "функциональщину" написали. Она по определению декларативна. Это свойство самой парадигмы FP.
Линтеры хороши для ручного кодирования
Линтеры хороши всецело. И когда они мешают — их можно отключать. А вообще JS хорош в том числе и тем, что кодогенерация нужна очень редко (почти никогда). Поэтому "ручное кодирование" — это наш хлеб.
Поэтому "ручное кодирование" — это наш хлеб.
Пока большинство так думает $mol никогда не взлетит.
Что касается усиления императивности. Топикастер топит за монады:) И именно они придают декларативным функциям императивности. Для меня императивность заключается в невозможности постпроцессорной обработки пользовательских задач. Накинуть тайпскрипт на тайпскрипт не получится.
Вы выше про "функциональщину" написали. Она по определению декларативна. Это свойство самой парадигмы FP.
Простите, вот тут уже я не соглашусь. ФП, которым занимаются большинство разработчиков — императивное. Монады как раз были предложены Уодлером и компанией как способ организации императивных цепочек вычислений в ФПЯ. И когда я слышу, что использование композиции pointless pointfree-функций из рамды это декларативное ФП — я тихонько посмеиваюсь. Хотя не буду скрывать, что деньги я получаю ровно за то же самое (ну, почти).
Если хотите истинной декларативности — смотрите в сторону моноидальных категорий. Но тут уже надо немного в теоркате разбираться. Очень советую глянуть вот этот доклад: https://www.youtube.com/watch?v=NBEzXO1xezU. Звук ужасен, но Олег Нижников здесь очень плотно и хорошо преподносит материал.
Спс за наводку. Посмотрю. Если смогу что-то понять :-D
Мне пока настоящее FP кажется сильно путанным, т.к. нет никакой практики. Мне показалось, что бесполезно читать про монады — ты либо их используешь, и тогда всё понятно, либо не используешь и тогда это выглядит как клубок теоретических знаний, которые очень сложно увязать в голове.
Вы каждый день используете монады — когда пишете someArray.flatMap(el => getOtherArray(el)), или когда пишете асинхронные функции, или даже когда просто пишете композицию двух чистых функций (Identity — тоже монада). Вопрос в а) узнавании паттерна, б) набивании руки в применении.
И нет никакого «настоящего ФП». Есть набор практик, который больше подходит в малом масштабе (тот же поинтфри, или линзы, или еще что-то такое же низкоуровневое), а есть набор, который больше для крупного масштаба подходит — тот же Onion architecture, использование систем эффектов, какие-то хитрые eDSLи и тому подобное. И всё это ФП.
Если хотите истинной декларативности — смотрите в сторону моноидальных категорий.
Если хотите реальной, а не мнимой декларативности, то посмотрите в сторону jsonnet.org Для старта можете прочитать https://databricks.com/blog/2017/06/26/declarative-infrastructure-jsonnet-templating-language.html
Надеюсь что $mol когда нибудь трансформируется в нечто похожее.
Пожалуйста, хотя бы погуглите те термины, о которых идет речь, прежде чем писать про реальность и мнимость.
Надеюсь что $mol когда нибудь трансформируется в нечто похожее.
Это поделие так же далеко от декларативности, как и прочие фронтовые фреймворки. Давайте придерживаться темы статьи в комментариях, пожалуйста.
view.tree описание в $mol вполне себе декларативно.
Вероятно https://leanpub.com/functional-programming-in-Ts-with-categories. Книжка с интригующим введением, но странной системой оплаты, антифрод которой не прининял ни одну из моих карт.
Большое спасибо за интересный материал. Жду продолжения :)
Можно ли написать аналогичный код на чистом JS (к сожалению примеры из статьи не компилируются). Мне интересно, тайпклассы для TS в текущем виде дают лишь возможность протайпчекать код или что-то большее?
На чистом JS, к огромному облегчению, я уже больше трёх лет не пишу, так что примеров на нем не будет. Классы типов это не про компайл-тайм проверки, а способ ad hoc-полиморфизма в рантайме — об этом в самом начале статьи написано.
Вот пример кода, написанного в стиле Tagless Final, с классами типов: https://gist.github.com/YBogomolov/cd50b3a479a940520ec5d0edf4d25ec0
Если это в рантайме, интересно узнать в какой JS код это потом преобразуется и благодаря каким фичам TS? Хотелось бы
какой-то минимальныйй пример.
Гист вполне рабочий — можете посмотреть, что выдает компилятор. Касательно фич — я очень советую официальную доку, ее не так давно обновляли.
Есть попытки сделать что-то на генераторах, но наиболее типобезопасным вариантом является Do из fp-ts-contrib.
А почему не взять родную fp-ts реализацию Do (v2.8+)? В Do из fp-ts-contrib так и не завезли аналог bindW. Я бы считал его как deprecated, он сделал своё дело.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Функциональное программирование на TypeScript: паттерн «класс типов»