Здравствуйте, B0FEE664, Вы писали:

BFE>Потому, что если вашей библиотекой пользуются, то про неправильный синус пользователь уже выяснил и подобрал коэфициент его корректирующий. Так что если вы его втихоря исправите, то будете дважды виноваты: сначала потому, что ошиблись, а потом, потому, что из-за вас пользователю пришлось код переписывать.

1 Откуда следует, что "про неправильный синус пользователь уже выяснил" ?
2 Не будем — в отличие от вас, у нас ищут не виноватых, а решения проблем
3 У твоих флажков слишком большая стоимость. см ниже. Не все могут себе позволить такое.

I>>Проще вводить ломающие изменению и отражать это через semver.
BFE>Конечно проще, если пользователей не жалко или если они вам не важны.

Ага, прям сидим и думаем, как бы пользователей разогнать. Твоя тактика "совместимости со старыми багами" была проверена Микрософтом. Микрософт зашел в тупик и отказался от этого.

На самом деле
1 любая более-менее серьезная либа имеет достаточно широкую "серую" зону, где никаких гарантий "а что, если" никто никогда дать не может, потому как любые тесты __дискретны__, сколько бы у тебя их не было.
2 в случае обратной совместимости стоимость майнтенанса либы увеличивается экспоненциально, то есть, просто обычный майнтенанс, когд стараемся ничего не сломать.
3 Для каждого флажка надо продублировать все ассоциированые тесты. То есть, сотня тестов, "как было", сотня таких же, но "как стало".

Итого
1 — майнтенанс либы должен быть экономически оправдан. Иначе очень быстро появляется 'новая либа', калька со старой, но 'без багов' и тд
2 — флажки вводятся только для равноценных альтернатив, типа "и так и так правильно" или только в том случае, если цена слома высокая
3 — ломающие изменения жизненно необходимы для существования самой либы
4 — периодически нужно депрекейтить старый АПИ и вводить новый

Здравствуйте, Ikemefula, Вы писали:

BFE>>Потому, что если вашей библиотекой пользуются, то про неправильный синус пользователь уже выяснил и подобрал коэфициент его корректирующий. Так что если вы его втихоря исправите, то будете дважды виноваты: сначала потому, что ошиблись, а потом, потому, что из-за вас пользователю пришлось код переписывать.

I>1 Откуда следует, что "про неправильный синус пользователь уже выяснил" ?
Из практики.

I>2 Не будем — в отличие от вас, у нас ищут не виноватых, а решения проблем
Ага. Пользователям это расскажите.

I>3 У твоих флажков слишком большая стоимость. см ниже. Не все могут себе позволить такое.
Хорошие библиотеки не дёшевы.

I>>>Проще вводить ломающие изменению и отражать это через semver.
BFE>>Конечно проще, если пользователей не жалко или если они вам не важны.
I>Ага, прям сидим и думаем, как бы пользователей разогнать. Твоя тактика "совместимости со старыми багами" была проверена Микрософтом. Микрософт зашел в тупик и отказался от этого.

И после того как Микрософт отказался от этого, у Микрософта выросло число пользователей?


I>На самом деле
I>1 любая более-менее серьезная либа имеет достаточно широкую "серую" зону, где никаких гарантий "а что, если" никто никогда дать не может, потому как любые тесты __дискретны__, сколько бы у тебя их не было.

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

I>2 в случае обратной совместимости стоимость майнтенанса либы увеличивается экспоненциально, то есть, просто обычный майнтенанс, когд стараемся ничего не сломать.
А то я не знаю.

I>3 Для каждого флажка надо продублировать все ассоциированые тесты. То есть, сотня тестов, "как было", сотня таких же, но "как стало".
Именно.

I>Итого
I>1 — майнтенанс либы должен быть экономически оправдан. Иначе очень быстро появляется 'новая либа', калька со старой, но 'без багов' и тд
Обычно такой либой является новая мажёрная версия.

I>2 — флажки вводятся только для равноценных альтернатив, типа "и так и так правильно" или только в том случае, если цена слома высокая
Что значит "правильно"? Вот в данном случае правильно — это как?

I>3 — ломающие изменения жизненно необходимы для существования самой либы
Нет. Ломающие изменения вообще не нужны, нужен прогресс.

I>4 — периодически нужно депрекейтить старый АПИ и вводить новый
Это новый лозунг эффективных менеджеров?

·>Вкратце — Firefox сделал сообщение "X is undefined" в JavaScript exception более информативным и это сломало какой-то популярный сайт, т.к. создатели сайта скопипастили какой-то демо код. Изменение откатили.


только про индусов

Здравствуйте, Ikemefula, Вы писали:

I>>>...поскольку на форуме RSDN.ru о нас подумают плохо.
I>·>Не поэтому, а потому что:
I>Ты подробностей не знаешь, но делаешь глубокомысленные выводы.
Никаких выводов особо и не требуется. Да я думаю, что ты и сам понимаешь, что такое решение плохое во всех смыслах. И используется лишь только как компромисс.

I>>>В конечном итоге
I>·>Ага. ВНЕЗАПНО!
I>Заметь, твоё предложение — встать в позу святоши.
Не знаю что этот ярлык конкретно значит.

I>>>вся эта затея зашла в тупик,
I>·>ЧТД.
I>Это же не сразу, а за несколько лет. Что характерно, от тебя никаких предложений, как решить проблему на эти несколько лет, не поступило
А что тут с предложениями-то? Вроде и так всё очевидно. Возможностей дофига — от "забить, т.к. после нас хоть потоп", "проект наш столько не проживёт, пусть хоть как-то поработает", "ну сломается, так пофиксим", до "нафиг послать такого вендора", "предусмотреть fallback на случай если они таки поменяют поведение и беспрестанно это мониторить".

I>·>Конечно, если от вас заказчик не ждёт надёжного решения, а "абы как заработало и чтобы вчера", то сойдёт.
I>Если фича нужна сейчас, то ждать несколько лет это не вариант.
Всяко бывает. Мне доводилось работать в компании, где был FCA, аудит, SLA и прочий контроль, высокая цена ошибки, поэтому там такие решения просто не прокатят — даже если фича очень нужна, но нет способа обеспечить приемлимое качество и надёжность реализации, то придётся обойтись без фичи.

Здравствуйте, B0FEE664, Вы писали:

I>>1 Откуда следует, что "про неправильный синус пользователь уже выяснил" ?
BFE>Из практики.

То есть, по существу сказать нечего.

I>>2 Не будем — в отличие от вас, у нас ищут не виноватых, а решения проблем
BFE>Ага. Пользователям это расскажите.

Они давно в курсе.

I>>3 У твоих флажков слишком большая стоимость. см ниже. Не все могут себе позволить такое.
BFE>Хорошие библиотеки не дёшевы.

Дело не только в стоимости. Если ломается более одного аспекта, то всегда есть шанс, что не найдется комбинации флажков, которая даст тебе нужное старое поведение.

I>>Ага, прям сидим и думаем, как бы пользователей разогнать. Твоя тактика "совместимости со старыми багами" была проверена Микрософтом. Микрософт зашел в тупик и отказался от этого.

BFE>И после того как Микрософт отказался от этого, у Микрософта выросло число пользователей?

Осталось тем же. Будь по твоему — Микрософт растерял бы юзеров.

I>>1 любая более-менее серьезная либа имеет достаточно широкую "серую" зону, где никаких гарантий "а что, если" никто никогда дать не может, потому как любые тесты __дискретны__, сколько бы у тебя их не было.
BFE>Я вам больше скажу: аналоговые компьютеры такая экзотика, что только в байках встречаются.

При чем здесь аналоговые компьютеры ? Напиши мне тест, скажем, для суммы чисел, а я покажу тебе некорректный код и тесты будут зелеными.

I>>2 в случае обратной совместимости стоимость майнтенанса либы увеличивается экспоненциально, то есть, просто обычный майнтенанс, когд стараемся ничего не сломать.
BFE>А то я не знаю.

Похоже, что да, ты не в курсе этой экспоненциальной зависимости и не в курсе, что типичный бюджет и состав команды или сроки фиксированы, читай — константа.

I>>3 Для каждого флажка надо продублировать все ассоциированые тесты. То есть, сотня тестов, "как было", сотня таких же, но "как стало".
BFE>Именно.

Если вписывается в бюджет — хорошо. Не вписывается — до свидания.

I>>1 — майнтенанс либы должен быть экономически оправдан. Иначе очень быстро появляется 'новая либа', калька со старой, но 'без багов' и тд
BFE>Обычно такой либой является новая мажёрная версия.

Не понимаю, ты намекаешь, что лучше выпустить мажерную версию, чем заниматься майнтенансом флажков ? Если так, то я согласен. Накопились ломающие изменения — делаем мажорный релиз, где прописываем чего сломано и тд и тд.

I>>2 — флажки вводятся только для равноценных альтернатив, типа "и так и так правильно" или только в том случае, если цена слома высокая
BFE>Что значит "правильно"? Вот в данном случае правильно — это как?

Например, вставать с кровати можно с левой ноги, а можно и с правой, а можно и с любой, и даже с руки и с любой другой части тела. Все это равноценные альтернативы, и так, и так правильно.

I>>3 — ломающие изменения жизненно необходимы для существования самой либы
BFE>Нет. Ломающие изменения вообще не нужны, нужен прогресс.

Откуда взяться прогрессу, если издержки на майнтенанс растут экспоненциально, а бюджет, состав команд или сроки фиксированы ?

I>>4 — периодически нужно депрекейтить старый АПИ и вводить новый
BFE>Это новый лозунг эффективных менеджеров?

Стоимость майнтенанса любого кода растет экспоненциально от количества поддерживаемых требований, ограничений и тд.
То есть, цикл жизни кода, если из него ничего не выбрасывать, а только добавлять, крайне короткий.
Поэтому вопрос с либами решается так — 1 добавляем только то, без чего не можем обойтись 2 выбрасывам всё, что не можем майнтейнить

Это следует из того, что бюджет, размер команды конкретного проекта или сроки релиза всегда фиксированы.
Условно, если у тебя X единиц денег на год и Y девелоперов, то прогресс ограничен именно этим. А если ты хочешь майнтейнить вообще все флажки введенные с начала времён, то не совсем ясно, откуда взяться прогрессу

Здравствуйте, ·, Вы писали:

I>>Ты подробностей не знаешь, но делаешь глубокомысленные выводы.
·>Никаких выводов особо и не требуется. Да я думаю, что ты и сам понимаешь, что такое решение плохое во всех смыслах. И используется лишь только как компромисс.

Я думаю это очевидно и ты мог об этом догадаться, когда я написал слово workaround

I>>Заметь, твоё предложение — встать в позу святоши.
·>Не знаю что этот ярлык конкретно значит.

Например, когда некий факт затрагивает эго девелопера, этот самый девелопер всеми силами отказывается решать проблему, например: "Так нельзя, потому что это антипаттерн!"

Здравствуйте, Ikemefula, Вы писали:

I>>>Ты подробностей не знаешь, но делаешь глубокомысленные выводы.
I>·>Никаких выводов особо и не требуется. Да я думаю, что ты и сам понимаешь, что такое решение плохое во всех смыслах. И используется лишь только как компромисс.
I>Я думаю это очевидно и ты мог об этом догадаться, когда я написал слово workaround
Слово workaround я написал давным давно и даже несколько раз. Непонятно тогда в чём было твоё возражение.

I>>>Заметь, твоё предложение — встать в позу святоши.
I>·>Не знаю что этот ярлык конкретно значит.
I>Например, когда некий факт затрагивает эго девелопера, этот самый девелопер всеми силами отказывается решать проблему, например: "Так нельзя, потому что это антипаттерн!"
Антипаттерн это не причина, а признак. А причина потому что получится ненадёжное решение. С другой стороны, ненадёжное решение может устраивать заказчика, вот и вылазит workaround.