Comments 26
Бритва Хэнлона/Хайнлайна - наиболее вводящая в заблуждение из упомянутых.
Этот принцип может, конечно, служить "противовесом", например, для фундаментальной ошибки атрибуции. Точнее - для половины этого эффекта, которая относится к оценке действий окружающих. То есть встречающейся склонности переоценивать фактор намерения и недооценивать фактор обстоятельств в причинах чужого поведения.
Но если этим принципом начинает пользоваться человек из тех, кто любит готовые ответы на все, а разбираться в каждом конкретном случае - не хочет или не очень может, применение этой бритвы оборачивается настоящей глупостью. Например, мне несчетное количество раз случалось напоминать людям, которые твердили про "глупость", "случайность" и т.п., что, например, в случае наличия истории коррупции, антисоциального поведения, идеологической одержимости, намерение как раз куда более вероятная причина чьих-то действий.
Кроме того, бритву Хэнлона невозможно кратко сформулировать так, чтобы она учитывала это обстоятельство. Вот даже в статье выше, автор предлагает формулировку:
Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности.
Но это логический нонсенс, потому что "никогда" в начале - квантор универсальности, который перечеркивает "не исключай", содержащее квантор существования. Если переписать это, получится "Никогда не делай Х, но иногда - делай Х".
Человеку, который действительно готов разбираться в причинах, никакая сомнительная помощь в виде эмпирических правил не нужна, человеку, который не готов, они с тем же успехом повредят из-за бездумного применения, а не помогут. Потому что они призваны, на самом деле, только напомнить о противоположной склонности, а не служить универсальным алгоритмом принятия решений.
Добавил бы закон Мерфи )
«Главное — в творческом запале не порезаться самому и не отсечь что-то нужное и ценное.»
Главное «с водой ребеночка не выплеснуть»
Если программа не компилируется, то в ней есть ошибка.
Есть один занятный нюанс в этом деле. Компилятор - тоже программа)))
Я лично репортил по меньшей мере раза 4 на баги в компиляторах и не менее раз 20 за последние 7 лет сталкивался с ошибками, которые уже кто-то зарепортил) Так что таки да, бывает что и компилятор злое зло)
У меня такое было что слетала версия компилятора, использую IDEA для java. Версию на 5 джава, доисторическую, хотя в настройках проекта стоит 8 или 11. А там в глубине compiler слетала на 5-ю. Потом было пару раз оболочка забывала что такое String то есть тип строка. И я заметил почему то это чаще происходит у новичков. Я как то сломал залочил Pascal в вузе, мне препод сказал что такого раньше не видел, хотя там программа на 20 строчек и специально ничего не хакал, просто неправильно что то написал. Ну и один раз случалось точка с запятой была ошибка не там где забыл, а 10 строчками ниже. Но такой редко случается.
Бритва Хэнлона/Хайнлайна - наиболее вводящая в заблуждение из упомянутых.
Этот принцип может, конечно, служить "противовесом", например, для фундаментальной ошибки атрибуции. Точнее - для половины этого эффекта, которая относится к оценке действий окружающих. То есть встречающейся склонности переоценивать фактор намерения и недооценивать фактор обстоятельств в причинах чужого поведения.
Но если этим принципом начинает пользоваться человек из тех, кто любит готовые ответы на все, а разбираться в каждом конкретном случае - не хочет или не очень может, применение этой бритвы оборачивается настоящей глупостью. Например, мне несчетное количество раз случалось напоминать людям, которые твердили про "глупость", "случайность" и т.п., что, например, в случае наличия истории коррупции, антисоциального поведения, идеологической одержимости, намерение как раз куда более вероятная причина чьих-то действий.
Кроме того, бритву Хэнлона невозможно кратко сформулировать так, чтобы она учитывала это обстоятельство. Вот даже в статье выше, автор предлагает формулировку:
Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности.
Но это логический нонсенс, потому что "никогда" в начале - квантор универсальности, который перечеркивает "не исключай", содержащее квантор существования. Если переписать это, получится "Никогда не делай Х, но иногда - делай Х".
Человеку, который действительно готов разбираться в причинах, никакая сомнительная помощь в виде эмпирических правил не нужна, человеку, который не готов, они с тем же успехом повредят из-за бездумного применения, а не помогут. Потому что они призваны, на самом деле, только напомнить о противоположной склонности, а не служить универсальным алгоритмом принятия решений.
Кроме того, бритву Хэнлона невозможно кратко сформулировать так, чтобы она учитывала это обстоятельство. Вот даже в статье выше, автор предлагает формулировку
Вариант "не объясняй лишь злонамеренностью то, что вполне объясняется глупостью*" не идеален, но суть передаёт.
Потому что они призваны, на самом деле, только напомнить о противоположной склонности
Что тоже немало для многих людей...
P.S. "*раздолбайством и т.п."
Огласите, пожалуйста, весь список.
Эм, бритва Оккама не говорит, что наиболее простое объяснение - единственно правильное. Бритва Оккама - это презумпция, которая устанавливает порядок рассмотрения версий: от самой простой к самой сложной ;) Собственно, бритва Хайнлайна/Хэнлона про то же, про порядок рассмотрения гипотез.
Только в реальности нет никакого установленного порядка причин, потому смотреть нужно всё равно на условия, в которых существует происходящее.
И еще дополню сам себя:
во-первых, "простота/сложность" в оригинальной бритве Оккама - это привлечение дополнительных сущностей. Чем меньше привлекается дополнительных сущностей, тем проще гипотеза.
во-вторых, получается, что бритва Хайнлайна/Хэнлона - это частный случай бритвы Оккама: версия глупости "проще" (в терминологии Оккама), так как не требует привлечения дополнительной сущности, злонамеренности (так как глупости соврешают все люди, а злодеяния - только некоторые). А вот версия злонамеренности сложнее, так как требует привлечения дополнительной сущности, той самой злонамеренности.
Как-то так :)
Хорошая подборка, но есть плохой пример:
Я считаю, что старый вариант интерфейса был удобнее, чем новый.
Покажите результаты A/B-тестов.
Смотрите: если я заявляю, что мне красный цвет нравится больше, чем зелёный, то ваша задача доказать, что мне зелёный цвет нравится больше. Если я заявляю, что считаю старый интерфейс более удобным, то какие А/В тесты вы с меня спрашиваете? Мне себя тестировать на консистентность своих вкусов?
Эта ситуация несколько сложнее.
Если тот, кто принял решение изменить интерфейс, не руководствовался результатами объективного тестирования сам, использование более высокого стандарта доказательств к оппоненту - просто прозрачная демагогия, не более.
Вопрос с тем, на ком должно лежать бремя доказательств, постоянно используется с демагогическими целями, как правило - одним и тем же способом: сначала, некто совершает некие действия или делает высказывания, которые представляет "очевидными" или мотивированными очевидными причинами. А когда кто-то начинает это критиковать, начинает требовать доказательств, что эти высказывания или действия - неверны, хотя сам, делая их, никаких обоснований не представлял.
кто принял решение изменить интерфейс, не руководствовался результатами объективного тестирования сам
Тут есть момент, на который я обращаю внимание: вы предполагаете очевидным контекст или целеполагание, которое ни из примера в виде диалога не видно, ни в реальности собеседник не всегда понимает.
Приведу пример такого контекста:
— Я недавно узнал, что у Хабра появилась новая версия. Попробовал её. Я считаю, что старый вариант интерфейса был удобнее, чем новый.
Я руководствовался результатами объективного тестирования? Нет. Но и не принимал решение об изменении интерфейса. Я принимаю решение, переключиться на старую версию или на новую, но это не требует А/В тестирования.
Если же контекст другой:
— Я просмотрел макет нового дизайна. Я считаю, что старый вариант интерфейса был удобнее, чем новый.
То более правильным (по моему мнению) является ответ
— Нам/вам надо провести А/В тестирование для того, чтобы понять, является ли старый вариант интерфейса действительно более удобным, чем новый. Ну и вспомнить, почему мы вообще приняли решение что-то поменять.
В этом случае нужно разделять тезисы «Я считаю / по моим представлениям / по моему вкусу / мне кажется, что …» и «Целевая группа в среднем считает, что …».
Перечисленные принципы сформулированы более-менее корректно, но примеры у меня скажем так "вызывали вопросики". Точнее "вызывали вопросики" до последнего пункта, где меня чуть не взорвало от возмущения.
Единственный способ доказать отсутствие ошибок — провести эксперимент тестированием.
В этом утверждении просто не менее 3 ошибок в одном.
Тесты принципиально не доказывают отсутствие ошибок. Тесты в лучшем случае доказывают наличие ошибок, которые проверяются тестами (и никаких других).
Тесты могут быть неправильными. И функциональные и нагрузочные. А еще могут быть неочевидно неправильными - например, зависеть от окружения, и показывать разный результат.
Единственность - это очень сильное утверждение. Что насчёт Coq, Agda и подобных?
И, казалось бы, чуть ниже есть оговорка:
Эксперимент не подтверждает полностью гипотезу, а лишь повышает вероятность её истинности. Тестирование не доказывает стопроцентное отсутствие ошибок.
Но у этой оговорки верно второе предложение, а первое фундаментально ошибочно. Да, "эксперимент не подтверждает полностью гипотезу", но это здесь трактовано неправильно. Эксперимент ни в коем случае не "повышает вероятность истинности" (я даже не представляю себе конструктивного ввода понятия "вероятности истинности теории"). Просто при наличии эксперимента, результаты которого согласуются с теорией, в другой теории придётся также объяснять и этот эксперимент.
Но у этой оговорки верно второе предложение
Да и оно неверно — тестирование в принципе не доказывает отсутствия ошибок. Ни 100%, ни даже 1%. Тестирование само по себе может показать (а не доказать) только два момента:
Наличие ошибки
Корректную работу на тестовом наборе данных
Что же касается отсутствия ошибок, то тестирование может (и должно) быть частью доказательства их отсутствия, но само по себе доказательством не является никак вообще.
Ещё можно добавить. "Любую функцию можно так покрыть юнит тестами, что никто не заметит что она работает неправильно"
Бритва Оккама и другие острые бритвы познания — как использовать в IT и в жизни