Только здесь не так просто, как на схеме из курса электронных приборов. Там есть правильный вход, правильный выход и отрицательная обратная связь, стабилизирующая преобразование сигнала. В рограммировании (и много где ещё) выход нам не даётся априори. Мы должны понять, куда прийти.
Можно пояснить, что имелось ввиду, под неизвестностью выхода?.. Если мы пишем программу, то мы должны гарантировать при правильных исходных данных правильный результат.
Допустим, мы в ситуации, когда мы в состоянии сформировать любой набор входных данных (вход) в зависимости от того, к чему мы должны прийти (выход, резульат). Тогда единственной проблемой в условии является понимание результата. Не всегда с первого или второго раза удаётся понять, что же всё-таки нужно. Для этого делаются прототипы. При работе над ними проясняется ситуация с тем, что должно быть на выходе.
Неизвестность выхода - это, наверно, было слишком грубо. Точнее было бы сказать, что на начальной стадии новой задачи понятие о выходе у разарботчика нечёткое.
Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.
Вообще-то я редко когда упускаю возможность решить задачу своими силами, а не стандартными средствами. И уж кто-кто, а я точно не закрываю тему разарботки.
Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?
Нет, не перестаёт. Но у него другая задача. Задача выбора, компоновки и т.д.
Вот, допустим, по конвейеру ползёт печатная плата. На ней не хватает элемента - автоматика его не ставит в виду его специфики. Это делает рабочий. Он ставит элемент на плату и всё, даже пайкой занимается дальше автоматика. Много ли здесь творчества? Как долго он будет считать, что занимается творчеством?
Осознание, что нужна сортировка - это одна задача. Выбор сортировок - другая. Они все решены. Теперь перед программистом задача - задействовать сортировку. Ему нужно написать sort и передать параметры. Или написать mySort и передать параметры. Но чтобы mySort заработал, его сначала нужно написать. Это ещё несколько подзадач, которые могут оказаться весьма творческими (или процесс творчества наложит на программиста эмоциональные отпечатки разной силы). Но процесс написания приводит к прояснению конечного результата. Он становится более чётким, и беспристастный наблюдатель заметит, что процесс создания mySort лишь частично решает задачу, а многие действия по отношению к
настоящему итогу бесполезны или даже вредны. Беспристрастный наблюдатель легко откажется от неправльного решения, а тот, кто написал, - будет сопротивляться.
Поэтому весьма желательно, чтобы код сам по вебе не являлся результатом творчества. А лучше бы этим резульатом было нечто, что трансформируется в код. Тогда отказываться от своей реализации чего-то-там будет гораздо проще: результат творчества не уничтожается.
