Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Alex Rider]

Да распрекраснейший в мире программист не представляет в какой именно момент поступит прерывание. Тебя никогда не удивляла логика работы твоего кода по мере его отладки? О, тогда ладно.

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

Твоя "эффективная" разработка - она в первую очередь в той среде, в которой ты умеешь работать. Ручаюсь, я освою IDE сишарпов куда быстрее, чем ты интерфейс ETH Oberon.

Не правда. После некого погружения в действительно удобную среду начинаешь писать на ней быстрее. Был опыт перехода с Delphi 7 на C# (MSVS 2005) - Delphi, котрую я знаю наизусть, кажется мне ужасом тихим - в ней ничего не удобно. Письками меряться не будем - у меня работа заключается в быстром освоении незнакомых софтин И IDE Visual Studio была не самой простой их них из-за больного количества возможностей. Что не значит, что пока их не выучишь, писать не сможешь.

Однако кого ни спрошу - на C# строгает. Ничего другого не приемлют. Даже в связке с C#. А кто-то из шарпачей сказал, что C# идеально использует возможности рантайма .NET, другим языкам это вроде как не очень удаётся.

Соглашусь, в основном разработка под .NET идет на C#. На мой взгляд, он удачнее других .NET-языков именно как язык, а не потому что он был запилен специально под .NET. Собственно, C# даже и не позволяет всего того, что возможно в .NET.

По моему скромному мнению Дельфи это замечательная среда разработки. При этом я имею ввиду где-то Дельфи 6-7.

Delphi сильно отстала от жизни.

Но переориентировать его не так было просто. Оберон (опять Компонентный Паскаль) - сильно проще.

Проблема Delphi не в языке. А в инструментах для создания приложений - отладчика, компилятора, мастеров, шаблонов, библиотек. Посему преимуществ урезанных языков я тут не вижу.

Тебе не всё равно каким образом получается там машкод? "Раз не натив, значит смотреть не буду" - позиция понятна, даже с сочувствием. Но я по правде говоря сильно надеялся на поддержку. А так - приходится всё делать самому.

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

И поясни, пожалуйста, смысл заниматься такой работой для получения компилятора, который делает то, что умеет SDCC, только намного хуже.

"Намного хуже" - это не однозначно. Тема эта очень большая. Из самого простого - упрощение IDE (в идеале - IDE.exe, которая дает на выходе bin, hex, tap, trd, spg), что психологически проще. Компилятор простого языка, вероятно, будет давать более эффективный код. Независимость от команды разработки SDCC - тоже плюс. Подсознательное ощущение, что каждая лишняя трансляция убивает производительность тоже играет вовред ZXDev.

Короче говоря, делай всё сам и нам показывай.

Да, в общем-то, и показывать даже не требуем

Как бы UNIX менялся. И Си менялся. Это просто название осталось.

Такое ощущение, что они менялись кардинально. C++ и Objective C - это совсем другие языки с C-подобным синтаксисом. Для самого C вышло несколько стандартов, которые не перепахивали язык до неузнаваемости. Ядро Linux медленно эволюционирует, хотя дистрибутивы его отличаются, да, за счет пакетов. Идеология UNIX практически не меняется.

Ну вот зачем тебе совместимость твоего проекта с AOS если ты делаешь проект под ядро BlackBox?

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

Хорошо если хоть программисты выбирают, а не дядя манагер, который краем уха слышал, что M$ - это круто.

Нет, не хорошо, когда программисты выбирают. Потому что они выбирают то, что знают, а не то, что подойдет. Хорошо, это когда манагер, принимающий решения, технически подкован, разбирается в предмете и сравнивает инструменты по характеристикам и условиям работы компании, без личных предпочтений.

---------- Post added at 20:59 ---------- Previous post was at 20:58 ----------

Чот тема стала похожа на соревнование "у кого длиннее" (я про посты).

[Oleg N. Cher]

Олег, не подменяй понятия. Мы говорили о понимании работы конструкций языка на примере лямбда-выражений. Причем тут прерывания?

Ага, тоесть программист таки понимает зачем он использует лямбды. Ну, браво. Но я слегка не об этом. Проблема избыточной сложности программных систем. Прерывания - это так, чепушинка. Современный новопрограммер может не понимать код "в глубину", не представляет как устроена его ОС и его процессор. Ты можешь сказать, что этого всего и не нужно. Вероятно, всё и не освоить. Но альтернативой сложной системе и сложному языку я бы назвал простые систему и язык. Самая большая проблема сложного языка и системы - склонность быть "Титаником". И в какой-то момент не смочь повернуть и увернуться. Примеров хоть сколько угодно. ОС Windows, архитектура 80x86, плавно перетекающая в x64. UNIX и Linux. Ну да, Си держит UNIX на плаву, UNIX держит Си, однако постом выше я показал несостоятельный момент Си, который несмотря на всю плавучесть Си уже готовит ему гробик. В этом свете C# и Java не могут окончательно вытеснить Си (пока что) - потому что это виртуальные платформы, а люди ещё не отвыкли от натива. Ну ничего, помаленьку отвыкнут.

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

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

Сложный IDE C#, напичканный возможностями, впечатляет беднягу программиста. Тебя должно порадовать то, что скоро бедняге нужно будет забыть то, что он умел и начать всё сначала. Потому что выбирает-то не программист, а манагер.

Проблема Delphi не в языке. А в инструментах для создания приложений - отладчика, компилятора, мастеров, шаблонов, библиотек.

Проблема Оберонов тоже в этом.

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

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

"Намного хуже" - это не однозначно.

Чтобы догнать наш гипотетический компилятор до уровня SDCC - нужна отмотивированная команда талантливых и заинтересованных разработчиков. Хотя бы человек 3-5.

Тема эта очень большая. Из самого простого - упрощение IDE (в идеале - IDE.exe, которая дает на выходе bin, hex, tap, trd, spg), что психологически проще.

Смотря кому проще. Мне психологически проще знать, что я завтра прикручу к своему XDev библиотеку на Си и модуль на асме, и не буду париться с закрытой средой, которая работает как чёрный ящик и в которой непонятно что происходит. Люблю, понимаешь, открытость и лёгкость интеграции с чем-то очень хорошо обжитым.

У меня, в принципе, готов XDevLite, который представляет из себя как раз один exe'шник. И всё примерно как ты говоришь, только ессно SDCC идёт всё-таки отдельным exe'шником. Не вижу смысла его впихивать. Ну и подсистема ZXDev, само собой, в виде многих файлов. Тоже не вижу смысла пихать их внутрь exe'шника. Разве что инсталятора.

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

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

Кстати, здесь было замечено, что коммерческие фирмы, дескать, юзают Оберон потому что так сложилось. И мечтают с него слезть в сторону .NET. Что же, можно сказать определённо, что человек, перед которым стоит выбор C++ или C# - не выберет Оберон с дурной башки. Просто потому что ему это не придёт в голову. Оберон выбирают те, кто верит в эту технологию и знает её хорошо. Это обычно те программисты, которые закончили ETH, слушали лекции Вирта и Гуткнехта. Я знаю примеры. Так что здесь выбор Оберона не случаен. И слезть с него потом никто не планирует и не мечтает. Это сознательный выбор подкованных фундаментальным образованием в области информатики программистов.

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

Это как сказать. Оптимизирующая кодогенерация - штука непростая. Если не веришь - спроси у Andrew771. Он в принципе делает то, что ты предлагаешь. И будет делать ещё не просто долго, а очень долго. Если не забьёт конечно. Поддержка от правильно психологически отмотивированных юзеров - офигенная, сам же видишь.

Независимость от команды разработки SDCC - тоже плюс. Подсознательное ощущение, что каждая лишняя трансляция убивает производительность тоже играет вовред ZXDev.

Это от непонимания логики работы ZXDev. Которое надо лечить просвещением, но никак не потаканием.

Да, в общем-то, и показывать даже не требуем

Это jerri требовал. Сам для себя он считает возможным делать чего хочет, чего угодно хвалить и чего угодно обсирать. Мне же предписывал появиться на задних лапках, но без короны, и начать всех удивлять крутыми играми на Обероне. Я мож бы и поступил так, но проекты всё долгоиграющие, а поддержки никакой, даже моральной.

[Oleg N. Cher]

Вы смотрели потрошка .NET? Беру файл dotnetfx35.exe, захожу в него в TC по Ctrl+Dn:

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Как видим, .NET 3.5 представляет из себя ровно всю плеяду дотнетов предыдущих версий, непонятно только куда подевался 1.1. Теперь можно порассуждать про экономное использование ОЗУ за счёт повторного использования компонентов и библиотек. Т.е. пользуясь технологией .NET вы получаете снежный ком, который в один прекрасный момент безусловно рухнет под собственной тяжестью. Впрочем, может всё ещё закончился красиво, поддержка 2.0 и 3.0 будет постепенно убрана. Но не расслабляйтесь пока, решать это не вам, а могучему m$.

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

Расскажу ещё байку про дотнет из книги Сержа Тарасова "Дефрагментация мозга. Софтостроение изнутри". Сама книга мне очень понравилась. Байка же, как мне кажется, иллюстрирует недостатки "титанического" подхода.

Когда старая школа молода


Изменения происходят столь быстро, что приходится записывать в ряды старой школы системы с приложениями на последних версиях автономного Visual Basic 6, безвозвратно растворившегося в бурлящей пучине. NET. Теперь, спустя немногим более десяти лет, когда начинают всплывать проблемы с поддержкой из-за отсутствия специалистов, принимаются решения о переделке систем в новой технологии с минимальными изменениями функциональной полезности или вовсе без оной. Тут-то и могут вскрыться интересные подробности.
В одной крупной электрической компании имелась база данных, собирающая эксплуатационную и прочую информацию за несколько лет от разнообразных датчиков и устройств в распределительной сети национального масштаба. Некоторые параметры отличались очень коротким интервалом замеров - «каждые N секунд». В итоге размер хранилища составляет около 3 терабайт информации за несколько фиксированных лет эксплуатации.
В общем, такой размер не является маленьким и для промышленных СУБД, требуя дополнительных усилий в проектировании, реализации, настройке и поддержке. Но пикантность ситуации состояла в том, что база данных была организована в виде двоичных файлов собственного формата.
Признаюсь, последний раз я видел такой подход в далёком 1994 году, когда мы переводили паспортные столы Санкт-Петербурга с подобных плоских файлов на прогрессивный по тем временам и, что важнее, открытый формат DBF под Clipper и FoxPro для MS-DOS и Novell-серверов. С оговорками перехода от флоппи-нет [115 - От англ. floppy net - жаргонное обозначения псевдосети передачи информации между устройствами с помощью гибких дисков. В современном варианте звучало бы как «флэшка-нет».] на каналы удалённой связи, многие паспортные службы долгое время продолжали в этой системе работать, характерные алфавитно-цифровые экраны в DOS-окошке я наблюдал уже в начале 2000-х годов.
В долговременной памяти всплыли воспоминания случаев необходимости ручного декодирования форматов. К великому счастью, программисты системы не занимались тогда «эволюционной» разработкой, а знали область, в которой работают, и добросовестно поддерживали проектную документацию в актуальном состоянии. Кроме возможности прочитать собственно об устройстве системы, все описания форматов двоичных файлов также были на месте. Возникший было тёмный призрак индустриальной археологии растворился в лучах взошедшего солнца.
Поскольку в нашу задачу входило предпроектное обследование, начались интересные опыты с технологиями новыми. Начали с прототипа конвертера, извлекающего данные из старых форматов и распределяющего их по таблицам промышленной СУБД, в качестве которой выступал SQL Server. Логично было бы написать такой прототип на C++ или другом языке с возможностями прямого доступа к памяти на уровне битов, но ввиду планируемой общей разработки исключительно на C# необходимо было оценить соответствующую программу в ипостаси распаковщика байтов.
Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. A ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked(). В итоге код достаточно простого алгоритма пестрел вот такими вставками, которые, на минуточку, суть рекомендуемые практики. Нас настигла расплата за автоматическое управление памятью.

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

Вторым пунктом была собственно база данных. На логическом уровне структура для тестируемого случая никаких сложностей не представляла: одна узкая длинная таблица, связанная с несколькими короткими справочниками, практически «звезда», но в режиме постоянного добавления пачек новых записей. Трудность представлял собой уровень физический. Втиснуть число-признак, кодируемое тремя битами, в те же три бита на уровне СУБД стандартные средства не позволят. Минимальный размер - байт. Использовать нестандартные битовые поля в принципе можно, но тогда мы лишимся поддержки ссылочной и прочей целостности, возможности использовать SQL для выборок без переупаковки значений в битовые структуры и фактически будем использовать СУБД в качестве продвинутого аналога файлового хранилища с улучшенными функциями администрирования.
Поскольку целью было упрощение работы с пользовательскими запросами, то лишать их доступа к данным посредством прямого и понятного человеку SQL было решительно невозможно. При использовании минимальных по размеру стандартных типов данных прогнозируемый размер базы данных без учёта дополнительных индексов превысил 6 терабайт, то есть минимум удвоился по сравнению с двоичными файлами. Сжатие данных несколько скрасило ситуацию, полученные 4,5 терабайта выглядели уже неплохо. За всё надо платить, в том числе за стандартность доступа и представления данных.
Третьим пунктом была загрузка данных из C#-пpилoжeния в базу данных. Поскольку интенсивность вставки из прибывающих от датчиков текстовых файлов составляла почти 400 тысяч записей каждые 10 минут, то, разумеется, приложение должно было справляться с этой задачей за меньшее время. Оптимальной, как и следовало ожидать, оказалась пакетная загрузка, игнорирующая ограничения целостности РСУБД. Такова обычная цена компромисса.
Что имеем по итогам более чем 10-летнего развития технологий? Появилась возможность стандартизировать хранение и доступ к большому массиву данных, используя вполне обычное серверное оборудование корпоративного класса и 64-разрядную промышленную СУБД. Возникла необходимость переделывать программное обеспечение из-за утраты поддержки среды разработки поставщиком и соответствующих компетенций на рынке труда.
Но я совсем не уверен, что ещё через 10 лет новые подрядчики, вынужденные в очередной раз переписывать систему, найдут документацию в том же полном виде, в котором нашли её мы. Если вообще найдут хоть что-то, кроме кода, остатков презентаций и наших отчётов.

[Vitamin]

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

А если таки требуется плыть далеко?

Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. A ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked().

А нахрена?

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

Есть такие страшные слова- поддержка и обратная совместимость.

[jerri]

Это jerri требовал. Сам для себя он считает возможным делать чего хочет, чего угодно хвалить и чего угодно обсирать. Мне же предписывал появиться на задних лапках, но без короны, и начать всех удивлять крутыми играми на Обероне. Я мож бы и поступил так, но проекты всё долгоиграющие, а поддержки никакой, даже моральной.

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

[Eltaron]

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Там инкрементальные улучшения. Основная масса библиотек неизменна со времен 2.0. 3.0 принес WCF, WPF и WWF, все в отдельных либах. 3.5 - LINQ, Linq2Sql, Linq2Xml, это всё тоже отдельные либы. 4.0 - дал Entity Framework, 4.5 - пространство System.Task для асинхронного выполнения. И то, и то - тоже отдельные либы. Плюс постоянно развивается язык, но там хранится обратная совместимость, и 2.0 проект собирается без проблем 4.5 компилятором.

Это так же можно сказать, что ты наращиваешь снежный ком, когда делаешь очередную новую либу для ZXDev. И что он тоже рухнет под собственной тяжестью.

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

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

const ushort A = 0x2312;
const ushort B = 0x2014;
ushort C = (ushort)(A + B);

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

const byte mask = 0x30; // 00110000

Можно ещё более безопасно

[Binary("00110000")]
const byte mask = 0x30;

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

[Advertiser]

[ZXMAK]

Зачем тут unchecked, я не понял.

Тот кто писал такой код, просто не знал C#
Конечно, статья полный бред, для указанной работы именно c# более всего подходит, а не c++, но нужно хоть книжку какую почитать по языку, прежде чем начинать писать на нем

PS: переписал код эмуляции Z80, на лямбдах скорость должна заметно вырости, занялся переписыванием движка, в старом связанность очень большая и много рудиментов

[SfS]

Позволь простой пример. Сишник пишет:

void fn() {
int *a; a = 1234; *a = 1234; // я выстрелил себе в ногу - ура!
}

Это парадигма Си.

Нормальный компиляторы выдают предупреждение, если тип не приведён принудительно.

Кроме того, обычно я ставлю опцию -Werror, которая трактует все предупреждения, как ошибки. И всё. Не прокатит твой пример.

А вообще "об дуру можно и член сломать".. В смысле - что любой инструмент можно и нужно использовать с умом.

[s_kosorev]

Был жизненный этап, вспоминаю с ужасом, на предприятии была учетная система на базе BlackBox.

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

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

Разработчики которые писали эту систему, отказались от поддержки, сказали что BB морально устарел и специалистов нет, предлагали переписать все на 1С.

В итоге разработал конвертер кода в C# и за полгода перенес все на .net, еще полгода переписывал интерфейсные вещи и движок БД, добавил нормальный Reporting.

Итог, по прошествии 5 лет, насколько мне известно, приложение используется, хотя склоняюсь теперь что возможно был бы смысл взять подходящую программу от 1С и не позволять брать вверх юношескому максимализму.

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

[Oleg N. Cher]

s_kosorev, спасибо, было интересно. Кстати, даже удивлён узнать о таком использовании BlackBox.

Всё так, не поспоришь. Правда, окружение очень важно, сообщество большое важно и т.д.

Но всё-таки я утверждаю, что C# и .NET хороши именно для типичных задач, где-нить на производстве. Там да, плюсов много.

А по Оберон-технологиям мало специалистов - это конечно так, но хороший спец по C# разберётся в Оберонах. Если понадобится.

Посмотрите, пожалуйста, вот это видео:

Прошивка контроллера Cortex-M3 (LPC1343F) программой на Oberon

Пара комментариев. Здесь показан самопальный компилятор, сделанный одним человеком - Александром Ширяевым. Это к вопросу создания компилятора Оберона для Z80. Да, это несомненно гораздо легче, чем сделать компилятор Си. Однако где желающие этим заняться? Что-то не замечены.

Дальше. На видео вы можете видеть BlackBox, запущенный в среде Ubuntu. Это нативная линукс-версия, адаптированная из авторской виндовской версии очень небольшим коллективом разработчиков. Просто сами делайте выводы.

Сам BlackBox был разработан швейцарской фирмой Oberon microsystems, насчитывающей человек 15 разработчиков. Фирма, само собой, коммерческая. Правда, уже перешла на дотнеты и забила на BlackBox - есть повод позлорадничать.

Ну и я сам адаптировал транслятор (Оберона-2 в Си) Ofront с Linux для командной строки Windows. Справился за несколько вечеров. Очень грамотно сделан, всё по полочкам. Также я вношу в него доработки с поражающей меня самого лёгкостью.

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

jerri, да вот всё не теряю надежды что ты наконец-то займёшься Обероном.