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

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

Ok. Беру понятие: переменная (variable) в языке программирования.

Понятная сущность. Чем она перегружена?

Ответ на »сообщение 3968« (Как слышно? Прием!)
___________________________
>>>>С терминами надо бы поаккуратнее. (Trurl)

>>>В смысле до последнего не давать чёткого определения?

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

Ужос! Как много буков!

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

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

>Как вы понимаете, это нельзя считать полезным определением модуля,
>ибо оно, как минимум, рекурсивное.

Теперь знаю, как Вас на экзамене можно завалить :) Рекурсию не любите?
А ведь очень эффективный приём. И в Алголе (прадедушке Оберона) появился.
Так что ругать за рекурсию - это святотатство на этой ветке.
Конечно, "Модуль ...это программная единица ... предназначенная" и т.д.,
Братцы, я понимаю, что умолчания это для Бэйсика, но не надо фанатизьма.
Подсократил. Признаю слишком. Но оттого и спор, что
0) модулю надо было дать расширенное определение;
1) определение существует;
2) споры пусты без терминологических определений.
Вот Вы специфически определяете "поддержка раздельной компиляции - особенность МП"
от чего выпадет в космос немало модулей.

А можно более другое определение модуля и объекта?
Помнится Вы упоминали 5 или 7 мнений с указанием фамилий,
но в чём они или в чём сухой остаток не указали (или я пропустил?).

>С терминами надо бы поаккуратнее. (Trurl)

В смысле до последнего не давать чёткого определения?
Это как в маркетинге - "Кто первым называет цену, тот проигрывает".

>Вот почему я предпочитаю просто рассуждать.
>Даже если это ровным счетом никому и не надо.

Надо-надо.
Меня вообще поражает и вызывает зависть Ваша способность
(не только по форуму, но и по Oberon2005 и по журналу МИР ПК)
генерировать и упорядочивать такие объёмы информации.
Приятно, когда такие люди в стране волшебной есть :)

Нет ли у Вас рассуждений на тему "почему древовидная топология
так вездесуща в программировании?" С В.Лосем вроде только
начали обсуждать, а он "до свиданья, с новым годом!" Вопрос не
перескок - с ним связан другой аспект объектов - наследование.
И вот тут как раз кривизна объектов, по моему, и преимущества модулей.

насчёт классов подумаю...

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

посмотреть публикации на http://www.alexus.ru/russian/articles.htm

Круто! Жалко только что Вы эту ссылку раньше не дали. Теперь можно подумать как ответить на Ваш вопрос: "Как на Обероне писать сложные системы?".

Ответ на »сообщение 3963« (Как слышно? Прием!)
___________________________

Продолжая сравнение модуля и объекта и аналогию с тортом. Торт - это данные. Модуль - хозяйка с тортом. Объект - официантка с тортом.

С объектом я понял. А класс? Это ресторан? Или ускоренные курсы подготовки официанток?

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

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

Результатом служит тот же пример с тортом. Как только мы начинаем оперировать привычными словами, нам уже трудно отсечь от них "прилипшие" к ним свойства в реальном мире. Нам нужно абстрагироваться, строить абстрактные слои и проводить отображение, а мы воюем с перегрузкой смысла. Вот так термины превращаются в просто слова.

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

Теперь о модулях и классах.

Как мы видели (и это показал тот же Оберон), модуль может быть трансформирован в класс, если несет в себе такую сущность, как расширяемый тип данных. Класс (как я подозреваю), совмещающий в себе свойства модуля и типа, вполне способен трансформироваться в модуль.

Возьмите язык, построенный на классах, ту же Java. Можно ли провести такую трансформацию (класса в модуль)? А вы попробуйте (сразу скажу, конечно, можно).

Требуется ли классам выступать в роли модулей? Вопрос. Думаю, да. Какое мнение у вас?

Ответ на »сообщение 3954« (info21)
___________________________
Наверное Куно Пфистер не идиот, но архитектор программного обеспечения он плохой. В Blackbox была один в один имитирована архитектура Oberon V2, а там где надо было придумать свое - принимались сиюминутные решения. Примеры - связь имен модулей и подсистем, структура каталогов и так далее.

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

Об инструментальном подходе при построении больших систем можно посмотреть публикации на http://www.alexus.ru/russian/articles.htm

Ну вот, Александр Сергеевич, теперь мне более-менее понятна природа того "апломба", с которым были сделаны ваши экспресс-комментарии.

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

Модульное программирование, эпоха которого заняла без малого 15-20 лет (от 1970-х до 1990-х годов), попросту отрезана. Я понимаю, что цель публикаций была иная -- показать прелесть и мощь объектной технологии, разобрать ее основные моменты.

Что мне не удалось найти (видимо был невнимателен) -- анализ недостатков объектного подхода, ту цену, которую приходится за него платить, границы его применимости, те задачи, на которых применять микроскоп для заколачивания гвоздей вряд ли целесообразно.

Вот ведь какая штука: развитие объектного подхода (как подхода к проектированию систем) началось, по моим наблюдениям, в середине 1990-х годов. До начала 1980-х годов о самом ООП, из которого подход и вышел, вообще даже не говорили.

После раскрутки Smalltalk-80 вышли первые языки -- Object Pascal и Objective C. Но до появления компиляторов C++ на ПК (1992-1993 гг.) можно было говорить разве что о скромных экспериментах со средой Smalltalk. Экспериментах преимущественно в сфере образования, но не в индустрии.

Итак, ООП "вышло в люди" в начале-середине 1990-х годов. Что массовая аудитория знала в диапазоне 1970-1990? Фортран, Си, Паскаль, Бейсик.

А что было в эти "темные средние века", в период, длиной 20 лет? Какие-то языки модульного программирования? Да кому они нужны, кто их знал? Какие-то там Mesa, CLU, Alphard, Modula-2, Ada? UCSD Pascal, Turbo Pascal -- ну их даже сторонники Компонентного Паскаля не признают за языки модульного программирования, куда уже катиться дальше?

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

Показательные стереотипы. Я понимаю, что многих они устраивают, с ними жить привычно. Их можно даже и не считать стереотипами.

Сразу скажу, я не являюсь апологетом модульного подхода. Он мне нравится, но я понимаю его недостатки. Я занимался этим вопросом с разными перерывами без малого 15 лет (благо в период Советского Союза можно было полностью отдаваться исследованиям и не заботиться о том, как завтра поесть и как прокормить семью). Сейчас другие времена.

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

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

Я никоим образом не хочу посягать на чье-либо благополучие и тем паче бизнес. Ради Бога, нравится, получается, убеждены в правоте и безупречности -- замечательно.

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

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

Я не настолько наивен. Я вижу, в каких руинах лежат сейчас Обероны. Я понимаю воинствующие возгласы, требующие взять под козырек и в едином строю под барабанную дробь четким шагом под флагами Черного Короба отправиться на смертный бой с вражескими полчищами "недалекого" Бьерна.

Что делать? Старость не радость. К тому же, мне вообще непонятны такие войны. Пользы они не приносят, а вред способны нанести непоправимый.

Вот почему я предпочитаю просто рассуждать. Рассуждать вслух. Даже если это ровным счетом никому и не надо.

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

Ответ на »сообщение 3959« (Как слышно? Прием!)
___________________________
С терминами надо бы поаккуратнее.

Модуль предназначен для хранения, трансляции, объединения
с другими программными модулями.

Объектный модуль - программа с неразрешенными внешними ссылками.

Объект - модуль, объединяющий в себе данные и операции над ними,
обладающий свойствами наследования и полиморфизма.

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

Объектный объект - программа с неразрешенными внешними ссылками, объединяющая в себе данные и операции над ними, обладающая свойствами наследования и полиморфизма.
Ну и т.д.

Кстати, как в упомянутом  ГОСТ 19781-90 насчет определений наследования и полиморфизма?