Ответ на »сообщение 5161« (AVC)
___________________________
>>> Наверное, все же i < sizeof(a) / sizeof (int).
Конечно...

>>> Представьте, что a -- массив, переданный как параметр некоей функции.
Вот представить это гораздо проще... Так как в С существуют два вида массивов - строки и все остальные. И строки обрабатываются очень легко, а для всех остальных передается длинна...

Ответ на »сообщение 5164« (Илья Ермаков)
___________________________
>>> Кстати, С. Янг в книге "Языки программирования реального времени" отмечает среди требований к языку  не просто читабельность, а то, чтобы "исходный текст был в основной мере понятен специалисту, не знакомому с этим языком". Весьма разумное, кстати, требование.
Это как возможность читать текст на английском не зная английского?
Илья, Вы, пожалуйста, приведите полную цитату того, что говорил Янг. Может быть он имел ввиду не совсем это?!.. Иначе это полная глупость и единственное, что это может означать - каждый (другой) язык должен быть похож на тот, с которым специалист уже знаком... И чем больше похож тем лучше, а еще лучше (очевидно), чтоб был только один язык...

Ответ на »сообщение 5159« (Антон Григорьев)
___________________________

Ответ на »сообщение 5158« (Стэн)
___________________________
Во всех остальных случаях по понятности того, что написано, Оберон оставляет далеко позади все известные мне языки.
Кстати, С. Янг в книге "Языки программирования реального времени" отмечает среди требований к языку (на перваых местах там также надёжность, строгая типизация, модульность и возможность построения АТД) не просто читабельность, а то, чтобы "исходный текст был в основной мере понятен специалисту, не знакомому с этим языком". Весьма разумное, кстати, требование.

А ещё, кстати, недавно я обратил внимание, что в четырёх классических книгах по языкам программирования в качестве эталона для объяснения понятий и идей используются языки Паскаль-семейства: Кауфман "Языки программирования" (Ада, Модула-2, с аргументированием в конце книги преимуществ второй, хотя для демонстрации больше использовалась первая, как более насыщенная разными конструктами), Янг "ЯП реального времени" (Модула-2, Ада), Бен-Ари "Языки программирования" (Ада), Пратт, Зелковиц "ЯП - разработка и реализация" (довольно много внимания уделяется Аде, которая всплывает то там, то тут).

Ответ на »сообщение 5150« (Антон Григорьев)
___________________________

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

ИМХО, Вы, Антон, подменяете здесь понятия.
А именно: абстракцию, которую надо реализовать (это цель), подменяете средством (ООП), причем в одной его разновидности.

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

Конечно, сначала лучше выяснить, в чем каждый видит суть спорного вопроса.
А то, может, и спорить-то не о чем. :)

Как это выглядит с моей стороны.
Все началось с обсуждения нового поста в блоге Зуева lonely compiler, где он написал, что, предоставляя программисту только процедурную абстракцию и модули, Оберон является слишком низкоуровневым.
Причем это утверждение подается в качестве настолько бесспорного, что даже не снабжается аргументами.
Как мне кажется, здесь скрыта какая-то ошибка, т.к., на мой взгляд, модульность является основным (если не единственным) способом выражения абстракции в любом языке.
Это может быть как модульность в духе модульных языков (как в Обероне), так и модульность как свойство класса (как в Си++ и т.д.). (Здесь я имею в виду формулу Б.Мейера класс = тип + модуль.)
Может быть и что-то третье, и четвертое и т.д.
Т.е. модульность довольно широкая концепция, и может быть реализована разными способами.
И вот спрашивается, какую-такую абстракцию нельзя выразить на Обероне? Файловую Систему? Словарь Англо-Русского языка? Что именно?
А вот тот факт, что это будет выражено не через классы, никоим образом не является недостатком Оберона (скорее, даже наоборот). Вы же не станете критиковать ФЯ за то, что -- оставаясь функциональными -- они поддерживают именно функциональную парадигму, а не парадигму "мейнстримового" ООП?
Разделение обязанностей между языком и программистом в Обероне выглядит так: язык обеспечивает безопасность типов, а программист создает новые абстракции с помощью модулей.

Ответ на »сообщение 5159« (Антон Григорьев)
___________________________

Единственный недостаток Обеорна в этом плане - это то, что в выражении A := B нельзя определить, чем является B - переменной или функцией без параметров.

А вот и неправда Ваша! :)
В отличие от Паскаля, в Обероне вызов процедуры-функции всегда требует присутствия скобок, даже если у функции нет аргументов.

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

Ответ на »сообщение 5153« (AVC)
___________________________
>>> В Обероне это как раз вообще не является проблемой (для массивов любой размерности; сравните с Си/Си++).
Сравниваю:
int  a[100];

for(int i = 0; i < sizeof(a); i++)
{
  ...
}

Наверное, все же i < sizeof(a) / sizeof (int).
Но возражение, конечно, не в этом, а в том, что у Вас, скорее всего, не будет под рукой конструкции sizeof (a).
Представьте, что a -- массив, переданный как параметр некоей функции.
Массив в Си передается просто как указатель; например, на 32-битных машинах Ваш sizeof (a) будет равен 4, независимо от длины массива.

Ответ на »сообщение 5159« (Антон Григорьев)
___________________________

И, успокоенный ложной гарантией того, что foreach якобы ВСЕГДА проходит по всем элементам, можете пропустить алгоритмическую ошибку, и догадаетесь, где её искать, только в самый последний момент.
Вообще-то foreach применяется и для того, чтобы проходить не все элементы или все, но в нестандартном порядке. В книге Банды Четырех именно так описан паттерн "Iterator".

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

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

Я говорил не об ошибках в реализации компилятора и стандартных библиотек, а об ошибках, которые вы можете допустить сами. Вы же можете реализовать свой класс, а в нём - интерфейс IEnumerable. А потом, спустя много времени, использовать его где-нибудь в другом месте. И, успокоенный ложной гарантией того, что foreach якобы ВСЕГДА проходит по всем элементам, можете пропустить алгоритмическую ошибку, и догадаетесь, где её искать, только в самый последний момент. В то время как глядя на цикл for, вы всегда сможете мгновенно определить, даёт ли он реальную гарантию, что проход осуществится по всем элементам множества, или нет.

Вообще, это принципиальное отличие Оберона от мейнстрима. Обероновские синтаксические конструкции, будучи вырванными из контекста, дают гораздо более полное представление о том, что они делают, чем конструкции мейнстримовых языков. Например, A.B := <выражение> в Обероне однозначно определяет то, что полю B переменной A будет присвоено значение заданного выражения и более ничего. А в большинстве популярных языков B может быть не полем, а свойством, и при подобном присваивании будет выполнена ещё куча скрытых действий. И таких примеров можно привести множество, потому что Оберон проектировался для того, чтобы его было просто читать. И это - очень важное достоинство. Единственный недостаток Обеорна в этом плане - это то, что в выражении A := B нельзя определить, чем является B - переменной или функцией без параметров. Во всех остальных случаях по понятности того, что написано, Оберон оставляет далеко позади все известные мне языки. Да, это его свойство вступает в противоречие с простотой написания и упрятывания низкоуровневых вещей внутрь, но тут уж каждый сам оценивает, хорошо это или плохо.

Ответ на »сообщение 5157« (Антон Григорьев)
___________________________
>>> А вот это неверное утверждение.
Точно также, как и неверно, что здесь можно заметить ошибку:

FOR i := 0 TO LEN(a)-1 DO
    ...
END;

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

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

а конструкция foreach так и означает, что будут пройдены все элементы множества...

А вот это неверное утверждение. Потому что семантика этой конструкции означает, что будут пройдены все элементы множества, которые возвращаются через определённый интерфейс (IEnumerable, если не ошибаюсь). И если для какого-то конкретного класса этот интерфейс по ошибке будет возвращать не все элементы, то по оператору foreach увидеть это будет невозможно, а вот for с явным указанием границ будет в этом случае куда как нагляднее, ошибку можно будет увидеть сразу.