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

Ответ на »сообщение 5768« (Сергей Перовский)
___________________________
В некоторых случаях (как например со сборщиком мусора) он соглашается усложнить компилятор. В других - например декларация типов, по старнике возлагает эту задачу на программиста.
Почему ? Разве нельзя выводить типы ? Можно, и механизм уже давно отработан.
Разве при этом теряется строгая типизация и ошибки о несовместимости типов на этапе компиляции ? Нет, компилятор все также прекрасно ловит эти ошибки.
Разве теряется возможность определать типы вручную если на то есть надобность ? Нет, во всех ML языках можно точно также вручную определать типы.
Разве при этом падает производительность программ ? Нет. OCAML например быстрее любого паскаля и оберона.

В соседней ветке по РусОС как раз зашёл спор о том, позволяет ли ЯВУ выразить больше, чем ассемблер. И выяснилось глубокое отличие во мнениях относительно того, что такое ЯП. Оказалось, люди видят его всего лишь как средство взаимодействия человека с машиной. Тогда - ну да, если можно объяснить машине, не указывая явно типы и избежать ошибок (хотя тонкие ошибки могут быть - и Вы это прекрасно знаете), то почему бы и нет?
Если считать язык средством выражения мысли, средством проектирования системы, то увольте - язык должен не только позволять, но заставлять разработчика явно выразить все свои решения. В том числе и по типам. Я не хочу потом, читая чужую программу, проделывать работу компилятора в уме, да ещё гадать - человек это хотел сделать, или просто бросил на откуп компилятору...
Сравнение со сборкой мусора не из той степи - на вопрос "Ненужную память освобождать надо?" ответ может быть только "да". А на вопрос "Какой тип здесь хочет использовать господин профессор?" может и должен дать ответ только сам "господин профессор".

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

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


Вся история человечества подтверждает
Принцип Калашникова:

Избыточная сложность есть уязвимость.
(Название и формулировка (С) info21.)

Спросите у американцев, сгинувших в болотах Вьетнама из-за того, что М-16 отказывалась стрелять в грязи.
Или спросите конкурентов Генри Форда, которых сей Форд стер с лица земли.

Суть Оберона не в отказе от автоматизации, а в отказе от избыточной сложности (как и суть замысла Генри Форда, нашего Кошкина (Т-34) и т.д.).

(Удивляюсь, что JoS так и не понял смысла Оберона из 4 лет участия в дискуссиях по Оберону...)

Ответ на »сообщение 5767« (Дядя .СЭМ)
___________________________

Есть сложность необходимая, есть избыточная. В чем вопрос-то?

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

Но почему-то диспутанты неизменно ломают лбы именно насчет этого самого точного положения неточно определенной функции.

Главное, сделать какой-нибудь разумный выбор, и все.

Вирт в Обероне ищет (в отличие от прочих) минимальности прежде всего.
Компонентный Паскаль (например) указывает эту точку чуть по-другому.

Что тут бодаться?

Ответ на »сообщение 5779« (AVC)
___________________________
>>> Меня это не слишком огорчает.
>>> Для меня методы и процедурные переменные -- единый, простой и удобный механизм для многих ситуаций. (Это я в отношении map и т.п.)
Не сомневаюсь, но это очень огорчит программиста, который будет использовать Ваш модуль, из которого Вы экспортировали FOREACH ввиде процедуры. Так как случаи, где бы он мог вызывать эту процедуру, будут ограничены не "многими", а самыми элементарными...

Ответ на »сообщение 5781« (AVC)
___________________________
И каждый раз компилятор должен генерить другой код?
А что, простым for на все эти случаи программист будет писать один и тот же код ?
Нет правильно ? И в том и в другом случае код будет разный. Только в одном случае вы это будете делать ручками, а в другом будет пахать компилятор.
И таки да, он должен. Не я а он.
Что касается конкретного типа структуры, то для чего foreach опишите для того и будет работать.
Из коробки будет работать со списками и массивами.
С более сложными структурами - Присобачите к вашей структуре итератор, и foreach будет с ней работать.
Не присобачите - ну не будет работать, обойдетесь обычным for.

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

>>>А теперь сравните это со следующим правилом: "Для каждого элемента..."

...массива
...списка
...дерева
...структуры данных заранее неизвестной реализации

И каждый раз компилятор должен генерить другой код?
Насколько универсальна конструкция foreach, встроенная в язык?

Ответ на »сообщение 5778« (AVC)
___________________________
Начинайте всегда с нуля, идите до Count-1 и не сворачивайте (не меняйте значение счетчика цикла).
И Господь Вас не оставит. :)

А теперь сравните это со следующим правилом: "Для каждого элемента..."

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

А ответ очень простой - таким решением почти невозможно нормально пользоваться. Вы просто так не напишите код типа:

Меня это не слишком огорчает.
Для меня методы и процедурные переменные -- единый, простой и удобный механизм для многих ситуаций. (Это я в отношении map и т.п.)

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

Ответ на »сообщение 5776« (AVC)
___________________________
>>> В Обероне с этим просто. Ответ: надо. :)

А проверять с нуля или с единицы ?
А оканчивать Count или Count - 1 ?
А счетчик до цикла инициализировать можно ? Нельзя ? Почему нельзя ? Или почему можно ? А что мне с этого будет ? Или не будет ?
А внутри цикла счетчик менять можно ?

Начинайте всегда с нуля, идите до Count-1 и не сворачивайте (не меняйте значение счетчика цикла).
И Господь Вас не оставит. :)

Ответ на »сообщение 5776« (AVC)
___________________________
В Обероне с этим просто. Ответ: надо. :)
А проверять с нуля или с единицы ?
А оканчивать Count или Count - 1 ?
А счетчик до цикла инициализировать можно ? Нельзя ? Почему нельзя ? Или почему можно ? А что мне с этого будет ? Или не будет ?
А внутри цикла счетчик менять можно ?

Сколько еще специфических и не относящихся к алгоритму деталей нужно упомнить, не забыть, не перепутать чтобы "грамотно" пользоваться оператором for ?
В foreach все эти лишние, ненужные, не того уровня детали, упрятаны под капот.