Оберон-клуб «ВЄДАsoft»

Не уверен, что тема подходящая, но раздела "Общие вопросы" не нашёл, потому пробую здесь.

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

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

Структура программы представляет собой стек компонентов: "Хранилище", "Движок", "Интерфейс".

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

Застрял на выборе языка для реализации. C/C++ изначально был отброшен ввиду кошмарности. Java/C# рассматриваются в качестве "последней надежды", если с другими вариантами случится провал/недопонимание. Интерпретируемые языки типа Ruby или (прости господи) Python если и пригодны, то для написания интерфейсной части; для прочего их использовать не считаю разумным. Экзотику всякую типа Немерле/Хаскеля/ОКамла и т.д. вообще не понимаю, видимо слишком стар.

В общем, в данный момент я встал перед окончательным выбором между Oberon, Ada и Pascal в указанном порядке. Душа лежит к Оберону, но сермяжная практичность заставляет усомниться в существующих инструментах. Из компиляторов познакомился только с Оксфордским и XDS. Последний нравится больше, но кажется заброшенным каким-то, видимо у разработчиков на Jet все силы уходят или возможностей для поддержки нет, не знаю. Десятилетняя ошибка "#RTS: Coroutines initialization fault 3...", вылетающая при запуске xm уверенности никак не добавляет. Потому на полном серьёзе рассматриваю вопрос выбрать Ada или на крайний случай (Free) Pascal.

Простите за долгое вступление, но полагал его нужным. Итак, вопросы.

Если я выберу для реализации проекта Оберон, то не придётся ли пожалеть? Сложно ли организовать взаимодействие между отдельными процессами, написанными на Обероне, в Линуксе или Винде? Насколько вообще жизнеспособен проект на Обероне, который не просто живёт сам по себе в уютненьком мирке среды Оберон, а погружён по самую маковку в реальный мир библиотек и сред, написанных на Си?

Тонкость в том, что в настоящий момент любой язык для меня находится в условно-латентном состоянии, т.е. я знаком с общими принципами программирования, но для изучения конкретного языка иконкретного иструмента мне придётся потратить месяц-другой. Так что мне в общем-то безразлично (но не одинаково любо-дорого), на чём писать, всё равно потребуется предварительное погружение в тему, будь то Oberon+XDS или Ada+GNAT.

------------------
Пара слов о себе. Первую программу написал в 1987 году для МК-61. После того работал на MS/DR/Novell-DOS, RSX-11, OpenVMS, OS/2, Linux. Программировал на FoxPro, Pascal, Delphi, VBA (Access, Excel), чуть-чуть примазался к Ораклу через SQL*Forms и PL/SQL. В последние 15 лет от практического программирования ушёл, однако продолжаю следить за тенденциями в мире моды софтостроительства. Посему очень поверхностьно знаком с Java, C#, Ruby и некоторыми другими инструментами.

Здравствуйте, Lifewalker!

Один мой знакомый начинающий веб-мастер очень удивился, когда я сказал ему что вместо PHP с серверной стороны и JavaScript с клиентской мог бы быть один язык, единая среда. Для меня Оберон со временем стал пластилином, из которого при наличии свободного времени, желания и воли можно вылепить практически что угодно. Сейчас на этом языке благодаря активности талантливых людей можно писать программы, работающие не только в рамках Оберон-ОС и Оберон-сред исполнения, таких как ETH Oberon, A2/AOS, BlackBox Component Builder, но и:

• приложения для Windows и Linux (в среде XDev были получены отличные результаты по генерации 64-битных приложений для Windows)
• приложения для таких популярных сред как JVM и .NET (с помощью компилятора GPCP)
• высоконагруженные веб-сайты (направление практически не освоено, но потенциал далеко превосходит PHP, ASP или Perl)
• мидлеты для платформы Java ME
• игры для ретро-компьютеров (например, для ZX Spectrum с процессором Z80)

Радует появление как минимум уже трёх компиляторов диалекта Оберон-07 для целевых сред исполнения Windows, Linux и JavaScript. Эти проекты двигаются энтузиастами-одиночками.

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

Возможно, что придётся. В любом случае, этот язык погружает вас в оторванную от мира языковую самосущность. За что его многие критикуют. Как только начинается сращивание его с грешной землёй, начинаются сложности. Приходится делать биндинги к существующим библиотекам. Мне вот, поскольку от Оберона отрываться не хочется, приходится делать GUI на FreePascal (KOL) и саму логику на BlackBox (с последующей сборкой результата в DLL/SO, благо, это легко сделать).

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

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

С этим есть трудности. Оберон предлагает свою идеологию, которая в ряде случаев проще. Но может вызвать отторжение у лунихоидов. Например, в Оберон-системах не поддерживаются атрибуты файлов в стиле Linux. Но всё возможно. Иногда с удивлением обнаруживается, что Оберон-подход упростил задачу, иногда удаётся переписать двадцать строк кода в пять, и с более понятной логикой. В общем, чудеса. И к библиотекам прицепиться, и оттранслировать модуль в исходник на Си, готовую .SO/DLL, или в .class, и удивительное дело: там, где другие средства пасуют (и даже никому не приходит в голову, что их можно было бы использовать и здесь), на Обероне выезжаем. Но замечу, что Оберон тоже требует времени на освоение, понимание тонкостей, хоть и прост как язык.

Трудно, очень трудно советовать. Но пока не попробуете — не почувствуете. А со слов других можно составить только начальное мнение. Походите по форуму, почитайте сообщения, почувствуйте настроение. Я Оберону доверяю, слишком легко исправлять проблемы самому, не приходится ждать реакции других людей или коллективов. Это подъёмный в одиночку инструмент, особенно при выборе удачной реализации. Иногда это не нужно, хочется решать проблемы своей задачи, а не среды. Кому ледокол, кому пирога. Так что, возможно, сейчас Free Pascal будет более удачным выбором (не исключая, что лет через 10 ситуация изменится коренным образом). Насчёт Ada ничего не могу посоветовать.

Да, а под какую архитектуру планшетов предлагается со временем переходить? И какой сложности GUI нужен для вашего проекта?

Задумка интересная. Вот может такие вопросы помогут сформулировать требования к гую и другому:

1. Сущности структурируются как-то так, как у автора прилагаемого файла (сети деревьев)?

2. Логика обработки возможна такая, как обсуждается здесь (как пример)?.. или попроще, как "помощь писателю" у Михайлова?..

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

Да, процессами в смысле висит в памяти процесс "Хранилище" и процесс "Движок" и между ними нужно гонять данные и сообщения (не RPC, а именно сообщения) туда-сюда. Если бы писал на Си или Джаве то был бы 100% уверен, что так или иначе результат достижим, но как это будет работать в случае реализации на Обероне - не представляю. В том числе потому не представляю, что до конца не решил каким именно механизмом всё это реализовать То ли по сети через localhost (с расчётом на потенциал распределённости) гонять мегабайты атрибутов "сущностей", то ли через разделяемую память - всё это ещё в голове, и до конкретной реализации не добралось.

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

К тому времени, когда проект доберётся до реального состояния всё может перемениться. Кто мог 5 лет тому назад сказать, что планешеты на Андроиде заполонят мир, и кто мог сказать 3 года тому назад, что самсунговская Бада будет спущена в унитаз?

Простой, тупой. Панелька слева|справа со списком атрибутов и|или критериев отбора с возможностью группировать их, справа|слева окно со списком сущностей в виде таблицы|списка|эскизов, с масштабированием и парой трюков по обработке, вот и всё. В общем, что-то среднее между Finder, iTunes и Nautilus, только логичнее и без файлов
Теоретически, его можно даже на HTML сваять. Однако, хочу вернуть к жизни некоторые фишки из OS/2, которые сегодня могут быть восприняты как "новое откровение", потому нужно будет посмотреть. В любом случае, там будет минимум элементов управления с заделом на пальцетыкальное управление навроде современного GNOM'а.

Огромное спасибо за подсказки, действительно весьма полезно. Ушёл с головой в изучение.

Всё это можно сделать и на Обероне, в т.ч. и привязаться в случае с Си к библиотеке на Си (как на уровне связки исходников, так и к оттранслированной .SO/DLL), а в случае использования Java-класса — к этому классу. Только чем больше вы будете полагаться на механизмы ОС — тем большей и будет привязка к этой ОС. И тем меньший потенциал по переносу на другие платформы. Я не вижу проблем, на Обероне можно написать модули, которые будут гонять мегабайты атрибутов через разделяемую память или через TCP/IP-протокол. Можно вообще сделать абстрактный интерфейс и к нему — различные реализации модуля связи. Компонентный Паскаль (диалект Оберона-2) предлагает для этого специальные удобные средства.

Oberon-way — это межмодульное взаимодействие, т.е. обмен сообщениями (в терминологии ООП), фактически вызовами процедур/методов между модулями. Это хорошо подходит в случае локальной работы. Если потребуется и удалённая, то, видимо, не обойтись без сети и TCP/IP. Возможно, не стоит сразу решать, что "процесс" будет многозадачным процессом (thread в Windows или fork в Linux), возможно, Оберон-путь, желющий избежать сложностей и проблем "истинной многозадачности", поможет переформулировать эту задачу в сторону кооперативной многозадачности.

Так что если хотите при решении задачи по максимуму опереться на языковые механизмы (или готовые кроссплатформенные библиотеки) и по минимуму — на внутреннее устроение ОС, то Оберон будет хорошим выбором. Особенно если есть опыт разработки на низком уровне (типа WinAPI).

Что ж, это не совсем оффтопик, потому что недостатки есть у любой вещи, и нужно думать как их исправить хотя бы частично! Здесь вольно обсуждать такие вопросы, я сам имею грешок поругать сишный синтаксис и т.п. А вопросы взаимодействия Оберон-технологий с Линуксом и Виндой — самый топик.

Ну, я имел ввиду именно Оберон-системы (ETH Oberon, A2/AOS), где конечно ни о каких атрибутах а-ля Линукс речь не идёт. Но если программа на Обероне скомпилирована и работает непосредственно под Линуксом — всегда есть возможность использовать встроенные механизмы ОС, в т.ч. и все возможности файловой системы.

Да, это как раз угнетает, непредсказуемость. Я думал о разработке на Обероне для Андроида, и, полагаю, это тоже возможно, раз уж это возможно для более ограниченной по возможностям платформы Java ME.
Раз нам в будущем предстоит прицепиться к неизвестной на данный момент платформе, то это игры по неизвестным на сей день правилам. Оберон может выручить, он уже сейчас является мостиком между .NET, Java и нативом. А раз так, то GPCP и BlackBox могут оказаться полезными.

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

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

Если бы мне пришлось столкнуться с необходимостью делать гуй на Обероне, я бы посмотрел в сторону того, что реализовано в BlackBox, или же решил бы писать прямо на WinAPI, ну или на GTK (что тоже можно сделать с помощью средств BlackBox, меня вообще радует продвижение BlackBox в сторону работы под Linux, но стабильной реализации всё ещё нет), или какое-то .NET или Java-решение для построения гуя (и работать с помощью компилятора GPCP). Оберон-системы здесь, похоже, не подойдут. Или надо делать что-то самопальное типа Oberon Visual Component Library (или биндинг к SDL_gui). Мы немного уже обсуждали вопрос построения гуя на Обероне в теме VisualOberon.

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

Это как сказать. Если будете придерживаться только стандартных языковых возможностей Оберона-1, Оберона-2 или Компонентного Паскаля, и только их, то, скорее всего, не придётся (с учётом того, что Оберон-2 можно рассматривать как надмножество Оберона-1, а КП — как надмножество Оберона-2) или придётся, но совсем незначительно, на уровне синтаксиса. Но в практической работе, как правило, дело не ограничивается только лишь стандартными средствами языка. Подключаются возможности модуля SYSTEM (или WinApi), кодовые процедуры, не-Оберон библиотеки, средства ОС и т.п. И здесь начинаются трудности с переносом между реализациями.

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

Советую для начала посмотреть BlackBox Component Builder. А вот для удобства Перевод документации BlackBox на русский язык.

Если поддержите своим проектом эконишу BlackBox, то будет просто здорово.

Жизнеспособие проекта будет зависеть только от Вас.

Зачем именно на обероне?

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