Re[10]: Антипаттерн, противоположный Primitive Obsession
От: Кодт Россия  
Дата: 22.03.23 11:37
Оценка: +1
Здравствуйте, T4r4sB, Вы писали:

TB>Понимаешь, в чём проблема. Если я забуду привести к инту при сложении u8+u8, то я получу падающий код. И компилятор ничего мне на это не скажет. То есть эти ограниченные Strong Types сами порождают грабли, хотя по задумке якобы должны от них защищать. И что самое хреновое — правильный код выглядит грязнее и хуже, чем неправильный но компилирующийся.


Нуу, посмотрел я на то, как ведёт себя руст, — да, соглашусь, это эребор!

Был бы я автором руста, я бы ввёл разные числовые типы — для арифметики в кольце и арифметики в диапазонах.
И ничего бы из них не делал выбором по умолчанию. Чтобы погроммисты сами выбирали себе вид боли.

Хотят получать странные числа в unsafe_i8 — пусть получают. Хотят получать за это по пальцам в strict_i8 — пусть получают.

А ещё лучше — ограничивать диапазоны не степенями 256, а произвольными числами. Как это делается в паскале и аде.


TB>Я не про то, что неявные преобразования зло. Я про то, что не надо плодить слишком много типов, и боже упаси ограничивать диапазон этих типов.


Много разных типов нужны для многих разных целей.
А то вон в сях пихали int куда ни попадя, и что, хорошо, что ли? Особенно, в функции работы с символами.

Где-то это важно для производительности, где-то напротив, важно сказать "компилятор, ну ты сам за меня реши, что лучше на какой платформе".


К>>Да, фигня какая, вдвое больше места и вчетверо медленнее вычисления.


TB>Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.


Так с самого начала и отбросили. А если где-то кому-то надо сверхдлинное время — вот пусть ровно там для себя и вводит.
Зачем всех заставлять-то?


К>>Аха, то есть, координаты для промежуточных вычислений (а не только перед финальным округлением) у нас уже полуцелые. Кто тут говорил, что int хватит?


TB>Очевидно, что пример с шахматной доской это не тот же пример, что с векторами-точками.


К>>Почему точка ровно посередине отрезка AB имеет физический смысл, а шестая по счёту точка на гребёнке из десяти засечек — не имеет физический смысл?


TB>Потому что мне нужен корректный код. Если я опечатался и написал a+(b-a)*0.6, то мне от этого ничуть не легче, чем если бы я написал (a+b)*0.6. Результат в обоих случаях неверен.

TB>Можно поспекулировать на тему, что во втором случае я замечу, что поведение системы меняется в зависимости от расстояния до нуля и поэтому быстрее найду причину бага, но это спекуляции, потому что в разных случаях может быть по-разному.

Насчёт легче или нет — это именно спекуляции.
Но в одном случае ты делаешь линейную интерполяцию с неправильным коэффициентом (хотел 0.7 или 0.5, рука дрогнула, подставил 0.6), а в другом — создаёшь неверную сущность, хотя для какой-нибудь фрактальной геометрии, возможно, она и пригодится.

Если тебя бесит, что в симметричной формуле линейной интерполяции появляется внутренняя асимметрия, — одна из точек становится важнее другой, — ну спрячь формулу в функцию.
Point interpolate(Point a, Point b, float ratio) { return a + (b-a) * ratio; }
Point midpoint(Point a, Point b) { return interpolate(a, b, 0.5); }

Point midpoint(vector<Point> points) { return points[0] + sum(points - points[0]) / size(points); } // псевдокод


А то, что interpolate(a,b,r) == interpolate(b,a,1-r), что симметрия там не вокруг 0, а вокруг 0.5 — ну блин извините! Сделай вокруг нуля
Point around_midpoint(Point a, Point b, float deviation) { return interpolate(a, b, deviation + 0.5); }  // или свою реализацию по вкусу


Зачем при этом воевать против системы типов-то?
Наоборот, система типов не даст тебе облажаться в попытках колхозной интерполяции (a+b)/2 или (a+b+c+d+e)/5 вместо библиотечной.


К>>Я вот тоже думал "нафига ввели точку, есть же вектор" — до того момента, как не полез в "промышленную" геометрию.

К>>Так что все эти вещи — выстраданные.

TB>Что такое "промышленная геометрия"? В популярных библиотеках нет этой шизы.

TB>Если же ты про библиотеки, предназначенные для сверх-надёжного кода для прошивок ядерных реакторов, то надеюсь, что тебе очевидно, что методы, применяемые в этой сфере, категорически не подходят в тех случаях, когда цена ошибки — это максимум потеря правок за последнюю минуту?

TB>И раз уж мы вспомнили про прошивки ядерных реакторов, то давай вернёмся к моему примеру про сложение u8+u8, которое компилятор не отловит. Ну и тогда уж, чтоб намёк про "надёжность" ограниченных типов был понятнее — давай заменим ядерный реактор на ракету Ариан-5


Я про библиотеки, используемые в промышленной робототехнике, — в ROS.

И давай не мешать в кучу арифметику чисел (и несчастный ариан) и типизацию структур (векторы и точки).
Если бы разработчики ариана использовали векторы и накосячили в аффинных преобразованиях, это было бы не менее эпично.
Перекуём баги на фичи!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.