OberonCore

Отвечу коротко.

1. Oberon microsystems, скорее всего, будет и дальше предоставлять исходные тексты -- это прогноз, базирующийся на их интересе к развитию Обероном в России и странах СНГ. Они заинтересованы в переносе BlackBox на другие платформы, в частности, Linux. Для этого у них нет ресурсов. Соответственно, можно рассматривать предоставление исходных текстов BlackBox на данном этапе как своего рода интеллектуальный бартер.

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

3. Для формирования собственной организации, занимающейся локализацией BlackBox, на мой взгляд, достаточно желания и "политической" воли. Всего лишь. Нет необходимости ее регистрировать. Но у нее должно быть понятное название. Она должна заниматься исключительно этим вопросом. У нее должны быть понятные координаты. Желательно, чтобы ее деятельность была публично "легализована" самой Oberon micrposystems.

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

Думаю, что тем, кто развивает BlackBox, надо просто объединиться в этом отношении, обнародовать план своих действий и начать активно развиваться.

Руслан, все языки Оберон-семейства - это замечательно, но стоит ли ориентироваться на Оберон-1? Тем самым, при создании любых общих решений для семейства, возможности О2 и КП отсекаются. Значит, эти решения будут неудобны для практического использования, и все равно будут создаваться альтернативные.

Возможно, стоит опираться на Оберон-2 и КП?

ОТ МОДЕРАТОРА - продублировал реплику INFO21 из старой ветки

СООБЩЕНИЕ ОТ INFO21:


Вопрос с прогнозом не по адресу. По адресу -- мне.

Попробую ответить так:

Будет ли Линус Торвальдс и дальше предоставлять исходные тексты своего ядра в открытом доступе?



Тут гадать не надо -- не хочет и не будет.



Ominc (Oberon microsystems, Inc.) тоже не считают.

Но столь ценят российское сообщество энтуазизстов ББ, что беспокоятся, как бы поддержка уникода в ББ 1.6 без поддержки Win 95-ME не повредила этому сообществу.



Вопрос локализации уже не актуален. Для тех, у кого Win до NT, достаточно русифицированной И.Горячевым версии 1.5. Всем остальным лучше не париться и подождать 1.6.

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

Предлагаю сосредоточиться на решении конкретных актуальных задач.

А в чем будет заключаться это практическое неудобство? К примеру мог ли BlackBox быть написан на Обероне?

Это весьма принципиальный вопрос.

Здесь есть разные аспекты. Выделю два: технический и маркетинговый.

1. Технический аспект.

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

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

Чем плоха ориентация исключительно на Оберон-2 и КП?

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

Оберон -- самый компактный язык, созданный Виртом и фактически зафиксированный 15 лет назад.

Оберон-2 -- экспериментальный язык, созданный проф. Мессенбеком, который перестал им заниматься более 7 лет назад и переключился на модные Java и C#. Кушать хочется всем.

КП -- язык конкретной коммерческой компании. Изменение базовых типов -- не самое страшное. Они создают проблемы несовместимости, но, как выясняется, в Обероне нигде не зафиксировано, что INTEGER -- 16 битов. Это миф, распространяемый непонятно зачем. Размеры практически всех базовых типов в Обероне могут определяться реализацией. SHORTINT действительно фиксируется в 8 битов (точнее в соотв. ему диапазон целочисленных значений). Остальные -- нет.

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

Лицо КП определяют связанные процедуры (type bound) + модификаторы (ABSTRACT, EXTENSIBLE, LIMITED, EMPTY, NEW). Это создает навороты (и новые понятийные проблемы) в ООП по сравнению с моделью Оберона.

Принципиально меняется подход к расширению типа. У Вирта он по умолчанию. На нем и строится расширяющее программирование. У КП -- требует явного модификатора EXTENSIBLE (с точностью до наоборот).

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

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


2. Маркетинговая сторона

Активно педалируется то, что КП -- язык Вирта. Чушь несусветная. К Вирту имеет самое отдаленное отношение. Внутри ETH даже Оберон-2 воспринимался в штыки (хотя в расширение ETH-компилятора ввели-таки read-only export), а о КП положительного мнения были только его создатели. Пфистер молодец, его детище (Oberon microsystems) как-никак движется вперед. Шиперски -- тот использовал КП как трамплин для своей карьеры в Microsoft Research. Хотя, свой вклад в КП продолжает опосредованно вносить, через университет QUT и систему GPCP.

Чем выигрывает КП в реализации BlackBox? Практичностью, удобством для определенных программистов. Язык придвинут к индустрии (вынужденно, рыночные интересы Oberon microsystems). К чему приведет использование КП в качестве знамени Оберон-движения? К маргинальному программированию. Никаких маркетинговых преимуществ по сравнению с конкурентами (Java, C#) он не имеет. Особенно, если политика его внедрения в массы в России строится на войнах языков ("смерть C++"), а не на мирном сосуществовании.

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

Почему Оберон не двигают? А где компиляторы? Где библиотеки? ETH-компилятор внутри Oberon System -- это несерьезно. Можно ли его оттуда извлечь, довести до ума и встроить в другие IDE (не только BlackBox)? Конечно. Но этим надо заниматься. Заниматься серьезно. Чтобы заниматься, надо, по крайней мере, осознать, что это дает.

Вопрос времени, мотивации, кадров.

Конечно. Зачем как-то соорганизовываться? И так сойдет. А будет ли кто-то извне всерьез подумывать о долгосрочных интеллектуальных инвестициях? Так это его проблемы. У нас свои задачи. Зачем что-то еще там обсуждать за рамками "национализированного" BlackBox? Нечего распылять силы и будоражить умы! Будем кропать помаленьку, ожидать милости наших благодетелей. Кто-то хочет переносить в BlackBox сторонние библиотеки из других языков? Пусть переносит. Ну а коли чего там поменяют, это его проблемы, не наши.

Как же без организации info21? Если я не ошибаюсь, Вы именно этим и заняты здесь сейчас.

В .NET национальные идентификаторы официально разрешены. Так что GPCP для .NET изначально более "широк" нежели CP под BlackBox.



Нет, далеко не безусловно. Например, модуль Stores - фундамент фреймворка Блэкбокса базируется на связанных с типом процедурах, которых нет в Обероне. Вы можете объяснить как написать аналог модуля Stores на Обероне? Мне вот, например, это кажется невозможным.

Загвоздка в том, откуда в Обероне взять инициализатор объекта, т.е. аналог Internalize-метода. В Компонентном Паскале инициализатор принадлежит типу (классу объектов), а не объекту. Поэтому в КП зная тип объекта, мы знаем и его инициализатор. В Обероне же, зная тип объекта, про инициализатор ни чего не известно (инициализаторов даже может быть несколько). Под "инициализатором" в Обероне я имею в виду процедуру которая делает присваивание обработчика:

Откуда аналогу модуля Stores написанному на Обероне узнать о каждом инициализаторе каждого типа объектов?

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

Нет модуля Stores - нет BlackBox-а.

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

Что есть Stores? Насколько я понимаю, это модуль, отвечающий в BlackBox за организацию persistent storage для объектов.

Вопрос: можно ли на Обероне реализовать persistent storage?
Ответ: пардон, а что есть gadget и library в Oberon System 3, на чем эта система и построена?

Вопрос: как осуществляется инициализация объектов в Обероне?
Ответ: Вирт называет это installation. Осуществляется явным присваиванием.

Цитата из книги Вирта "Programming in Oberon" (2004):



Кстати, а насколько принципиально, легко ли реализовать BlackBox в ныне существующем виде на Обероне или сложно?

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

Выскажу свое мнение по поводу перспектив Оберон-семейства.

1) "Маркетинговая сторона." Считаю бессмысленным противопоставлять Оберон, Оберон-2 и КП. Виртом 15 лет назад был дан толчок новому направлению, и то, что от него пошли ветки, доказывает лишь его успешность. Естественно, все продумать и предвидеть тогда было невозможным. Кое-что пришлось и придется менять. Будут развиваться версии. Сразу подчеркну: нужно не допустить их принципиального расхождения между собой. Но обеспечить 100%-совместимость тоже не удастся. Все наработки не могут развиваться единственной веточкой. Они должны составить скорее плотную гроздь, но не разрастаться до огромного дерева.

Ничего страшного в появлении версий нет. Это признак того, что Оберон-сектор живет и развивается. Что сейчас самое главное в Оберон-технологиях?
а) Стиль мышления. Нюансы синтаксиса и реализации не столь важны, главное, чтобы в российской индустрии и образовании прижился сам принцип построения модульного, расширяемого, надежного, простого ПО.
б) Это - реальная альтернатива ПО от Microsoft, и именно благодаря КП и ББ. Медленное умирание Borland оставляет всю армию Паскаль-программистов (и преподавателей) без реальной базы для своей работы. Эстафету сегодня может принять лишь ББ. Развитие Оберона как абсолютно независимого от конъюнктуры языка - заманчивая, но во многом утопичная идея. А сколько это займет времени? Год, два, три? А текущие задачи не ждут. И их решать надо сегодня: писать ПО, учить студентов, школьников... Для школы вообще выбор сейчас прост: не BB, так VB. Если победит последний, то года через три Оберон уже будет никому не нужен. И спор "Паскаль или С" станет бессмысленным. Ибо не будет ни того, ни другого. ИТ-отрасль страны окончательно превратится в мастерскую по подгонке "труб разного диаметра" от Microsoft, Oracle, SAP и иже с ними. А что можно предложить взамен, например, для деловых приложений и производственных систем? ETH Oberon? Имея в руках ББ, можно потеснить тот же 1С и VB. А если не потесним сейчас, то - при таких темпах автоматизации экономики и управления - уже не потесним вообще.
Поэтому давайте не будем выдумать проблем и противостояний там, где их нет. Пусть каждый решает текущие задачи, которые перед ним стоят. Если проект Оберона как "нейтральной полосы" обретет свое воплощение, проблемы стыковки с ним не возникнет. Переход пройдет легко и естественно. Т.к. самое главное - не нюансы синтаксиса и не кодировки исоходников, а стиль мышления. Стиль мышления сегоднящих и будущих российских ИТ-инженеров. Оберон, КП, ББ - в конце концов, все это только инструменты, на которых можно этот стиль отточить и применить в деле.



И автоматы Калашникова, между прочим, бывают разные. Тот, который был создан в 1947 году, тоже "стабильный, доказал свою жизнеспособность, нейтральный". И это ничуть не помешало появиться АК-74 (с новым калибром) и множеству модификаций. Потому, что иногда требуется и складной приклад, и подствольный гранатомет, и оптический прицел. И что это меняет? Главное, чтобы стрелял так же надежно, был совместим по главным деталям и мог выпускаться на одном конвейере.

2) "Техническая сторона." По поводу раширения Оберона в Обероне-2 и Компонентном Паскале.

а) Базовые типы. Вирт зафиксировал их размер в языке 15 лет назад в расчете на то, что еще много лет они будут оставаться актуальными. Так оно и случилось, 15 лет - большой срок. А что сейчас? Сейчас у нас не то что на подходе, а уже на пороге - 64-разрядные архитектуры. И цепляться за старый 32-разрядный стандарт смешно. Так или иначе, в самое ближайшее время придется переносить Оберон-системы на 64-разрядные платформы, а значит - принимать соответствующий INTEGER, LONGINT, REAL и иже с ними. И это действительно "не самое страшное" - это абсолютно нормальное, штатаное событие.

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

в) Использованию процедурных типов для формирования методов ничто не препятствует.
Однако на практике такая гибкость нужна не столь часто, а вот связанных методов в повседневной работе очень не хватает. Дело в том, что абсолютная расширяемость в любом случае недостижима. Когда над системой работает двое человек в своей лаборатории - это одно дело, а когда делается массовый продукт - совершенно другое. Конечному пользователю не только невозможно, но и не нужно позволять стыковать "все со всем" - это уже не модульность, а винегрет получается. В конечном счете, глобальным расширением будут заниматься сами разработчики и те, кто будет ими допущен к работе над проектом.
Именно поэтому явный модификатор EXTENSIBLE - вполне разумная вещь, так как разработчик лучше кого бы то ни было знает, что можно расширять, а что нельзя. Абсолютно безопасно в реальных проектах можно расширять лишь абстрактные типы, т.к. у них определен только интерфейс, а не поведение. Заменять произвольный метод произвольного объекта ой как опасно - его "соседи по типу" ждут определенных, не видимых снаружи, но отлично видимых внутри модуля, побочных эффектов. Ориентация на расширение "по умолчанию" - это аналог слабой типизации, когда предполагается, что программист, занимающийся расширением, предусмотрит все нюансы и последствия своих действий.
Расширяющее программирование в большинстве случаев должно оперировать как единицей расширения не методом, а типом и объектом. В ББ расширяемость обеспечивается концепцией "директорий". Существует абстрактный модуль, который содержит, кроме самих типов, еще и переменную-фабрику, которая создает конкретные реализации этих типов. При этом фабрика устанавливается ("инсталлируется") извне, без всякой перекомпиляции (так же, как и инициализация методов в варианте с процедурными полями). Например, по умолчанию свою реализацию для Ports предоставляет HostPorts, но можно создать свою и подключить ее прямо во время выполнения среды. Получаем не намного меньшую гибкость, чем в случае процедурных полей, однако при этом большую ясность и надежность.
Однако никто не мешает при необходимости использовать в КП стиль Оберон-1. Есть много задач, для которых он будет самым удобным.

г) Модификаторы ABSTRACT, EXTENSIBLE, LIMITED, EMPTY, NEW - это не навороты, а насущная необходмиость, если мы хотим иметь возможность выражать проектные решения в терминах языка. КП можно использовать как язык проектирования. Оберон-1 - нет. В противном случае множество ключевых моментов проекта придется отражать в текстовой документации или в "костылях"-диаграмах UML.

Верно. Проект Oberon2005 на это и направлен. Проект Информатика-21 кроме КП ничего не признает. Поклонники КП, к сожалению, тоже.

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

Причем это исходит от апологетов даже не КП, а BlackBox. Не нравится, так не мешайте. Про помогать уже давно никто речь не ведет. Вам не нужно? Очень даже верю. Так занимайтесь своим делом, правьте BlackBox, создавайте с его помощью системы. Бог помощь. Кто вам в этом мешает?

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



И чем вас так достал Microsoft? А Borland еще не достал? А Sun? А IBM?



В этом я не уверен. Куда пойдут Delphi-программисты? Во-первых, многие с Delphi не уйдут еще много лет. Во-вторых, умирание Borland это гипотеза. В-третьих, выбор у людей помимо BlackBox немалый. И BlackBox, боюсь, будут выбирать не в первую очередь, и даже не во вторую. Вы, кстати, когда-нибудь работали с системами программирования на Ada-95? Попробуйте ради интереса.



Независимого от чего или от кого? Это уже давно самостоятельный язык. И в отличие от КП/BlackBox не привязан намертво к Win32. Вы что-то сейчас пишете на BlackBox? А куда-нибудь это можно перенести? Или вас жесткая привязка к библиотеке BlackBox не смущает, и вас проблемы переносимости не волнуют? Вы готовы в это вкладывать свои силы и время?



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



В этом моменте вы невнимательны. Я отмечал обратное. Что же, раз так уверенно утверждаете, приведите место в описании языка Оберон, где фиксируются размеры базовых типов языка (про SHORTINT я уже отмечал).



Это вы о BlackBox? Надо же, а я только подумывал о том, чтобы на него начать переходить. А когда это будет, как будет выглядеть, как придется мне потом править свой код? Сроки? Или это ваши предположения?



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



Безусловно, разумная. Есть еще много чего разумного. И все нужно, и все полезно, и все разумно. Посмотрите на Zonnon -- там почти все разумно. Но масштаб языка несопоставим с Обероном. Сложность КП выше Оберона. Комбинации модификаторов создают очень занятные сочетания. Они все понятны, очевидны и доступны для понимания даже школьникам?

Может, вы, как и другие, всерьез считаете, что КП -- это не более чем косметические изменения по отношению к Оберону?

Встяну и я, пожалуй, хоть вопросы и не ко мне.


Не совсем так. Проект "Информатика-21" изначально направлен на КП, да. Но никто не заявляет, что нет Оберона кроме КП и Info21 пророк его. Просто к остальным Оберонам этот проект безразличен (в отличие от языков семейства С, к которым он несколько враждебен).


А распыления сил недостаточно? В нынешней ситуации это самое плохое, что может произойти.


А никто и не говорит, что BlackBox перехватит всех. Но хоть десятую часть может попытаться.


Оберон-1 намертво привязан к ОС Оберон и её эмуляциям. И для того, чтобы это стало не так, придётся создать помпилятор, систему, и шлифовать, шлифовать, шлифовать. И получится в результате что-то похожее на BlackBox, потому что BlackBox и есть результат столкновения желаемого с реальностью. Но только BlackBox есть сейчас, а Оберон-1-система появится года через три, если повезёт. А BlackBox под линукс будет.


Можно сказать, что КП - несущественные изменения по отношению к Оберону-2. А вот в Обероне-2 по отношению к оригиналу - изменения очень даже существенные.

Точно. "Безразличность" проекта Информатика-21 состоит в том, что любое упоминание работ по развитию Оберона встречается в штыки. Любое.



Супер! BlackBox адаптирован для работы в школе и для определенных курсов в вузе. Проведена начальная локализация, о которой затем сказано, что в 1.6 она будет не нужна. Сделан перевод документации. Ведется закрытый проект по переносу на Linux. А теперь позвольте вопросы:

1. Какие задачи для новых разработчиков были поставлены Информатикой-21, из-за чего собственно и могут "распыляться силы"? Или разработчики все теперь у нас превращаются в переводчиков?

2. Сколько человек занимаются целенаправленным развитием BlackBox?

3. Где обнародованные планы и сроки? Если это все делается в закрытом режиме, то о каком распылении может идти речь? Или работа ведется по принципу "вот вам BlackBox, развивайте, как хотите"?

4. Какова потребность в рабочих руках для развития BlackBox: проекты, количество, квалификация исполнителей? Когда об этом заявлялось, где?




Что вы, перенос компилятора не есть его создание с нуля. Почему обязательно должно получиться похожим на BlackBox? Откуда такие мысли? Или встроить компилятор Оберона во внешнюю IDE означает скопировать BlackBox? Почему встраивание компилятора Оберона в BlackBox и снабжение его стандартной (переносимой) библиотекой означает создание похожего на BlackBox? Появится через три года? Откуда такие сроки? Как их вам удалось вычислить, если (a) не проводилась оценка трудоемкости работ и (b) не известны количество и состав исполнителей?



Хоть вы так не считаете. Уже обнадеживает.

На официальном сайте? Так и сказано? Если отдельные товарищи так говорят - чтож, это поле для переговоров.


Стоит задача - приспособить BlackBox (как язык Оберон-семейства) в школах и вузах. Одной зи первоочередных проблем был перевод документации. Теперь он почти завершён и люди займутся чем-нибудь другим. Например плотно сядут за Линукс.


Ну это у Info21 спросить надо. Думаю человека три


Да, омс действовала именно по этому принципу. Теперь, насколько я понял, они пересматривают свою позицию. Думаю, будут и планы, и сроки, и единое руководство.


Перенос - это не создание с нуля. Компилятора. А среду (с динамической загрузкой модулей) придётся создавать с нуля.
Вставить компилятор во внешнюю IDE (не BlackBox!) можно - только кому он там нужен без динамической загрузки (среда то чужая, не поддерживает)?
Вставить компилятор в BlackBox - не проблема. Только он будет фактически отрезан от существущего фреймворка - методов то в Обероне-1 нет
Про то, почему это будет похоже на BlackBox - позже отдельное сообщение организую.
Откуда сроки? Ну мы же не Вирты. И заниматься этим будем в свободное от работы время. Вот я и прикинул, что год уйдёт на проектирование и создание альфа-версии среды, год - на отладку-доводку-обкатку и год - на продвижения продукта до положения, в котором сегодня пребывает BlackBox. А этот BlackBox к тому времени тоже на месте стоять не будет...


Но я считаю, что отличия эти не в худшую сторону (по сравнению с Обероном-1).

Руслан, я обвиняю Вас во лжи.

Вы уже во многих постах "поливаете" и Компонентный Паскаль, и Блэкбокс.

Никто Вам не мешает развивать Классический Оберон. Но Вы ничего не делаете -- только занимаетесь занудным начетничеством и маниловщиной.
И сейчас пытаетесь напропалую порочить проекты (и Блэкбокс, и Информатику-21), которые решают конкретные проблемы.

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

Сколько нужно ума, чтобы это понять?

Меня абсолютно возмущает ложь и передергивания, которым предался Руслан, самолюбие которого оказалось где-то чем-то задето.
Поэтому не считаю нужным смягчать выражения.



Опять тень на плетень.
Какую конкретную проблему решит такой компилятор??
Никакую. Вот поэтому и не делают.

Вам нужно решать какие-то свои психологические проблемы -- Вы и сделайте, никто не мешает.



Демагогия и вранье в открытую.

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



"самое отдаленное" -- Руслан, чем Вы объелись?!



Как многозначительно звучит-то. Один человек в штыки воспринимал -- Гуткнехт. Который, кстати, первым совместимость со старым Обероном и разрушил.



Ну и ну!!!!!!!!!
Постоянные передергивания.
"ВЫнужденно".

Начнем с того, что "рыночные интересы" само по себе вовсе не плохо.

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

Запрет на несанкционированное расширение типов и переопределение методов (комплекс атрибутов EXTENSIBLE, ABSTRACT и т.п.) -- решение проблемы "fragile base class" -- учите, Руслан, теорию.



Классический Оберон еще более маргинален, это очевидно козе.



Что за бред. Спросим Иру из Гомеля: почему она на Блэкбоксе работает.



Где Вы видите такую политику?!
Кто занимается внедрением КП "в массы"??
Информатика-21 имеет четкую конкретную цель: общие вводные курсы программирования. С++ там не место. Любой ответственный преподаватель с половиной мозга это понимает.



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

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



Потому что нет реальной проблемы, которую такое продвижение могло бы решить.
ББ решает -- вот его и двигают.



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

Отдельный пост про то, почему конкурентноспособная Оберон-система будет похожа на BlackBox.

Всё дело в привычках и требованиях пользователей. Причём не только программистов, а именно всех пользователей. Пользователи хотят, чтобы можно было вставлять текст из ворда и копировать в Ворд. Чтобы в документ среды можно было вставить рисунок или диаграмму Экселя. И пользователю трудно будет объяснить, почему у нас документы составные, а вставить диаграмму нельзя (а можно только что-то, реализованное в самой среде). Если кому-то кажется, что таким пользователям место дома у плиты, он глубоко заблуждается - я, например, регулярно вставляю в текст модуля картинки и формулы в качестве комментария. И мои знакомые, занимающиеся "непромышленным" программированием, были бы только рады такой возможности (если бы не были безнадёжно привязаны к C++).

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

Всё это приводит к тому, что среда должна использовать многие механизмы базовой операционной системы (будь то Windows или Linux), некоторые "стандартные" подходы к созданию UI. Всё это мы и имеем в BlackBox`е - вполне windows-диалоги, MDI интерфейс, поддержку OLE. Думаю не ошибусь, если скажу что в скором времени мы увидим полноценные тулбары и интеллисенс...

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

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

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

Ну если косметические изменения, то попробуйте объянить постороннему разработчику, который только что прочитал книги Вирта "Algorithms & Data Structures" (Oberon Version, 2004) и "Programming in Oberon" (2004), как ему работать с этим в BlackBox/КП? Расскажите, не стесняйтесь. Быть может, в помощь ему сделать комментарии к книгам Вирта, где пояснить, что из слов мэтра он должен забыть, а где что нужно "подмазать", чтобы приведенные Виртом примеры заработали.

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

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

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

Они наверняка знают, что делают.



Ложь и еще раз ложь. Мешаете конкретно вы. Я ничего не делаю? Ну-ну...



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

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



Что вы, куда уж нам скудоумным супротив великих ученых. Я когда-нибудь обращался к тем, кто задействованы в развитии BlackBox в России, с пламенным призывом все бросить и срочно возрождать настоящий Оберон? Нет.

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

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

Что вообще вам здесь не нравится? В чем конкретно распыление сил? Пока я вижу от вас демагогию, лозунги и откровенное лоббирование BlackBox. Мне это не нравится. Я об этом говорю открыто, при этом не смотря на откровенные провокации, никого не оскорбляю.

"Организация" должна вырасти, а не выдумываться. И организация состоится, только если будет нацелена на решение конкретных реальных задач.

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

Данный сайт ООО Метасистемы -- начало аналогичной самоорганизации -- в сфере малого бизнеса.

Руслан действует совершенно абстрактно: даются лозунги ("Только ЕТХ Оберон -- язык Вирта", "Оберон привлечет широкие массы" и т.п.), и выдумывается "организация", в которой "все как у взрослых" -- полный комплект надувания щек с приседаниями, И чтобы новые релизы "раз в квартал" (именно это предлагал Руслан в отношении Информатики-21 -- просто повеситься!)

И логика возникновения сайта Руслана сильно другая (достаточно посмотреть на собрание его сочинений).

Слов нет, личный интерес есть вещь ключевая (другое дело, что разные люди по-разному увязывают свой интерес с другими интересами -- в зависимости от ума и темперамента) -- я и сам уломал Oberon microsystems выпускать Блэкбокс с не слишком радикальной лицензией (они приготовили уже GPL).
Но, боюсь, с черным пиаром в отношении конкурентов -- сплошные передергивания + прямая ложь -- в последнее время Руслан зашел слишком далеко.

Дайте цитату -- а то Вы все из головы выдумываете.
На Информатике-21, сколько помню, речь идет о "школе Вирта".



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

Ваши "разграничения" -- обыкновенное nit-picking.



Сначала посмотрите на название сайта.

Оберон развивают те, кто какие-то реальные проблемы решает. Оберон майкросистемз развивают. Гутнекхт борется с concurrency -- и тоже развивает.
А как Вы развиваете? Никак. Одна маниловщина.



Ну сколько же цветастых слов Вам всегда нужно...

Занимайтесь на здоровье -- только не дезинформируйте народ. Это моя главная к Вам претензия.



"Я не порочил .. хорошая систем, но .. создающая .. огромные риски"

0) Вы хоть думаете, что Вы пишете?
1) Развитие в режиме open source в принципе хаотично.
2) Я никаким развитием не руковожу.


Вы бы лучше книжку Вирта закончили переводить.



0) Меня пригласили Вы.
1) Я Вас ни о чем не просил -- я дал согласие и предложения в ответ на Вашу просьбу.
2) Где Вы видите недовольство?