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

Поскольку предполагалось, что при переносе UNIX на новую платформу достаточно написасать для нее транслятор с С, сам транслятор нужно было писать на ассемблере, а то и в кодах. И все правила языка выбирались исходя из принципа "все для разработчика транслятора".

Это не так. К облегчению транслятора концепции Си отношения не имели. Ритчи в 1993 г. довольно подробно изложил историю создания своего языка. Оригинал можно посмотреть здесь: http://www.europrog.ru/book/cddr1993e.pdf

Я понимаю Ваше предубеждение в отношении работ Вирта по Оберону, якобы он шел по пути облегчения работы/структуры компилятора. Боюсь, это серьезное заблуждение. Он в ряде случаев шел навстречу компилятору (с тем же DEFINITION). Но на общем балансе концепций языка это отразилось в незначительном объеме.

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

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

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

Если Вы говорите о подходах к программированию, заложенных в Оберон, то их по большому счету немного: модульное программирование и расширяющее программирование (читай, ООП на свой манер). Это парадигмы. То, о чем говорит ASU -- это методология. Как она отображается на парадигмы -- это отдельный разговор, до него речь даже не дошла. Как эти парадигмы отображаются на конкретные языки реализации с учетом требований методологии -- тоже осталось тайной за семью печатями. Т.е. против конкретного языка Оберон были выдвинуты какие-то претензии, что он-де не соответствует некоей методологии, для которой язык программирования не имеет значение. Вас тут ничего не смущает?

Если есть желание обсуждать методологию ASU в сопоставлении с модульным или расширяющим программированием в исполнении Оберона или КП -- давайте будем обсуждать. Нет возражений. Но тогда давайте уже по полной программе -- на каких парадигмах она реализована, на каких языках. Карты на стол.

К чему были эти странные полунамеки в отношении квалифицирующего импорта? Он-то каким сюда боком? Модульное программирование что с ним, что без него как было самим собой, так и остается. Если Вы сами поняли -- к чему, так поясните. Попробуем разобраться.

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

Может быть Вам жалко времени, объяснять нам, бестолковым, простые с Вашей точки зрения вещи, но тогда как Вы убедите различных чиновников от образования? С ними явно проще не будет :)

Я слишком плохо объясняю? Возможно. Но мне непонятно, когда по нескольку раз в одно предложение формулируется мысль, а потом постоянно всплывает недопонимание. Мысль-то несложная. Перечитываю то, что написал. Нет там двоякого толкования. Ну нет.

Что касается чиновников от образования, то у меня нет цели их в чем-то убеждать. Я не занимаюсь ни пропагандой Оберона, ни его продвижением в какой бы то ни было среде. Нет у меня такой цели. По крайней мере, в настоящее время. За что видимо и получаю тычки со стороны представителей Оберон-общественности. Продвигать Оберон здесь по меньшей мере неразумно. Здесь можно что-то обсуждать. По крайней мере, пытаться обсуждать.

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

Которому из интерфейсов? Я не могу дать модулю имя "А и В". Мне придется создать три модуля А, В и С из которых первые два будут в качестве реализации иметь обращение к С с разными параметрами.

Давайте тогда уточним в отношении A и B -- что совпадает, что отличается (интерфейсы, реализации)? Два одинаковых интерфейса с одинаковой реализацией (различие только на уровне имен) или два разных интерфейса с одинаковой реализацией?

Ответ на »сообщение 4044« (Руслан Богатырев)
___________________________
>>>Сопоставление языка программирования Оберон с методологиями некорректно.
Но ветка называется не "язык Оберон", а "Оберон-технология". Т.е. мы обсуждаем положенные в основу языка принципы и подходы к программированию. Почему же некорректно сравнивать их с другими методологиями?
Кстати, провел со студентами занятие по выбору языка программирования для конкретной разработки (в курсе "теория принятия решений"). Полный кошмар: вся группа смогла перечислить десяток языков программирования. Про Lisp вспомнили двое после напоминаний. Про Prolog никто не слышал. Понятие декларативных языков оказалось абсолютно новым. Впрочем Оберон тоже никто не назвал. Вот и выбирай язык :)
Когда объяснял, почему С получился таким простым, но так плохо подходящим для программирования, сформулировал очевидный принцип: С это язык с максимально упрощенным транслятором. Поскольку предполагалось, что при переносе UNIX на новую платформу достаточно написасать для нее транслятор с С, сам транслятор нужно было писать на ассемблере, а то и в кодах. И все правила языка выбирались исходя из принципа "все для разработчика транслятора".
Я это к чему? К тому, что синтаксический минимализм - мечта разработчика транслятора :)
С точки зрения пользователя это хорошо до определенного предела.

Ответ на »сообщение 4048« (AVC)
___________________________
>>>Вместе с тем, критика квалифицирующего импорта совершенно неубедительна.
>>>ASU так и не указал альтернативный способ разрешения конфликта имен.
А я указал :)
Нужно отделить имя интерфейса от имени модуля.
И явно описать импорт переменных и функций из заданного интерфейса.
Писать каждый раз, что функция синус должна быть взята из модуля математика, а ни в коем случае не из модуля тригонометрия, все таки большое занудство.

Ответ на »сообщение 4046« (Руслан Богатырев)
___________________________
>>>Почему в форум, где не идет торговля Оберонами, где обкатываются идеи до их воплощения (орг.деятельности, программных реализаций, публикаций), где разные элементы Оберонов и Оберон-технологий подвергаются критическому разбору специалистов в этой сфере, постоянно появляются желающие походя пнуть ногой язык, а заодно и тех, кто его изучает и использует.
Надеюсь это не на мой счет...
Я конечно не могу себя причислить к "специалистам в этой сфере", но кое-что в этом жанре умею.
Стараюсь никого лично не задевать и на эмоции не переходить.
Чего и Вам желаю :)
Может быть Вам жалко времени, объяснять нам, бестолковым, простые с Вашей точки зрения вещи, но тогда как Вы убедите различных чиновников от образования? С ними явно проще не будет :)

Ответ на »сообщение 4040« (Руслан Богатырев)
___________________________
>>>какие проблемы дать "подмене" имя, соответствующее интерфейсу?
Которому из интерфейсов? Я не могу дать модулю имя "А и В". Мне придется создать три модуля А, В и С из которых первые два будут в качестве реализации иметь обращение к С с разными параметрами. Можно и так. Но не слишком удобно.

IMHO, Слишком много эмоций с обеих сторон.
Уверен, что ASU не проводит по отношению к Оберону "враждебную политику". :)
Вместе с тем, критика квалифицирующего импорта совершенно неубедительна.
ASU так и не указал альтернативный способ разрешения конфликта имен.
А главная мысль (что квалифицирующий импорт несовместим со "слабыми" связями) просто ошибочна (IMHO). Механизм совмещения был изложен в этой ветке многократно.
Вообще, создается впечатление, что ASU критикует не такую частность, как квалифицирующий импорт, а модульный подход как таковой.
Если это предположение верно, то тогда так и надо говорить.

Ответ на »сообщение 4044« (Руслан Богатырев)
___________________________

Подходы к "системостроительству" не зависят от языка программирования.

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