OberonCore

Запутаться в условии линейного поиска - это как в трёх соснах... А где вообще гарантии, что человек хоть что-то умеет. Конечно, таковых нет. Давайте ориентироваться на тех, кто не умеет, и отменим всю специальную нотацию. Формулы вообще, например. И будем писать всё словами.


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

Спорить смысла нет. У Вас сложившийся стиль составления программ. Свои задачи Вы успешно одолеваете за счёт накопленного чутья - и вперёд с песней... Речь же идёт о подготовке молодых программистов, изначально ориентированных на другой способ мышления.

Я про образование вообще ничего не говорил. Я даже не против идеи обучения на обероне И я не против акцентов на Дейкстре. Я против догм.

При чём тут догма.

Есть некоторый уровень понимания вопроса (алгоритмизации, в данном случае), при котором одно представляется грамотным (потому что является проекцией с того уровня), а другое - нет (потому что нет таких ситуаций на верхнем уровне мышления, которые давали бы такие "тени" на нижнем).

Тому, кто не учитывает тот над-уровень, эти рассуждения о грамотности-безграмотности будут казаться догмой. Для другого же очевидно, что ни в каком случае его мысль не даст проекции, например, в FOR-BREAK. Так же, как компиляция с ЯВУ не даст некоторых последовательностей двоичного кода, которые могут быть написаны вручную.

Да. Вы просто форумом ошиблись. В который раз...

При том, что в данном случае FOR/WHILE вообще не причем. А вы усиленно вдалбливаете в неокрепший мозг, что именно это корень всех зол



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

Да отстаньте вы уже... Не читайте мои сообщения и все.

Читабельность в условиях знания над-уровня и без него совершенно разная. Вы либо будете узнавать паттерны, либо нет. Почитайте какой-нибудь текст с формулами, не зная ничего про то, что описывают эти формулы. Тоже будет очень хреново. Это как обиженный студент на физмате, пропустивший месяц и потом пришедший на семинар, смотрит на доску и плюётся: "чёртовы формулы, ну какой дурак их придумал... Совсем ничего не понятно. Неужели нельзя без них?"

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

В данном случае "причём" то, что была допущена ошибка при проектировании процесса поиска (т.е. его условия). Вместо анализа была предпринята наивная попытка "обойти подбором". WHILE для побора не подошёл, рука сразу потянулась к FOR, а там и RETURN приклепался.

Опять ахинея какая-то.

Речь о банальном обучении пользоваться схемой поиска и формальной логикой.

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



Какую такую нижележащую дрянь? Или вы это так - "Карфаген должен быть разрушен"?

Спор не о чем.

Тяжко вздохнув... Давайте на примере. Если Вы знаете правила, по которому транслятор переводит некоторые в ассемблер, Вам будет легче читать и восстанавливать исходную идею, чем если Вы ожидаете любых возможных сочетаний команд? Только тут ЯВУ - это законы "обсчёта" алгоритмов, транслятор - голова грамотного программиста, а ассемблер - язык программирования. В случае Оберона - с созданными намеренно затруднениями для "вольных изысков".


Этак мы очень далеко от темы ветки уйдём. Посмотрите на морально устаревшие архитектуры ОС, тащащиеся из 70-х годов, хотя бы.

Да тут речь не о сочетаниях, а о количестве команд. Вы искусственно сужаете это количество. Это может помогать пониманию, а может наоборот стирать исходную идею. Зависит от. Идея FOR - итерирование по заранее известному диапазону. В данном примере она очень даже в тему: итерирование - отдельно, проверка специфичного условия - отдельно. Вы же все этого сужаете до обобщенного WHILE со зверским условием, из которого при чтении надо выдирать итерирование и "полезную" проверку, чтобы понять что происходит.

Обсуждение от kim241 вынесено в Отвлечённые:
viewtopic.php?f=12&t=1449

Опять 25... Ничего выдирать не надо. Надо узнавать шаблон в лицо. Который на каждом шагу.

Никакого полного итерирования "в диапазоне" нет. Есть процесс, идущий от начала до конца. Формулируется конец. Более того, формулируется по готовому шаблону, который от зубов отлетает.

Надо. Конкретно - итерирование. В WHILE его не видно.



Конечно нет. Потому что RETURN стоит в середине. Вы же не будете утверждать, что RETURN увидеть труднее, чем найти INC(i) + проверку диапазона в обощенном WHILE и убедится, что эта i больше нигде не изменяется и никуда не отдается по ссылке?

P.S. Только не надо опять начинать про то, что такие вольности (RETURN из FOR) позволяют писать кошмарный код. Да, позволяют. Но и более читабельный, чем обощенный WHILE - тоже позволяют.

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

Короче, придёт новое наученное поколение - и никаких проблем у него не будет. Старого кобеля, как говорится.. Даже если он борозды не портит...

Крамольная мысль - а чем по существу паттерн поиска через while лучше, чем паттерн итератора с досрочным выходом?

Мне почему-то представляется, что они оба есть не более чем варианты технической реализации идеи поиска... Каждая реализация со своими особенностями. Плюсами и минусами.

Меня интересует когнитивно-эргономическая точка зрения.
Если средство программирования поддерживает конкретный паттерн, то без разницы, какой именно.
Если не поддерживает, то вероятность ошибиться в том и в другом случае априори одинакова.

Ещё раз подчеркну мысль, что суть (путь математическая) и конкретная реализация модели - вещи разные.

P.S. Возможно, я недооцениваю важности инварианта. Мне кажется, что в данном случае он больше является атрибутом конкретной реализации, чем сути задачи.

Здравая мысль. Но не кажется ли вам, Илья, что паттерны вполне можно заучивать и на С++? Из опыта преподавания первокурсникам разных языков знаю, что первый язык программирования учится как первый иностранный. Что заучат - то и помнят.
Дело не в языке, а в преподах.
Сам грешен - увлекался финтифлюшками С++ в ущерб правильной постановке мозгов.

Вижу только одно существенное преимущество Оберона перед С++ в этом плане: конструкция модуля со всеми вытекающими.

А строить прогу "под доказательство" - в этом С++ и Оберон совершенно эквивалентны.

Позвольте вбросить свои 5 копеек.
Если речь идёт о конкретном FOR с RETURN, то существо тут, на мой взгляд такое. Когда человек с кем-то договаривается, то от него ждут выполнения оговоренных условий. Если этот человек посередь рабочего процесса сруливает пивка попить, то отношение к нему изменится и необязательно в лучшую сторону.
Когда пишется текст (я акцентирую - именно текст), описывающий FOR, то это, по сути, договор между писателем и читателем - на выполнение заданного количества итераций. Когда же писатель (как в плохом детективе, достаёт рояль из кустов) делает внезапный выход через RETURN, то это называется "семь пятниц на неделе" или попросту, "кидалово" (сорри за словечко).