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

Ответ на »сообщение 3790« (Руслан Богатырев)
___________________________
но из предыдущего поста все же повторю идею, что возможно лучше вырасти ценителей чем насильно их искать либо сужать рамки применения О/КП...
хотя как-то утопично, люди для ЯП, а не ЯП для людей))
Ценители "выращиваются" легко - стоит начать учить, например, на КП/ББ, как мейнстрим начинает восприниматься как халтурная "поделка", на которую народ особенно и смотреть не хочет.

По поводу интерфейсов/реализации - в КП/ББ есть с этим свои проблемы... Для метапрограммирования требуется доступ к символьной информации о различных сущностях ЯП. Однако некоторые аспекты в символьную информацию кодовых модулей не помещаются - например, информация о типе возвращаемого параметра процедур. В символьные файлы такая информация помещается - но только для экспортированных сущностей. В этом плане среда требует доработки...

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

только меня вот смущает деление О и КП, как языки для системщиков и прикладников...

И чем смущает, тем что есть разные по своей сути профессии: системный программист и прикладной программист, или что Оберон и КП ориентированы на несколько разные задачи этих сфер? Можно и не делить программистов, считая что есть просто программист, только что даст такое слияние в одном флаконе для анализа? Если человек за свою практику ни разу не написал компилятор, не реализовал диспетчер процессов, не программировал сборщик мусора, не довел до ума драйвер, не сделал хотя бы простейшую UI-систему и т.п., то ему будет трудно осознать сложности и особенности такой работы. Это базис, а не надстройка. Оберон несмотря на то, что язык системного программирования, самым замечательным образом может быть использован для программирования прикладного (но тут уступает себе же в другой ипостаси). Аналогичным образом и с КП. Языки-ядра тем и хороши, что могут работать в обе стороны, ибо не тянут за собой хвост окружения, в которых растворяются другие.

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

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

Верно.

к сожаления само модульное программирование я до конца еще не понял, точнее то, где его применение наиболее целесообразно, какие задачи на нем решать лучше чем др способами

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

люди уже хорошо влядеющие ЯП в О/КП не нуждаются,

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

Ответ на »сообщение 3790« (Руслан Богатырев)
___________________________
попытаюсь пояснить, чем деление на системщиков и прикладников не совсем нравится
в этой ветке уже высказывались мысли, что не сам язык си плох, а то что язык системного программирования стали широко использовать для прикладных задач, что неразумно.
вот вопрос: неужели при наличии нормальной среды(фреймворка) использования О для прикладных задач было бы неразумным?
др вопрос, что возможно в системной области О легче всего показать свои плюсы...
но из предыдущего поста все же повторю идею, что возможно лучше вырасти ценителей чем насильно их искать либо сужать рамки применения О/КП...
хотя как-то утопично, люди для ЯП, а не ЯП для людей))

Ответ на »сообщение 3790« (Руслан Богатырев)
___________________________
идеи на самом деле интересные, относительно нестандартного развития языков О/КП (не путем вывертов иде)

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

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

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

Но такой подход обсуждается тут как светлое будущее программирования :)

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

Второе позволяет иметь как бы миниоперационку, внутри которой есть компилятор (т.е. внутри прикладной системы!) да еще со средствами метапрограммирования (т.е. на лету хоть за ухом почесать). Круто. :)

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

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

Ответ на »сообщение 3786« (Руслан Богатырев)
___________________________
>>>Если страшно, то это можно запретить. От добра, как известно, добра не ищут.
Но такой подход обсуждается тут как светлое будущее программирования :)

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

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

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

Классический Оберон в сфере системного программирования сейчас может быть востребован либо как образец элегантного подхода (реализации системы Oberon -- более богат и полезен в изучении, чем связка Си-UNIX), либо в "осовремененном" виде (Active Oberon в рамках Bluebottle). КП в сфере прикладного программирования (включая акцент на инфраструктурное ПО и на программную инженерию) при сохранении языка ядра (Оберон) имеет более выигрышную (с технологической точки зрения) позицию, нежели подобная связка Си-C++.

Проблема в том, что сейчас активность наиболее заметна в двух направлениях:
1. Active Oberon (Bluebottle) -- системщик-хозяин
2. КП (BlackBox) -- прикладник-хозяин

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

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

РЕЗЮМЕ. Попытки решить задачу в лоб -- нарастить мощную номенклатуру и сделать среду-конфетку, переливающуюся всеми цветами радуги, -- путь утопичный. Нужно думать над другими вариантами. Кое-что здесь пунктирами обозначено.

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

Осталось добавить, что к штатной схеме: "MODULE --> DEFINITION" добавляется верифицирующая: "INTERFACE --> MODULE --> DEFINITION".

При этом:
* INTERFACE -- зона ответственности проектировщика (и вход верификатора)
* MODULE -- зона ответственности программиста (и вход компилятора/верификатора)
* DEFINITION -- зона ответственности компилятора (и вход компилятора/линкера)

Вся тройка поддерживает исходный и бинарный вид.

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

Рассмотрим эволюцию из Модулы-2 в Оберон. В языке Модула-2 поддерживалось деление на описательный (DEFINITION MODULE) и исполнительный (IMPLEMENTATION MODULE) модули. В Обероне Вирт сначала эту схему сохранил (Оберон-1988), а затем привел к нынешнему виду (Оберон-1990), перешедшему и в КП.

Попробуем проанализировать данное проектное решение с позиций дня сегодняшнего и опыта работы на Обероне и Модуле-2.

В работе "From Modula to Oberon" (1990), в самом ее конце, есть соответствующее обоснование Вирта: "Описательная и исполнительная части модуля слиты воедино. Это вызвано желанием иметь спецификацию модуля с точки зрения программиста и с точки зрения компилятора в виде одного документа. Спецификация интерфейса для клиентов модуля (описательная часть) может быть получена автоматически. Объекты, ранее описываемые в описательной части (и еще раз встречающиеся в исполнительной части), помечаются специальным значком экспорта. Таким образом, отпадает необходимость компилятору проводить структурное сопоставление двух текстов."

С точки зрения удобства компилятора это несомненно, но давайте все же определим цену вопроса в отношении удобства программиста (и, что, более важное, коллективной разработки). Так ли уж она велика?

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

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

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

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

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

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

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

Язык Компонентный Паскаль (КП) ориентирован на несколько иную категорию -- прикладник-хозяин. Здесь уже "ядреность" языка-ядра не так важна (даже вызывает у некоторых раздражение). Важнее связка со средой (BlackBox) и сервисное обслуживание (каркасы модулей, библиотеки, компоненты, "полезности" пользовательского интерфейса).

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

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

Вот один из вариантов решения, с привлечением возможностей инструментальной среды.

1. Программист пишет сразу интерфейс-контракт, который может (и должен) подвергаться предварительной компиляции-верификации (на предмет корректности) в отрыве от (несуществующей) реализации.
2. Интерфейс-контракт тщательно документируется, в частности, для модуля в специальной части (INVARIANT) указываются инварианты модуля (условия, выполняемые для любой процедуры -- как перед началом ее выполнения, так и после ее завершения). Если требуется оставаться в рамках языка, это оформляется как хинтовка для инструментальной среды -- т.е. в комментариях.
3. Для каждой процедуры/метода аналогичным образом указываются отдельно предусловия (PRE) и постусловия (POST). Они задают механизм валидации входных и выходных параметров.
4. Существуют три команды (кнопки): (1) генерирования на основе утвержденного интерфейса заготовки реализации ("Gen"), (2) синхронизации интерфейса с реализацией ("Sync") и (3) проверки на соответствие ("Check"), при этом интерфейс всегда первичен. При "протаивании" инварианты, пред- и пост-условия оформляются как ASSERT-операторы в соответствующих точках процедур. Команда Sync гарантирует правку "поверх" реализации. Команда Check выдает лист несоответствий (между контрактом и реализацией).

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

Чтобы не ломать сложившуюся схему (сохраняя ее для тех системщиков-хозяев и прикладников-хозяев, которым такие "сюрплясы" совсем не в жилу), можно в дополнение к DEFINITION (генерируемому из MODULE стандартным образом) добавлять документированный INTERFACE (отдельный файл). Это документация-контракт, которая проверяется не штатным компилятором, а специальным средством, встроенным в инструментальную среду (верификатором). Таким образом, относительно просто и прозрачно поддерживаются обе схемы (Оберона и Модулы-2), причем с расширением в сторону контрактного программирования а-ля Eiffel. Таким образом, DEFINITION -- это средство для контроля со стороны компилятора, а INTERFACE -- для "отдела технического контроля" (в рамках системы контроля качества и обеспечения повышенной надежности).

Ответ на »сообщение 3785« (RBV)

Рабочий стол масштабируется к размерам обоев :). У меня такой проблемы не возникает - ЖК монитор с разрешением 1280х1024 (видать как и у швейцарцев). :)
По-моему в случае с WinAos это всё-же некорректное поведение пользовательского интерфейса. Поскольку нельзя вернуть обратно режим отображения 1:1.
А в ОС Bluebottle эта возможность работает очень даже замечательно. Дело в том, что ОС Bluebottle предоставляет нам не только GUI а ещё и ZUI (Zoomable User Interface) http://en.wikipedia.org/wiki/Zooming_User_Interface
Все Zoom операции выполняются комбинациями клавиш с участием клавиши "Meta" (или Alt+Shift) или клавиши "Meta" с мышиным колёсиком. Подробно описано в Tutorial.Text
Идея довольно интересная, и главное, кому привычнее работать с обычным GUI, такая возможность тоже есть :)