Ответ на »сообщение 2566« (Илья Ермаков)
___________________________

Для Оберонов необходим единый стандарт на библиотеку метапрограммирования - это станет основой для любого взаимодействия, в том числе распределенного.

Еще один штрих. Семейство Оберонов достаточно разнообразно, но при этом "покрывает" большой пласт императивного программирования, что повышает ценность всего комплекса этих языков. Если выставить некие ориентиры, то получится что-то вроде
* Оберон - Си
* Оберон-2 - Objective С
* Компонентный Паскаль - Java
* Active Oberon - Limbo
* Zonnon - Modula-3 (с прицелом на .NET).

Задача унификации работы на этих языках исходя из микроядра (Оберон) и базовой инструментальной платформы КП/BlackBox имеет некое (хоть отдаленное, зато конкретное) приближение к идее А.П.Ершова о создании лексикона программирования:
* "Предварительные соображения о лексиконе программирования (1983)
http://www.europrog.ru/classics/ae1983.pdf
* "Язык или лексикон" (1983)
http://www.europrog.ru/classics/ae1983b.pdf

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

Некоторые размышления о языке "золотой середины" я изложил в статье "Оберон как эсперанто программирования" http://www.computer-museum.ru/histsoft/ober_esp.htm и http://www.oberon2005.ru/paper/obe_esp.pdf

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

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

Оберон-мышление, Оберон-философия - это нечто большее, чем Оберон-технологии. А потому - более ценное.

Понимаю, что вопрос трудный.
Но не могли бы Вы немного подробнее на него ответить?

Постараюсь это сделать в ближайшие дни.

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

Let's consider now why C is a great language.

Вы зрите в корень. Для существующих компьютеров нужен идеальный компромисс между уровнем детализации (близким к машинной архитектуре) и уровнем абстрагирования (близким программисту). Эдакая золотая середина.

Я бы выделил здесь две пары языков: Си (Денниса Ритчи) и Оберон (Никлауса Вирта), а также Forth (Чарльза Мура) и Occam (компании Inmos).

Си ближе к железу, чем Оберон, в нем низкоуровневые вещи размазаны по языку. В Обероне они по возможности выделены в SYSTEM. Плюс в Обероне есть две фундаментальные по своей простоте и композиционной выразительности вещи - модули и расширяемые записи, которые Си может имитировать. Си занял уникальное место стандарта де-факто в качестве промежуточного языка для кросс-компиляции и работе на разных платформах во многом благодаря своей близости "золотой середине". Деннис Ритчи очень хорошо относится к языкам Вирта, включая Паскаль, Модулу-2 и Оберон. Вирт же прилюдно не раз выражал скепсис по отношению к Си, но кое-что оттуда перенял (самый простой пример - нумерация массивов от нуля, которую он сначала критиковал, а потом "зашил" в Оберон).

Что касается Форта, то язык ориентирован на чисто стековые архитектуры и слегка уходит от программиста в сторону машины (по нотации). Occam(-2) создавался при участии и консультациях Хоара, ориентирован на хоаровский формализм Communicating Sequential Processes (CSP) и заточен под транспьютеры. Что является тоже некоторым уходом в сторону, но уже от традиционного железа.

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

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

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

Например, здесь

Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time---but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it.

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

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

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

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

Т.е. в каком-то смысле это конкурент "Си-машины", которой Алекс Степанов дал сходную высокую оценку (сейчас точно не помню, в какой статье)?

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

Вечный вопрос - есть ли в программировании место искусству?

Можно ли позволить программам быть произведениями искусства, писать стихи на языке программирования?
...
Программы на Хаскелле подобны хайку - несколько строк, а сколько в них глубинного, потаённого смысла, который может обсуждаться веками...
Этим он (Хаскелл) и отличается от тяжеловесного, грубоватого Оберона, и от корявого С++...



"Хайку, Япония, Восток дело тонкое". Ну просто не могу удержаться:

http://oko-planet.spb.ru/?open&h=1&p=5_3&type=viewmes&site=000286F2

Японское Агентство по космическим исследованиям предложило отказаться от посылки автоматических станций для исследования поверхности и происхождения Луны.
...
Ранее Япония отказалась от запуска ракеты с датчиками на Марс.

Кому хайку сочинять, а кому в космос летать.

Ответ на »сообщение 2517« (Илья Ермаков)
___________________________

Хоар вроде бы сейчас занимается как раз-таки ортогональным к ФП подходом - развитием методов автоверификации и доказательства императивного кода. На мой взгляд - для практики самый перспективный подход. И оберонщики здесь тоже на месте не стоят, хе-хе ;)

Автоверификация очень не любит Halting problem. Кроме того, никто не избавляет программиста от необходимости задавать исходные спецификации для проведения верификации. Далее, насколько я знаю состояние дел в области ATP, им требуется "помощь" в ходе вывода. Соответственно, скорее всего от программиста потребуется также понимание утверждений, сгенерированных верификатором автоматически.  Математический аппарат, столь красивый в случае простых программ, семантика которых укладывается в рамки преобразователей предикатов Дейкстры обозримого размера, становится, как бы это выразиться поприличнее, несколько замысловатым в случае доказательства свойств программ, оперирующих над структурами данных типа орграфов произвольной связности. Интересно, что будет проще для "обычного" программиста --- овладение "чистым" лямбда-исчислением и индуктивными  рассуждениями для доказательства свойств Ф-программ или темпоральными логиками и "эффектами" для суждений об императивных программах?

Информация к размышлению. Уже достаточно давно была создана система программирования на языке Scheme, которая называлась VLISP. Ее корректность была верифицирована с точностью (пишу по памяти, могу ошибаться) до соответствия исполнителя его формальной спецификации. Кроме того, стандарт языка Scheme (R5RS) включает формальное определение его семантики. Среди известных мне языков это единственый случай такого серьезного отношения к верифицируемости (специально ориентированные на верификацию языки типа Gypsy не в счет).

>>> лезть ко всем с единым аршином

Видимо, долгое проживание в отрыве от корней сказывается на менталитете.
В России говорится "на свой аршин" - у каждого разный - длина руки человека.
А единый аршин - это прогрессивная идея метрической системы.
Я ж и говорю - конкретика хромает.

Ответ на »сообщение 2566« (Илья Ермаков)
___________________________

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

Согласен. Вот еще немного информации к размышлению в этом направлении.

Давайте попробуем вернуться к триаде Ершова: синтезирующее, сборочное и конкретизирующее программирование. Возьмем за отправную точку классический Оберон (уровень сложности - Си). В нем активно присутствуют средства синтезирующего программирования, есть основа для сборочного (модули) и конкретизирующего программирования (расширение типа, сохранение псевдомодуля SYSTEM), а также (неявно) средства метапрограммирования.

Дальше начинается ветвление (назовем условно - ветвь "Мессенбек/Пфистер" и линия "Гуткнехт").

Язык Оберон-2 (Мессенбек) есть шаг в сторону конкретизирующего программирования (type-bound procedures, read-only export, динамические массивы, WITH, FOR), явная автоматическая сборка мусора, явная метаинформация (метапрограммирование), явная динамическая загрузка модулей  -- в Обероне это неявно, в описании языка не представлено. Уровень сложности: классическая Modula-2 (не ISO).

Язык Компонентный Паскаль (Пфистер, Шиперски) есть дальнейший шаг от Оберона-2 в сторону сборочного (в данном случае framework-компонентного) и конкретизирующего программирования (модификаторы записей, более явное ООП, приближение к Java-модели, в том числе и по базовым типам). Уровень сложности: меньше, чем Java, C#.

Active Oberon (Гуткнехт) берет за точку отсчета классический Оберон, точнее, Object Oberon (язык Мессенбека, из которого потом получился Оберон-2). Active Oberon ввел ссылки на анонимные record-типы (POINTER TO RECORD), не отменяя реализацию ООП средствами классического Оберона. Но двинулся дальше в сторону сборочного (расширяемые (refined) контракты-интерфейсы -- DEFINITION) и конкретизирующего программирования (явное слово OBJECT, разделение на процедуры и методы, делегатные процедурные типы), нетрассируемые указатели (без контроля со стороны сборщика мусора), а главное – активные объекты (объекты-процессы, возвращение к Simula-корням) и модификаторы для параллельного программирования (синхропримитивы). Уровень сложности: меньше, чем Eiffel.

Язык Zonnon (Гуткнехт, Зуев) -- дальнейший шаг от Active Oberon в сторону сборочного (базисная четверка композиционных конструкций: module-object-definition-implementation) и конкретизирующего программирования (перегрузка операций, обработка исключений, процессы (activity) и протоколы). Уровень сложности: Modula-3, Ada.

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