Для этого надо знать, каково оно и кто его меняет. Небось не все знают, что капитализация буквы i - часть state. А если всё это учитывать - это сколько поклажи надо с собой таскать, весь мир на горбу.
> Для этого надо знать, каково оно и кто его меняет.
Ровно наоборот. Никто ничего не меняет. Состояние, которое мы обрабатываем, — неизменяемо. Мы, если хотим чо менять, возвращаем другой экземпляр состояния.
> сколько поклажи надо с собой таскать
Да, это правда. Но тут включается в работу: (1) злобный матан, о котором владелец этого жжурнала может рассказать намного больше, чем я; (2) ленивость и отложенные вычисления; (3) те самые The Elders, которые умеют писать оптимизации на уровне средства языка. Что, с философской точки зрения, есть хорошо, потому что говнокодер типа меня даже если и напишет свою рукописную оптимизацию, то напишет её не лучше, чем The Eldets. Что, впрочем, не уменьшает значения правила Know Your Tool; совсем плохому коду, конечно, ничто не поможет.
Думаю, что ровно наоборот: в любой момент времени следует: 1. Знать причины всех бед (мутабельность — одна из них, если вообще не главная) 2. Писать Правильно™ — именно в контексте наличествующих средств. Know Your Tool™. Знать, что уже написано by the Elders. Ну и интересоваться тем, чо они пилят сейчас. Чтобы знать, как будет Правильно в будущем.
Состояние, которое мы обрабатываем, — неизменяемо.
Беда в том, что это "состояние" - неизвестно в общем случае. Т.е. если вам надо посчитать 2+2, то ещё куда ни шло, а если надо дело иметь с реальным миром, то оказывается, что у арабов 2 не такое, у евреев + не такой, а у турков по четвергам после полудня надо добавлять к сумме 0.725. И это всё - часть вашего состояния. Таскать по всему коду набор знаний "а не в Турции ли мы? А сколько сейчас времени?" и т.п. explicitly - это путь к психушке. А implicitly - получается global mutable state.
И непонятно, чем тут особенно elders с матаном помогают.
Мне кажется, Вы путаете состояние и преобразование.
Если Ваша мат.модель подразумевает, что вычисление "2+2" не есть чистым, то есть, зависит от времени года, фазы Луны или нахождения в Турции по четвергам, то:
1. это еще вовсе не означает отказ от сути "состояния". Иначе получим, что Тьюринг — лох вследствие того, что в Турции по четвергам хотят обмануть наивного туриста.
2. да, надо набор знаний передавать. Потому что трёх аргументов "2", "+" и "2" не достаточно для преобразования.
1. Заранее знать, что чисто, а что нет, очень трудно, и оно всё время меняется. Общаться с окружающим миром необходимо, а он по определению нечист. И эта нечистота расползается. Т.е. я не спорю, что вещи вроде мемоизации и чистых функций - прекрасны там, где работают. Проблема даже не в том, что они работают не везде, а в том, насколько тяжело заранее знать, где именно, и поддерживать это знание on the long run.
2. Ну яот я такую картину в dependency injection наблюдал, когда для каждого пука надо функцию с 20 аргументами, каждый из которых зависит он различного набора из 10 других аргументов. Разбираться в этом спагетти и держать его в голове - это довольно сильно запаривает. Невольно зарождается мысль - не может быть, чтобы нельзя это делать как-нибудь по-другому.
2. Согласен, такое дебажить — с ума можно сойти. Но опять-таки: The Elders уже давно придумали, как с этим бороться: функции с массивным injection (если ФП, то — с кучей лямбд на входе) дождны быть настолько тупыми, что там не должно быть места багам. У нас в тэге F# недавно подобный вопрос пробегал (http://stackoverflow.com/q/38663990/974789).
Но, возвращаясь к исходной точке: состояние всегда должно быть детерминировано по времени {исполнения}, иначе будет то, о чём написано в шапке постинга. И тем более, нет причин считать, что "состояние" не имеет смысла.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
juan_gandhi) wrote2016-08-04 10:04 am
no subject
no subject
no subject
no subject
Ровно наоборот. Никто ничего не меняет. Состояние, которое мы обрабатываем, — неизменяемо. Мы, если хотим чо менять, возвращаем другой экземпляр состояния.
> сколько поклажи надо с собой таскать
Да, это правда. Но тут включается в работу:
(1) злобный матан, о котором владелец этого жжурнала может рассказать намного больше, чем я;
(2) ленивость и отложенные вычисления;
(3) те самые The Elders, которые умеют писать оптимизации на уровне средства языка. Что, с философской точки зрения, есть хорошо, потому что говнокодер типа меня даже если и напишет свою рукописную оптимизацию, то напишет её не лучше, чем The Eldets. Что, впрочем, не уменьшает значения правила Know Your Tool; совсем плохому коду, конечно, ничто не поможет.
no subject
no subject
Думаю, что ровно наоборот: в любой момент времени следует:
1. Знать причины всех бед (мутабельность — одна из них, если вообще не главная)
2. Писать Правильно™ — именно в контексте наличествующих средств. Know Your Tool™. Знать, что уже написано by the Elders. Ну и интересоваться тем, чо они пилят сейчас. Чтобы знать, как будет Правильно в будущем.
no subject
Беда в том, что это "состояние" - неизвестно в общем случае. Т.е. если вам надо посчитать 2+2, то ещё куда ни шло, а если надо дело иметь с реальным миром, то оказывается, что у арабов 2 не такое, у евреев + не такой, а у турков по четвергам после полудня надо добавлять к сумме 0.725. И это всё - часть вашего состояния. Таскать по всему коду набор знаний "а не в Турции ли мы? А сколько сейчас времени?" и т.п. explicitly - это путь к психушке. А implicitly - получается global mutable state.
И непонятно, чем тут особенно elders с матаном помогают.
no subject
Если Ваша мат.модель подразумевает, что вычисление "2+2" не есть чистым, то есть, зависит от времени года, фазы Луны или нахождения в Турции по четвергам, то:
1. это еще вовсе не означает отказ от сути "состояния". Иначе получим, что Тьюринг — лох вследствие того, что в Турции по четвергам хотят обмануть наивного туриста.
2. да, надо набор знаний передавать. Потому что трёх аргументов "2", "+" и "2" не достаточно для преобразования.
no subject
1. Заранее знать, что чисто, а что нет, очень трудно, и оно всё время меняется. Общаться с окружающим миром необходимо, а он по определению нечист. И эта нечистота расползается. Т.е. я не спорю, что вещи вроде мемоизации и чистых функций - прекрасны там, где работают. Проблема даже не в том, что они работают не везде, а в том, насколько тяжело заранее знать, где именно, и поддерживать это знание on the long run.
2. Ну яот я такую картину в dependency injection наблюдал, когда для каждого пука надо функцию с 20 аргументами, каждый из которых зависит он различного набора из 10 других аргументов. Разбираться в этом спагетти и держать его в голове - это довольно сильно запаривает. Невольно зарождается мысль - не может быть, чтобы нельзя это делать как-нибудь по-другому.
no subject
Можно, конечно, сложить лапки и сказать: это конец; мир неавтоматизируем, увольняюсь из программеров и иду в управдомы ©. Но ведь это не выход.
Мат.модель есть приближение на пути к формализации. Формализация есть необходимое условие автоматизируемости. Вот и всё.
2. Согласен, такое дебажить — с ума можно сойти.
Но опять-таки: The Elders уже давно придумали, как с этим бороться: функции с массивным injection (если ФП, то — с кучей лямбд на входе) дождны быть настолько тупыми, что там не должно быть места багам.
У нас в тэге F# недавно подобный вопрос пробегал (http://stackoverflow.com/q/38663990/974789).
Но, возвращаясь к исходной точке: состояние всегда должно быть детерминировано по времени {исполнения}, иначе будет то, о чём написано в шапке постинга.
И тем более, нет причин считать, что "состояние" не имеет смысла.