>а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"

и как собственно выбрать эффективный инструмент не перепробовав все доступные ?

>ну давай сначала ещё этот лист делать и алфавит изобретать?

в предыдущих темах я одному анониму объяснил, что мастер - делает свой инструмент, и катается на своем велосипеде.

>Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.

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

>что в любой сложной системе таких фокусов хватает

Зададимся вопросом, почему должно быть сложно? Разве дом построенный из обычно кирпича считается сложным?

>И чем дальше - тем важнее, так каа сложность софта всё растёт.

Какая именно сложность? Временная или пространственная? Любую сложность нужно преодолевать, в этом суть. Убил "время" человека, считай убил человека (ц)

>Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.

ага, мы научились писать программы которые одну программу с одного ЯП переводит в другой ЯП, но не придумали программу которая за нас будет писать её, парадокс.

>Ну так шестерёнку можно тоже по-разному реализовать.

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

>И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.

Это все навеяно формализмом ЯП, будь один ЯП (асм), такого не было бы.

>Валом таких компромиссов.

А корней проблемы ?

>Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.

Повторюсь, в предыдущих темах по этому поводу я анониму объяснил, в чём разнича между "задачей" и "проблемой". Задачи - решают, так как существует метод их решения, а проблемы - разрешают, так как нет метода. Любая задача вытекает из разрешенной проблемы.

>к ней нет вагона готовых сторонних модулей

На все готовое

>Опять же - либо компромиссы и что-то оабочее либо вечно пишем идеал, не дающий никакого практического выхлопа.

Легко говорить про компромиссы когда есть варианты, в 70-ых бы почитать ваши коменты.

>Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?

Ну определим сначала, что к чему влечет, мейнстрим к хобби, или хобби к мейнстриму. ))