Ответ на »сообщение 1305« (Alexey Veselovsky)
___________________________
А что мешает написать PROCEDURE proc1*(c: COLOR)?
Та же убогость. Но - не языка...

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

А что мешает написать PROCEDURE proc1*(c: COLOR)?

PS. Для того чтобы подписывать сообщения не нужно регистрации. Лично я - не зарегистрированый пользователь этого форума.

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


Тогда, следуя этой логике, Вам надо выбирать именно Обероны - проще них среди компилируемых языков я ничего не встречал.


Не надо под видом простоты подсовывать убогость. Где перечислимый тип? Я не хочу читать PROCEDURE proc1*(c: INTEGER) и гадать, что такое "c".

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

В общем подобные ляпы в статье могут допускать только недоучившиеся студенты.


А ты кто такой, что твоему определению модуля я должен доверять больше, чем статье в википедии?

>>>простые смертные программисты выбирают простоту чтения
Тогда, следуя этой логике, Вам надо выбирать именно Обероны - проще них среди компилируемых языков я ничего не встречал. А уж по реализации импорта-экспорта они чемпионы - даже никакого разделения на interface и implementation не требуется. На одной "звездочке" все сделано. Куда уж проще.

>>>А если в других языках есть похожие штуки, но не
>>>как в обероне, то это совсем не модули.

Кошка тоже очень похожа на тигра :)
Модуль - это контейнер для ресурсов программы, который является самостоятельной единицей компиляции, загрузки и выгрузки. Это, как минимум. Все остальное - это политика :)
И поменьше читайте всякую фигню в википедии. В статье, на которую Вы ссылаетесь, к модульным языкам отнесен Pascal, который никаких модулей никогда не поддерживал. Поэтому после него и появилась Modula. В общем подобные ляпы в статье могут допускать только недоучившиеся студенты.
Помните профессора Преображенского - не читайте по утрам всякую... Читайте более серьезные работы.
Удачи.

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

в Java построена целая вавилонская башня из private, public, protected, private protected.


Эта "башня" позволяет более четко отразить замысел программиста для читателя. Так же как и пресловутый перечислимый тип. Пока Вирт делает упор на простоту компилятора, простые смертные программисты выбирают простоту чтения.

Ответ на »сообщение 1297« (Сергей Губанов)
___________________________

Тут одно из двух. Либо Вы не знаете [питон/C#/Java] либо не знаете что такое модули. В указанных языках поддержка модулей отсутствует.

Да-да, модули это такие штуки... ну как в обероне. А если в других языках есть похожие штуки, но не как в обероне, то это совсем не модули.
http://en.wikipedia.org/wiki/Module_%28programming%29

>>>Не все так однозначно. Спецификаторы доступа и их
>>>отличия при обучении можно и опустить.
Очень даже однозначно.
Для решения проблем, которые в Оберонах решаются простым и ясным механизмом экспорта-импорта модулей и их ресурсов и которые требуют от программиста запонимания всего трех вещей: IMPORT, * и -, в Java построена целая вавилонская башня из private, public, protected, private protected. Ибо забыли они принцип Оккама, который гласит: не изобретай сущности без особой необходимости. Другими словами, не занимайся избыточным словотворчеством.
И что значит "при обучении"? При обучении программистов? А они спросят "а зачем тогда эти примочки, если есть языки, которые без них прекрасно обходятся?". Не боитесь, что после этого у Явы-C# рейтинг упадет? Шутка, конечно, деньги такие вложены, что не дадут упасть - подставят очередные подпорки.

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


>> Модульности в C-языках как не было, так и нет до сих пор.

> Я явно указал питон/C#/Java. О каких С-языках ты говоришь?


Тут одно из двух. Либо Вы не знаете [питон/C#/Java] либо не знаете что такое модули. В указанных языках поддержка модулей отсутствует.