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

...
А мне пришлось отказаться от вариантного типа, т.к. он позволяет оперировать только стандартными типами данных и сделать объектные обертки над различными типами данных - это позволяет свободно расширять список типов данных не изменяя механизм хранения и обмена. Без наследования с такой задачей не справиться.

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

Ответ на »сообщение 4734« (Axcel)
___________________________
>>>При этом никаких специфических показаний для подобной схемы у нас нет, просто так удобнее, надежнее.
Показания очевидные: простота сведения взаимодействия модулей к обмену простыми данными или тектовыми файлами.
А мне пришлось отказаться от вариантного типа, т.к. он позволяет оперировать только стандартными типами данных и сделать объектные обертки над различными типами данных - это позволяет свободно расширять список типов данных не изменяя механизм хранения и обмена. Без наследования с такой задачей не справиться.

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

Ответ на »сообщение 4730« (MS)
Кроме задач коллективной разработки операционных систем я так и не нашел применения раздельной загрузке. А потеря возможности обмениваться объектами с применением наследования, это, по моему, большой минус.


Я как-то уже приводил пример из своего опыта работы в Delphi. Повторюсь еще раз.
Как-то мы на скорую руку "слепили" приложение из отдельных exe - х, по "рабочее - крестьянски", через WinExec. Через некоторое время мы "вдруг" заметили, что такое наше "архитектурное" решение наиболее устойчиво (по сравнения с dll или монолитом),  очень удобно в плане модификаций, так что теперь мы уже совершенно осознано пользуемся этим приемом. При этом никаких специфических показаний для подобной схемы у нас нет, просто так удобнее, надежнее. Но ведь это же и есть истинная модульность. Просто в Обероне она поддерживается на уровне языка, а в Delphi приходится слегка изощрятся. 

Ответ на »сообщение 4730« (MS)
___________________________
>>>Единственно что, неприветствуется (но и НЕзапрещается) межмодульное наследование, что, в общемто, вполне логично - если у Вас взаимодействуют несколько программ, Вы же их стараетесь сделать максимально не зависимыми.

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

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

Никакого противоречия между модульным подходом и объектным не существует. Вообще это не подходы, а просто две разные стороны. Можно сказать, ортогональные. Модули позволяют разделить и изолировать куски программ, что очень и очень полезно.

Проблему Вы, Сергей, просто выдумали. Если у Вас логически простая задача -- ну, напишите ее в одном модуле и возитесь с ним. Кто мешает?
А я предпочту разбить на несколько -- опыт показывает, что так жить проще и удобнее.

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

У меня все больше подозрение, что Оберон - идеальный инструмент для "попрограммирования" :)
Это не в укор, а только для очерчивания границ применимости.


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

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

Оформляем исследуемую эвристику в виде модуля или объекта.
Это не сопоставимые (в рамках Оберона) вещи. Т.к. в Оберонах модуль является единицей компиляции (и, соответственно, есть соответствие модуль-файл), то Вашу посылку можно представить в виде "Оформляем исследуемую эвристику в виде ФАЙЛА или объекта."
Модульный подход не протвостоит ООП. Модуль, фактически, является некой законченной программой, в которой могут быть и объекты и процедуры и т.д. и т.п.
Единственно что, неприветствуется (но и НЕзапрещается) межмодульное наследование, что, в общемто, вполне логично - если у Вас взаимодействуют несколько программ, Вы же их стараетесь сделать максимально не зависимыми.
Предложенная Вами схема, при модульном подходе, может выглядить следующим образом - 1) модуль ввода-вывода ("лабораторный стенд") 2) модуль(и) реализации модели (он(и) и являются объектом исследования).
В часть 2 Вы можете вставлять свои веками наработанные модели.
Как удобнее делать разбиение на модули в Вашем случае мне сказать трудно, но по идее выделяете в отдельный модуль наиболее изменяемую часть модели и меняете этот модуль в зависимости от задачи. А уж как Вы реализуете свою модель внутри модуля - Ваше личное дело - можете с ООП, можете без ...

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

Ответ на »сообщение 4725« (Как слышно? Приём!)
___________________________
>>>Когда ясно как решать задачу - это школьный учебник.
Когда трем людям в мире ясно как решать задачу - это не школьный учебник :)
>>>Термин "случайное программирование" - передёргивание.
info21 предложил более удачный:
>>>пописал программу, вернулся к формулам, их пописал, потом снова попрограммировал, и т.д.
У меня все больше подозрение, что Оберон - идеальный инструмент для "попрограммирования" :)
Это не в укор, а только для очерчивания границ применимости.

Ответ на »сообщение 4726« (info21)
___________________________
Еще насчет раздвигания границ.
Есть замечательный пример в чистой математике, где подобная эволюция идет уже 100+ лет, и еще не закончилась.

Есть такая аксиома выбора в теории множеств. Формулировка естественная (=б.-м. первая попавшаяся). Но приводит ко всяким патологическим примерам. Когда поняли, что все ее патологические следствия неконструктивны, придумали ей замену -- аксиому детерминированности (Мычельски-Штейнгауз, 1964). Вещь замечательная ("любая функция измерима" и т.п.). Но до сих пор даже профессиональные математики в подавляющем большинстве о ней не знают (у меня даже был раз случай, когда аудитория осерчала; впрочем, это были не настоящие математики, а "математические физики"), хотя есть даже популярные для математиков-неспециалистов брошюрки (В.Кановей, Москва, 1984).

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