Здравствуйте, SkyDance, Вы писали:
SD>Return value, конечно же. И дело в "апологетстве", а в минимизации мест, где происходят side effects — для того, чтобы отладка всего этого не стала кошмаром. Дело в том, что любой side effect по сути своей является ничем иным как использованием "глобальной переменной". Которые ровно за этот самый недетерминизм и ругают.
Что такое глобальная переменная в контексте записи на диск? Содержимое жестокого диска + (опционально)RAM?
А в случае передеачи\приема данных из сети -- содержимое дисков и памяти, всех подсоединенных к сети
компьютеров? И как предполагается взаимодействовать, если нету глобальных переменных?
Очевидно, что мы общаемся благодарю изменению некой глобальной переменной (бд на диске). Без
изменения этой глобальной переменной общение и много чего еще, да почти все в ИТ, было бы
не возможно.
S>>И как добавлять эти метаданные без перехвата исключения на месте? SD>В тех местах, где таки надо снабдить пролетающее исключение — хватай, добавляй метаданные, прокидывай дальше. SD>Таких мест должно быть очень мало. Потому что если их много, отладка такой программы будет настоящим адом. Все-таки, эффективное программирование возможно только тогда, когда программа детерминированно делает что от нее ожидается. А не валится с рандомной диагностикой.
Это так, но такое не всегда возможно.
S>>Это именно реальный мир. В огороженном вольере сидять как раз программисты на фп языках. Ну или SD>ФП тут не при чем, это вопрос грамотного дизайна. Детерминированное поведение ровно так же ожидается и от функций на все том же С++. Собственно, на этом базируется все авто-тестирование — подаются те самые детерминированные "моки", которые детерминированно возвращают ожидаемое значение. SD>Если совсем уж простой пример привести, если функции на языке С++ передать все данные, и никакие другие глобальные переменные та функция не использует, ее поведение должно быть детерминировано. Легко тестируемо, и вообще, о такой функции легко рассуждать (reasoning). Даже если кому-то поначалу сложно научиться (ну как же так, всю жисть глобальные переменные дергали, а тут вдруг низ-зя), это таки вопрос освоения мощных инструментов. Речь, разумеется, о тех участках кода, где эти инструменты применимы (это подавляющее большинство non-performance-critical кода).
О каких инструментах речь? А почему именно инструменты, а не методологии?
S>Что такое глобальная переменная в контексте записи на диск? Содержимое жестокого диска + (опционально)RAM?
Речь о детерминизме: если содержимое диска (и RAM) детерминировано (т.е. мы _ЗНАЕМ_, что читаем таблицу умножения с диска, или знаем, что мы читаем ровно тот же файл, что и будет там дальше), смысла добавлять это в метаданные пролетающего исключения нет. Попробую еще раз повторить: перехватывать и модифицировать исключение нужно только в тех случаях, когда поведение функции проблематично из-за отсутствия повторяемости (детерминизма).
В контексте тестирования: зачем мы используем моки? Да ровно затем, чтобы поведение SUT (system under test) было детерминированным. Иначе вместо отладки своей системы мы будем отлаживать баги зависимостей.
Кстати, о метаданных. В контексте все того же pread, возвращающего ENOENT — сдается мне, редко когда в пролетающее исключение будут добавлять, например, половину прочитанных данных (потому что ошибка произошла при чтении второй половины).
S>компьютеров? И как предполагается взаимодействовать, если нету глобальных переменных?
Очевидно же, что целью запуска программ как раз являются какие-то побочные эффекты (например, вывод чего-то на экран). Но код, где эти эффекты создаются, при грамотном проектировании всегда хорошо локализован. К примеру, слой, который пишет данные на диск, обычно отделен от вычислительного слоя. Именно затем и отделен, чтбоы минимизировать те самые побочные эффекты. Чтобы можно было легко и надежно тестировать. Я не знаю, сколько раз уже говорили о том, что раскидывать state changes по всему коду так себе идея. Сколько уже этих разговоров про transactional behaviour (а ведь это не что иное как выделение побочных эффектов в две специальные области, read и write, так что первое осуществляется при старте транзакции, второе — при commit'е).
S>О каких инструментах речь? А почему именно инструменты, а не методологии?
Методологию я тоже считаю инструментом. Кроме методологии, могут быть и непосредственно технические решения (да те же транзакции), и языки (более-менее припоминается Haskell, ибо вышеупомянутый erlang ну очень прагматичен в этих вопросах, и не пытается ограничить создание побочных эффектов).
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pzz, Вы писали:
Pzz>>При каких вообще условиях pread может вернуть ENOENT? CC>В том случае прилетело через четвёртые руки. CC>Т.е. на три уровня ниже файловой системы, на которой лежал тот самый файл. Даже не в том же стеке.
Чёй-то оно неуставные коды ошибок в pread суёт? Кривая реализация сетевой файловой системы?
Здравствуйте, Pzz, Вы писали:
Pzz>Чёй-то оно неуставные коды ошибок в pread суёт?
А какую оно должно было сувать если произошло нестандартное?
Втихаря сжевать реальную ошибку, которую вернули "снизу" и выплюнуть generic "Eнишмагла" — за такое сразу руки отрывать надо.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pzz, Вы писали:
Pzz>Ты не знаешь, сколько их туда зашло, чтобы две вышли.
Хм... Я смотрю там девайс внутри куда суровее чем казалось поначалу.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pzz, Вы писали:
Pzz> мало того, что не обещают какой-либо определенный порядок обхода при итерации ассоциативного массива (который в Go называется map), а еще и делают, в ущерб даже и производительности, этот порядок псевдослучайным, разным при каждом вызове.
Понимаю смысл рандомизации при заполнении ассоциативного массива, но при итерации... Зачем?
R>Понимаю смысл рандомизации при заполнении ассоциативного массива, но при итерации... Зачем?
Ну чтоб при каждой итерации порядок был не гарантирован
С другой стороны ведь и на псевдослучайность можно завязаться.
Так что теперь это уже не поменять, а то вдруг где-то энтропия опасно понизиться
