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

D>>А как вам вот такой тезис, что программа просто должна быть достаточно xxx?
D>>Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать;

PD>Если бы мы были в однопрограммной системе — готов согласиться. А в многопрограммной — нет. Потому как отдельная программа может быть вполне достаточна, а все вместе они едят ресурсов немеряно и тормозят.

PD>Кстати, сформулируй критерий достаточности, если можешь.

Для начала честно признаюсь с неспособности его сформулировать, но могу показать, где как я думаю стоит его искать в конкретных случаях.
Во первых полностью согласен с мыслями

Автор: GlebZ
Дата: 06.10.05

Glebz о достаточной оптимальности. Особенно с его классификацией и походом к оптимизации.

Далее предлагаю забыть о том что работа это не только возможность кушать, но еще и сточник кайфа и способ "поддерживать форму". И посмотреть на "достаточно" только с точки зрения бизнеса.
Во-первых наше место в делании денег на софте: Делает их кассир, в тот момент когда приходит покупатель. А приходит он потому, что отдел PR удачно прорекламировал продукт и покупатель не только узнал, но еще и решил купить. А вот теперь наше место — помочь PRщкам делать свою работу лучше. Если бизнес делается не на продаже софта, немного меняются детали моего рассуждания, но общая идея таже — наше дело делать софт, достаточно востребованный пользователем. Достаточно в смысле бизнеса.
Теперь, кто же тот самый пользователь, для которого надо быть достаточным? Ответ — тот же для кого стараются PR. Тут пользователи делятся на две группы:
1. Кто уже выбрал. Их надо удержать, новая версия (патч) должена быть достаточна, что бы пользователь не взял другой продукт и должена быть выпущена достаточно быстро.
2. Кто про продукт знает, но не пользуется. Соответственно достаточно чтобы потенциальный пользователь стал действительным.
Ксати предположения о target group и цене на продукт могут очень помошь всести многопрограммную систему к "квази" однопрограммной.
Сколько ресурсов у предполагаемого пользователя? Какие сколько из них заняты его типовыми программами? — Остальное только для нас
Сколько пользователь заплатит за наш софт? А сколько за апгрейд, что бы не тормозил?
Девелопер должен думать о том как с наибольшей пользой потратить свое рабочее время. В частности, если плохо известно для кого стараемся, то очень может быть, что стоит вообще ничего не кодить, а узнать это.

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

PD>Удобство UI прямого отношения к эффективности обычно не имеет. А вот чистота и последовательность архитектуры отнюдь не требует применения неэффективных методов. Скорее наоборот — скажи кратко, но хорошо (К. Прутков)

Не соглашусь по обоим пунткам. Тривиальный пример — это выбор платформы (процессорный код vs VM, различные языки — различного качества компиляторы/VM`ы).
Архитектура может быть достаточно гибкой для оптимизации, но при этом излишне сложной, если оптимизация не потребуется. И наоборот, очень удобной, но местами эффективные решения придется делать кривостью. В первом случае получаем много скорости мало фич, во втором — наоборот. Конечно замечательно, когда "кратко, но хорошо", но бывает озарение не пришло...
C UI теже проблемы. Все время стоишь перед выбором, усложнять реализацию или использовать не эффективные решения. Например, хочу показать всегда актульную информацию -> паттерн observer -> что наблюдаем? И тут часто оказывается, что следить за всем подряд существенно проще чем только за тем, что необходимо. А если завтра после небольших изменений необходимого станет больше?