Ответ на »сообщение 5639« (Стэн)
___________________________

Ответ на »сообщение 5620« (Илья Ермаков)
___________________________
Тоже самое и FOR ... BREAK. Ну не сможете мне формально доказать, что FOR ... BREAK - плохо, а WHILE это хорошо в языках с side-effect'ами. Остается только статистически. У Вас есть статистика?

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

Ответ на »сообщение 5654« (AVC)
___________________________

А вот сейчас в голову пришла мысль, что Вирт, возможно, сознательно проводит такую политику: он проектирует язык так, чтобы отклонения от правил были обнаружимы (например, в КП попытка изменить управляющую переменную в теле цикла FOR обнаруживается с помощью DevAnalyzer.Analyze), но не запрещает окончательно.

По-моему, в отношении FOR дело несколько проще. Для Вирта введение этого цикла в язык -- компромисс, на котором настаивают другие. Ему этот цикл похоже не нравится. В любом случае в классическом Паскале, классической Модуле-2 запрещалось изменение значения управляющей переменной внутри цикла. Явно.

В классическом Обероне этого цикла нет. В Обероне-2 (это вариация Мессенбока на основе классического Оберона) -- его семантика прописана скупо и допускает изменение значения. В экспериментальном Oberon-SA образца лета 2007 г. (который может отражать нынешнюю точку зрения Вирта) раздел по FOR очень напоминает описание в Обероне-2. Но этого явно недостаточно для вынесения суждения. Вот если Вирт закрепит свою точку зрения в Обероне-07, тогда можно будет говорить уже что-то определенное.

Описание классического Паскаля (редакция 1972 г.): http://www.oberon2005.ru/paper/nw_pas.pdf
Описание классической Модулы-2 (редакция 1988 г.): http://www.oberon2005.ru/paper/nw_m2.pdf

Ответ на »сообщение 5633« (Jack Of Shadows)
___________________________

... устоявшейся школы программирования. ...

ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА-ХА

Ответ на »сообщение 5632« (Jack Of Shadows)
___________________________

... Ваши "предметники" просто не будут иметь времени разобраться в огромном пласте знаний, необходимых для создания программ скажем работающих с БД (SQL, odbc, jdbc, mysql), с сетями (tcp/ip, sockets), через интернет (http, xml, xsl), с шифрованием (SSL, RSA, AES), распараллеливанием (actors, threads, semaphores, processes, message passing), графическими форматами, особенно скажем такими специфическими как медицинские (DICOM)...

Очень характерная тирада: сначала эти "профессионалы" громоздят гималаи мусора, а потом говорят, мол, без нас вы тут не разберетесь...

Когда Бекус фортран придумал -- ему это говорили.
В 60-х гг. в ЦЕРНе выч. центр это физикам навяливал.

Jack, компостируйте мозги кому-нибудь другому.

Ответ на »сообщение 5632« (Jack Of Shadows)
___________________________

... Эта идиотская мысля что можно каким то образом обойтись без профессионалов и отдать все "предметникам" - это наверное бзик оберонистов. Такого настойчивого всплывания этой темы раз за разом я больше нигде  кроме этой ветки не видел.

Ну сколько можно уже мириться с этой инфантильностью. Пора взрослеть.


Ну сколько можно передергивать и клеветать.

Jack, начните взросление с себя.

Ответ на »сообщение 5634« (Илья Ермаков)
___________________________


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

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

Ответ на »сообщение 5659« (pepper)
___________________________
P.S. Вирт проектирует язык "от компилятора", выставляя для компилятора определенные критерии (простота, прежде всего). Этим все очень хорошо объясняется.

Абсолютно верно. Сколько раз уже об этом говорил. Для Вирта главное чтобы компилятор легко было написать. Через что при этом приходится проходить пользователю этого компилятора - для него судя по всему дело десятое. Можно и "рекомендациями" обойтись. А чо ! Пусть в церковь чаще ходит и рекомендации на ночь читает, и все будет путем.

Ответ на »сообщение 5654« (AVC)
___________________________

ет...
А вот сейчас в голову пришла мысль, что Вирт, возможно, сознательно проводит такую политику: он проектирует язык так, чтобы отклонения от правил были обнаружимы (например, в КП попытка изменить управляющую переменную в теле цикла FOR обнаруживается с помощью DevAnalyzer.Analyze), но не запрещает окончательно.

Ага, ярчайший пример такого языка - C++ ;) (даже не C). При "правильном" программировании можно много чего обнаружить на этапе компиляции (чего оберонам и не снилось), зато лазеек сколько угодно. К чему этот приводит все уже знают.

P.S. Вирт проектирует язык "от компилятора", выставляя для компилятора определенные критерии (простота, прежде всего). Этим все очень хорошо объясняется.

Ответ на »сообщение 5656« (Стэн)
___________________________

Ответ на »сообщение 5654« (AVC)
___________________________
>>> Казалось бы, запрети любое иное использование, и дело с концом. Но он не запрещает...
>>> А вот сейчас в голову пришла мысль, что Вирт, возможно, сознательно проводит такую политику: он проектирует язык так, чтобы отклонения от правил были обнаружимы (например, в КП попытка изменить управляющую переменную в теле цикла FOR обнаруживается с помощью DevAnalyzer.Analyze), но не запрещает окончательно.
Это хорошая гипотеза, осталось только разобраться с мотивами. Конкретный цикл FOR - в чем глубокий смысл возможности изменить упровляющую переменную в нутри этого цикла, даже, если это элементарно обнаруживается?

Мы имеем как бы два уровня требований компилятора/анализатора: обязательный (компилятор) и "совещательный" (анализатор). Подобный подход практиковался в свое время в Си: "слабенький" (почти бестиповый) компилятор и занудливый верификатор lint. Разница лишь в том, что сишный верификатор старался выполнить невыполнимую работу. :)
Согласен, здесь, как на суде, надо предъявить мотив.
С мотивом окончательной ясности нет.
У меня пока две гипотезы: (1) оставить программисту "лазейку" на случай некоей особой ситуации, (2) какие-то конкретные трудности в реализации "строгого варианта языка" в рамках (однопроходного) компилятора (например, компилятор слишком усложнялся, к чему Вирт, вроде бы, всегда относился болезненно).
Вероятно, стоит подумать и о других возможных мотивах.

Ответ на »сообщение 5655« (AVC)
___________________________
>>> >>> Что не так в этом цикле?
>>> Переменная i не меняется?
Как вариант. Наверное, 9 из 10 ошибок с WHILE заключаются в этом.
А может быть и нет, возможно что Process(i) меняет значение переменной и все правильно... В том-то все и дело, что с WHILE приходится гадать что же там не правильно... 

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