>а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"и как собственно выбрать эффективный инструмент не перепробовав все доступные ?
>ну давай сначала ещё этот лист делать и алфавит изобретать?
в предыдущих темах я одному анониму объяснил, что мастер - делает свой инструмент, и катается на своем велосипеде.
>Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.
комбайн против лопаты? контекст? - для того, чтобы вспахать один квадратный метр - лопата идеальный инструмент, для одного гектара - вероятно комбайн, а вот придумайте теперь мне инструмент который вспахает всю землю.
>что в любой сложной системе таких фокусов хватает
Зададимся вопросом, почему должно быть сложно? Разве дом построенный из обычно кирпича считается сложным?
>И чем дальше - тем важнее, так каа сложность софта всё растёт.
Какая именно сложность? Временная или пространственная? Любую сложность нужно преодолевать, в этом суть. Убил "время" человека, считай убил человека (ц)
>Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.
ага, мы научились писать программы которые одну программу с одного ЯП переводит в другой ЯП, но не придумали программу которая за нас будет писать её, парадокс.
>Ну так шестерёнку можно тоже по-разному реализовать.
Есть такие понятия как однозначность, единственность - и собственно любой алгоритм можно однозначным и единственным "эффективным со всех сторон" способом реализовать.
>И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.
Это все навеяно формализмом ЯП, будь один ЯП (асм), такого не было бы.
>Валом таких компромиссов.
А корней проблемы ?
>Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.
Повторюсь, в предыдущих темах по этому поводу я анониму объяснил, в чём разнича между "задачей" и "проблемой". Задачи - решают, так как существует метод их решения, а проблемы - разрешают, так как нет метода. Любая задача вытекает из разрешенной проблемы.
>к ней нет вагона готовых сторонних модулей
На все готовое
>Опять же - либо компромиссы и что-то оабочее либо вечно пишем идеал, не дающий никакого практического выхлопа.
Легко говорить про компромиссы когда есть варианты, в 70-ых бы почитать ваши коменты.
>Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?
Ну определим сначала, что к чему влечет, мейнстрим к хобби, или хобби к мейнстриму. ))
