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

Есть у меня коллега, очень толковый программист. Как доходит до оператора For он жалобно спрашивает: "тут единичку вычитать надо?".

В Обероне с этим просто. Ответ: надо. :)

Ответ на »сообщение 5773« (AVC)
___________________________
Если foreach действительно нужен (вряд ли это так в случае простого массива)...
Есть у меня коллега, очень толковый программист. Как доходит до оператора For он жалобно спрашивает: "тут единичку вычитать надо?". За пятнадцать лет работы программистом он считанные разы правильно поставил граничные значения переменной цикла. Вот такая особенность мышления. Если бы он мог просто написать foreach для массива, сколько бы времени сэкономил...
А объект-контейнер с методом foreach мы писать пробовали, вот только туда нужно процедуру подставлять, для пары операторов это неудобно. Сразу встает вопрос о введении анонимных функций и т.д.

Ответ на »сообщение 5773« (AVC)
___________________________
>>> Если foreach действительно нужен (вряд ли это так в случае простого массива), почему бы его не экспортировать в качестве процедуры из модуля, определяющего соответствующую структуру данных?
Лучше спросить о том, почему никто так обычно не делает на языках тип C, Оберон, Delphi (7.0)...
А ответ очень простой - таким решением почти невозможно нормально пользоваться. Вы просто так не напишите код типа:

ls = [1,2,3,4,5,6,7]
a  = 3;
foreach (l in ls)
  print(l + a);
end;

или

ls = [1,2,3,4,5,6,7]
proc x =
  map (\y => y + x) ls
proc 3

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

Избыточная или нет конструкция FOR? Для кого-то избыточная, а для кого-то и foreach совершенно необходимая конструкция.

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

Ответ на »сообщение 5769« (Jack Of Shadows)
___________________________
Как можно говорить о "задачах которые привычны" в отношении к универсальному языку программирования ?
А как можно не говорить? Разработка языка дело субъективное и зависит от личного опыта. Человек писал некоторые программы на некоторых языках и почувствовал, что его что-то не устраивает. Определенные задачи на определенных языках решались неудобно. И он создает новый язык, на котором ЭТИ задачи решать удобно. То, что упрощая решение одних задач он усложняет решение других, остается незаметным.
Люди, которые решают задачи, сходные с задачами автора в восторге.
Те, кто решает принципиально другие задачи в недоумении.

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

Все очень субъективно и единой истины тут нет.

Ответ на »сообщение 5770« (Stargazer)
___________________________
Угу, индустрии настоящие бойцы не нужны, индустрии нужно мясо, да побольше.

Настоящие бойцы нужны всем. У вас есть методика выращивания "настоящих бойцов" в миллионных количествах в короткие сроки ?
Вы знаете как заменить пехоту на спецназ ? Бегом в министерство обороны! Сразу станете министром :))

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

Ответ на »сообщение 5769« (Jack Of Shadows)
___________________________
На воспитании монахов шаолиньского монастыря оберона, индустрию необходимым количеством программистов не обеспечить.


Угу, индустрии настоящие бойцы не нужны, индустрии нужно мясо, да побольше.

Ответ на »сообщение 5768« (Сергей Перовский)
___________________________
Виртовские языки отражают не только его четкость мышления, но и те задачи, которые для него привычны.

Виртовские зяки отражают только лишь мнение Вирта :)) Как можно говорить о "задачах которые привычны" в отношении к универсальному языку программирования ? Это же вам не sql и не пролог.
Существует два подхода в написании компиляторов.
Первый - как можно меньше работы разработчику компилятора.
Второй - Как можно меньше работы пользователю компилятора.

Например в первом случае на программиста возлагается задача освобождения памяти вручную. Зато разработчику компилятора легче. Не нужно заморачиваться со сборщиком мусора.
Во втором случае от программиста это не требуется. Это задача уже возлагается на разработчика компилятора и виртуальной машины.

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

Но вот возни с выведением типов для разработчика компилятора много. Понять Вирта можно. Он уже старичок. Самому возиться ему неохота и времени уже нет. Мешка денег на команду раработчиков у него тоже нет.
Да какое там выведение типов. Тут даже от перечислимых типов приходится отказываться :))

Для Вирта это может быть логическое завершение его долгого пути в программировании.
Для нас же с вами - это тупик.
Чтобы двигаться дальше нужно продолжать усложнять компилятор, возлагая на него все больше и больше задач.
На воспитании монахов шаолиньского монастыря оберона, индустрию необходимым количеством программистов не обеспечить.

Ответ на »сообщение 5767« (Дядя .СЭМ)
___________________________
следуя обоим пунктам можно сделать компилятор проще... 
+1
Язык невозможно оценивать безотносительно к области решаемых задач.
Избыточная или нет конструкция FOR? Для кого-то избыточная, а для кого-то и foreach совершенно необходимая конструкция.
Нужен ли сверлильный станок, если есть токарный? Если сверлить раз в год, то не нужен - да здравствует минимализм. А если каждые пять минут?
Виртовские языки отражают не только его четкость мышления, но и те задачи, которые для него привычны.

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

- Если бы сейчас была дискуссия, - начала женщина, волнуясь и загораясь румянцем, - я бы доказала Петру Александровичу...
М. Булгаков "Собачье сердце"

И все-таки не все так просто, пара утверждений:

1. всю целочисленную арифметику можно реализовать с помощью одной операции - вычитания.
2. практически все управляющие конструкции языка программирования можно заменить на комбинации IF и GOTO без потери функциональности.

следуя обоим пунктам можно сделать компилятор проще...  со всеми вытекающими последствиями для корректности, надежности, переносимости ...

Не могу отнести полноценную реализацию целочисленной арифметики или управляющих структур языка к избыточной сложности. Так что с этих позиций сложность реализации компилятора не может служить прямым мерилом избыточной сложности.

В случае с FOR наверное все-таки более корректно говорить об избыточной сложности существующих реализаций самого оператора.