Ответ на »сообщение 1744« (Снегурочка)
___________________________

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

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

Для таких задач есть Си. Там нет избыточной сложности.

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

Для этого есть, например, Smalltalk или Eiffel.

У info21 оба этих пункта сочетаются. Кроме того - в первом пункте Си не катит. Профессионал из проблемной области, особенно такой сложной, как ядерная физика, не имеет возможности тратить дни на ловлю глюков с памятью, нарушением типизации и т.п. Тут нужна безопасная бритва с тройным лезвием, а не топор...
+ их задачи невозможно решать эффективно без ООП и модульности.
Smalltalk не покатит по эффективности. Eiffel не покатит по требованию (1) - сложноват, насыщен возможностями, полезными для ИТ, но бесполезными в данном случае.

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

Да, Оберон - это простой язык, который позволяет решать сложные задачи.

Позволю себе уточнить:

Прилагательное "простой" тут крайне misleading: я предпочитаю "чистоту" как отсутствие грязи, энтропии и т.п.

(И скромно признаюсь, что "Purity" в заглавии доклада Гуткнехта на Дне Оберона в ЦЕРНе возникло по моему настоянию вместо Simplicity; "The Power of Simplicity" -- это на самом деле название достаточно известного не то худ. фильма, не то книги, и Гуткнехт хотел сыграть на этой аллюзии, тем более что в ETH давно и привычно говорят про simplicity; поскольку в ЦЕРНе я нес колоссальный репутационный риск при организации этого дня, то голову ломал над каждым словом в программе; в этом плане поговорка "простота хуже воровства" меня давно беспокоила.)

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

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

Для таких задач есть Си. Там нет избыточной сложности.

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

Для этого есть, например, Smalltalk или Eiffel.

Коллеги!

А кто использовал GP CP?
Вопрос в следующем: имеем уже два места из которых поступает компилятор CP. Язык - понятно, австралийцы приводят OM-описание, значит, вроде как клянутся блюсти... А насколько "обвеска" разнится?

Ответ на »сообщение 1701« (Снегурочка)
___________________________

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


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

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

Впрочем, все это хоть и медленно, но явственно уходит в прошлое, слава Богу.

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

Попробую резюмировать Ваши аргументы в пользу тезиса "Модульный подход к программированию плохо совместим с ООП":

1. Синтаксис (Зачем писать в ООП стиле на языке, который своим синтаксисом демонстрирует неуважение к ООП?)
2. Динамическая загрузка-выгрузка модулей (Либо ООП, либо динамические модули.)

Честно говоря, больше не нашел. Первое возражение относится к языку. Второе - к одному из подходов к реализации (Oberon System, BlackBox).

1. Что касается синтаксиса Оберона (равно, как и КП), то там действительно нет явного использования слова class. Оберон - это ассемблер ООП. То, что ООП "имитируется"/реализуется средствами расширяющего программирования (с type extension) на основе модулей (по Вирту) - принципиальный подход Вирта и краеугольный камень Оберонов.

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

2. Динамическая загрузка-выгрузка модулей накладывает отпечаток на специфику реализации классов в модулях. Но это совсем не обязательная особенность Оберон-технологии (Вы вольны запретить/не использовать загрузку-выгрузку, либо пользоваться Оберон-реализациями без данной специфики). Чем виноват-то сам модульный подход?

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

P.S. Если мы стараемся всесторонне анализировать плюсы и минусы языков, систем и технологий, имеющих отношение к Оберону, то стоило бы, на мой взгляд, меньше идти в сторону эмоционально-субъективного восприятия и побольше внимания уделять технической стороне дела.

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

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

Милый мой, я не обязан собирать ссылки индивидуально каждому несерьезному перцу. Несерьезному -- т.к. все ссылки и факты были даны много раз.


А как насчет многих моих вопросов, оставленных без ответа?

Простите, сколько Вам лет?

Ответ на »сообщение 1735« (Сергей Перовский)
___________________________
>>>Зачем писать в ООП стиле на языке, который своим синтаксисом демонстрирует неуважение к ООП?
Хм™. Кажется, ни один язык не демонстрирует своим синтаксисом неуважение к ООП в такой мере как Лисп.
Однако OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.- Alan Kay

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

Ответ на »сообщение 1729« (Снегурочка)
___________________________
> Но мне гораздо проще научить ООП при помощи языка, в котором понятие класс введено явно, чем объяснять отдельно идеологию и отдельно, как это реализовать при помощи рекордов и функций, зависимых от типа.


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

>>>Только сделана она не на обероне-1 и не на обероне-2 и даже не на >>>компонентном паскале, а на блэкбоксе (ББ).
:)
У меня уже нет сил это обсуждать. ББ - это среда, компонентный каркас. А язык программирования в ББ - это Component Pascal. Вы обсуждаете тему, не зная даже об этом?!
No comment :(