Просто для информации. В mailing list Bluebottle (не путайте с Blackbox) время от времени идут жалобы на нестабильность системы. Вчера прошло сообщение о нестабильности в "Heap and CG". Ответ разработчиков цитирую "current state
as intolerable. Analysing the problem and finding a solution has a high priority in the next few months."
В общем, как я понимаю, ошибки в ядре и если их исправление потребует нескольких месяцев, то рассматривать Bluebottle как продукт плка рановато.

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

Переменная может иметь нюансы своей трактовки в разных языках программирования. Но вы не только привели разные языки, но еще и языки с разными парадигмами.
Я не вполнне понимаю, что такое "языки с разными парадигмами". Но возьмем два языка, которые Вы относите к одной парадигме: Modula-2 и Clu.
В одном a[i] – переменная, в другом –нет.

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

Почему бы, точно так же, не дать определения модуля и класса (не претендуя на всеобщность)?

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

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

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

Ответ на »сообщение 4002« (info21)
___________________________
Речь идет не об архитектуре языка, а об архитектуре системы. Я отметил, что архитектура Blackbox-а (фреймворка, среды разработки и исполнения) скопирована с архитектуры системы Oberon V2. Подтверждений этому множество - например, настройка с помощью модуля Config, структура загрузчика, схема каталогов, импорт текстов V2/V4 а не S3  и так далее. Что же касается примеров плохих решений принятых там где нельзя было использовать опыт V2 - их тоже много. Один из примеров - введение имени подсистемы в оператор MODULE, то есть сходный модуль Cmds подсистемы Forms в операторе MODULE имеет имя FormsCmds, то есть внешнее имя модуля не совпадает с внутренним. Еще один пример плохого проектирования Blackbox, это сохранение собственного формата исходных модулей и документации, что непозволяет пользоваться стандартными средствами разработки имеющимися в host-системе, например средствами контроля версий. Список можно продолжать достаточно долго.

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

Например, число Фибоначчи есть сумма двух предыдущих чисел Фибоначчи... Согласен, что круга в определении быть не должно.Но вот рекурсия, имхо, вполне может быть.

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

Предположим, что я не знаю, что такое числа Фибоначчи, и пользуюсь подобным определением.
Начинаем с 1: какие были два предыдущих числа Фибоначчи? В определении этого нет, и потому оно не работает. И почему еще надо начинать с 1? Это ниоткуда не вытекает.

Вывод: при задании рекурсивного определения надо следить, чтобы не произошло "зацикливание" или не получилась неопределенность.

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

С моей точки зрения, это не определение понятию "модуль", а уточнение его назначения. Если в определении термина приводится сам термин, такие определения весьма сомнительны, хотя готов согласиться, что теоретически они могут применяться при соблюдении целого ряда условий.

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

Что означает слово "тавтология" в русском языке?

1. Повторение одних и тех же или близких по значению слов без уточнения или изменения смысла.
2. Логическая ошибка в определении понятия, состоящая в том, что определяемый предмет определяется через самого себя (в логике).

Думаю, здесь возражений не будет.

Ответ на »сообщение 3974« (Руслан Богатырев)
___________________________
Переменная может иметь нюансы своей трактовки в разных языках программирования. Но вы не только привели разные языки, но еще и языки с разными парадигмами.
Я не вполнне понимаю, что такое "языки с разными парадигмами". Но возьмем два языка, которые Вы относите к одной парадигме: Modula-2 и Clu.
В одном a[i] – переменная, в другом –нет.

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

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

Кстати, на счёт датировки начала массового признания и применения ООП.
Согласен с Русланом Богатырёвым. Это – середина 90-х.
На мой взгляд это вызвано было как раз не изменением мышления программистской массы и её подходов к РЕШЕНИЯМ задач, а было вынужденной мерой. Просто без элементарных знаний ООП люди не смогли бы более-менее использовать... графические библиотеки и оболочки, хлынувшие на рынок в тот момент.
Уже давно подмечено, что преимущества ООП наиболее ярко и наглядно проявились именно при построении графического интерфейса пользователя. Я в то время успел попользоваться: ZINC, TurboVision, SuperVision, ObjectVision... Потом Дельфи пришла. А ведь есть ещё целый мир Иксов... И в каждом из них в 99% необходимо применение языка, поддерживающего ООП. Тут просто "шаблонами" кода не обойдёшься. Эффективное использование всякого фреймвока предполагает знания принципов его построения.
Кстати, оттуда же из "всеобщности" "наглядной агитации" с применением иллюстративного и примерного материала из графических приложений тянутся и многие стереотипы спорящих на счёт ООП. Опять-таки большая часть людей "танцует" от возможностей и идеологии средств реализации, а не от задач, подгоняя под привычные рамки видимое и слышимое...

Ответ на »сообщение 4003« (info21)
___________________________
Да я уже успокоился, после 3000 :)

По поводу отделения наследования и полиморфизма и т.п. Есть в рассуждениях ASU некое смешивание понятий:

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

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

(Щас кто-нить пристанет, что значит "намного". Заранее посылаю...)

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

Подобному смешению способствуют примеры и рассуждения с геометрическими объектами (в том числе у ASU), которые (рассуждения) не слишком поясняют, зачем, собственно, нужно наследование.

Убедительнее примеры более технические, подчеркивающие общность проблемы и решения. Например, для класса задач нужно реализовать манипуляции с какими-нить списками. Но хочется отделить общую "технологию связи" от конкретного содержимого, специфичного для конкретной задачи. Как только наблюдено, что "технология связи", работающая с одним полем next, абсолютно нечувствительна к наличию и комплектации остальных полей (конкретных данных) -- все остальное ООП детерминировано (абстрактный базовый тип Link с одним полем next: Link, и конкретные его расширения с дополнительными полями, а равно и необходимость подставлять расширенные потомки в качестве значений параметров, описанных как абстрактный Link.

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

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

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

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

Ответ на »сообщение 4001« (Иван Горячев)
___________________________

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


Что, Иван Николаевич, опередил коварный AVC? :-)
Ничего, такими темпами "словогенерации" уж и до пяти тысяч недолго... 8))

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

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

В Blackbox была один в один имитирована архитектура Oberon V2...


Раз уж Вы сравнивали:

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