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

Adding a new shape, an ellipse for example, simply means adding a module Ellipses to the system's library. No changes to the other modules are needed, in particular no recompilation. This implies that an extension is possible without requiring availability of the source text of the base.

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

Почему мы должны так опасливо относиться к перетрансляции? Чем интерфейсные соглашения периода компиляции хуже соглашений периода сборки и выполнения? Ведь не процессорное же время мы экономим?

Прекрасно понимаю, что ассоциативные конструкции в исходном тексте сейчас совсем не в ходу, и вряд ли кого-либо убедит, например, отсылка к Eclipse http://eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html . Так что в плане практических советов от моих рассуждений проку мало. Но тут очень точно высказались Декарт и Руслан Петрович, и с таких высот даже мое изобретательство, кажется, не выглядит совсем уж оторвавшимся от жизни и здравого смысла.

Ответ на »сообщение 2374« (S.A.)
___________________________

>>>В плане переосмысления путей дальнейшего
>>>распространения Оберона в России давайте тогда
>>>еще больше упростим задачу. Требуется
>>>определить целевые аудитории, где в лице
>>>Компонентного Паскаля (Оберона) не обязательно
>>>обеспечивается ПОЛНОЦЕННАЯ замена Delphi.

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

1) Первое. Это, конечно, сфера образования, прежде всего среднего. Здесь Оберонам на данный момент практически нет конкуренции. Чтобы там не говорили оппоненты, не будет нормальный человек запускать большую промышленную среду с десятками "рюшечек" для того, чтобы объяснить, что такое массив или оператор цикла. Это просто нерационально. По этой причине в школе до сих пор доминируют Turbo Pascal и QBasic(!). А Delphi и прочие появляются "на сцене" уже тогда, когда человек научился понимать разницу между while и repeat. Вот эта ниша между полным непониманием, что такое программирование, и готовностью работать в "насыщенной" промышленной среде пока совершенно свободна и Блэкбокс может занять это место (в общем у меня он уже это место занимает).

2) Вторая ниша. Думаю, что это задачи, где удельный вес и роль интерфейса минимальны, а роль алгоритма максимальна. Думаю, что к этим задачам можно отнести все "вычислительные" задачи ("числодробилки"), многие задачи дискретной математики. Для этих задач большинство "инструментов", которые так красиво смотрятся в Delphi и прочих студиях просто не нужны, они там, как Мерседес в спальне :). На соседней ветке (И-21) я привел пример алгоритма для решения задачи "Ханойские башни". Понимаю, конечно, что это опять пример на тему образования, но суть дела от этого не меняется: у меня есть задача, особые дельфийские "красивости" мне не нужны (только отвлекают), ввод-вывод может быть вообще потоковым (In->StdLog) - решение в Блэкбоксе выглядит абсолютно естественным.

3) Третья ниша. Здесь я не специалист, пусть меня поправят профи, но все-таки. Любые системы, где безопасность программирования стоит на 1 месте среди прочих плюсов языка. Что мы здесь имеем на данное время: Ada 95 и Модула 2. С Адой трудно тягаться - в ней параллельное программирование "зашито". Но Модулу, вроде бы, Обероны могут заменить в полном объеме.

4) Четвертое. "Непрофессиональное программирование" (название, конечно, условное).
О чем речь? Ну, конечно, не о тех пользователях, которые вообще не могут программировать, кроме как в Word'e :). О тех, которые могут, но которым не нужно делать промышленный проект. А нужно, что-то вроде моих ханойских башен: быстрый ввод, быстрый вывод и алгоритмы, алгоритимы, алгоритмы. В общем "рюшек" поменьше, а "математики" и надежности побольше. И чтобы меню и прочие нужные штучки уже были готовы. Не чтобы просто делались, а вообще были готовы к употреблению - ну, например, как в Блэкбоксе :)). Можно сказать, что таких пользователей и таких задач нет? Есть. У меня есть живой пример. Мой знакомый математик, который может программировать, когда ему надо "быстренько" какую-то модельку рассчитать о Дельфях и прочих вижуал-студиях даже не вспоминает. Он запускает Турбо Паскаль и свою модельку в нем рисует. Я его однажды спросил, "А чего, мол, в нем, устаревшем?". На что получил ответ: "Мне красивые кнопочки нужны или задачу решить?". Мы пришли к выводу, что задача все-таки важнее. Можно спросить: а почему тогда не Блэкбокс? Так не знает он ничего об этой системе, я ему еще о ней не рассказал. Из отпуска выйду - обязательно дам ему дистрибутивчик (в порядке эксперимента :).
Пока все.
Извините, за многословие.
Всем удачи.

Ответ на »сообщение 3897« (Руслан Богатырев)
___________________________
Я за модули - однозначно!
Аргументировать пожалуй не получится, но *.dll это просто маразм!
Осбенно процесс написания на них wrapper'ов на мегабайты... :)))
А класс нужно в чем-то хранить.
Все говорят классы, классы... А как они представлены физически - *.dll. Спасибо. Сыты этим  ... погорло.

Ответ на »сообщение 3896« (Cardinal)
___________________________
Мои поздравления! :)
Странность ещё в том, что при попытке проиграть mp3-файл (с диска FAT32) зависает проигрыватель.
У меня тоже были проблемы с воспроизведением звука. Точнее, звука вообще услышать не удалось.
Скорее всего у Вас драйвер звуковушки не был установлен.
Драйверов, к сожалению, очень мало :(
AosPCITools.DetectHardware попробуйте.
Если драйвер установится, можно будет запустить Mixer (Меню Tools).
А может проблема и в плеере...

Продолжу свои размышления о модулях и классах, на время отойдя от чисто технической стороны дела.

Сначала небольшая преамбула.

Почему мы так подробно разбираем модули и пытаемся выяснить особенности этой концепции и ее истоки?

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

Ответ лежит едва ли не на поверхности. В свете нашей дискуссии можно выделить два полюса, два “мировоззрения” -- “модулецентрический” (module-centric approach) и классоцентрический (class-centric approach).

Если проследить эволюцию взглядов проф. Вирта применительно к его языкам Паскаль, Modula, Modula-2 и Оберон, то нетрудно заметить, что Вирт -- сторонник первого подхода, где модули первичны, а все остальное (включая классы) вторично. Если познакомиться с работами Бертрана Мейера и его языком Eiffel, то можно увидеть, что тот является ярко выраженным сторонником другого “мировоззрения” -- первичны классы, все остальное вторично.

Позиция Мейера -- доминирующая “идеология” в современном мире программирования, особенно промышленного программирования. Языки большой тройки (C++, Java, C#) на уровне своего синтаксиса, семантики и прагматики воплощают именно ее. Бьерн Страуструп, Джеймс Гослинг и Андерс Хейльсберг, как и Бертран Мейер, отстаивают гегемонию классов.

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

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

Традиционные императивные языки на уровне программирования в малом (programming-in-a-small), т.е. на уровне операторов и процедур несущественно отличаются друг от друга. В этом плане можно, конечно, рассуждать о goto, ELSIF, break, LOOP и т.п. Но это детали.

Синтаксис безусловно играет немаловажную роль. Я уже приводил пример с тем, что если Java перевести в Оберон-синтаксис, то вы увидите перед собой едва ли не другой язык (хотя семантика его останется нынешней). Синтаксис языков программирования ориентирован не только и не столько на компьютер (не на удобство работы компиляторов и интерпретаторов), сколько на программиста, человека. Человек весьма консервативен по свои взглядам.  Если брать тот же Eiffel, то если бы он был выполнен в доминирующем Си-синтаксисе, его ждала бы, на мой взгляд, большая популярность. Вирт верно заметил, что ставка Гослинга на Си-синтаксис при создании Java -- это удачный маркетинговый ход. Вкусы и привычки формируют и формируют целенаправленно.

И все же с приходом к пониманию того, что архитектура программных систем выдвигается на первый план, а нюансы инженерных решений для “подземных коммуникаций” -- на второй, все большее значение приобретает программирование в большом (programming-in-a-large). Здесь и происходит переход от computer science (компьютерные науки, информатика) к software engineering (программная инженерия, технология программирования).

Что же позволяет производить такой переход? Прежде всего, абстракции самого разного уровня. В модулецентрических языках модуль является главным средством абстрагирования (и это явно отмечают Мартин Рейзер и Никлаус Вирт в упоминавшейся здесь книге Programming in Oberon). В классоцентрических языках таким универсальным средством является класс.

Французский математик и философ Рене Декарт выдвинул в XVII в. знаменитый принцип “подвергай все сомнению” (de omnibus dubitandum). При этом он отнюдь не являлся “отъявленным” революционером, пытающимся во что бы то ни стало разрушить старое и на его обломках построить новый мир. Напротив, если посмотреть его работы, то несложно заметить принцип эволюциониста, “постепеновца”, который отстаивал и Д.И.Менделеев. Нужно ставить под сомнение сложившиеся стереотипы и методы, а находя более удачные и практичные решения, следовать им, даже несмотря на то что некоторое время они будут создавать неудобства...

Р.Декарт “Рассуждения о методе, чтобы верно направлять свой разум и отыскивать истину в науках”:
“Вряд ли разумно отдельному человеку замышлять переустройство государства, изменяя и переворачивая все до основания, чтобы вновь его восстановить, либо затевать преобразование всей совокупности наук или порядка, установленного в школах для их преподавания. Однако, что касается взглядов, воспринятых мною до того времени, я не мог предпринять ничего лучшего, как избавиться от них раз и навсегда, чтобы заменить их потом лучшими или теми же, но согласованными с требованиями разума. И я твердо уверовал, что этим способом мне удастся прожить свою жизнь гораздо лучше, чем если бы я строил ее только на прежних основаниях и опирался только на те начала, которые воспринял в юности, никогда не подвергая сомнению их истинность. Ибо, хотя я и предвидел в этом разные трудности, они вовсе не были неустранимыми и их нельзя было сравнивать с теми, которые обнаруживаются при малейших преобразованиях, касающихся общественных дел. Эти громады слишком трудно восстанавливать, если они рухнули, трудно даже удержать их от падения, если они расшатаны, и падение их сокрушительно. Далее, что касается их несовершенств, если таковые имеются - в том, что они существуют, нетрудно убедиться по их разнообразию, - то привычка, без сомнения, сильно сгладила их и позволила безболезненно устранить и исправить многое, что нельзя было предусмотреть заранее ни при каком благоразумии. Наконец, почти всегда их несовершенства легче переносятся, чем их перемены. Так, большие дороги, извивающиеся между гор, из-за частой езды мало-помалу становятся настолько гладкими и удобными, что гораздо лучше следовать по ним, чем идти более прямым путем, карабкаясь по скалам и спускаясь в пропасти.”


В отношении классов и их диктатуры. Мне доводилось дискутировать по этому вопросу не только в онлайновых форумах, подобных этому. И вот какое я вынес наблюдение. Схема рассуждения человека, не пользующегося принципом Декарта и не привыкшего ставить под сомнение сложившуюся годами повсеместную практику, выглядит примерно так

1. Все работают на классах
2. Люди не дураки
3. Я не дурак и буду работать на классах

Понятно. Бери готовый рецепт и не сомневайся, куда-нибудь индустриальная магистраль тебя ведь выведет.

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

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

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

УСТАНОВИЛ!!! Установил бутылку наконец-то!!! Нужно  было сменить тип системы до форматирования командой Partitions.ChangeType ... 11 76 ~, где 11  - FAT32, 76 - AOS. Неожиданностью ещё было то, что при запуске форматирования, среда Oberon словно виснет, курсор перестает двигаться внутри окна, и только в логе появляется очень медленно ход форматирования. Не сразу также было понятно как записать конфигурацию раздела - щелчок на команде Partitions.SetConfig. Странность ещё в том, что при попытке проиграть mp3-файл (с диска FAT32) зависает проигрыватель.
По поводу QNX. Мои коллеги сейчас разрабатывают систему на QNX 6, пользуются IDE Momentics, и постоянно матерят язык С (глотает все подряд) и саму среду за "тормоза" (они раньше на Дельфи работали, сложно им привыкнуть к тому, что проект собирается от полминуты до 2-3, как они говорят - даже для пустой формы).

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

Честно скажу, меня несколько удивляет та эйфория, в которой пребывают некоторые поклонники системы Oberon и системы BlackBox. Скажу так: проблем выше крыши, и если есть желание добиться в данной области достойного уровня (т.е. быть впереди индустрии на два шага впереди), надо работать засучив рукава.

Да, система Oberon уникальна! Под видовс и писать уже не хочется :)
Но успех в мэйнстрим сегменте обеспечит только наличие нормального пользовательского ПО.
Хотя-бы почтового клиента, для начала. А потом и Офис.
А бутылка, еще претендует и на роль серверной ОС.
Работать надо!

Ответ на »сообщение 3885« (Горбунов-Посадов)
___________________________


    Здесь некоторое недоумение вызывает позиция Н.Вирта, который в недавно опубликованном интервью [Вирт, 1998] заявил, что «расширяемое программирование подразумевает возможность добавления модуля без какого-либо изменения существующих модулей — они не должны даже перекомпилироваться». С первой половиной утверждения (отсутствие изменений существующих модулей) можно уверенно согласиться, но для чего понадобилось безусловно исключить трансляцию из процесса подключения нового модуля — не совсем понятно. Похоже, неявная отправная точка последнего тезиса состояла в том, что Н.Вирт видит подключаемый модуль исключительно в образе модуля трансляции.


Эту мысль Вирт высказал еще раньше. Думаю, полезно восстановить контекст, в котором она была высказана.
В разделе 12.4 (Objects and modules) книги Рейзера и Вирта "Programming in Oberon" есть такие слова:

Adding a new shape, an ellipse for example, simply means adding a module Ellipses to the system's library. No changes to the other modules are needed, in particular no recompilation. This implies that an extension is possible without requiring availability of the source text of the base.

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

Ответ на »сообщение 3885« (Горбунов-Посадов)
___________________________

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

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

Книга весьма нешаблонная и достойна внимательного изучения. С позиций дня сегодняшнего там есть, что почерпнуть, причем не просто исследователям и студентам, а профессиональным программистам. Написана очень доступным языком.

Вообще поднимаемые вопросы, имеющие самое прямое отношение к таким вещам, как конфигурационное управление, очень актуальны по сей день. Хороших работ по этой теме мне попадалось крайне мало.

Несколько лет тому назад один знакомый, успевший поработать в святая святых Microsoft, при встрече в Москве рассказал достаточно занятную информацию о том, как там решались подобные вопросы в отношении подготовки коммерческих релизов. Информация носила излишне инсайдерский характер и была достаточно сомнительна. Естественно, я не дал ей хода. Тем не менее, уровень проработки этих вопросов (точнее, бардак, который с этим творился) меня сильно поразил. Прошло несколько лет, возможно с теми проблемами во флагмане мировой индустрии уже справились, но все же уделять этим вопросам надо пристальное внимание.

Честно скажу, меня несколько удивляет та эйфория, в которой пребывают некоторые поклонники системы Oberon и системы BlackBox. Скажу так: проблем выше крыши, и если есть желание добиться в данной области достойного уровня (т.е. быть впереди индустрии на два шага впереди), надо работать засучив рукава.

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

Небольшой пример. Книга Александра Семеновича Кронрода "Беседы о программировании" вышла тиражом ... 400 экз. (во 2-м издании, которое и попалось мне в руки). Она конечно не для "народных масс" и вряд ли может считаться настольной книгой программиста, но нешаблонные мысли крупного математика, сделавшего немало в период зарождения советской школы программирования, да для такой огромной страны и таким мизерным тиражом... Такие времена, такие нравы...

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

Да и там народ интересуется... Интересно, что и там идиотские вопросы на счёт перетягивания идей в Обероны из.... Явы и Майкрософт появляются... :о))))))

Владимир, угадайте с трех раз из какого языка были произведены заимствования в Компонентном Паскале при переходе к нему от Оберона(-2).

:o)