E
пишешь в фп стеке — пиши с фп либами, которые дизайнили под фп, такое вот правило пальца имхо
/toxic
Size: a a a
2021 February 28
AS
Возьмёшь дуби, замучаешься с конкатенацией, возьмёшь сверху quill, который компилит нерабочий код на раз-два. Будешь с теплотой вспоминать уютный слик, пусть не совсем с тру фп интерфейсом.
БЁ
Как продать скаловый фп стек бизнесу, если там либы хуже качеством
AS
фп важно для программиста на уровне его взаимодействия с кодом, а не на уровне исполнения кода в ВМ или еще где
слик вполне себе фп
Α
слик вполне себе фп
согласен
странная логика говорить раз не F[_] то не ФП
типа не служил не мужик)
странная логика говорить раз не F[_] то не ФП
типа не служил не мужик)
Α
DBIO это тоже монада
Α
и ленивая пока run не сделаешь - ничего не произойдет
ΛВ
слик вполне себе фп
val setupFuture = db.run(setup)
футуры исполняются сразу и следовательно не соблюдают ссылочную прозрачность как минимум. Значит не фп (не в понимании «фп ето программирование с ФВП»)
футуры исполняются сразу и следовательно не соблюдают ссылочную прозрачность как минимум. Значит не фп (не в понимании «фп ето программирование с ФВП»)
ΛВ
согласен
странная логика говорить раз не F[_] то не ФП
типа не служил не мужик)
странная логика говорить раз не F[_] то не ФП
типа не служил не мужик)
да хоть голое ИО/ЗИО/моникстаск, необязательно тф
Α
val setupFuture = db.run(setup)
футуры исполняются сразу и следовательно не соблюдают ссылочную прозрачность как минимум. Значит не фп (не в понимании «фп ето программирование с ФВП»)
футуры исполняются сразу и следовательно не соблюдают ссылочную прозрачность как минимум. Значит не фп (не в понимании «фп ето программирование с ФВП»)
Task.deferFromFuture(db.run(setup))ΛВ
Task.deferFromFuture(db.run(setup))я это и имею в виду под «не задизайнено под фп-подход с сохранением СП» — надо каждый чих заворачивать в такое вот
ΛВ
что не добавляет удобства, нужно писать свои обертки
Α
IO.fromFuture(IO(db.run(setup)))
согласен хуже чемsetup.transact(tr)
Но зато check тесты не нужно писать и свои запросы тоже не надо везде копии плодитьT
фп важно для программиста на уровне его взаимодействия с кодом, а не на уровне исполнения кода в ВМ или еще где
программист, который не шарит в том как исполняется код в ВМ, иногда пишет очень стрёмный в плане перформанса код
два топ примера из практики
на втором месте .toMap который вызывали на mutable кеше, который мог быть большой 10-20 мб, несколько сотен раз в секунду чтобы получить immutable Map
там дальше ни на что это вообще не влияло
убрать .toMap - минус 60 процентов primary allocation, минус 30 процентов загрузки прода (а прод тогда был 72 ядра)
а на первом месте - lazy val за каким-то хером в теле метода, которая тогда (2.11 по-моему скала ещё была) автоматически становилась глобальным тред локом для всех тредов, которые этот метод вызывают
так что фп важно для программиста all the way down
два топ примера из практики
на втором месте .toMap который вызывали на mutable кеше, который мог быть большой 10-20 мб, несколько сотен раз в секунду чтобы получить immutable Map
там дальше ни на что это вообще не влияло
убрать .toMap - минус 60 процентов primary allocation, минус 30 процентов загрузки прода (а прод тогда был 72 ядра)
а на первом месте - lazy val за каким-то хером в теле метода, которая тогда (2.11 по-моему скала ещё была) автоматически становилась глобальным тред локом для всех тредов, которые этот метод вызывают
так что фп важно для программиста all the way down
ΛВ
программист, который не шарит в том как исполняется код в ВМ, иногда пишет очень стрёмный в плане перформанса код
два топ примера из практики
на втором месте .toMap который вызывали на mutable кеше, который мог быть большой 10-20 мб, несколько сотен раз в секунду чтобы получить immutable Map
там дальше ни на что это вообще не влияло
убрать .toMap - минус 60 процентов primary allocation, минус 30 процентов загрузки прода (а прод тогда был 72 ядра)
а на первом месте - lazy val за каким-то хером в теле метода, которая тогда (2.11 по-моему скала ещё была) автоматически становилась глобальным тред локом для всех тредов, которые этот метод вызывают
так что фп важно для программиста all the way down
два топ примера из практики
на втором месте .toMap который вызывали на mutable кеше, который мог быть большой 10-20 мб, несколько сотен раз в секунду чтобы получить immutable Map
там дальше ни на что это вообще не влияло
убрать .toMap - минус 60 процентов primary allocation, минус 30 процентов загрузки прода (а прод тогда был 72 ядра)
а на первом месте - lazy val за каким-то хером в теле метода, которая тогда (2.11 по-моему скала ещё была) автоматически становилась глобальным тред локом для всех тредов, которые этот метод вызывают
так что фп важно для программиста all the way down
ну там не совсем про это была реплика.
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
T
ну там не совсем про это была реплика.
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
а, ну по-моему достаточно посмотреть в имплементации скала коллекций с var и прочим
Α
ну там не совсем про это была реплика.
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
Я говорил о том, что ФП дает бенефиты именно на этапе чтения/написания/поддержки кода и архитектуры, а смысла фанатично требовать тру-фпшность на всех уровнях нет.
Поэтому например нормально внутри скаластд коллекций видеть вайлтру и прочие мутабельные штуки, и иметь вполне себе нетруфп-грязную-какещехотите жвм
while truшки в локальных методах это вполне себе ФП если я не ошибаюсь
называется локализованный эффект
называется локализованный эффект
ΛВ
while truшки в локальных методах это вполне себе ФП если я не ошибаюсь
называется локализованный эффект
называется локализованный эффект
да, я про это и говорю
ΛВ
Ссылочная прозрачность сохраняется на важном для разработчика уровне и отлично