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

S>>>Эта необходимость ортогональна тому, идут значения в функцию отдельно или кортежем.

I>> Это пример того, как второе значение увеличивает сложность.
S>Этот пример увеличивает сложность как с применением кортежа, так и без него.

Именно. Если не брать во внимание кортеж, про который тебе хочется поговорить, то получится "пример увеличения сложности". См ниже.

I>>Ты путаешь контекст — это пример увеличения сложности. Если ты запихал это в кортеж, часть кода станет короче, но сложность никуда не денется — как была, так и осталась. Проявляется, например, в том, что на UI нужно бОльше тестов, на API нужно бОльше тестов. В разработке аналогично — всё равно надо валидировать, т.к. инпут вида Балтимор+Россия.
S>Эта сложность появилась не от применения кортежа.

Не совсем понятно, почему тебе хочется про кортеж говорить Как только в требованиях появились "страна+город", вместо "страна", сложность вырастает сама собой. И никакие "декартовы произведения" тебя не спасут.

I>>>>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
S>>>Что это меняет?

I>>Известно что — принципиально отсутствует возможность бесплатного отката.
S>Верно для неперсистентных структур данных.

Более того — это признак неперсистентных структур данных.

I>>Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.
S>Для тебя это огрызок. И если учителя в школе не смогли пояснить, то мне это зачем?

Снова из тебя понты лезут Когда говорят "удельный" то это всегда соотношение двух величин. Из твоего огрызка непонятно, про какие именно величины идет речь

I>>Совсем необязательно. Значительная часть типичного веб-приложения написана на самом православном функциональном языке — SQL, а другая — на декларативном CSS где вообще нет никакой императивщины. Что характерно, и там и там обычно багов пруд пруди. Одни заметны глазом, вызывают негатив и недоверие, а другие стоят огромных денег Что интересно — когда SQL писали руками, багов было еще больше.

S>А я и не писал что это обязательно. Наоборот, отметил что это субъективные ощущения.

А мне субъективно кажется, что количество багов зависит от
1) качества требований
2) уровень планирования, например прессинг "давай-давай" всегда ведет к увеличению багов
3) отношения разработчика к работе
4) от квалификации разработчика
5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд

И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.

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

S>>>Эта необходимость ортогональна тому, идут значения в функцию отдельно или кортежем.

I>> Это пример того, как второе значение увеличивает сложность.
S>Этот пример увеличивает сложность как с применением кортежа, так и без него.

Именно. Если не брать во внимание кортеж, про который тебе хочется поговорить, то получится "пример увеличения сложности". См ниже.

I>>Ты путаешь контекст — это пример увеличения сложности. Если ты запихал это в кортеж, часть кода станет короче, но сложность никуда не денется — как была, так и осталась. Проявляется, например, в том, что на UI нужно бОльше тестов, на API нужно бОльше тестов. В разработке аналогично — всё равно надо валидировать, т.к. инпут вида Балтимор+Россия.
S>Эта сложность появилась не от применения кортежа.

Не совсем понятно, почему тебе хочется про кортеж говорить Как только в требованиях вместо "страна" появились "страна+город", сложность вырастает сама собой. И никакие "декартовы произведения", ни кортежы, ни прочие приседания тебя не спасут.

I>>>>Сложность восстановления(и частота ошибок) почему то зависит от количества фигур. Странно, да ?
S>>>Что это меняет?

I>>Известно что — принципиально отсутствует возможность бесплатного отката.
S>Верно для неперсистентных структур данных.

Более того — это признак неперсистентных структур данных.

I>>Итого — 1 ты согласен, что выдал огрызок и 2 пояснять отказываешься.
S>Для тебя это огрызок. И если учителя в школе не смогли пояснить, то мне это зачем?

Снова из тебя понты лезут Когда говорят "удельный" то это всегда соотношение двух величин. Из твоего огрызка непонятно, про какие именно величины идет речь

I>>Совсем необязательно. Значительная часть типичного веб-приложения написана на самом православном функциональном языке — SQL, а другая — на декларативном CSS где вообще нет никакой императивщины. Что характерно, и там и там обычно багов пруд пруди. Одни заметны глазом, вызывают негатив и недоверие, а другие стоят огромных денег Что интересно — когда SQL писали руками, багов было еще больше.

S>А я и не писал что это обязательно. Наоборот, отметил что это субъективные ощущения.

А мне субъективно кажется, что количество багов зависит от
1) качества требований
2) уровень планирования, например прессинг "давай-давай" всегда ведет к увеличению багов
3) отношения разработчика к работе
4) от квалификации разработчика
5) уровень разработки на проекте, например, подходы к тестированию, проектированию и тд

И где то во втором десятке идут языки программирования и парадигмы. Например, при прочих равных, функционалист, которому наплевать и на работу, и на команду, и на результат, гораздо хуже ответственного педантичного студента императивщика.