00:00:00 Определение функтора 00:01:40 Функтор из прототипа 00:08:17 Функтор из прототипа (упрощенный) 00:09:14 Функтор из замыкания 00:11:49 Функтор из замыкания с тернарным оператором 00:12:44 Аппликативный функтор из прототипа 00:18:08 Аппликативный функтор из замыкания (монада) 00:23:11 Пример применения монады 00:28:37 Функциональный объект 00:39:44 Пример применения функционального объекта 00:45:27 Обобщение
Спасибо! Интересно мозги потренировать... Я пока не написал упрощенную функцию для считывания параметра из конфинга, не мог понять, как ваша монада работает (примерно 28 минута). Вот моя функция, которая не монада, но делает тоже. Может кому-то поможет лучше понять про монады: const fp = obj => txt => txt.split('.').reduce((prev, key) => (prev[key]), obj);
По моему не особо правильно показывать монады и функторы в js... Это не функциональное мышление... Мы думаем что делает объект,а не что мы делаем с алгебраическим типом данных... Проблема в том,что слушатель незнакомый с хаскеллем может подумать,что функторы и монады это контейнеры,что является грубейшей ошибкой... Это скорее видео для тех,кто хочет реализовать монады и функторы в js,а не для тех,кто с ними не знаком... П.с. Ничего не имею против видео,отличный урок... Хотя,тут вопрос спорный ибо функторы и монады понятия не из haskell,а из теории категорий,и как их лучше перевести в программирование,это уже субъективщина....
В JS функциональное программирование в первую очередь - это источник идей о том, какой синтаксис и приемы можно взять на вооружение. И даже думать о монадах, как о контейнерах, а не как об абстракциях цепочек вычислений, вполне допустимо для js. Вот промисы же не монады, но взяв приемы из ФП они очень обогатили js.
Нет,я не против,просто это уже не ФП выходит... Хотя,опять же,это хождение по тонкому льду,ибо в том же хаскелле настолько все абстрактно,что не можешь определится, это сущность что-то делает или это действия над ней. Естественно такие функциональные объекты имеют место быть
@@mechmaker9346 в js даже функциональные объекты с мутабельным состоянием распространены, это не ФП, конечно, это мультипаралигменное программирование. Чистое ФП для js не прижилось, тут много всего, что встроено в язык и вошло в практику и рушит принципы ФП, если строго следовать, то можно зайти в тупик.
@@TimurShemsedinov + Естественно в js не OnlyFP. Вообще мало какие яп позволяют создавать чисто ФП код. Ибо есть несколько причин: 1.Отсутствие библиотек под ФП,или их не особая распространенность. 2.отсутствие рекурсии,не выдающей stackoverflow,что ведёт к тому,что становится невозможным передавать состояние без мутации переменных и создание долгого цикла. 3.Ну и естественно отсутствие такой хорошей поддержки ФП,как на пример в хаскелле. Нет кучи фич,облегчающих написание ФП кода.
@@mechmaker9346 в js чистый фп код очень плохо оптимизируется, потому, что все заточено под оптимизацию прототипов, а вот замыкания по-разному: пару лет назад разогнали хорошо, а теперь опять все медленно стало. И это вряд ли изменится, потому, что производительность тестируют на больших массивах кода, написанного в старом стиле.
Мне интересно ваши студенты понимают материал сразу же на паре? Я изучаю js примерно год и не посидев над таким кодом минут 20 я ничего не пойму из этого. Не вижу большого смысла, так усложнять код (функторами и монадами), если это все можно также сделать и императивным путем, но это не будет выглядеть так же пафосно. Читаемость кода сильно падает, если тоже самое написать на условном ООП. Конечно, если это придумывали умные дядьки, значит им видней что истинна, а кто я такой? Я же обычный смертный, которому критиковать такой священный код не по силам.
Пример "7-path.js". Императивный код хорошо отрабатывает, если мы не найдем нужный код, ничего не валится с ошибками. А вот функциональный код не работает при передаче неверного пути или если в объекте не будет нужного ключа. Я даже специально попробовал запустить именно ваш код, в надежде, что я ошибся, но нет) И в итоге, получается пример бессмысленный) Еще и с учетом того, что проверку ключей можно чейнить, по принципу: if(config?.server?.ssl?.key?.filename) {}
Лучшее объяснение с примерами функторов и монад для реального применения в JS, а не голая теория из математики, чтобы потом голову сломать где, как и зачем это применять. У вас классные уроки !
немного не хватает определений. Функтор - это, Аппликативный функтор это. Приходится свойства паттерна извлекать из реализации, рискуя спутать конкретную реализацию и сам концепт.
14:14 -- такое опредление map категорически не соответствует требованию функтора. Нельзя превентить повторную запаковку после мапа. Я понимаю, что это попытка сделать рабочим apply. Но строго говоря, это нарушает требование: F(x).map(f) => F(f(x)). А вот в конструкторе такое сделать ... -- вроде, как должно получится.
28:08 не понятно где это условие, при котором "вычисления дальше не пойдут", ведь при отсутствии поля по ключу, мы возвращаем пустой объекти и делаем следующий шаг редьюса, т.о. редьюс пробежит по всем распарсенным ключам, только каждый раз будет возвращаться пустой объект и попытка взять у него поле. Не понятен этот момент(
вы о примере 7-path? Я оставил коммент, может я не прав, но Пример "7-path.js". Императивный код хорошо отрабатывает, если мы не найдем нужный код, ничего не валится с ошибками. А вот функциональный код не работает при передаче неверного пути или если в объекте не будет нужного ключа. Я даже специально попробовал запустить именно ваш код, в надежде, что я ошибся, но нет) И в итоге, получается пример бессмысленный) Еще и с учетом того, что проверку ключей можно чейнить, по принципу: if(config?.server?.ssl?.key?.filename) {}
в итоге реально в Maybe пустой объект приходит, что нельзя трактовать как отсутствие значения и поэтому тут все бессмысленно получается) так как map() у Maybe запускается и происходит ошибка уже в "fs"
28:38 -- кое-что важное потерялось ) function Counter() {} Counter.prototype = Object.create(Function); // a то у нас перестанут работать apply, bind, и call.
Ну так можно сказать обо всем, например - зачем нам фабрики, если есть конструкторы. Функциональные концепции обогащают если к ним относиться без фанатизма, как и концепции ооп, реактивного программирования. Все это только разные синтаксисы и их можно комбиноровать и находить более выразительные для каждой задачи.
@@TimurShemsedinov в ФП неудобно писать и читать код, его намного сложнее понять впринципе. Я привык всегда писать в ООП, ФП кажется каким-то кошмаром нечитабельным. В ООП всё предельно просто, создаём шаблон (объект) и на основании него получаем экзмепляры этого объекта, можем всё индивидуально изменить, всё понятно. Я конечно могу ошибаться, так как посмотрел про ФП буквально минут 10-15, но не это всё равно бред полный.
@@AkkayHT228 Я знаю людей, которым ФП проще писать и читать, мне вот примерно одинаково, это дело привычки. Все парадигмы имеют свои плюсы и минусы. У ООП тоже много проблем, например, в многопоточном приложении доступ к объектам с использованием примитивов синхронизации гораздо сложнее, чем делать многопоточные приложения с имутабельными данными на ФП. Функциональный код распараллеливается, тестируется, не вызывает проблем с архитектурой и интеграцией, и во многих случаях можно найти много общего с ООП, вот тут есть лекция th-cam.com/video/0JxSs_GcvbQ/w-d-xo.html
@UCbG9xPEttNUQNQM-4z4LjXw Ну освоить ООП за неделю, разве что без паттернов, а с паттернами это несколько месяцев. Так же и с ФП - можно освоить за 3 дня без паттернов, т.е. понять функции, контексты, замыкания и все. Я советую освоить несколько парадигм и не спешить ни куда, как минимум ООП, ФП, реактивное и асинхпонное, без этого на JS полноценно писать не выйдет. Потом возьмешь react или rx.js и все это понадобится.
.. только с бумажкой и ручкой это можно понять (далее с чуть сокращениями) : fn => maybe( null ( fn , x => ++x ) ) - выходит как возврат независимого вызова maybe .. далее это вызывается в ap методе верхнего maybe : maybe( null( fn => null ( fn, 10), x => ++x ) ) .. подставляем : maybe ( null(x=>++x , 10) - уже дает новый мэп (который потом вызывается с логом ) с замыканием на 11 . пс . надеюсь не ошибся . . очень сложно как механизм ( хотя применение может и нормально , в виде уже готовой ф-ии но это всё нужно раскрыть в виде разных примеров ) . А по вашему оно всё стоит внимания в практике ?
00:00:00 Определение функтора
00:01:40 Функтор из прототипа
00:08:17 Функтор из прототипа (упрощенный)
00:09:14 Функтор из замыкания
00:11:49 Функтор из замыкания с тернарным оператором
00:12:44 Аппликативный функтор из прототипа
00:18:08 Аппликативный функтор из замыкания (монада)
00:23:11 Пример применения монады
00:28:37 Функциональный объект
00:39:44 Пример применения функционального объекта
00:45:27 Обобщение
Спасибо!
Интересно мозги потренировать...
Я пока не написал упрощенную функцию для считывания параметра из конфинга, не мог понять, как ваша монада работает (примерно 28 минута).
Вот моя функция, которая не монада, но делает тоже.
Может кому-то поможет лучше понять про монады:
const fp = obj => txt => txt.split('.').reduce((prev, key) => (prev[key]), obj);
reduce - швейцарский нож в js )
Интересно. Сложно. Спасибо!
Есть ли ссылка на список прикладных задач по данной теме?
Я займусь лабораторными с осени
Что такое монады? я так и не понял.
Покопай Huskell. Можно встретить литературу, где это более-менее доступно объясняется.
Это всего лишь моноид в категории эндофункторов (с) :)
пока лучшая видюха про JS
По моему не особо правильно показывать монады и функторы в js...
Это не функциональное мышление...
Мы думаем что делает объект,а не что мы делаем с алгебраическим типом данных...
Проблема в том,что слушатель незнакомый с хаскеллем может подумать,что функторы и монады это контейнеры,что является грубейшей ошибкой...
Это скорее видео для тех,кто хочет реализовать монады и функторы в js,а не для тех,кто с ними не знаком...
П.с.
Ничего не имею против видео,отличный урок...
Хотя,тут вопрос спорный ибо функторы и монады понятия не из haskell,а из теории категорий,и как их лучше перевести в программирование,это уже субъективщина....
В JS функциональное программирование в первую очередь - это источник идей о том, какой синтаксис и приемы можно взять на вооружение. И даже думать о монадах, как о контейнерах, а не как об абстракциях цепочек вычислений, вполне допустимо для js. Вот промисы же не монады, но взяв приемы из ФП они очень обогатили js.
Нет,я не против,просто это уже не ФП выходит...
Хотя,опять же,это хождение по тонкому льду,ибо в том же хаскелле настолько все абстрактно,что не
можешь определится,
это сущность что-то делает или это действия над ней.
Естественно такие функциональные объекты имеют место быть
@@mechmaker9346 в js даже функциональные объекты с мутабельным состоянием распространены, это не ФП, конечно, это мультипаралигменное программирование. Чистое ФП для js не прижилось, тут много всего, что встроено в язык и вошло в практику и рушит принципы ФП, если строго следовать, то можно зайти в тупик.
@@TimurShemsedinov
+
Естественно в js не OnlyFP.
Вообще мало какие яп позволяют создавать чисто ФП код.
Ибо есть несколько причин:
1.Отсутствие библиотек под ФП,или их не особая распространенность.
2.отсутствие рекурсии,не выдающей stackoverflow,что ведёт к тому,что становится невозможным передавать состояние без мутации переменных и создание долгого цикла.
3.Ну и естественно отсутствие такой хорошей поддержки ФП,как на пример в хаскелле.
Нет кучи фич,облегчающих написание ФП кода.
@@mechmaker9346 в js чистый фп код очень плохо оптимизируется, потому, что все заточено под оптимизацию прототипов, а вот замыкания по-разному: пару лет назад разогнали хорошо, а теперь опять все медленно стало. И это вряд ли изменится, потому, что производительность тестируют на больших массивах кода, написанного в старом стиле.
Мне интересно ваши студенты понимают материал сразу же на паре? Я изучаю js примерно год и не посидев над таким кодом минут 20 я ничего не пойму из этого. Не вижу большого смысла, так усложнять код (функторами и монадами), если это все можно также сделать и императивным путем, но это не будет выглядеть так же пафосно. Читаемость кода сильно падает, если тоже самое написать на условном ООП. Конечно, если это придумывали умные дядьки, значит им видней что истинна, а кто я такой? Я же обычный смертный, которому критиковать такой священный код не по силам.
12 к просмотров и так мало лайков! Жадюги!
Хм, неплохо, или я за год поумнел или лекции стали неплохо так подробными.
Ну больше материала и примеров стало
Отличный обзор.
Вот ссылка на алгебраические структуры: монады, функторы и кучу другого )
github.com/fantasyland/fantasy-land
Пример "7-path.js".
Императивный код хорошо отрабатывает, если мы не найдем нужный код, ничего не валится с ошибками.
А вот функциональный код не работает при передаче неверного пути или если в объекте не будет нужного ключа. Я даже специально попробовал запустить именно ваш код, в надежде, что я ошибся, но нет) И в итоге, получается пример бессмысленный) Еще и с учетом того, что проверку ключей можно чейнить, по принципу:
if(config?.server?.ssl?.key?.filename) {}
Интересно а вы сами где все это учили?)
За 25 лет программирования это все из разных мест собралось
Лучшее объяснение с примерами функторов и монад для реального применения в JS, а не голая теория из математики, чтобы потом голову сломать где, как и зачем это применять. У вас классные уроки !
немного не хватает определений. Функтор - это, Аппликативный функтор это. Приходится свойства паттерна извлекать из реализации, рискуя спутать конкретную реализацию и сам концепт.
Если что, это можно найти в словаре курса.
14:14 -- такое опредление map категорически не соответствует требованию функтора. Нельзя превентить повторную запаковку после мапа. Я понимаю, что это попытка сделать рабочим apply. Но строго говоря, это нарушает требование:
F(x).map(f) => F(f(x)).
А вот в конструкторе такое сделать ... -- вроде, как должно получится.
Почему-то напоминает Fluent Interface
місцями важкувато, але круто!)
Отличные лекции! Спасибо Тимур
28:08 не понятно где это условие, при котором "вычисления дальше не пойдут", ведь при отсутствии поля по ключу, мы возвращаем пустой объекти и делаем следующий шаг редьюса, т.о. редьюс пробежит по всем распарсенным ключам, только каждый раз будет возвращаться пустой объект и попытка взять у него поле. Не понятен этот момент(
вы о примере 7-path? Я оставил коммент, может я не прав, но
Пример "7-path.js".
Императивный код хорошо отрабатывает, если мы не найдем нужный код, ничего не валится с ошибками.
А вот функциональный код не работает при передаче неверного пути или если в объекте не будет нужного ключа. Я даже специально попробовал запустить именно ваш код, в надежде, что я ошибся, но нет) И в итоге, получается пример бессмысленный) Еще и с учетом того, что проверку ключей можно чейнить, по принципу:
if(config?.server?.ssl?.key?.filename) {}
в итоге реально в Maybe пустой объект приходит, что нельзя трактовать как отсутствие значения и поэтому тут все бессмысленно получается) так как map() у Maybe запускается и происходит ошибка уже в "fs"
В последнем примере с коллектором данных после вызова `collector.callback` нужно устанавливать `collector.finished = true`?
сложна нипанятна
Спасибо за лекцию!
28:38 -- кое-что важное потерялось )
function Counter() {}
Counter.prototype = Object.create(Function); // a то у нас перестанут работать apply, bind, и call.
Спасибо!
А зачем примешивать в map методы ap и chain в функциональном стиле? Ведь на прототипах не было примеси только отдельные методы
Спасибо. Интересно
Зачем усложнять жизнь, добавляя всякие ненужные монады и функторы?
Ну так можно сказать обо всем, например - зачем нам фабрики, если есть конструкторы. Функциональные концепции обогащают если к ним относиться без фанатизма, как и концепции ооп, реактивного программирования. Все это только разные синтаксисы и их можно комбиноровать и находить более выразительные для каждой задачи.
@@TimurShemsedinov в ФП неудобно писать и читать код, его намного сложнее понять впринципе. Я привык всегда писать в ООП, ФП кажется каким-то кошмаром нечитабельным. В ООП всё предельно просто, создаём шаблон (объект) и на основании него получаем экзмепляры этого объекта, можем всё индивидуально изменить, всё понятно. Я конечно могу ошибаться, так как посмотрел про ФП буквально минут 10-15, но не это всё равно бред полный.
@@AkkayHT228 Я знаю людей, которым ФП проще писать и читать, мне вот примерно одинаково, это дело привычки. Все парадигмы имеют свои плюсы и минусы. У ООП тоже много проблем, например, в многопоточном приложении доступ к объектам с использованием примитивов синхронизации гораздо сложнее, чем делать многопоточные приложения с имутабельными данными на ФП. Функциональный код распараллеливается, тестируется, не вызывает проблем с архитектурой и интеграцией, и во многих случаях можно найти много общего с ООП, вот тут есть лекция th-cam.com/video/0JxSs_GcvbQ/w-d-xo.html
@UCbG9xPEttNUQNQM-4z4LjXw Ну освоить ООП за неделю, разве что без паттернов, а с паттернами это несколько месяцев. Так же и с ФП - можно освоить за 3 дня без паттернов, т.е. понять функции, контексты, замыкания и все. Я советую освоить несколько парадигм и не спешить ни куда, как минимум ООП, ФП, реактивное и асинхпонное, без этого на JS полноценно писать не выйдет. Потом возьмешь react или rx.js и все это понадобится.
Timur Shemsedinov спасибо, надеюсь потраченное время на изучение парадигм окупится в будущем
~19 минута --> 6-closure-ap.js --> // Usage --> 2й fp.maybe это просто ... совсем не понятно !
.. только с бумажкой и ручкой это можно понять (далее с чуть сокращениями) :
fn => maybe( null ( fn , x => ++x ) ) - выходит как возврат независимого вызова maybe ..
далее это вызывается в ap методе верхнего maybe :
maybe( null( fn => null ( fn, 10), x => ++x ) )
.. подставляем :
maybe ( null(x=>++x , 10) - уже дает новый мэп (который потом вызывается с логом ) с замыканием на 11 . пс . надеюсь не ошибся . . очень сложно как механизм ( хотя применение может и нормально , в виде уже готовой ф-ии но это всё нужно раскрыть в виде разных примеров ) . А по вашему оно всё стоит внимания в практике ?
а почему называется maybe ? это к чему отсылка такая ? может лучше mapbe ?