Для информации.

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

Их электронные версии можно найти на сайте Oberon2005.

Ответ на »сообщение 2885« (Руслан Богатырев)
___________________________
Ответ на »сообщение 2882« (Владимир Лось)
___________________________
На мой взгляд, ваш подход -- яркая иллюстрация того, что изучать язык надо отнюдь не для непосредственного его применения.
Согласен 101%!
Уже просто само ознакомление с... и понимание идей и парадигм, на которых основывается тот или иной язык обогащают опыт и набор приемов для решений задач.

Некоторые мои друзья начинали с Modula-2 и уже будучи вовлечены на новой работе в потогонное производство на основе C++ чувствовали себя королями. Они понимали то, что просто не могли понять люди, выросшие на C++.
Тут есть одно тонкое различие:
Одни умеют писать программы на С/С++, другие - программировать... :о)

Религиозные войны, с одной стороны которых участвуют приверженцы с/с++, часто вызываются их собственными детскими страхами от осознания ловушки в которую они попали, "запав" на единственный язык. Нельзя не признать, что с/с++ обладает богатым арсеналом средств выражения идей программиста. Но у подавляющего большинства программистов, использующих эти языки возникает ложная иллюзия что с помощью с/с++ "легко решаются" ВСЕ проблемы программирования. Более того, основная масса "сионистов" становится просто не способна уже просто к восприятию иной семантики если она не выражается синтаксисом "похожим" на сишный... Процесс заходит так глубоко, что "тяжелая артиллерия" начинает работать уже на стадии обсуждения оформления блоков... :о))) А то, что в Модуле и последующих виртовских языках блоков (как понятия) вообще нет - уже и не воспринимается... :о) Вслед за этим не воспринимается уже и сам существенный семантических "сдвиг" в выражении смысла последовательности действий в этих языках... И так – на всех уровнях восприятия языка.

Всем обратившимся за libao.
Коллеги, ещё раз повторюсь, что я НЕ СОБИРАЮСЬ РЕАЛИЗОВЫВАТЬ И ВЕСТИ ЕЁ ПОД Win-системы!
Пардон у сообщества за некоторую внетемность сообщения, но, практически все обращающиеся за библиотекой (или собирающиеся это сделать), читают эту тему...

Ответ на »сообщение 2887« (SVK)
___________________________
Ответ на »сообщение 2882« (Владимир Лось)
___________________________
Прошу прощения за оффтопик. Владимир, я Вам пытался бросить пару писем (уже давненько) --- Вы их получали? У меня есть кое-какие подозрения, что хотмэйл их Вам не пропустил (поэтому, собственно, и пишу сюда).

Здравствуйте, Сергей!
Оказывается, МС и здесь считает себя умнее всего остального мира: после 10 дней (а почему не 5, 2 или 1 день?) непоявления на хотмэйле, из ящика удаляется вся пришедшая почта...
Теперь пишите спокойно: минимум раз в три дня я туда  заглядываю... :о)

Ответ на »сообщение 2888« (Сергей Губанов)
___________________________
Ответ на »сообщение 2882« (Владимир Лось)
___________________________
... но пришел начальник и сказал, что думать о количестве потоков в программе - это не дело программиста. Количество потоков в программе задается конфигурационным файлом, который читается программой при старте. Я до сих пор в шоке...
Я б такому начальнику ответил встречным вопросом из хорошего советского фильма "Серёжа":
- "Дядя Петя, Вы - дурак?"

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


Рассуждаем о том, что эти строки, определяющие интерфейс, рассредоточены по тексту.

Они собраны компактно в интерфейсном модуле. Это карта навигации по реализации.

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

Представлена она как раз-таки достаточно компактно -- в интерфейсном модуле на уровне исходных текстов.

Раскрою маленький секрет. После Modula-2 и Modula-3 (где можно делать НЕСКОЛЬКО интерфейсов к одному исполнительному модулю) я от этого решения Оберона не восторге, о чем прямо и сказал Вирту в ходе нынешнего турне. Но при этом, согласен, что цена за простоту и надежность вполне приемлемая.

... -- все это изложено в диссертации ETH #10650 "Separate Compilation and Module Extension"

Спасибо, интересно будет почитать, несмотря на PDF-формат.

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

Думаю, вы наверное в курсе, что PDF не только давно стал стандартом де-факто в области электронных изданий (в т.ч. любых руководств, справочников и т.п.), но несмотря на сильнейшую конкуренцию между Adobe Systmes и Microsoft, последняя вынуждено приняла решение о включении в новый Office 12 будущего года средств создания PDF для всех своих форматов. А как же им не хотелось этого делать!

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

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

Все вопросы ему (и Гуткнехту) с переводом будут направлены, надеюсь, на ближайшей неделе.

По оптимистичной оценке надо ожидать ответов не ранее  20-х чисел октября. Не факт, что будет отвечать на все, но те, на которые ответит, будут обязательно опубликованы. Елена Филиппова отдельно об этом объявит на Королевстве.

В отношении моего знакомства с Delphi -- знаю хуже, чем Modula-2 и Oberon. Я не практикующий (сейчас) программист. На Обероне и Modula-2 пишу от случая к случаю. Однако в вопросах анализа концепций разных языков опыт имею. Для нашей полемики, думаю, этого вполне достаточно, поскольку по-новому детально сейчас изучаю спецификации всех ведущих языков. И для удобства все эти стандарты (C, C++, Delphi, C#, Java) опубликовал на тематическом сентябрьском диске Мира ПК.

Относительно макросов и шаблонов. Это мощный и очень полезный аппарат для автоматизации создания исходных текстов (особенно для различных высокоуровневых абстракций). Но в идеале ЯЗЫК не должен на него опираться.

Одиночное-множественное наследование. И то, и другое имеет свои плюсы и минусы. Критика использования множественного наследования, принятого в C++, усугубляется проблемами самого языка. Но если одиночное наследование в случае необходимости (а она бывает очень редко) на уровне интерфейсов моделирует множественное, то не вижу больших оснований ратовать за последнее.

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

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

Что касается стремления к максимальной простоте языка и отказа от всего навороченного, то это жизненный принцип, которому на моей памяти Вирт никогда не изменял. Приведу один пример из реальной жизни. На одной из Ершовских конференций в Новосибирске конца 80-х -- начала 90-х годов один очень уважаемый наш ученый делал доклад по объектно-ориентированным вещам. Когда в кулуарах после лекции Вирта спросили мнение об этом докладе, он ответил примерно так (передаю мысль) -- это слишком сложно, чтобы быть правильным. Я был в двух шагах и хорошо это слышал.

Когда в язык для облегчения труда программиста привносят все новые и новые могучие средства, которые дают более компактную запись, это автоматически переносит проблему на другой уровень -- через пару-тройку лет (а, быть может, и раньше) те, кто этим пользуются, уже перестанут понимать, какую цену они платят за такое удобство (ведь они толком даже и не представляют, как это РЕАЛИЗОВАНО). Никакие вычислительные мощности от глупостей не спасут.

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

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

Эту позицию можно принимать или не принимать. Лично я ее глубоко уважаю и полностью разделяю.

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

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

Ответ на »сообщение 2892« (Руслан Богатырев)
___________________________
Под интерфейсом модуля разумеют экспортную часть модуля (весь экспорт) и НИЧЕГО иного.

Видимо, я неудачно использовал закрепленный за другим понятием термин "интерфейс". Тогда назовем это "кратким содержанием модуля".
Оно весьма полезно. Помогает легко ориентироваться в модуле.

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

Рассуждаем о том, что эти строки, определяющие интерфейс, рассредоточены по тексту.

Что же, придется вернуться к вопросу, который уже разъяснял. IDE (Integrated Development Environment) -- это понятие, предложенное МАРКЕТОЛОГАМИ.

Я в курсе. Можно вместо IDE сказать "сервисные средства СП". Смысл не изменится.

Я так подробно об этом пишу, чтобы раскрыть простую истину -- формированием интерфейсного модуля на основе спецификаций экспорта в Обероне занимается КОМПИЛЯТОР, а не IDE. Это ОЧЕНЬ большая понятийная разница.

О том, что компилятор формирует интерфейсный модуль, предназначенный для чтения программистом, я не знал.

Вопрос раскрыт в моем ответе #575 в форуме Информатика-21.

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

Он не только существует ФИЗИЧЕСКИ, но и подразумевает наличие символьного файла (бинарного представления интерфейса), который требуется компилятору при трансляции тех модулей, которые ИМПОРТИРУЮТ данный.

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

... -- все это изложено в диссертации ETH #10650 "Separate Compilation and Module Extension"

Спасибо, интересно будет почитать, несмотря на PDF-формат.

Руслан, я бы хотел взять в нашем споре таймаут. Дело вот в чём: свои сомнения по поводу подхода Вирта я изложил в вопросе самому Вирту (который вы, возможно, видели). Поэтому, прежде чем двигаться дальше, я бы хотел дождаться ответа от Вирта, потому что имел случай убедиться, с какой неожиданной стороны он умеет подходить к, казалось бы, давно решённым вопросам.

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

И ещё хочу сказать, что наш разговор ушёл в сторону от темы, которая меня больше всего интересует. И произошло это по моей вине - я с самого начала неправильно расставил акценты. А интересует меня вот что. Вот, например, есть такие средства, как препроцессор и его макросы. С одной стороны, иногда это жутко удобно, но с другой - иногда поиск ошибки, вызванной неправильным использованием макросов, стоит нескольких лет жизни. Вопрос: что с этим делать? Можно просто спрятать голову в песок и сказать: макросы не нужны ни в каком виде. А можно попытаться найти компромисс в виде не столь гибкой, но более безопасной конструкции, какой являются, например, шаблоны. Ведь при всех их недостатках шаблоны - это явный прогресс по сравнению с макросами. Другой пример - множественное наследование. Можно, испугавшись проблем, связанных с ним, вообще выкинуть его из языка, а можно найти компромисс в виде множественного наследования интерфейсов. Конечно, наследование интерфейсов опять-таки решает не все задачи, которые может решить множественное наследование классов, но за счёт безопасности использования является разумным компромиссом. Так вот, когда я говорил о разработчике компилятора, я на самом деле имел ввиду не того, кто будет писать код, а того, кто разрабатывает сам язык и утрясает его возможности с безопасностью. У меня создаётся впечатление, что Вирт и его ученики просто устранились от решения многих проблемных моментов, выкинув на фиг всё, что не имеет простого готового решения. Вирт сформулировал принцип, что в язык должны включаться только хорошо проверенные средства. Но ведь это же тупиковый путь. Откуда возникнут новые средства, если в язык будет включаться только то, что проверено? Где проврено? В других языках? Но это означает вечно плестись в хвосте, собирая только то, что доведено до ума другими. Радует одно: Вирт не следует сформулированному им же принципу до конца, и Оберон всё-таки содержит ряд очень хороших новшеств, которых не было нигде до него. Но всё-таки мне чисто по человечески обидно, что Вирт, которого я считаю весьма незаурядным человеком, а может, даже и гением, не считает нужным заниматься вопросами поиска компромиссов, а просто выкидывает существующие проблемы из области своих интересов. Я думаю, у Вирта это получилось бы куда лучше, чем у Страуструпа, и даже чем у Хейлсберга.

Кстати, а Гуткнехт не предлагал денег за задачу, которую можно решить на Delphi, но нельзя на Обероне? :) Мне просто очень интересно, можно ли реализовать что-то типа VCL, не имея в языке метаклассов и виртуальных конструкторов.

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

Похоже мы как-то недопонимаем друг друга.

Размеры методов НИКАК не зависят от их РАСПОЛОЖЕНИЯ внутри модуля. Так что это высказывание насчет "не взглянешь" -- это по части не Оберона.

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

Под интерфейсом модуля разумеют экспортную часть модуля (весь экспорт) и НИЧЕГО иного.

Причем тут размеры методов? Притом, что при больших методах, на экране помещается малая часть интерфейса, т.к. он перемешан с реализацией. И это именно следствие синтаксиса Оберона.
В качестве примера для сравнения я привел Delphi (Pascal), где весь интерфейс в соотв. секции в компактном виде представлен. Это на мой взгляд удобнее, чем по два файла на каждый модуль, как в Modula-2.

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

Вобщем-то есть и обратная сторона медали - интерфейсная часть избыточна, и ее надо синхронизировать с исполнительной. Так что при определённой функциональности IDE (опять!), её отсутствие скорее достоинство.
Только вот хорошо ли так зависеть от IDE?
Впрочем, я лично не думаю, что плохо.

Что же, придется вернуться к вопросу, который уже разъяснял. IDE (Integrated Development Environment) -- это понятие, предложенное МАРКЕТОЛОГАМИ. Оно сильно затемняет структуру организации инструментальных средств. Есть старое, проверенное годами понятие системы программирования (СП), куда включаются компилятор (интерпретатор), система поддержки языка (RTS/RTL, в частности, реализация псевдомодуля SYSTEM в Modula-2/Обероне), базовые библиотеки, а также сервисные средства (исходное понятие IDE), включающие синтаксически ориентированный редактор, make-система и т.д. В современных СП среда IDE сращивается с компилятором, но может выступать и отдельно (пример -- Eclipse, Visual Studio для интеграции сторонних языков).

Я так подробно об этом пишу, чтобы раскрыть простую истину -- формированием интерфейсного модуля на основе спецификаций экспорта в Обероне занимается КОМПИЛЯТОР, а не IDE. Это ОЧЕНЬ большая понятийная разница.

Рад, что вопрос в отношении процедур-методов и их компоновки по модулям разрешился. Надеюсь, здесь удалось кое-что разъяснить.

Тут немного не понял - что это был за вопрос?

Вопрос раскрыт в моем ответе #575 в форуме Информатика-21.

Таким образом, в Обероне есть те же ДВА модуля -- интерфейс и реализация. С тем лишь отличием, что описательный модуль (DEFINITION) бессмысленно править вручную, ибо он есть продукт генерирования собственного текста из спецификаторов экспорта в реализации.

Т.е. он где-то существует физически? Или виртуально, лишь в виде совокупности спецификаторов экспорта в реализации?

Он не только существует ФИЗИЧЕСКИ, но и подразумевает наличие символьного файла (бинарного представления интерфейса), который требуется компилятору при трансляции тех модулей, которые ИМПОРТИРУЮТ данный.

Детали того, как организуется раздельная компиляция (separate compilation), чем она отличается от независимой компиляции, как в идеале должна быть устроена система, где используются интерфейсные и исполнительные модули, что такое символьные файлы и зачем они нужны -- все это изложено в диссертации ETH #10650 "Separate Compilation and Module Extension" (есть на сайте Oberon2005 -- http://www.oberon2005.ru/paper/eth10650.pdf), которую защитил в 1994 г. Regis Crelier -- аспирант Вирта.