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

Ответ на »сообщение 5653« (Стэн)
___________________________
>>>Что не так в этом цикле?

Переменная i не меняется?

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

>>>В теории все просто, так как там нет side-effect'ов, а вот на практике они появляются...

Давайте попробуем "разобраться" с побочными эффектами.
Меня тоже удивляет, почему Вирт проектирует языки так, что побочных эффектов можно избежать, дает рекомендации, как это сделать, но не делает последнего шага -- не запрещает их на корню (к чему, например, призывает уважаемый Geniepro).
Например, он рекомендует использовать для цикла FOR только локальную переменную, не допускать ее изменения в теле цикла, а по окончании цикла -- считать ее значение неопределенным.
(Кстати, при таком подходе управляющая переменная совсем не обязана быть локальной в цикле, вполне достаточно объявить ее как обычную локальную переменную. Так что в Аде и Модуле-3 используется, думается, более прямолинейный и грубый подход.)
Казалось бы, запрети любое иное использование, и дело с концом. Но он не запрещает...
А вот сейчас в голову пришла мысль, что Вирт, возможно, сознательно проводит такую политику: он проектирует язык так, чтобы отклонения от правил были обнаружимы (например, в КП попытка изменить управляющую переменную в теле цикла FOR обнаруживается с помощью DevAnalyzer.Analyze), но не запрещает окончательно.
Та же политика, что и в отношении loop-holes. Использовать их не запрещается, но это использование легко обнаруживается по использованию псевдомодуля SYSTEM.

Ответ на »сообщение 5648« (AVC)
___________________________
>>> IMHO, вполне можно обосновать преимущество (как минимум, при прочих равных) WHILE перед FOR ... BREAK.
>>> По крайней мере со времен книги "Структурное программирование" принято считать (или я здесь ошибаюсь?), что цикл строится/обосновывается с помощью метода математической индукции (отсюда и выделение инварианта).
Это очень интересный оборот "при прочих равных"... Его бы стоило раскрыть более подробно.
Что касается построения/обоснования - один пример я уже приводил. В теории все просто, так как там нет side-effect'ов, а вот на практике они появляются... А вот одна из самых распространенных ошибок с WHILE-циклами, которая вообще не характерна для FOR.

WHILE i < len DO
  Process(i);
END;

Что не так в этом цикле?

Ответ на »сообщение 5650« (Сергей Перовский)
___________________________

Ответ на »сообщение 5649« (AVC)
___________________________
>>>Мне кажется, что понимание (как минимум) основ управления должно быть общей частью (хотя бы технического) образования, и уж никак не является особой компетенцией программистов, тем паче -- кодеров, высокомерно отстукивающих на клавиатуре программный код по чужим спецификациям.
Об том и звук...
Но выпускники вузов не могут ответить даже как называется наука об общих принципах управления :(
Ни специалисты в программировании, ни специалисты "в поездах".

(AVC тянет руку) Кибернетика, да? :)

Ответ на »сообщение 5646« (AVC)
___________________________
>>> Вроде как программисты -- головастые ребята, а медики или физики проявляют в своей области не больше интеллекта, чем пассажиры метро в вагоне (ведь такие аналогии пошли в ход для красного словца).
Может быть, я просто Вас недопонял, но я про физиков и медиков ничего подобного не говорил...
Точно также как и про головастых ребят...
А говорил я о том, что в каждой области есть свои специалисты - в метростроении, автомобилестроении, в строении зданий, точно также как и в производстве медицинского оборудования... И что самое интересное во всем этом, инженерам не нужно знать все тонкости постановки диагноза пищевого отравления испорченным мясом, либо самолично обладать навыками экстремального вождения в условиях обледенения дорожного покрытия, чтобы производить хорошие машины и оборудование...
И если Вы перечитаете сообщение »сообщение 5634«
>>> Речь о том, чтобы системы для врачей программировали люди с медицинским образованием, которые получили программисткую подготовку и занимаются профессионально, но не программированием вообще, а программированием в медицине.
то увидите, что Илья в программировании предлагает делать все наоборот - способность ставить диагноз - основное умение, а знание о том, что такое группы Ассура отодвинуть на второй план по принципу - "хорошо, если, но если нет, то и так сойдет"...

Ответ на »сообщение 5649« (AVC)
___________________________
Мне кажется, что понимание (как минимум) основ управления должно быть общей частью (хотя бы технического) образования, и уж никак не является особой компетенцией программистов, тем паче -- кодеров, высокомерно отстукивающих на клавиатуре программный код по чужим спецификациям.
Об том и звук...
Но выпускники вузов не могут ответить даже как называется наука об общих принципах управления :(
Ни специалисты в программировании, ни специалисты "в поездах".

Ответ на »сообщение 5647« (Сергей Перовский)
___________________________

Ответ на »сообщение 5646« (AVC)
___________________________
>>>И какой достойный вывод?
>>>Что сначала надо разбираться в управлении, потом в программировании, и только потом -- "в поездах"?

Насчет второго и третьего места я настаивать не буду :)
Меня больше всего заботит, что системы управления делают люди в управлении не разбирающиеся. Знание объекта управления и инструмента программирования на этом фоне бесполезны.


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

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

Ответ на »сообщение 5620« (Илья Ермаков)
___________________________
>>> Или Вы хотите иметь предохранитель от дурости? Так это уже мало относится к вопросу правильных и неправильных циклов.
О, это прямым образом относится к правильным и неправильным циклам... Не так давно был разговор про FOREACH, и в том числе и Вы говорили, что это плохо, потому, как там все неявно, и итератор может работать непредсказуемо, и выдавать совсем не то, и это не увидишь простым просмотром кода...
Вот в приведенным примере явности не на много больше:
WHILE (i < len) & Condition(i) DO ... END;

В принципе, обнаружение побочных эффектов в функциях дело нехитрое, причем в языке ничего менять не надо.
Так что ничто не мешает, если прижмет, запретить использование в конкретном проекте побочные эффекты в функциях.
Здесь принципиальная разница с ситуацией, скажем, в Си/Си++, где многие проблемы нельзя отследить по причине плохо спроектированного языка.

А теперь докажите мне, что FOREACH хуже WHILE в общем случае для области применения. Формально не докажите, остается статистически показывать, что в одном случае ошибок меньше, чем в другом. Однако я сомневаюсь, что у Вас есть такая статистика. Тоже самое и FOR ... BREAK. Ну не сможете мне формально доказать, что FOR ... BREAK - плохо, а WHILE это хорошо в языках с side-effect'ами. Остается только статистически. У Вас есть статистика?

IMHO, вполне можно обосновать преимущество (как минимум, при прочих равных) WHILE перед FOR ... BREAK.
По крайней мере со времен книги "Структурное программирование" принято считать (или я здесь ошибаюсь?), что цикл строится/обосновывается с помощью метода математической индукции (отсюда и выделение инварианта).
Логическое объединение инварианта цикла и условия его завершения должно давать искомый результат.
В случае с WHILE как минимум условие завершения цикла явно обозначено, в отличие от FOR...BREAK.
Кроме того, WHILE завершается в точке, где выполняется инвариант, а BREAK -- в произвольном месте.

Ответ на »сообщение 5646« (AVC)
___________________________
И какой достойный вывод?
Что сначала надо разбираться в управлении, потом в программировании, и только потом -- "в поездах"?
Насчет второго и третьего места я настаивать не буду :)
Меня больше всего заботит, что системы управления делают люди в управлении не разбирающиеся. Знание объекта управления и инструмента программирования на этом фоне бесполезны.