Мы, каждый из нас, глубоко укоренены в том, что считаем правильным. Я считаю правильным хорошее качество машинного кода, чего почти все реализации Оберона не дают. С уровня асма Оберон-компиляторы типа ETH Oberon дают самый простой и неэффективный машинный код. Для меня минимализм языка идёт рука об руку с минимальным объёмом порождаемого кода. И это не прихоть, а потребность решать ресурсоёмкие задачи для различных платформ. А Оберон-сообщество предпочитает простоту его получения "в лоб".
Обидно, что почти все Обероны дают код худшего качества, чем древний Дельфи 2.0
А чуть ли не единственный оптимизирующий компилятор Excelsior XDS, который переплюнул бы Delphi 2.0, закрытый и с багами. У нас нет единого мультитаргетного Оберона, таким образом,
budden прав. И породить такой единый Оберон — годы работы. И килобаксы.
Плюс кому-то больше нравится Оберон-07, кому-то КП.
Я понял: резко на Оберон никто не вспрыгнет, нужен инструментарий для переходного этапа.
А то приходит новичок в Оберон-сообщество и хочет инструмент для быстрой и удобной разработки. А такого нет. Ему дадут в лучшем случае BlackBox с низкой сопутствующих объяснений, почему всё не так, как он хочет) Лоска нет, одни шероховатости. Я занимаюсь Обероном с 2007 года, одни шероховатости. Даже у MIDletPascal'я есть лоск: набрал прогу из трёх строк, нажал кнопочку Build и получил готовый мидлет. И справка по функциям по F1.
Кто видел среду разработки Monkey-X? Его IDE? Совершенно гибридная штука, вызывает для своей работы MinGW, C# и бог ещё знает что. Android SDK. Тем не менее, масса примеров в комплекте. И та самая кнопочка Build. И справка по F1. А делает один человек. Уже не говоря про автодополнение и подсветку синтаксиса. А ещё — выбор платформы. Открывающийся список, и в нём: винда, андроид, хтмл5, линух и прочее. Вот такое хочу. На Обероне.
Monkey-X получился за счёт гибридизации. Он тупо вызывает внешние компиляторы и утилиты. А мы, оберонщики, трудолюбиво пишем линкеры, разбираем форматы и чураемся всего, что не считаем пуританско-оберонным) И долго ещё будем этим заниматься) А в Monkey тупо готовое юзается. И лоск есть, в отличие от Оберонов, вот что обидно) Я вот никогда не хотел разбираться с форматами obj, exe и т.д. Поэтому я не против компиляторов в натив, но пусть их пишет кто-то ещё, но не я)
Просто так получается, что Оберон вынужден догонять какие-либо другие средства, в том минимальном объёме, в котором его вообще хоть где-то используют.
Всё это сложно. Вот как сделан Patchouli. Он тупо каждый модуль пихает в отдельную dll. Не умеет линковать нормально. И у каждого Оберона есть какой-то косяк. И мэйнстримцы, тёртые калачи, это хорошо понимают.
А Оберон-то юзать хочется. Вот и взялся я за транслятор в Си.
По сути у оберонщиков есть один бзик. Они готовы мириться с кодом посредственного качества, лишь бы он был получен наипростейшим слоем. Я же готов пренебречь лишними уровнями, лишь бы получился приемлемый результат высокого качества. То есть оберонцы за простой компилятор, а я за простой и оптимальный машинный код, полученный благодаря сложному процессу оптимизации.
А ещё я за то, чтобы нажал кнопку — получил мидлет, нажал — получил программу. А сейчас в Native Oberon нажмёшь кнопку — и получишь модуль для ОС, которую никто никогда нигде не использует.
Я читал в рассылке ETH как там один немец по имени Dieter Gloetzel написал утилиту для конвертирования из одного музыкального формата в другой на ETH Oberon. Сяк-так с горем пополам он сумел собрать её для Windows и Linux x86 через местные линкеры, хотя попутно задавал много вопросов в рассылке. Даже если не принимать во внимание то, что утилита его не работает с именами файлов юникодовыми буквами в винде) И на его exe будет ругаться почти любой антивирус. Да, антивирусы ругаются на код, порождённый многими Оберон-линкерами.
Но, в конце концов, буржуяка упёрся в то, что ему нужна была эта утилита для Linux'а не-x86. И он принялся знаете за что? За трансляцию в Си. Но это было не так просто, потому что потребовало потянуть за собой пол-ETH-Oberon'а. В итоге я не знаю чем дело закончилось, но всё это крайне характерно для Оберон-решений.
Dieter писал(а):
As some of you know I have written an App in ETHOberon 2.5 on Windows, which converts MusicXML into another format and finally to Note sheets.
For reasons of portability I want to translate this App into C language. There seem to be two possible paths to follow:
1. Converting my app to Oberon 2 and then using Ofront as C-Translator
2. Converting my app to Oberon07 and then using Obnc as C-Translator
Does anybody have experience with this type of problem?
Are there further alternatives or other ideas?
Мне нужен мультитаргетный Оберон. Причём было бы идеально, если бы новые таргеты можно было описывать на простом уровне. Я уже давно с этим определился. Пока такого нет — я плотно сижу на трансляции в Си. Хотя я ничем таким серьёзным на Обероне и не занимаюсь на самом деле, всё для души. Иное дело команда Ильи Ермакова, они BlackBox используют в коммерческой разработке, и это ограничивает их в железках, Илья говорил. Даже хотели поюзать транслятор КП-в-Си, потому что наработаны решения на КП, а завести их сейчас можно только на архитектуре x86.
Какой я вижу выход из ситуации? Хотелось бы, чтобы оберонщики больше консолидировались вокруг больших и серьёзных проектов, но наступать на горло своей песне, да ещё и без финансирования — это так не в природе человеческой...