Угу, ошибся.

Это не странности. Для англоязычного человека - это естественно.
Такое поведение следует из лексического значения этих слов.
пока верно делай то-то. Или делай до тех пор, пока не случится то-то.
Эти операторы цикла существовали до паскаля. Они просто были приняты. В басике действуют они же.

Оберон создавался, как теоретический язык.
Это мегаколлекция новых идей. Заслуги оберона огромны. Это всё современное программирование.
Java и дотнет - прямые потомки оберона. Правда пока что единственные. Но и этого более, чем достаточно.
Сам по себе оберон слишком абстрактный, чтобы быть практическим языком. Там заложен полный абсолют.
Джава и дотнет взяли от него по максимуму настолько, насколько возможно, не выходя за пределы практичности.
В дельфи ограничились ещё меньшим - сочли неуместным заводить свой пакет библиотек и виртуальную машину. Оставили такую возможность программеру - хочешь, ставь пакет, нет такой возможности - включай необходимое в ехешник.
Поэтому просто сели на хвост дотнету.
Хотя и в Win32 версии множество идей оберона присутствуют.

Ты имеешь в виду, что Вирт подгонял язык под ключевые слова которые у него были? Он не мог взять другие ключевые слова? 

Давайте проведем аналогию с реальным языком (в смысле не программирования). Если бы реальные языки были бы представлены C и Pascal-ем, на чем вам лучше было бы говорить? По мне так жесткое следование правилам и невозможность креативных действий - минус
Может аналогия и глупая, но все же

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

В чем нестыковка. В стандарте написаны критерии неопределенного поведения

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

Аналогия не глупая, а не корректная. ЕЯ допускает неоднозначность и незаконченность формулировок. Ты можешь совершенно спокойно сказать фразу: Ну как у тебя с этим делом?. Если из контекста человек не поймет о чем речь, то он тебя переспросит. Компилятор же не может переспрашивать программиста, что он имел в виду. И кстати возможен вариант, что человек поймет тебя неправильно и даст ответ на другой вопрос.

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


Чтобы "руки были целы".

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

имхо нет , все правильно ,
каждый язык должен воплотить какой либо алгоритм, и этот алгоритм можно будет и на Си реализовать и на Паскале, а небольшие отколнения друг от друга , имхо не столь существенно !
(много ты сможешь привести различий между си и паскалем?)

Опять же если вернуться к С, приведи пример не undefined behaviour, когда компилятор истолкует код не так, как его видел программист

Хорошо, допустим
Но, если приводить примеры, UNIX и все UNIX-like системы + подавляющее большинство программ для них написаны на С, M$ Windows написана на С/С++, огромное число прикладных приложений как под UNIX, так и под M$ написаны на С/С++ (и сейчас пишутся). Это дань традиции? Почему не Pascal/ObjectPascal? Ведь, если Pascal/ObjectPascal более строгий и типизированный, то программы меньше подвержены ошибкам, лучше сопровождаются, более понятны. Почему люди вообще не отказываются от языков типа С? C вашей цитатой, я думаю согласятся многие, но почему на практике все несколько иначе?

По каким критериям? (синтаксиc, ...)

Это сообщение отредактировал(а) MAKCim - 14.10.2006, 12:08

Так в том то и различие между ЕЯ и ЯП, что поведение программы строго регламентируется спецификацией. И за редким исключением undefined behaviour, поведение программы четко предсказуемо. Эта фраза относилась к тому, что проводить аналогии между ЕЯ и ЯП не корректно.



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

Фишка в том, что Pascal появился чуть ли не раньше С

Добавлено @ 12:53 

ОК

А ассемблер - ещё раньше...

Я все же считаю, что у каждого языка есть область применения, где его использование наиболее эффективно. Драйвера, например, хоть и можно писать на делфи, но малоэффективно, лучше на ассемблере или С. Математику можно писать на С++, но на фортране будет быстрее. Писать для Офиса можно тоже на чем угодно, но проще и быстрее на VB так как он туда просто встроен. Делать ГУИ можно и на Visual C++, но на делфи куда быстрее, удобнее, легче, нагляднее и проще. А для веба так вообще лучше JAVA не найти. 
Давайте жить дружно  и использовать те средства, которые хороши для ваших нужд, а не насиловать язык, пытаясь делать на нем горы кода, при том, что на другом языке все это укладывется в 10 строк.

При чем здесь ассемблер?

Так об этом и речь
Здесь некоторые доказывают, что чем меньше в языке неоднозначностей, чем он строже - тем меньше шанс сделать ошибку, тем он более понятный и правильный. В принципе да. Казалось бы, что может быть лучше для написания драйверов - все просто, четко и понятно. Почему тогда С, а не Pascal? 

Готов допустить, что в ETH изобрели компонентное программирование в современном понимании. Какие ещё концепции появились в Обероне впервые?

В данном случае не столько язык слаб, сколько компилятор, не предназначен. Нет ни среды ни отладчика. Потому эффективней использовать уже наработаные коды и докумнтацию. 

Граждане!
С проблемой множественного наследования в Delphi можно справиться с помощью интерфейсов. Но шаблоны-то все равно в Delphi не поддерживаются. ИМХО, очень большой минус. Даже если не разрабатывать свои, а использовать STL. А это - скорость разработки