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

Ассемблер и Оберон
В принципе -- да, но ассемблер - не 3GL, потому его упоминать не стал.

Господа, смотрите сюда: 

»сообщение 4158« (ASU) «Oberon, в том виде, котором он есть сейчас хорошо реализует принципы структурного программирования, и потому его удобно использовать для написания подпрограмм и модулей. Но он нарушает системные принципы,  правильнее было бы сказать, что не запрещает нарушать системные принципы, не формирует культуру построения систем...
»сообщение 4237« (ASU) Рассмотрите бОльшие системы, там логика управления вынесена на отдельный уровень.
»сообщение 4209« (ASU) Но Оберон не соответствует требованиям ОТС и создавать на нем системы... проблематично...
»сообщение 4195« (ASU) Речь шла о ERP-системе.

То есть тезис очень простой: на Обероне проблематично создавать бОльшие системы, например, ERP.
Давайте вспомним, что такое ERP-система физически.
Предположим, что у нас транснациональная корпорация. Наверное, ее ERP-система будет насчитывать 10-ки тысяч компьютеров, соединенных гетерогенными сетями, территориально удаленных на тысячи километров, работающие по всему Земному шару в 24 часовых поясах. Легко ли такую систему написать на Обероне? Я не знаю.

Теперь самое главное! Какие ОС будут крутиться на тех десятках тысяч компьютеров? Скорее всего, это будет коктейль из Windows и Linux. И всё, что мы сможем написать – это отдельно взятый exe-шник, который при запуске будет крутиться в изолированном процессе ОС. И простое взаимодействие, выходящее за рамки этого процесса нивелирует все бонусы, которые предоставляет тот или иной язык программирования. Будь-то Оберон с модулями, C++ с шаблонами, ASM и Nemerle с макросами, или Enlarg c функциональностью и потоками…

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

Вообщем, если что и обсуждать, так это не способ построения и реализации Систем на отдельно взятом языке, а способ и удобство создания отдельно взятого exe-шника на том или ином языке для конкретного класса задач. А построение распределенных программных (а вообщем случае – инженерных) систем, – тема действительно выходящая за приделы отдельно взятого языка.

Ответ на »сообщение 4312« (Илья Ермаков)
___________________________

Нет, Франц в Sun вроде не работает - или уже работает? :-) Он вроде бы занимается независимыми исследованиями по Ява-технологиям на базе какого-то американского университета.

Возможно, про это я из тем по Оберону почерпнул. Видимо напутал. Но ведь по Яве исследования-то!;)

Если и подниметесь, то абсолютно никакого преимущества не получите - это все равно, что автоматический декомпилятор с ассемблера в ЯВУ - высокоуровневой программы-то все равно не получите...

В данном случае преимуществ не надо. Надо чтобы уже написанное работало с новой виртуальной машиной и компилятором. Желательно, работало не хуже, чем раньше.
Хотя зачем вообще конвертировать? Пусть старый p-код выполняет старая машина. А деревья Франца - новая. Версии .NET вон как отличаются и ничего. Это я к тому, что обратная совместимость не является причиной неиспользования Сановцами деревьев Франца. Интересно почему тогда не используют?

А вообще, это детали.
Вопрос был - не вызовет ли переход на JIT замедления.
А почему он должен вызвать? Из-за отложенной кодогенерации?
Ну так в большинстве "продвинутых" архитектур натив-компиляторов (GCC, инструментарий Excelsior и т.п.) фронт-енд и бэк-енд разделены промежуточным представлением - и это ничего кроме положительных эффектов не дает...

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

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

Ответ на »сообщение 4309« (Илья Ермаков)
___________________________
Я знаю что такое синтаксические деревья Франца, а также то, что сам Франц работает в Sun.
Удивительно, что при всех возможностях, эти деревья не используются в Java. Значит есть причина. Интересно какая?
Обратная совместимость врядли тут играет роль, т.к. преобразовать p-код в дерево Франца можно.
А может уже используются?
Нет, Франц в Sun вроде не работает - или уже работает? :-) Он вроде бы занимается независимыми исследованиями по Ява-технологиям на базе какого-то американского университета.
А p-код в дерево Франца преобразовать нельзя - сами подумайте: основная идея деревьев Франца - сохранение высокоуровневой семантической информации. Как Вы из низкоуровневого представления подниметесь к более высокому уровню? Если и подниметесь, то абсолютно никакого преимущества не получите - это все равно, что автоматический декомпилятор с ассемблера в ЯВУ - высокоуровневой программы-то все равно не получите...

Ответ на »сообщение 4309« (Илья Ермаков)
___________________________

Франц в 1993 г. в диссертации "Динамическая кодогенерация - ключ к переносимому ПО" предложил промежуточное представление в виде очень компактного синт. дерева, которое позволяет Just-In-Time-кодогенератору сгенерировать максимально эффективный код для целевой платформы. Это уже много раз обсуждалось, сами можете посмотреть все материалы - Руслан ссылки даст...

Я знаю что такое синтаксические деревья Франца, а также то, что сам Франц работает в Sun.
Удивительно, что при всех возможностях, эти деревья не используются в Java. Значит есть причина. Интересно какая?
Обратная совместимость врядли тут играет роль, т.к. преобразовать p-код в дерево Франца можно.
А может уже используются?

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


Язык Оберон -- универсальный язык программирования (3GL). Ненужность импорта обосновывается несоответствием принципам "системности" по ASU. При этом утверждается, что 3GL не важен для методологии и воплощения архитектуры (т.е. Бейсик и Оберон -- все едино).


Ассемблер и Оберон

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

Ответ на »сообщение 4275« (Илья Ермаков)
___________________________
Это как Java чтоли? Дык она производительностью не блещет, хоть и оптимизировали они компилятор по самое нехочу. В смысле денег много в это вложили.
IMHO одно из достоинств Оберона в том, что он компилируется в нативный код. И теоретически (при наличии хороших компиляторов) можно получить высокое быстродействие.

Нет, это не "как Ява". В Яве изначально использовался интерпретор примитивного, древнего как мир, P-кода для стековой машины (предложенного Виртом в 70-х для переносимости Паскаля). Хотя позднее в Яву ввели предкомпиляцию байт-кода в нативный код, все равно это не дает приемлемой эффективности, т.к. байт-код ориентирован на стековую машину и не может быть эффективно оптимизирован под регистровые CISC-процессоры.
Франц в 1993 г. в диссертации "Динамическая кодогенерация - ключ к переносимому ПО" предложил промежуточное представление в виде очень компактного синт. дерева, которое позволяет Just-In-Time-кодогенератору сгенерировать максимально эффективный код для целевой платформы. Это уже много раз обсуждалось, сами можете посмотреть все материалы - Руслан ссылки даст...

В свете дискуссии видятся два тезиса:
1. Механизм экспорта-импорта нужен языку Оберон
2. Механизм экспорта-импорта не нужен языку Оберон

Если тезис (1) сомнению не подвергается -- нечего обсуждать. Если подвергается, переходим к его отрицанию -- тезису (2).

Язык Оберон -- универсальный язык программирования (3GL). Ненужность импорта обосновывается несоответствием принципам "системности" по ASU. При этом утверждается, что 3GL не важен для методологии и воплощения архитектуры (т.е. Бейсик и Оберон -- все едино). Если едино -- что обсуждаем? Какая тогда разница, есть в языке импорт или нет, если все решают наверху архитекторы и проектировщики? Может, он вдруг помешал этим самым архитекторам? Чем же, позвольте полюбопытствовать? У них чего-то не отображается на него?

»сообщение 4074« [ASU]
Посмотрите мои сообщения, с самого начала говорилось о том, что система должна конструироваться (собираться). Но это иной процесс, отличный от программирования и не разумно его выполнять из 3GL, нужен специализированный инструмент. Но не менее неразумно развивать 3GL в направлении конструирования систем... ничего хорошо из не может получиться.

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

»сообщение 4149« [ASU]
На Обероне легче писать отдельные модули, и те плюсы, о которых здесь было сказано очень много (ясный синтаксис, контроль типов и пр.) способствуют этому. Но в Обероне царит анархия, когда надо установить межмодульные связи. Каждый делает то, что счел нужным и то, как счел нужным... Никаких правил, никакого контроля (кроме проверки соответствия типов формальных и фактических параметров), никакой логики (концепции)... впрочем, как и в других 3GL.

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

Систему можно строить как снизу (формируя элементы/слои и связи-разъемы), так и сверху (танцуя от общей архитектуры и опускаясь вниз по уровням абстракции системы -- детализируя и конкретизируя). Определяется условиями проекта и характером работы. Использование методологии -- как правило, разработка сверху вниз. Там предыдущий этап задает рамки последующему. Но для такого подхода анархия импорта -- абсурд. Ведь рамки уже заданы спецификациями, и программист не имеет права на самодеятельность (он работает под контролем "начальника участка"). А вот для построения снизу вверх нужны ограничители, иначе программист много чего может наворотить. Импорт интерфейсов в модульном подходе Оберона -- ровно такой ограничитель. Именно он и задает надежность на уровне языка программирования.

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

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

То есть, если написан модуль А, который экспортирует интерфейс «альфа» и написан модуль Б, который импортирует интерфейс «альфа», то Вы считаете их модулями разных уровней иерархии?.. Хорошо... я не против, но эта иерархия не имеет ничего общего с иерархией уровней системы. Я попробую пояснить на другом примере. Если в базе данных таблица А ссылается на таблицу Б, то это не означает, что одна из таблиц «выше», а другая «ниже». Это просто связи на одном уровне... и все..

Кто же спорит?
И когда один элемент списка "ссылается" (через указатель) на другой элемент этого же списка, это тоже не говорит о разнице уровней.
А вот если один модуль определяет некий АТД, а другой им пользуется, то почему же это не иерархия?
Просто "иерархии" бывают разные.
Например: целое и часть, начальник и подчиненный...
Надо только уточнять, о какой иерархии идет речь.