AP
Математика — это лисп?!
Да, с альтернативным ридером просто
Size: a a a
2020 December 09
AP
LaTeX(ps) вместо S-exps
АГ
Ну вот и профункторы запомнит
Профункторы имеют крайне мало шансов войти в common knowledge разработчиков даже на Хаскеле, не говоря уже о мейнстриме. А следовательно требовать это знание от людей - все равно что самоизолироваться в очень маленькой и никому ненужной нише
AP
AP
Предпочту избегание успеха перекраиванию терминологии в пользу сирых и новичков
AP
Уже Elm есть
АГ
Я согласен с тем, что заменять домен конструкциями из теорката не нужно.
Мне не нравится подход
Во-первых, я хочу иметь сумму языков и возможность составом этой суммы манипулировать. Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта. Поэтому
Ну а дальше из всех возможных языков надо устранить нехобходимость работать с продолжениями руками:
И до системы эффектов остаётся один шаг - просунуть финальную монаду во все эффекты параметром.
Мне не нравится подход
Free Foo, где Foo - язык бога.Во-первых, я хочу иметь сумму языков и возможность составом этой суммы манипулировать. Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта. Поэтому
-- reaaly fast because index-tagged!
import "fastsum" Data.Sum
kind Effs :: [* -> *] -> * -> *
type Effs fs a = Free (Sum fs) a
Ну а дальше из всех возможных языков надо устранить нехобходимость работать с продолжениями руками:
import "free" Control.Monad.Codensity
import "fastsum" Data.Sum
kind Effs :: [* -> *] -> * -> *
type Effs fs = Codensity (Free (Sum fs))
И до системы эффектов остаётся один шаг - просунуть финальную монаду во все эффекты параметром.
> Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта.
Или не нужно. Исходя из своей практики, я склонен верить, что не нужно. Принцип YAGNI в действии
Или не нужно. Исходя из своей практики, я склонен верить, что не нужно. Принцип YAGNI в действии
AT
Я согласен с тем, что заменять домен конструкциями из теорката не нужно.
Мне не нравится подход
Во-первых, я хочу иметь сумму языков и возможность составом этой суммы манипулировать. Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта. Поэтому
Ну а дальше из всех возможных языков надо устранить нехобходимость работать с продолжениями руками:
И до системы эффектов остаётся один шаг - просунуть финальную монаду во все эффекты параметром.
Мне не нравится подход
Free Foo, где Foo - язык бога.Во-первых, я хочу иметь сумму языков и возможность составом этой суммы манипулировать. Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта. Поэтому
-- reaaly fast because index-tagged!
import "fastsum" Data.Sum
kind Effs :: [* -> *] -> * -> *
type Effs fs a = Free (Sum fs) a
Ну а дальше из всех возможных языков надо устранить нехобходимость работать с продолжениями руками:
import "free" Control.Monad.Codensity
import "fastsum" Data.Sum
kind Effs :: [* -> *] -> * -> *
type Effs fs = Codensity (Free (Sum fs))
И до системы эффектов остаётся один шаг - просунуть финальную монаду во все эффекты параметром.
А что это за синтаксис импортов?
AP
А что это за синтаксис импортов?
всегда был такой, packageimports
AT
Потому что инаково. А не потому что сложно
Это к тому, что даже бизнес-велью (быстро, дёшево) — не аргумент. Для тех, кому "активно не интересно".
АГ
Я знаю только одну устоявшуюся практику в мейнстриме — игнорировать и/или осуждать всё немейнстримовое.
Мейнстрим большой. В нем хватает разных мнений
K
> Это не бизнес-задача, это то, что мне нужно для выполнения бизнес-задач и внутреннего комфорта.
Или не нужно. Исходя из своей практики, я склонен верить, что не нужно. Принцип YAGNI в действии
Или не нужно. Исходя из своей практики, я склонен верить, что не нужно. Принцип YAGNI в действии
Ну можно и на golang программировать, if err != nil, как говорится. У нас мощный язык, всё-таки, а мы CPS-оптимизацию фримонады делаем руками.
AT
Профункторы имеют крайне мало шансов войти в common knowledge разработчиков даже на Хаскеле, не говоря уже о мейнстриме. А следовательно требовать это знание от людей - все равно что самоизолироваться в очень маленькой и никому ненужной нише
"Паттерны проектирования имеют крайне мало шансов войти в common knowledge разработчиков на JavaScript". Кому не пофиг? 😂
K
Уже Elm есть
Не вспоминай. Это живой (кхм) пример того, как не надо упрощать, чтобы js-ники не разбегались - и всё равно разбегаются
АГ
Например? Ну, кроме того, что порядок слоя обработки ошибок решает, как оно взаимодействует с эффектами.
Ну а почему вообще речь идет про механизмы эффектов? Где сами бизнесовые задачи, которые требуется решить? Я могу лишь сделать референс на статью Де Гуза "effect tracking is commercially worthless", да на свою про HFM. Не хочу повторять одно и то же много раз, тем более что (смотри картинку про уровни) разговор не склеится все равно. Я рассуждаю про верхнеуровневые концепции дизайна приложений, про риски и complexity, а рассуждения в стиле "можно функтор засунуть в фри монаду" - это все самый нижний уровень, а именно - детали имплментации.
https://degoes.net/articles/no-effect-tracking
https://github.com/graninas/hierarchical-free-monads-the-most-developed-approach-in-haskell
https://degoes.net/articles/no-effect-tracking
https://github.com/graninas/hierarchical-free-monads-the-most-developed-approach-in-haskell
АГ
Предпочту избегание успеха перекраиванию терминологии в пользу сирых и новичков
От тебя не ожидал, но ладно
YS
И ты, Брут...
K
Ну а почему вообще речь идет про механизмы эффектов? Где сами бизнесовые задачи, которые требуется решить? Я могу лишь сделать референс на статью Де Гуза "effect tracking is commercially worthless", да на свою про HFM. Не хочу повторять одно и то же много раз, тем более что (смотри картинку про уровни) разговор не склеится все равно. Я рассуждаю про верхнеуровневые концепции дизайна приложений, про риски и complexity, а рассуждения в стиле "можно функтор засунуть в фри монаду" - это все самый нижний уровень, а именно - детали имплментации.
https://degoes.net/articles/no-effect-tracking
https://github.com/graninas/hierarchical-free-monads-the-most-developed-approach-in-haskell
https://degoes.net/articles/no-effect-tracking
https://github.com/graninas/hierarchical-free-monads-the-most-developed-approach-in-haskell
При чем здесь рыночный успех эффектов, если это деталь имплементации?
АГ
Ну можно и на golang программировать, if err != nil, как говорится. У нас мощный язык, всё-таки, а мы CPS-оптимизацию фримонады делаем руками.
Это всё тоже про детали