Ответ на »сообщение 2908« »сообщение 2906« »сообщение 2905« »сообщение 2903« (Руслан Богатырев)
___________________________
Руслан, ну Вы так всю малину подавите!

Тока-тока, наконец, стали появляться  труды а ля Александреску, в которых уже не сами по себе проблемы и задачи программирования разбираются, а проводятся изыскания в самом инстрУменте(!) (вроде как призваном служить чисто реализационным целям и недолжном содержать "затенённые углы")...

Эдак скоро и диссертации появяться на тему, вроде:

"изучения полноты и замкнутости кольца перегруженных арифметических операций языка С++ над полем комплексных чисел с представлением полей класса complex перегруженными нестандартной реализацией чисел целого типа в условиях интенсивного применения операций ввода-вывода потомков класса iostream"... :о))))))

То есть вся эта шарага начинает приобретать черты, присущие системам входящим в стадию, подобную бюракратическим системам, описанных вариантами законов Мерфи... - ВЕЩЬ В СЕБЕ И ДЛЯ СЕБЯ :о)

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

Чем же PDF-то провинился :o) Или лучше вместо одного PDF иметь по два вида HTML (для чтения с экрана и для печати), да еще без возможности с их стороны четкого управления композицией страницы и сложными формулами?

Вот для печати PDF - самое то. И на страницы разбито и формат фиксированный. При электронном же чтении, эти достоинства превращаются в недостатки.
Пропуски между страницами (и даже само разделение на страницы) электронному документу ну никак не нужны. А когда увеличивается размер шрифта чтобы комфортно, без напряжения зрения (я дорожу своим единичным зрением) читать, то появляется необходимость горизонтального скроллинга, что практически исключает возможность прочтения.
А если автор еще на пару колонок текст разбил, то удовольствие лицезреть дерганый скроллинг неизбежно... :(
И главное - почему-то отстуствует возможность нажать ctrl+a, ctrl+c и вставить это все куда-нибудь в опеноффис.
А документы с формулами и рисунками и в HTML прекрасно читаются, смысл не меняется от переформатирования.

1. PDF можно делать в виде одной страницы ("портянки" как привычно пользователям в Web). Не надо относиться к PDF как на бытовом обывательском уровне относятся к DVD, считая что там можно размещать только фильмы.

2. Копирование и вставка текста (Ctrl/A и Ctrl/C) работают в Acrobat Reader (в Professional тем более), если автор документа явно не запретил копирование. Во всех PDF, создаваемых в редакции "Мир ПК-диска" (помимо заимствованных), НИКАКИХ ограничений на модификацию нет. Это принципиально.

3. О композиции страницы даже не буду спорить. Очевидное преимущество PDF. И ПРИЕМЛЕМЫЕ возможности HTML.

4. Многоколоночная верстка обычно является следствием подготовки ПЕЧАТНЫХ документов PDF. Я использую одноколоночную верстку и здесь этот упрек не по адресу.

5. PDF для простоты можете считать как упакованный Postscript со средствами расширенного гипертекста, превышающего возможности HTML. Со всеми вытекающими плюсами по отношению к языку разметки в лице HTML.


А кто умалчивает-то собственно? Есть подозрение, что никто особо ни о чем не умалчивает. Просто все занимаются СВОИМИ делами и разработками. В современном мире, если хочешь быть у всех на слуху, то надо крутиться. Ну в турне, например ездить.;)

Это конечно правильно, но...

Если кто-то использует напрямую возможности языка без явного указания источника заимствования, то это является как минимум НЕПРИЛИЧНЫМ в профессиональном сообществе (а не на базаре), а если учесть прямое напоминание об этом со стороны разработчиков -- также УМЫШЛЕННЫМ УМАЛЧИВАНИЕМ (о факте с Ada-95 писал, о Java можно отдельно долго говорить).

Ada-95 использовал идею расширения типа, которая НИГДЕ и НИКОГДА ранее до Оберона публично не использовалась.

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

Чем же PDF-то провинился :o) Или лучше вместо одного PDF иметь по два вида HTML (для чтения с экрана и для печати), да еще без возможности с их стороны четкого управления композицией страницы и сложными формулами?

Вот для печати PDF - самое то. И на страницы разбито и формат фиксированный. При электронном же чтении, эти достоинства превращаются в недостатки.
Пропуски между страницами (и даже само разделение на страницы) электронному документу ну никак не нужны. А когда увеличивается размер шрифта чтобы комфортно, без напряжения зрения (я дорожу своим единичным зрением) читать, то появляется необходимость горизонтального скроллинга, что практически исключает возможность прочтения.
А если автор еще на пару колонок текст разбил, то удовольствие лицезреть дерганый скроллинг неизбежно... :(
И главное - почему-то отстуствует возможность нажать ctrl+a, ctrl+c и вставить это все куда-нибудь в опеноффис.
А документы с формулами и рисунками и в HTML прекрасно читаются, смысл не меняется от переформатирования.

Относительно бескомпромиссности Вирта. Знаете, это очень даже неплохо. Мне понятно, чем это диктуется. Когда десятилетиями умалчивают о вещах, которые, КАК МИНИМУМ, не хуже модных, популярных, растиражированных решений, трудно не быть бескомпромиссным.

А кто умалчивает-то собственно? Есть подозрение, что никто особо ни о чем не умалчивает. Просто все занимаются СВОИМИ делами и разработками. В современном мире, если хочешь быть у всех на слуху, то надо крутиться. Ну в турне, например ездить.;)

В чем состоят принципиальные различия между языками Оберон и Компонентный Паскаль и чем обусловлено одновременное развитие обоих направлений в России.

Пояснения к сообщениям »сообщение 2907« и »сообщение 2903«.

Язык Оберон (Oberon) – это самый простой и компактный универсальный язык программирования, созданный проф. Виртом и проф. Гуткнехтом в 1988 г. Он поддерживает процедурное, модульное и объектно-ориентированное программирование и опирается на концепцию расширения типа (type extension). В его основе лежит ориентированная на экземпляры (instance-centered), а не на классы (class-centered) модель ООП, исповедующая для реализации методов использование процедурных переменных, а не процедурных констант (как в других языках).

Язык Компонентный Паскаль (Component Pascal) был создан последователями Вирта – Клеменсом Шиперски и Куно Пфистером в компании Oberon microsystems (Швейцария) в 1997 г.

Он отличается от языка Оберон тем, что следуя своему прямому предшественнику, языку Оберон-2, созданному проф. Мессенбоком (Университет в Линце им. Кеплера, Австрия), исповедует более привычную многим модель ООП, ориентированную на классы, сохраняя при этом возможность применения схемы ООП оригинального Оберона.

Компонентный Паскаль видоизменил систему базовых типов языка Оберон, приблизив ее к языку Java (и став в этом отношении надмножеством Java). Средства передачи формальных параметров для процедур приближены к языку Ada (IN, OUT). Язык ввел средство ограничения расширения типа. Для построения схем отношения интерфейсов объектов и их реализаций, приближенных к общеупотребительным в ИТ-индустрии, используются новые модификаторы (EMPTY, EXTENSIBLE, ABSTRACT, LIMITED).

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

Дальнейшее развитие инструментария для оригинального Оберона (как эталонной модели языков Оберон-семейства и эсперанто программирования) продолжится по линии создания собственных независимых средств (СП, включая библиотеки), а также путем использования существующих СП для языков Оберон-2 и Компонентный Паскаль в лице XDS, BlackBox, GPCP и др. с обеспечением схем миграции Оберон-модулей между этими системами.

К итогам Большого турне Вирта.

Краткая информация о направлениях развития языков Оберон-семейства опубликована на Oberon2005:
http://www.oberon2005.ru/r101005.html

К ответу на вопрос о том, почему в Обероне нет обработки исключений.

Уточненный вариант. В предыдущем сообщении возникли ошибки копирования блоков текста.

Для простой по своей архитектуре системы Oberon, которая была реализована на языке Оберон, опираясь на механизм команд (экспортируемые модулями процедуры без параметров), в этом не было необходимости. Это явилось первым побудительным мотивом отказаться от использования обработки исключений в языке Оберон.

Вторая причина состоит в том, что обработка исключений (exception handling), близкая по своей природе к оператору goto и программным прерываниям, является достаточно опасным средством, при этом потребность использования исключений острее всего проявляется в наиболее критичных задачах (системы реального времени).

Для них обработка исключений, как показал опыт использования предшественника Оберона — языка Modula-2, может быть эффективно вынесена на уровень библиотек. Результаты подобного исследования для обработки исключений в среде параллельных процессов были опубликованы в журнале Structured Programming (1993), в редколлегии которого были Дональд Кнут и Никлаус Вирт, группой отечественных специалистов из Московского авиационного института – это была первая публикация советских ученых в столь авторитетном издании. См. I.Egorov, R.Bogatyrev, D.Petrovichev. Yet Another Approach to Modula-2 Implementation of Exception Handling Mechanism // Structured Programming, 1993, #14(1), pp. 23-36.

http://www.oberon2005.ru/paper/m2ex.pdf


Другой подход был предложен проф. Ханспетером Мессенбоком, автором языка Оберон-2, и его коллегами из Университета в Линце им. Кеплера (Австрия). См. Markus Hof, Hanspeter Mossenbock, Peter Pirkelbauer. Zero Overhead Exception Handling Using Metaprogramming // 1996.

http://www.oberon2005.ru/paper/p_ex.pdf

К ответу на вопрос о том, почему в Обероне нет обработки исключений.

Для простой по своей архитектуре системы Oberon, которая была реализована на языке Оберон, опираясь на механизм команд (экспортируемые модулями процедуры без параметров), в этом не было необходимости. Это явилось первым побудительным мотивом отказаться от использования обработки исключений в языке Оберон.

Вторая причина состоит в том, что обработка исключений (exception handling), близкая по своей природе к оператору goto и программным прерываниям, является достаточно опасным средством, при этом потребность использования исключений острее всего проявляется в наиболее критичных задачах (системы реального времени).

Для них обработка исключений, как показал опыт использования предшественника Оберона — языка Modula-2, может быть эффективно вынесена на уровень библиотек. Результаты подобного исследования для обработки исключений в среде параллельных процессов были опубликованы в журнале Structured Programming (1993), в редколлегии которого были Дональд Кнут и Никлаус Вирт, группой отечественных специалистов из Московского авиационного института – это была первая публикация советских ученых в столь авторитетном издании. См. I.Egorov, R.Bogatyrev, D.Petrovichev. Yet Another Approach to Modula-2 Implementation of Exception Handling Mechanism // Structured Programming, 1993, #14(1), pp. 23-36. 3. Почему в Обероне нет обработки исключений?

Для системы Oberon, которая была полностью реализована на языке Оберон, в этом не было необходимости. Обработка исключений, близкая по своей природе к оператору goto и программным прерываниям, является достаточно опасным средством, при этом необходимость использования исключений сильнее всего проявляется в наиболее критичных задачах (системы реального времени). Для них обработка исключений, как показал опыт использования предшественника Оберона — языка Modula-2, может быть эффективно вынесена на уровень библиотек. Результаты подобного исследования для обработки исключений в среде параллельных процессов (!) были опубликованы в журнале Structured Programming (1993), в редколлегии которого были Дональд Кнут и Никлаус Вирт, группой отечественных специалистов из Московского авиационного института – это была первая публикация советских ученых в столь авторитетном издании. См. I.Egorov, R.Bogatyrev, D.Petrovichev. Yet Another Approach to Modula-2 Implementation of Exception Handling Mechanism // Structured Programming, 1993, #14(1), pp. 23-36.
http://www.oberon2005.ru/paper/m2ex.pdf

Другой подход был предложен проф. Ханспетером Мессенбоком, автором языка Оберон-2, и его коллегами из Университета в Линце им. Кеплера (Австрия). См. Markus Hof, Hanspeter Mossenbock, Peter Pirkelbauer. Zero Overhead Exception Handling Using Metaprogramming // 1996.
http://www.oberon2005.ru/paper/p_ex.pdf

Извините, может ли кто-нибудь пояснить ситуацию с лицензией на BlackBox? Свободно распространяется версия только для обучения как и написано в лицензии 2001 года (версия 1.4), или уже и коммерческая тоже?

ООП в Обероне против ООП в ведущих промышленных языках.

Модули и расширения типа против концепции классов и пространств имен.

Процедурные переменные против процедурных констант.


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

Никлаус Вирт, From Modula to Oberon (1988):

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

Никлаус Вирт, Modula-2 and Object-Oriented Programming (1990):

Объявление класса в объектно-ориентированных языках выглядит подобно объявлению записи с дополнительными объявлениями процедур (или их заголовков). Такой подход обладает некоторыми достоинствами и ведет к определенным последствиям. В языках Modula-2 и Oberon соответствующее поле процедурного типа предполагает особую роль переменной и, следовательно, фактическая процедура должна присваиваться этой переменной явно всякий раз, когда порождается новый экземпляр записи. Это можно рассматривать либо как нагрузку (и как источник ошибок), либо как дополнительную степень свободы (и мощи). К тому же большинство типичных приложений привязывает одну и ту же процедуру (обработчик) ко всем экземплярам класса: взгляд с позиции методов ориентирован на классы; взгляд с позиции Oberon'а — на экземпляры.

<...>

Различия между подходами с акцентом на классы (class-centred) и с акцентом на экземпляры (instance-centred) по отношению к описанию методов можно рассмотреть под другим углом. В первом случае методы объявляются как (процедурные) константы, во втором — как (процедурные) переменные. Ограниченные возможности первого подхода уже проявились в отношении подклассов, т.е. расширений типов. Обычно подкласс делает методы отличными от методов своего суперкласса.
И так как методы задаются в виде констант, вызывается новая реализация, которая переопределяет описание суперкласса. В соответствующих реализациях переопределение (перегрузка) осуществляется за счет выделения своей таблицы методов для каждого подкласса. В ориентированном на экземпляры подходе языка Oberon не требуется ни подобный дополнительный механизм, ни дополнительная символика переопределения, так как все это достигается через обычное явное присваивание.

<...>

Как результат, Oberon концептуально проще, и его реализации не нагружаются дополнительными механизмами работы с классами. С другой стороны, объектно-ориентированные языки могут предоставлять несколько более удобную символику и обеспечивать безопасность за счет гарантии неизменности объявленных методов для всех экземпляров класса, что выражается в улучшенной эффективности отложенных вызовов. Правда, это стоит рассматривать как незначительное преимущество, поскольку есть уверенность в том, что использование объектно-ориентированной парадигмы должно быть осознанным и там, где это в самом деле нужно. При проектировании операционной системы [Oberon] мы обнаружили, что практически вся система была успешно запрограммирована в традиционном стиле, а объектно-ориентированный стиль затронул лишь систему визуализаторов, которая предоставляла распределенное управление.

Детали подхода Вирта к поддержке ООП в Обероне изложены в его новой книге “Programming in Oberon” (October 2004), в 4-й главе, посвященной ООП.

В родоначальнике ООП, языке Simula, использовались поля данных (прообраз комбинированного типа record языка Паскаль), но не было понятия методов (они появились в Smalltalk) — поведенческим аспектом класса занималась сопрограмма (coroutine).
Сопрограмма была положена в основу квазипараллелизма языка Modula-2, но в Обероне этот механизм не используется (вынесен за пределы языка).

Оберон предлагает использовать схему, близкую Simula: вместо набора методов, реализуемых через поля процедурного типа (т.е. коммутаторов процедур) заводится одна выделенная процедура-обработчик (handler). Она имеет два параметра: объект, к которому применяется, и сообщение (message). Сообщение выражается в виде расширяемого комбинируемого типа (RECORD), это определяет протокол класса. Подобный подход показал свою эффективность и наглядность при реализации системы Oberon (1985—1995).

При таком подходе объект (object) представляется указателем на запись. Запись содержит всего одно поле процедурного типа – handle. При инициализации (порождении объекта) этому полю явно присваивается процедура-обработчик, которая в точности удовлетворяет спецификации процедурного типа по набору формальных параметров процедуры. Обработчик имеет два параметра: объект-адресат и сообщение. Сообщение определяется то действие, которое требуется применить по отношению к объекту-адресату сообщения. Обработчик создается из коммутатора сообщений, реализуемого через выделенный условный оператор IF-ELSIF-END. Сообщения могут отправляться в режиме широковещательной рассылки всем объектам с разнородной структурой данных без знания характера этой структуры. Неприемлемые сообщения будут просто игнорироваться.

Примечание: все цитируемые работы доступны на сайте Oberon2005.

Ответ на »сообщение 2893« (Антон Григорьев)
___________________________

Мне просто очень интересно, можно ли реализовать что-то типа VCL, не имея в языке метаклассов и виртуальных конструкторов.

1) А зачем Вам именно VCL? Есть и другие (более правильные) способы построения фрэймворка. Смотрите, например, BlackBox. Форма (в терминологии Delphi) в BlackBox является персистентным объектом, который можно одновременно "открыть" как в режиме редактирования, так и в режиме исполнения (в один и тот же момент времени!!!).

2) Ту же самую задачу, которую решают метаклассы с виртуальными конструкторами можно решить иными (классическими) способами. Вот только зачем такая задача вообще нужна?...