По поводу этой дискуссии:
Я хорошо знаю главное детище Степанова - STL, чтобы делать выводы о его складе как программиста.
Достаточно ясно, что он из категории убеждённых, что "программисту можно всё", и что "сила интеллекта" переломит любые законы объективной реальности.
Геннадий Тышов писал(а):
Какое бы, не было отношение к оператору GoTo - он является фундаментальным (основополагающим) оператором в программировании.
И к этому можно относится спокойно.
Он не может быть фундаментальным, т.к. на уровне алгоритма - т.е. уровне системного анализа и описания поведения чего бы то ни было - его просто нет.
Соответственно, это некий "шум", "мусор" с уровня некоторых частных реализаций вычислительной техники.
Не происходит ли здесь подмена предмета обсуждения? Да, на уровне алгоритма и алгоязыков мы можем отказаться от оператора безусловного перехода (БП - я уж так буду его называть, тем более что это определение точнее) в его произвольном значении. Как я понимаю, претензия Ильи к Степанову кроется именно здесь - видимо, в STL можно ставить БП где захочется и адресовать его куда захочется, т.е. управляющая структура будет иметь тип "спагетти", как в Бейсике? Если так, то я согласен с Ильёй относительно этого языка - но это, на мой взгляд, никак не отменяет факта существования БП в структурных алгоритмических конструкциях - просто он там скрыт под видом других ключевых слов - а по своему значению является ограниченным, имея чёткие места положения команд БП в каждой конструкции и определённые возможные адреса перехода. И именно визуализация на языке, где в алфавит входит БП - а мы располагаем таким языком, это ДРАКОН - позволяет показать это наглядно, что я и сделал
в этом подпункте для ветвлений и
в этом подпункте для циклов.
Именно с участием этих ограниченных БП мы записываем программный код этих конструкций. И при обучении надо не затушёвывать это обстоятельство (что было бы своего рода "информатическим ханжеством" - считаем, что БП в каком бы то ни было виде нарушает "целомудрие структурности", и потому делаем вид, что в структурном коде его нет, хотя он есть
), а выявлять его, отделяя факт СУЩЕСТВОВАНИЯ оператора БП (в т.ч. в структурных программах) от возможности его ПРОИЗВОЛЬНОГО употребления (что в структурных программах, конечно, недопустимо).
Следует уточнить и замечание о "частных реализациях". Уровень реализации алгоритмов также имеет свои математические формализации - в первую очередь это абстрактные машины Тьюринга и Поста. Они отражают конкретные свойства дискретных программируемых машин для переработки данных - работу с данными как с текстом, т.е. с линейной последовательностью символов, помещаемой на "ленту памяти" машины - при этом нелинейные управляющие структуры д.б. как-то погружены в этот линейный порядок. Это - не частность, а общая закономерность.
На более высоком уровне линейность игнорируется, все структуры записываются (и текстово, и графово) в предположении двумерности. То, что в алготекстах БП "прячется" под ключевыми словами, специфическими для разных алгоструктур, обоснованно - так нагляднее для человека, чётко выражается требование ограничения его употребления. И здесь БП выступает как средство выкладки этих структур в линию по цепочкам, ограниченным вершинами разветвления-слияния. Разве не так это происходит при трансляции (см. хотя бы того же Свердлова)?
К частностям же можно отнести то, что память в конкретной платформе "аппаратура-ОС" м.б. сегментирована так или иначе, что накладывает ограничения на размер кода программы и требует в общем случае выкладывать не по алгоритмически назначенным границам цепочек, а и по более мелким. И это также постарался наглядно показать
в этом подпункте для следования операторов.
Конечно, в технике структурной алгоритмизации БП как самостоятельная операционная единица не нужен - только как break и continue, если они используются (а конструкции Дейкстры и этого не подразумевают) - лично я согласен с Ильёй, что лучше "открыть код и увидеть привычный и очевидный линейный поиск", чем "увидеть цикл на больше чем страницу с несколькими break, который нужно долго мысленно "гонять"". В произвольном виде БП требуется при ассемблерном программировании, в т.ч. при реализации трансляторов.
Ограничение на управляющие структуры приведённых Карповым ModelChecking-языков только конструкциями Дейкстры, как уже упоминал, можно преодолеть даже для их гибридизации с техноязыком, так что это вроде как не вопрос. Кстати, доказательство этой возможности тоже использует БП.
Вход
FAQ
Поиск
