По поводу прошлого поста хотелось бы отметить один интересный феномен.
В принципе, то, в чём я участвую, называется миграцией data warehouse. При этом, естественным образом получается достаточно жестокий сравнительный тест как двух вариантов скриптов клиента, так и самих используемых баз. Данных и кода так много, что сама собой начинает лезть всякая чертовщина.
Мой любимый пример - когда один и тот же код на одних и тех же данных каждый четвёртый раз выдаёт семь ошибочных строк. (Семь из семидесяти тысяч и ошибочным значением в одном столбце из двух десятков.)
В прошлом посте приведён банальный пример. Грубо говоря, пользователь пишет
2 + 2 = 4
а база данных говорит, что не равно.
Зато, с тем, что
2 + 2 + 0 = 4
база данных соглашается.
Эффект срабатывает для нескольких строк из сотен тысяч, но расписывать подробности я не буду. Пост был не про конкретный баг, а про применимость математических абстракций.
Феномен же, который хочу отметить здесь, связан с поведением так называемых профессионалов. Между прочим, достаточно типичный феномен.
Толпа народа, вдруг, начала не просто строить теории, но сразу перешла в нападение, объясняя, что только дураку может быть не понятно, почему два плюс два не равно четырём.
То есть, первым предположением идёт то, что дурак тот, кто сообщил об ошибке.
Вторым, что это не ошибка, а такое интересное свойство системы, которое отрицает математику, но при этом совершенно правильное.
Третьим рубежом защиты выступают некоторые дополнительные условия, которые теоретически позволяют сдвинуть ошибку в зону второго случая. При этом, исходную задачу можно почти полностью погрести под горой свежепредуманных дополнений.
Где-то там, в конце списка болтается банальный баг в софте. То есть, ошибка в коде базы данных теоретически не отрицается, но практически находится за горизонтом рассматриваемых причин. Собственная компетенция под сомнение не ставится никогда.
Почему то, что лезет сейчас, не обнаружили предыдущие поколения? Вот именно потому, что порядок поиска проблем инвертирован к правильному.
Да, чтобы сразу не влезать в споры по первому пункту. Пользователь может быть болваном, но система должна или соглашаться с тем, что два плюс два равны четырём, или говорить явно и чётко, что дополнительные условия не дают правильно провести сравнение.
В принципе, то, в чём я участвую, называется миграцией data warehouse. При этом, естественным образом получается достаточно жестокий сравнительный тест как двух вариантов скриптов клиента, так и самих используемых баз. Данных и кода так много, что сама собой начинает лезть всякая чертовщина.
Мой любимый пример - когда один и тот же код на одних и тех же данных каждый четвёртый раз выдаёт семь ошибочных строк. (Семь из семидесяти тысяч и ошибочным значением в одном столбце из двух десятков.)
В прошлом посте приведён банальный пример. Грубо говоря, пользователь пишет
2 + 2 = 4
а база данных говорит, что не равно.
Зато, с тем, что
2 + 2 + 0 = 4
база данных соглашается.
Эффект срабатывает для нескольких строк из сотен тысяч, но расписывать подробности я не буду. Пост был не про конкретный баг, а про применимость математических абстракций.
Феномен же, который хочу отметить здесь, связан с поведением так называемых профессионалов. Между прочим, достаточно типичный феномен.
Толпа народа, вдруг, начала не просто строить теории, но сразу перешла в нападение, объясняя, что только дураку может быть не понятно, почему два плюс два не равно четырём.
То есть, первым предположением идёт то, что дурак тот, кто сообщил об ошибке.
Вторым, что это не ошибка, а такое интересное свойство системы, которое отрицает математику, но при этом совершенно правильное.
Третьим рубежом защиты выступают некоторые дополнительные условия, которые теоретически позволяют сдвинуть ошибку в зону второго случая. При этом, исходную задачу можно почти полностью погрести под горой свежепредуманных дополнений.
Где-то там, в конце списка болтается банальный баг в софте. То есть, ошибка в коде базы данных теоретически не отрицается, но практически находится за горизонтом рассматриваемых причин. Собственная компетенция под сомнение не ставится никогда.
Почему то, что лезет сейчас, не обнаружили предыдущие поколения? Вот именно потому, что порядок поиска проблем инвертирован к правильному.
Да, чтобы сразу не влезать в споры по первому пункту. Пользователь может быть болваном, но система должна или соглашаться с тем, что два плюс два равны четырём, или говорить явно и чётко, что дополнительные условия не дают правильно провести сравнение.
no subject
Date: 2014-12-25 08:26 pm (UTC)Оттого и такая реакция.
no subject
Date: 2014-12-25 08:48 pm (UTC)Насчёт же плавающей точки, я сильно сомневаюсь, что есть варианты, когда добавление целочисленного нуля может чем-то помочь.
no subject
Date: 2014-12-25 09:23 pm (UTC)Что значит "помочь"? Если здесь подразумевается "изменить поведение", то это ж наблюдаемый факт. Это происходит и этому должно быть какое-то объяснение (глючил же калькулятор и Excel в Windows, оказался глюк в Intel CPU).
И здесь будет какое-то объяснение. Например, "добавление нуля приводит к изменению парсинга строки, и порядок действий получается не "(x + (y + z))", а "((x + y) + z), что приводит к другому результату". Невозможный результат с точки зрения математики.
no subject
Date: 2014-12-25 09:40 pm (UTC)no subject
Date: 2014-12-25 09:57 pm (UTC)no subject
Date: 2014-12-26 06:32 pm (UTC)no subject
Date: 2014-12-26 05:55 pm (UTC)Но , молодежь таких тонкостей не знает.
no subject
Date: 2014-12-26 06:30 pm (UTC)К тому же, для определённого класса задач вполне можно использовать равенство. Потому что, опять же, не вещественные числа, а их двоичное представление.
no subject
Date: 2014-12-26 07:13 pm (UTC)no subject
Date: 2014-12-26 09:23 am (UTC)Не, ну 2+2 конечно, чисто теоретически, может быть не равно 4м, но в этом случае +0 тоже ничего изменит. Ну плюс, зачем такое даже чисто теоретически применять в базах данных не понятно.
А эффект еще от менталитета зависит. Славяне например любят критиковать, так что в их случае дискуссия бы просто перешла в русло "ну там и бажина на бажине"
no subject
Date: 2014-12-26 09:34 am (UTC)no subject
Date: 2014-12-26 12:13 pm (UTC)А то разговор начинается с "ваша математика - фуфло". Эээ, не "наша математика" фуфло, а те погонщики рабов, под руководством которых был написан кривой софт. И написан как раз под лозунгами вроде "мне не надо, чтобы было красиво и правильно, мне надо, чтобы клиент был удовлетворен (- девочка, ты отличница? - я удовлетворительница!)".
Да, клиент оказался доволен, потому что по счастливой случайности множество его потребностей совпало с тем, что предлагал продукт на момент покупки.
А потом появились новые пользователи, с другими кейсами, и - внезапно, обнаружились баги.
Найденный вами баг очень похож на ошибки типизации в PHP или яваскрипте. Дополню - любители математики молятся на системы типов, в кондовом же бухгалтерском SQL типы с 92 года не сильно поменялись. Переименовать столбец, чтобы имя соотвествовало содержимому? Find Usages? Скопировать произвольную запись вместе с дочерними, поменяв только ключи и указанные поля, то есть сделать клон? Не бывает, в СУБД до сих пор средние века.
Постгрес, кстати, известен своей академичностью. То есть, его писали ученые, а не бизнесменствующие программисты, хорошо знающие потребности клиента.
no subject
Date: 2014-12-26 06:26 pm (UTC)Руководство - это руководство. А баги в системе - это проблема техническая. Причём, совершенно ортогональная реальным и мнимым требованиям бизнеса и менеджмента.
Насчёт академичности говорить сложно, после того, как следующее выдаёт единицу:
SELECT CASE WHEN CAST( 'NaN' AS float) > CAST ('Infinity' AS float) THEN 1 ELSE 0 END ;
no subject
Date: 2014-12-26 05:33 pm (UTC)no subject
Date: 2014-12-26 06:08 pm (UTC)Идеальная программа
Date: 2014-12-26 07:30 pm (UTC)Но разве мы можем сделать такой софт, который расшифрует все-все варианты "неправильного" человеческого ввода и каждый раз будет понимать их корректно? Как это организовать без многолетнего сбора и анализа статистики этих вариантов в каждом программном продукте?
Мне кажется, это малореально в современном мире.