Смотрим вместе YT: [Try2] Ulbi - Функциональное программирование от А до Я. ФП на JS.

preview_player
Показать описание
Это вторая попытка посмотреть видео Ulbi TV: Функциональное программирование от А до Я.

Первая провалилась в силу того, что я постоянно отвлекался на чат, вопросы etc...

Итак:
Посмотрим вместе, на скорости полтора, видео от
Ulbi TV: Функциональное программирование от А до Я. ФП на JS. Монады, функторы, каррирование, композиция

_В этом видео мы поговорим про функциональное программирование на javascript. Разберем такие темы как: Декларативность, Чистые функции и сайд эффекты, Иммутабельность (неизменяемость), Функции первого класса, Функции высшего порядка, Композиция/конвейер, Частичное применение и каррирование, Chaining, Контейнеры, Функторы и аппликативные функторы, Монады, Спецификация Fantasy-Land_

Таймкоды:
00:00:00 Музыка
00:02:15 Вступление
00:03:40 Проверка/настройка звука
00:08:00 Предисловие
00:10:35 Ремарка об ООП/ФП
00:14:25 Приступаем к просмотру
00:16:40 Что такое ФП
00:24:15 Концепции ФП
00:32:05 Декларативность
00:36:25 Чистые функции
00:43:40 Иммутабельность
00:59:15 Функции первого класса/Функции высшего порядка
01:07:10 Смысл концепций ФП
01:10:15 Композиция
01:17:30 Каррирование и частичное применение
01:30:20 Переподключение
01:32:35 Продолжение - Каррирование и частичное применение
01:36:50 Сhaining
01:40:10 Контейнеры
01:45:50 Функторы и монады
01:53:40 Аппликативные функторы
01:58:40 Спецификация Fantasy land
01:59:30 Другие монады (either, future, writer)
02:00:55 Завершаем просмотр
02:01:45 Разбираем ФП на примерах. Демонстрация абстракций на примере контейнеров
02:32:30 Парсим сложенный JSON
02:42:30 Продолжение - Демонстрация абстракций на примере контейнеров
02:47:00 Зачем нам это? Пример кода с Promise
02:58:50 Пересмотрим момент о контейнерах на базе классов с комментариями маэстро


*Поддержать маленького бородатого JavaScript-ра*
Карта Приват (Bobrov Maksym): 5168745021397333

USDT Tron (TRC20): TKoZu59WHiX6L6qvwYTYTsZJerDrnAHBTx
USDT etherium (erc20): 0x75fb8a62dfcf453b2e73f1ef1c407d46f918fffa
TON: UQAGXvuhxg3qU0eFgOxtdDlKXqdp1zPq6yCRSRbRYQClxOzH
bitcoin:bc1q74aru82v4d3alay7p53jdwkmxe4a5gz7fmvfm2?message=AsForJS&time=1686349743

⎡~yt ~2 ~js ~ulbi ~fp ~try2⎦
Комментарии
Автор

00:00:00 Музыка
00:02:15 Вступление
00:03:40 Проверка/настройка звука
00:08:00 Предисловие
00:10:35 Ремарка об ООП/ФП
00:14:25 Приступаем к просмотру
00:16:40 Что такое ФП
00:24:15 Концепции ФП
00:32:05 Декларативность
00:36:25 Чистые функции
00:43:40 Иммутабельность
00:59:15 Функции первого класса/Функции высшего порядка
01:07:10 Смысл концепций ФП
01:10:15 Композиция
01:17:30 Каррирование и частичное применение
01:30:20 Переподключение
01:32:35 Продолжение - Каррирование и частичное применение
01:36:50 Сhaining
01:40:10 Контейнеры
01:45:50 Функторы и монады
01:53:40 Аппликативные функторы
01:58:40 Спецификация Fantasy land
01:59:30 Другие монады (either, future, writer)
02:00:55 Завершаем просмотр
02:01:45 Разбираем ФП на примерах. Демонстрация абстракций на примере контейнеров
02:32:30 Парсим сложенный JSON
02:42:30 Продолжение - Демонстрация абстракций на примере контейнеров
02:47:00 Зачем нам это? Пример кода с Promise
02:58:50 Пересмотрим момент о контейнерах на базе классов с комментариями маэстро

AsForJS
Автор

Респект, Мурычу, за то что стал спокойнее обозревать видео 😅

wolfern
Автор

13:21 Любой дислектик может освоить ФП, это чрезвычайно просто.
3:27:34 Спустя час отладки. "Ну что-то я тут напутал по дороге". Отладить это не представляется возможным, но теоретически должно работать. Завершаем стрим.

AlexSav
Автор

В математике \xy.x+y- это просто сокращенная запись от (\x(\y.x+y)) чтоб писать меньше скобок. Т.е. с математической точки зрения (x, y) => x + y - это тоже самое что (x) => (y) => x+y так как подстановка переменных все равно происходит по порядку. Далее идет приведение кода к математической форме, где каждая переменная содержит в себе некое выражение. Что x = 5 можно воспринимать как x = () => 5; т.е. x() вернет 5. Таким образом любую абстракцию мы можем единообразно апплицировать - по сути там может содержаться что угодно.

niy
Автор

Видосы Мурыча можно смотреть уже хотя бы за наряды. Тоже хочу так наряжаться, когда стану дедом 👍

АнимусАнанимус
Автор

Мурыч на 47:48 прицепился у скоупу, хотя это не проблема. Проблема в другом - Ульби мутирует объект по ссылке, что является сайд-эффектом.

АнимусАнанимус
Автор

на 1:33:15 куда-то ушёл
поставил на паузу подожду пока вернётся

Ылыфылф
Автор

Григорий Бизюкин записал версию 2024 функциональное програмирование, будет на него обзор?

Safr
Автор

Насчёт предлагаем ой абстракции вида God Composition - это лютая связность кода, и такая композиция в общем виде является нерешаемой задачей.
Например, как композировать такой штукой CPS?
Вот у нас есть число 42 в CPS:
const fourtytwo = cont => someFn(cont(42))
Удачи его распаковать в итоге, хотя композируется CPS замечательно.

А если объект - асинхронно е вычисление, которое можно выполнить в гонке, а можно - последовательно?
Тоже нужно во что-то оборачиваться в зависимости от того, как это хочется с композировать, и прописывать в God Compose все комбинации?

Математики не глупые, они в курсе про проблемы вычислимости и композируемости, и то, что мы видим в Фентези Ленд - на данный момент самые передовые решения, к которому пришли умные дяди.
Пришли они к тому, что видов композиции много, их отношения друг с другом разные, но у них есть определённые закономерности и система.
Это не ООП и здесь речь не про инженерию, а про математику. Композируемость - проблема математическая и решается соответствующе.

Хотя и в инженером смысле я бы естественно отдал предпочтение Фэнтезилэнд, т.к. это ПРАВИЛЬНЫЕ (математические корректные, согласованный) абстракции, которые не претендуют на универсальное решение всех задач и вместо этого решают строго определённые, но на 5 с плюсом.

АнимусАнанимус
Автор

А куда делся участок видео, где автор сообщает всем самую главную истину своего подхода "Мне глубоко плевать на спецификацию..."?

ИгорьБлудов-нс
Автор

стоит отметить, что это

var type = (anyThing) => (make) => make(anyThing)

var str = type('123')
var log = type(console.log)

log(str)

очень круто

artyomboyko
Автор

Кстати, как стоит в JS поступать с "глобальными" переменными, когда они нужны? Заводить каждую отдельно, или отправить в window/global/etc лишь ссылку на скрипт с переменными (чтобы пользоваться ими через этот скрипт и его методы)? Второй способ выглядит во всём лучше, это действительно так и есть с точки зрения

aethernova
Автор

Не нашел у автора ссылки на github или любые другие работы. Чтобы понять, что его комментарии стоит слушать.

CaiN
Автор

А Мурыч точно знает, что такое функторы и монады?
Что-то бред Ulbi с 1:47:00 про "монада - это конкретная реализация функтора", совершенно бредовая реализация Maybe, не менее бредовый граф подтипирования container->functor->monad и прочие ляпы не сильно смутили Мурыча👀

АнимусАнанимус
Автор

2:24:14 делать множество с отмеченной точкой лучше не надо, бо может случится и такое:

var userFromDB = { name: 'theCont', age: 32 }
_typeThing(user)

И юзер с неожиданным ником сломает вам приложение. Функторы, конечно, будут лучше чем вот эти вот все финтифлюшки с недоCPS.

Идея Мурыча, на самом деле, недалека от разумной. Если довести ее до ума, получится следующее:
const of = x => f => f(x)
const map = f => fx => fx(x => of(f(x)))
const unOf = fx => fx(x => x)

const add5 = map(x => x + 5)
const twentyFive = of(25)
const minus3 = map(x => x - 3)

console.log(unOf(
minus3(add5(twentyFive)))
) // prints 27

Но если присмотреться внимательно, это -те же яйца, только в профиль- тот же функтор, контейнер, или как еще там Identity обзывают:

const of = x =>
({ unOf: x // cпособ достать значение
, map: f => of(f(x)) //тот самый map функтора
})
const map = f => fx => fx.map(f)
const unOf = fx => fx.unOf

const add5 = map(x => x + 5)
const twentyFive = of(25)
const minus3 = map(x => x - 3)

// 27
console.log(of(25).map(x => x + 5).map(x => x - 3).unOf) // 27

На хачкеле:
of = (&)
map = of . (of .)
unOf = of id

АнимусАнанимус
Автор

Мурыч, подскажи

Ты постоянно говоришь "функция должна работать исключительно со своими параметрами"

Это прекрасные слова

Однако, даже в своей абстракции
var typeThing = (theThing) => (doMakeThing) => doMakeThing(theThing)
твои функции используют идентификаторы из родительского окружения
(doMakeThing) => doMakeThing(theThing)
theThing это идентификатор из родительского окружения

Можешь ли ты написать эту абстракцию, но так, чтобы функции работали ИСКЛЮЧИТЕЛЬНО со своими параметрами?
Без внешних идентификаторов

artyomboyko
Автор

Мурыч, не согласен с тем, что ты акцентируешь внимание на том, что использование глобальной области видимости и импортов не вписывается в концепцию ФП.
Во-первых, в лямбда-исчислении есть константы. Это полноправная часть синтаксиса.

Во-вторых, как ты знаешь, в лямбда-исчислении есть понятие области видимости, так что глобальный скоуп и импорты в ЯП можно спокойно легализировать представив их в виде параметров лямбды (т.е. локальным скоупом), значением которой является сама программа (модуль).
Таким образом глобальный скоуп модуля превращается в локальный скоуп лямбды, которая и представляет собой этот модуль. Возможность использовать одни объявления в других объявлениях этого же модуля и в них самих может быть достигнута использованием комбинатора неподвижной точки.

Т.е. простой модуль можно представить как:
module = λimports. λglobal. Exports
И экспорты модуля как:
exports = (λglobal. global global) (module Imports)

Такая трансляция довольно механическая и двусторонняя.
Пример:

Пусть module это:

import {twenty} from "numbers"
add = ...
a = twenty;
b = 30;
add50 =x => add x (add 25 50);

где весь глобальный скоуп экспортируется.

Можем представить это в лямбда-исчислении:
module = λimports. λglobal. { a: imports.twenty, b: 30, add50: λx. global.add x (global.add global.a global.b) }
(лямбда-исчисление с операторами, числовыми литералами, объектами и деструктуризацией, чтобы лишний раз не ломать мозг)

Ну и экспорты модуля = (λglobal. global global) (module {twenty: ...})

Т.е. глобальный скоуп, модули и экспорты сами по себе - проблема скорее синтаксическая и ортогональная ФП. Всё это вполне представимо в лямбда-исчислении.

Конечно, если мы будем говорить о конкретной реализации модульной системы, и в частности о динамических импортах, то всё несколько сложнее, но тоже решается, если мы признаем возможность чистого I/O в ФП (с чем Мурыч не согласен), но это уже совсем другая история.

АнимусАнанимус
Автор

Как по мне автор обозреваемого видео 80% всего что он говорит вообще нужно проигнорировать и не забивать голову чепухой

mooncorizer
Автор

Вижу где-то так:
ООП - дешевая разработка, но дорогая поддержка.
ФП - наоборот, дорогая разработка, но дешевая поддержка.

ЛавсанАгат