Oberon space

Точно также конструктор должен подтвердить расчётом, каждый болт (на срез, кручение, изгиб...), каждую заклёпку... Ничего хитрого, как видите.

То есть, это инструмент проектирования, абстракция, представляющая собо расчёты? Никакого графического воплощения у неё нет.

Цитата: Valery Solovey от Февраль 14, 2012, 01:27:51 pm

Только здесь не так просто, как на схеме из курса электронных приборов. Там есть правильный вход, правильный выход и отрицательная обратная связь, стабилизирующая преобразование сигнала. В рограммировании (и много где ещё) выход нам не даётся априори. Мы должны понять, куда прийти.

Можно пояснить, что имелось ввиду, под неизвестностью выхода?.. Если мы пишем программу, то мы должны гарантировать при правильных исходных данных правильный результат.

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

Почему "при использовании sort - ноль творчества"? Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?.. Это напоминает разговор с И. Ермаковым, который тоже как-то одномерно понимает творчество. Если есть хороший/пригодный для данных условий элемент, то его не надо выбрасывать и пересоздавать заново, надо его использовать. Но при этом не надо навсегда закрывать тему разработки этих элементов.

Вообще-то я редко когда упускаю возможность решить задачу своими силами, а не стандартными средствами. И уж кто-кто, а я точно не закрываю тему разарботки.

Если конструктор собирает некоторое изделие (прибор, например) из стандартных компонентов/на стандартной элементной базе, то он перестаёт творить?

Нет, не перестаёт. Но у него другая задача. Задача выбора, компоновки и т.д.

Вот, допустим, по конвейеру ползёт печатная плата. На ней не хватает элемента - автоматика его не ставит в виду его специфики. Это делает рабочий. Он ставит элемент на плату и всё, даже пайкой занимается дальше автоматика. Много ли здесь творчества? Как долго он будет считать, что занимается творчеством?

Осознание, что нужна сортировка - это одна задача. Выбор сортировок - другая. Они все решены. Теперь перед программистом задача - задействовать сортировку. Ему нужно написать sort и передать параметры. Или написать mySort и передать параметры. Но чтобы mySort заработал, его сначала нужно написать. Это ещё несколько подзадач, которые могут оказаться весьма творческими (или процесс творчества наложит на программиста эмоциональные отпечатки разной силы). Но процесс написания приводит к прояснению конечного результата. Он становится более чётким, и беспристастный наблюдатель заметит, что процесс создания mySort лишь частично решает задачу, а многие действия по отношению к настоящему итогу бесполезны или даже вредны. Беспристрастный наблюдатель легко откажется от неправльного решения, а тот, кто написал, - будет сопротивляться.

Поэтому весьма желательно, чтобы код сам по вебе не являлся результатом творчества. А лучше бы этим резульатом было нечто, что трансформируется в код. Тогда отказываться от своей реализации чего-то-там будет гораздо проще: результат творчества не уничтожается.

Распределение памяти под динамические структуры представляется в виде карты памяти программы. [...]

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

А что имел ввиду Валерий    - давайте спросим у него

Я увидел задачу, напоминающую учебную, и предоставил схему её решения. Времени я на неё потратил больше, чем Vlad, но недостаточно, чтобы уверенно сказать, что она работает. Для этого понадобилось бы ещё некоторое количество времени. Ещё несколько человек предоставили свои варианты решения. После этого началось решение задачи "что лучше". Я не называю своё решение лучшим. Я согласен, что зачастую следует использовать стандартные библиотеки. Но выбор лучшего алгоритма - это другая задача.
Поскольку, как я считаю, целью было получение схемы, то я не сделал ошибок. Вы сказали, что мои ошибки что-то показывают. Но в исходной задаче решение было у меня в голове, а код - это реплика, с помощью которой я хотел передать решение. В устной речи бывают оговорки, и если собеседник замечает неточность, то он акцентирует на ней внимание, чтобы говорящий добавил в свои слова определённость.
Поскольку задача имела черты учебной, то я решил немного по этому поводу высказаться. Почему, собсна, sort() лучше? С чего Vlad взял, что решением будет она, а не "i++; println();"? Потому-то она и учебная, что ученик должен понять, что здесь будет решением. А отвeт "правильно будет использовать sort()" или "... подсчётом", как я уже говорил - это решение другой задачи. Важной для инженера, да, но не сейчас.

Рекомендую помнить афоризм К. Пруткова: "Специалист подобен флюсу".

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

Вот тут где-то советовали начинающим программистам пользоваться языком без сборки мусора. А что, это его (начинающего) главная цель? Освоить ручное управление памятью.

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

Умение вручную разместить и убрать переменную из памяти поможет ему? Нет. Можно ли без этого навыка обойтись в программировании? Довольно часто - да.
Умение сначала пытаться усвоить задачу перед её решением поможет ему? Да. Можно ли без него обойтись? Только в простейших случаях.

Усваивать не значит заучить текст и уметь его по памяти слово в слово прочитать его как слева направо, так и справа налево. Это такая вещь, которая может много где пригодиться по жизни. И никакое программирование ей не нужно. А вот обратное - хорошо программировать пренебрегая этой вещью - я думаю, невозможно. И поэтому, это умение должно быть освоено или до начала программирования или вместе с ним. И поэтому преподаватели (конкретно Илья и info21) считают, что
а) любые элементы в зыке программирования лишние, и мешают учиться правильно воспринимать задачу. Но поскольку без элементов не будет формы, в которую можно облекать решение, то пускай хотя бы их будет разумно минимально.
б) требуются задачи, на которых студент учился бы "отпускать" своё сознание для усваивания задачи, а не судорожно бы тыкался по списку запомненных операций над данными.

Хороша ли задача, которую привёл Пётр, чтобы преподаватели использовали её в качестве наработки навыка усваивания (или анализа - так, наверное, правильнее)? Сложный вопрос. Но, думаю, она даётся именно с этой целью. А не чтобы обезьяна нашла, как написать на клавиатуре sort.

Ну, конкретное значение этого термина зависит от "предметной области", так сказать. Моё определение касается тех, тех, кто в основном работает с кодом.

Вот в один прогон. Вроде, не накосячил. Есть поле для оптимизации.

cl, cr, x, tmp : INTEGER;

x := 0;
cl := 0;
cr := LEN( a );
WHILE x < cr DO
IF a[x] = 1 THEN
tmp := a[cl]; a[cl] := a[x]; a[x] := tmp;
cl := cl + 1;
ELSIF a[x] = 3 THEN
tmp := a[cr]; a[cr] := a[x]; a[x] := tmp;
cr := cr + 1;
END
x := x + 1
END