Ответ на »сообщение 3737« (Владимир Лось)
___________________________

Ответ на »сообщение 3734« (info21)
___________________________
компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...)
А представим себе CPU, прямо интерпретирующую Оберон. Что тогда? Шифровать?
Представить себе "CPU, прямо интерпретирующую Оберон" не могу ... Не понимаю, что у ваз вызвало затруднение?

Но это же у Вас затруднения :-)

В чем смысл требования бинарности?
Экономия времени при загрузке? С Обероном, в общем-то, мизер.
Остается защита от дурака?

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

Я никак не могу понять, чем неудобна Java. Объясните, пожалуйста.

Давно объяснено:
http://www.uclic.ucl.ac.uk/harold/srf/javaspae.html

Уважаемые коллеги!

Я снова исчезну на неопределённо-продолжительное время. Скорее всего, до того неопределённое, что, всех, - заранее, - с Новым Годом! ;о) Желаю в новом году крепкого здоровья, новых интересных проектов и всяческих успехов в работе!
Благодарю единомышленников за помощь, солидарность и советы, а оппонентов - за стимулирование в развитии и открытие новых горизонтов!
Надеюсь снова встретиться со всеми вами в 2006 году в форуме славного Королевства, чей корабль плывёт сквозь время, ведомый нашей Многоуважаемой Королевой!

Ответ на »сообщение 3737« (Владимир Лось)
___________________________

Ответ на »сообщение 3734« (info21)
___________________________
компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...)
А представим себе CPU, прямо интерпретирующую Оберон. Что тогда? Шифровать?
Представить себе "CPU, прямо интерпретирующую Оберон" не могу. Могу представить "CPU, с системой команд, поддерживающей Оберон", благо есть опыт в виде "CPU, с системой команд, поддерживающей Модула-2" в виде "Кроноса"...
Не понимаю, что у ваз вызвало затруднение? Ну да, будет двоичны йфайл загружаемого модуля определённого формата, из которого можно будет извлечь как сегменты кода(данных и др.) так и запакованную мета-информацию... В чём проблема?
Продолжу мысль.
А представить себе, (info21), CPU с поддержкой аппаратного исполнения байткода, например - модуля Jazelle в современных процессорах архитектуры ARM9T не судьба? ;)
Напрасно. Например, Java на нём ускоряется очень сильно (см. тест Nokia 6630 на jbechmark.com по сравнению с другими).

Ответ на »сообщение 3734« (info21)
___________________________
компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...)
А представим себе CPU, прямо интерпретирующую Оберон. Что тогда? Шифровать?
Представить себе "CPU, прямо интерпретирующую Оберон" не могу. Могу представить "CPU, с системой команд, поддерживающей Оберон", благо есть опыт в виде "CPU, с системой команд, поддерживающей Модула-2" в виде "Кроноса"...
Не понимаю, что у ваз вызвало затруднение? Ну да, будет двоичны йфайл загружаемого модуля определённого формата, из которого можно будет извлечь как сегменты кода(данных и др.) так и запакованную мета-информацию... В чём проблема?

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

Я формулировал тезис о том, что ООП обладает дополнительными "степенями свободы" по отношению к модульному программированию -- наследованием и полиморфизмом. Эта дополнительная гибкость при прочих равных условиях является дополнительным источником ошибок.

Локализация эффекта воздействия изменений в ОО-системе сложнее, чем в МП-системе (МП -- модульное программирование), из-за врожденного в у ООП делегирования функций обработки сообщений (пресловутого ОО-контекста). Это приводит к потере контроля над системой (ее сложностью).

ООП -- парадигма, доказавшая свою полезность и практичность, но я против ее диктатуры.
Модульное программирование тоже имеет контекст выполнения. Этот контекст определяется интерфейсом взаимодействующих модулей и стуктурами данных, которые передаются из вызывающего кода вызываемому.
Так в чём отличие контекста исполнения модульной программы от ООП-программы? А в том, что структуры передаваемых данных в ООП-программе могут быть активными, прямо влияющими на любые контексты выполнения во всей программы, а не только на контекст двух взаимодействующих модулей!

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

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

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

Ответ на »сообщение 3732« (Руслан Богатырев)
___________________________
Хороший язык программирования должен быть:
а) структурным;
б) модульным;
в) объектным;
Желательно, чтобы все эти свойства были реализованы грамотно и удобно.
К сожалению, авторы разных языков при интерпретации всех свойств могут опираться только на свой опыт и делают языки, удобные для решения привычных для них задач. Человек, решающий другие задачи чертыхается или берется писать собственный язык.

Я никак не могу понять, чем неудобна Java. Объясните, пожалуйста.

Ответ на »сообщение 3715« (Владимир Лось)
___________________________

компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...)

А представим себе CPU, прямо интерпретирующую Оберон. Что тогда? Шифровать?

Ответ на »сообщение 3732« (Руслан Богатырев)
___________________________
Хороший язык программирования должен быть:
а) структурным;
б) модульным;
в) объектным;
Желательно, чтобы все эти свойства были реализованы грамотно и удобно.
К сожалению, авторы разных языков при интерпретации всех свойств могут опираться только на свой опыт и делают языки, удобные для решения привычных для них задач. Человек, решающий другие задачи чертыхается или берется писать собственный язык.

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

Выберите время и почитайте про модульное программирование. А еще лучше -- изучите каноническую Modula-2. Глядишь, польза будет.

Хотя, что я все про Modula-2? Возьмите чистый как рафинад Оберон, отрежьте у него расширение типа (можете мысленно), т.е. лишите его возможности реализовывать ООП. Вот вам чистый язык модульного программирования.

Да, забыл, есть же Oberon-SA -- подмножество Оберона для Strong ARM. Если не ошибаюсь, там вообще нет расширения типа, запрещен экспорт-импорт переменных, нет половины операторов ветвления и цикла (только IF, WHILE и REPEAT), всего четыре базовых типа CHAR, BOOLEAN, INTEGER, REAL.

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