Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, thesz, Вы писали:
T>>Укажи, где в исходном утверждении находится фраза "состояние никогда не должно быть невидимым" или её перевод на английский.
AF>Re[11]: Почему монады лучше lvalue (глобальных переменных).
Это мне неинтересно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Почему монады лучше lvalue (глобальных переменных).
Если считать это верным, то напрашиваются следующие выводы:
— Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния. Даже передача сообщений не спасает, умолчание не то. Поэтому объекты этому условию скорее не удовлетворяют.
— Монады состояния скорее удовлетворяют этому условию, чем наоборот, поскольку состояние (в большинстве случаев) может быть доступно только на выходе.
— Изменяемые переменные не удовлетворяют условию.
— Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Почему монады лучше lvalue (глобальных переменных).
T>Если считать это верным, то напрашиваются следующие выводы: T>- Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния. Даже передача сообщений не спасает, умолчание не то. Поэтому объекты этому условию скорее не удовлетворяют. T>- Монады состояния скорее удовлетворяют этому условию, чем наоборот, поскольку состояние (в большинстве случаев) может быть доступно только на выходе. T>- Изменяемые переменные не удовлетворяют условию. T>- Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.
Ты уж до конца цитируй
The main advantage of named state is that the program becomes modular. The main disadvantage is that a program can become incorrect.
Здравствуйте, thesz, Вы писали:
T>Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность".
Не могу понять, что означают выражения "высокая модульность" и "низкая модульность". Есть устоявшиеся термины cohesion и coupling, и для них определены high/low cohesion/coupling. Если под "высокой/низкой модульностью" ты понимаешь что-нибудь из этого, то это одно дело. А если что-то другое...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, VoidEx, Вы писали:
VE>>Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.
AF>Я это условие специально жирным выделил. Оно не просто "не удовлетворяет" — оно ему противоположно. Или например здесь: "Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния". Сравни с "state should never be invisible"
А теперь внимательно ещё раз прочти его пост и посмотри условие, которое выделил он.
А потом ещё прочти мой пост. Двух раз должно быть достаточно.
Я гляжу в моду уже вошло брать другое условие (противоположное причём) и оспаривать несоответствие утверждений этому новому условию. AF>Ты и thesz — один и тот же человек, не так ли?
Нет, я просто читать умею.
Re: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, gandjustas, Вы писали:
G>А вот что такое "named state" не очень понятно.
Дак в статью-то загляни:
...To do this, we add an abstract notion of time to the program. This abstract time is simply a sequence of values in time that has a single name. We call this sequence a named state.
ну пожалуйста, используйте тэг code только по назначению!!! — Кодт
По сути дела это понятие "переменной".
Re[3]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>А вот что такое "named state" не очень понятно.
К>Дак в статью-то загляни: К>
К>...To do this, we add an abstract notion of time to the program. This abstract time is simply a sequence of values in time that has a single name. We call this sequence a named state.
К>По сути дела это понятие "переменной".
Мда... порвало мозг окончательно.
Re[4]: Почему монады лучше lvalue (глобальных переменных).
T>>Если считать это верным, то напрашиваются следующие выводы: T>>- Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния. Даже передача сообщений не спасает, умолчание не то. Поэтому объекты этому условию скорее не удовлетворяют. T>>- Монады состояния скорее удовлетворяют этому условию, чем наоборот, поскольку состояние (в большинстве случаев) может быть доступно только на выходе. T>>- Изменяемые переменные не удовлетворяют условию. T>>- Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.
J>Ты уж до конца цитируй J>
J>The main advantage of named state is that the program becomes modular. The main disadvantage is that a program can become incorrect.
Я с этим не согласен, поскольку это противоречие.
max(модульность) ≡ min(взаимозависимость).
min(взаимозависимость) ≡ min(вероятность ошибки при изменении части).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Курилка, Вы писали:
G>>А вот что такое "named state" не очень понятно.
К>Дак в статью-то загляни: К>
К>...To do this, we add an abstract notion of time to the program. This abstract time is simply a sequence of values in time that has a single name. We call this sequence a named state.
К>
К>По сути дела это понятие "переменной".
... изменяемой. Короче, с чем боролись на то и...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
G>>>А вот что такое "named state" не очень понятно.
К>>По сути дела это понятие "переменной".
VD>... изменяемой. Короче, с чем боролись на то и...
Вообще-то значение слова "переменный" подразумевает под собой изменения. Это уже программисты понапридумывали изменяемые/неизменяемые переменные (хотя лучше , возможно, было бы иметь другой термин).
Ну и кто боролся, если не секрет? Peter van Roy?
Re[5]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, thesz, Вы писали:
T>Я с этим не согласен, поскольку это противоречие.
T>max(модульность) ≡ min(взаимозависимость).
Откуда берется тождество? Модульность, если не ошибаюсь, это скрытие деталей реализации. Но система может состоять из множества модулей, которые очень сильно связаны друг с другом на уровне интерфейсов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>Я с этим не согласен, поскольку это противоречие.
T>>max(модульность) ≡ min(взаимозависимость).
E>Откуда берется тождество? Модульность, если не ошибаюсь, это скрытие деталей реализации. Но система может состоять из множества модулей, которые очень сильно связаны друг с другом на уровне интерфейсов.
Модульность, по-моему, степень независимости при разработке отдельных частей системы.
Если её считать, как простое число модулей (частей) системы, то она не даёт ничего нового при оценке стоимости разработки.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, thesz, Вы писали:
E>>Откуда берется тождество? Модульность, если не ошибаюсь, это скрытие деталей реализации. Но система может состоять из множества модулей, которые очень сильно связаны друг с другом на уровне интерфейсов.
T>Модульность, по-моему, степень независимости при разработке отдельных частей системы.
T>Если её считать, как простое число модулей (частей) системы, то она не даёт ничего нового при оценке стоимости разработки.
T>>Если её считать, как простое число модулей (частей) системы, то она не даёт ничего нового при оценке стоимости разработки.
E>Похоже, здесь разная интерпритация терминов.
E>Есть модульность (Modularity).
Modular programming is a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.
E>Есть связанность (Coupling).
E>Ты, похоже, трактуешь модульность в смысле связности.
Трактовка википедии недалеко ушла от моей.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, thesz, Вы писали:
E>>Есть модульность (Modularity). T>
Modular programming is a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.
E>>Есть связанность (Coupling).
E>>Ты, похоже, трактуешь модульность в смысле связности.
T>Трактовка википедии недалеко ушла от моей.
Модульность, по-моему, степень независимости при разработке отдельных частей системы.
Похоже, я многое в этой жизни пропустил, поскольку теперь "степень независимости" является синонимом "software design technique".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
E>>>Откуда берется тождество? Модульность, если не ошибаюсь, это скрытие деталей реализации. Но система может состоять из множества модулей, которые очень сильно связаны друг с другом на уровне интерфейсов.
T>>Модульность, по-моему, степень независимости при разработке отдельных частей системы.
T>>Если её считать, как простое число модулей (частей) системы, то она не даёт ничего нового при оценке стоимости разработки.
E>Похоже, здесь разная интерпритация терминов.
E>Есть модульность (Modularity). E>Есть связанность (Coupling).
E>Ты, похоже, трактуешь модульность в смысле связности.
По-моему ты тут зачем-то противопоставляешь 2 очень взаимосвязных термина: модульность говорит о том, что прогамма "побита" на части, т.е. модули, так вот внутри этих модулей хорошая связность, а между ними она должна быть минимальной для реализации separation of concerns.
Правда, вот с Хаскелем ситуация выходит, что даже отдельные функции становятся модулями, если не рассматривать классы типов.
Re[7]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Курилка, Вы писали:
E>>Есть модульность (Modularity). E>>Есть связанность (Coupling).
E>>Ты, похоже, трактуешь модульность в смысле связности.
К>По-моему ты тут зачем-то противопоставляешь 2 очень взаимосвязных термина: модульность говорит о том, что прогамма "побита" на части, т.е. модули, так вот внутри этих модулей хорошая связность, а между ними она должна быть минимальной для реализации separation of concerns.
Еще раз: модульность -- это подход к разработке ПО, при котором система строится из модулей со строго определенными внешними интерфейсами, а детали модулей скрыты внутри и недоступны снаружи. Поэтому само понятие max(модульность) для меня выглядит странным. Надо полагать, что max(модульность) -- это "хороший дизайн", а это очень субъективно.
Связность как раз показывает степень взаимосвязи между компонентами системы. И как раз у связности можно определять min и max.
Но в таком случае не понятно, почему "хороший дизайн" эквивалентен минимальной связанности.
Ну и кроме того, когда речь заходит о "степени независимости", то значит разговор идет именно о "связности", а не о "модульности" (если брать за основу определения из Wikipedia).
К>Правда, вот с Хаскелем ситуация выходит, что даже отдельные функции становятся модулями, если не рассматривать классы типов.
Это проблемы Хаскеля.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
E>>>Есть модульность (Modularity). E>>>Есть связанность (Coupling).
E>>>Ты, похоже, трактуешь модульность в смысле связности.
К>>По-моему ты тут зачем-то противопоставляешь 2 очень взаимосвязных термина: модульность говорит о том, что прогамма "побита" на части, т.е. модули, так вот внутри этих модулей хорошая связность, а между ними она должна быть минимальной для реализации separation of concerns.
E>Еще раз: модульность -- это подход к разработке ПО, при котором система строится из модулей со строго определенными внешними интерфейсами, а детали модулей скрыты внутри и недоступны снаружи. Поэтому само понятие max(модульность) для меня выглядит странным. Надо полагать, что max(модульность) -- это "хороший дизайн", а это очень субъективно.
E>Связность как раз показывает степень взаимосвязи между компонентами системы. И как раз у связности можно определять min и max.
Тут в терминологии я, видимо, напутал, получается я имел в виду cohesion
Забавно, что оно вики переводится как связность, а coupling как связанность.
Re[9]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
E>>>Есть модульность (Modularity). T>>
Modular programming is a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.
E>>>Есть связанность (Coupling).
E>>>Ты, похоже, трактуешь модульность в смысле связности.
T>>Трактовка википедии недалеко ушла от моей.
E>
E>Модульность, по-моему, степень независимости при разработке отдельных частей системы.
E>Похоже, я многое в этой жизни пропустил, поскольку теперь "степень независимости" является синонимом "software design technique".
Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность". Да вообще можно сделать прилагательное "модульный". "Модульный дизайн программы"
Слово "модульность" само по себе, без дополняемого существительного — software design technique. Вместе с существительным — свойство этого существительного.
Не так?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>Модульность это и свойство: "модульность программы", "модульность системы", например. "Высокая модульность", "низкая модульность".
E>Не могу понять, что означают выражения "высокая модульность" и "низкая модульность". Есть устоявшиеся термины cohesion и coupling, и для них определены high/low cohesion/coupling. Если под "высокой/низкой модульностью" ты понимаешь что-нибудь из этого, то это одно дело. А если что-то другое...
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
E>>>Есть модульность (Modularity). E>>>Есть связанность (Coupling).
E>>>Ты, похоже, трактуешь модульность в смысле связности.
К>>По-моему ты тут зачем-то противопоставляешь 2 очень взаимосвязных термина: модульность говорит о том, что прогамма "побита" на части, т.е. модули, так вот внутри этих модулей хорошая связность, а между ними она должна быть минимальной для реализации separation of concerns.
E>Еще раз: модульность -- это подход к разработке ПО, при котором система строится из модулей со строго определенными внешними интерфейсами, а детали модулей скрыты внутри и недоступны снаружи. Поэтому само понятие max(модульность) для меня выглядит странным. Надо полагать, что max(модульность) -- это "хороший дизайн", а это очень субъективно.
Мы можем соответствовать подходу в большей или меньшей степени. Эта оценка субъективна, согласен.
Объективно мы можем оценивать модульность путём упрощения уже готового решения. Если мы можем что-то разграничить ещё сильней, то мы повышаем модульность, нес па?
E>Связность как раз показывает степень взаимосвязи между компонентами системы. И как раз у связности можно определять min и max.
При повышении модульности мы снижаем связность и наоборот, так?
E>Ну и кроме того, когда речь заходит о "степени независимости", то значит разговор идет именно о "связности", а не о "модульности" (если брать за основу определения из Wikipedia).
It's the dreaded "the program becomes modular".
К>>Правда, вот с Хаскелем ситуация выходит, что даже отдельные функции становятся модулями, если не рассматривать классы типов. E>Это проблемы Хаскеля.
Это достоинство Хаскеля.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Почему монады лучше lvalue (глобальных переменных).
J>The main advantage of named state is that the program becomes modular. The main disadvantage is that a program can become incorrect.
T>max(модульность) ≡ min(взаимозависимость).
T>min(взаимозависимость) ≡ min(вероятность ошибки при изменении части).
T>Пожалуй, я не виноват в том, что автор исходной цитаты использовал термин modular.
Ну ты же указал тождество между max(модульность) и min(взаимозависимость). Оно мне не понятно, поскольку под max(модульность) можно понимать разные вещи. В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!
Но вполне может оказаться, что декомпозиция на модули выполнена неудачно, что при большом количестве модулей взаимосвязей между ними слишком много и поэтому связность у частей системы слишком большая.
Т.е. твое тождество можно воспринимать как цель, к которой нужно стремиться. Но не факт, что она достижима в условиях ограниченного времени и ресурсов.
T>Я не считаю, что для программы с именованным состоянием уменьшается связность.
Я тоже так не считаю.
T>Поэтому я считаю, что цитата неверна (содержит противоречие) вне зависимости от нашего расхождения в понимании термина модульность.
У меня сложилось впечатление, что вывод "The main advantage of named state is that the program becomes modular." в обсуждаемой статье вообще не был доказан. Был приведен какой-то мутный пример и все.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Почему монады лучше lvalue (глобальных переменных).
E>Т.е. твое тождество можно воспринимать как цель, к которой нужно стремиться. Но не факт, что она достижима в условиях ограниченного времени и ресурсов.
Там ещё есть, кроме модульности.
T>>Я не считаю, что для программы с именованным состоянием уменьшается связность.
E>Я тоже так не считаю.
T>>Поэтому я считаю, что цитата неверна (содержит противоречие) вне зависимости от нашего расхождения в понимании термина модульность.
E>У меня сложилось впечатление, что вывод "The main advantage of named state is that the program becomes modular." в обсуждаемой статье вообще не был доказан. Был приведен какой-то мутный пример и все.
Я рад, что мы пришли к общему мнению.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!
Орррррррригинально.
Тот факт, что такое определение не имеет абсолютно никакого смысла, не напрягает?
Re[13]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, VoidEx, Вы писали:
E>>В моем представлении, max(модульность) -- это соотношение количества модулей к объему программы. Т.е., чем на большее количество модулей разбита система, тем больше модульность. Но!
VE>Орррррррригинально.
Каждый думает в меру своей распущенности. Если объем программ или выхлоп программиста зачастую измеряют в KLoc, то почему бы аналогичным образом не изменять модульность?
VE>Тот факт, что такое определение не имеет абсолютно никакого смысла, не напрягает?
Когда я еще учился программировать преподаватель рассказывал, что он застал повальное увлечение структурным и модульным программированием. Которое временами принимало оригинальные формы, как то -- полный запрет на использование глобальных переменных, оператора goto и жестких ограничений на объем модуля (скажем, 3K строк). И если твой модуль оказывался на 10 строчек больше объявленного предела, тебе приходилось его разбивать на два более мелких.
Я сам столкнулся с более современным проявлением этого подхода. Мной был написан транслятор из специализированного языка в Java и этот транслятор генерировал java-файлы в десятки тысяч строк. Когда такой файл приходил на code review, мы сразу же получали официальное замечание -- мол, отрефакторите свой класс XXX. А то у него код слишком большой, во много раз превышающий рекомендуемый объем. Мы объясняли, что этот файл генерируется автоматически, замечение снимали. Но до тех пор, пока файл не попадал на глаза другому code reviewe
r-у. Который сразу же выдвигал официальное замечание (никто почему-то не обращал внимание на комментарии вначале сгенерированного файла).
Так что количество смысла в данном определении сильно зависит от степени маразма читателя
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VoidEx, Вы писали:
E>Каждый думает в меру своей распущенности. Если объем программ или выхлоп программиста зачастую измеряют в KLoc, то почему бы аналогичным образом не изменять модульность?
В принципе-то конечно можно.
Но если говорить о данном конкретном случае (а именно фразе на английском), то не понимаю, как наличие named state влияет на количество модулей.
Re[15]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, VoidEx, Вы писали:
E>>Каждый думает в меру своей распущенности. Если объем программ или выхлоп программиста зачастую измеряют в KLoc, то почему бы аналогичным образом не изменять модульность?
VE>В принципе-то конечно можно. VE>Но если говорить о данном конкретном случае (а именно фразе на английском), то не понимаю, как наличие named state влияет на количество модулей.
Я вообще не понимаю, почему автор статьи решил, что наличие named state каким-то образом влияет на улучшение модульности.
А дальше началось наше с thesz разногласие по поводу того, какой смысл вкладывается в "модульность". Поскольку у меня были свои представления о том, что может означать "max(модульность)" (и это не то, что min/max(coupling)), а у thesz -- свои. Но это разногласие не имеет отношения к процитированной английской фразе, а всего лишь следствие заочного общения по переписке.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Почему монады лучше lvalue (глобальных переменных).
T>>- Подход Эрланга — я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию, чем наоборот.
AF>А ты уверен, что всё правильно прочитал и понял?
Да. А ты?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Почему монады лучше lvalue (глобальных переменных).
Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Andrei F., Вы писали:
AF>Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?
В исходном утверждении жирным выделено другое.
Re[5]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, VoidEx, Вы писали:
VE>>В исходном утверждении жирным выделено другое.
AF>Ну и что? Я выделил ту часть, которая явно была понята неправильно.
Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?
Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.
Re[7]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, VoidEx, Вы писали:
VE>Какому условию, с твоей точки зрения, подход Эрланга не удовлетворяет, процитируй его.
Я это условие специально жирным выделил. Оно не просто "не удовлетворяет" — оно ему противоположно. Или например здесь: "Объекты удовлетворяли бы этому условию, если бы не могли дать доступ к частям внутреннего состояния". Сравни с "state should never be invisible"
Ты и thesz — один и тот же человек, не так ли?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, thesz, Вы писали:
T>>Да. А ты?
AF>Почему подход Эрланга "я могу передать значение части состояния куда-либо, но извне оно не видно, — скорее удовлетворяет условию" — если в исходном утверждении сказано "состояние никогда не должно быть невидимым"?
Тут возможно так много ответов, что я смущён обилием вариантов.
Начну-ка я с просьбы процитировать исходное утверждение, где сказано именно так, как у тебя в кавычках. Поэтому:
Укажи, где в исходном утверждении находится фраза "состояние никогда не должно быть невидимым" или её перевод на английский.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Почему монады лучше lvalue (глобальных переменных).
Здравствуйте, thesz, Вы писали:
T>Укажи, где в исходном утверждении находится фраза "состояние никогда не должно быть невидимым" или её перевод на английский.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, thesz, Вы писали:
T>>Это мне неинтересно.
AF>То есть ответ на вопрос тебя не интересует? Я почему-то так и думал.
Меня интересовало ровно то, что выделено жирным в самом первом посту.
Ответ на твой вопрос интересует тебя, не меня.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
