Рассуждения о развитии Оберон-технологий в сложившихся условиях.
Цитата:
XDev использует транслятор в Си, а меня интересует натив.
Я тоже не являюсь большим сторонником звена промежуточных представлений между языком и машинным кодом, из него генерируемым. Но сейчас в условиях такого маленького Оберон-социума тянуть:- а) нативы большого и всё увеличивающегося количества старых и новых платформ, а заодно:
- b) форматы исполняемых файлов (ELF, PE, DEX, .class/JAR и т.п.)
Как мы понимаем, это попытка повторить то, что уже сделано на других средствах. Вечно плестись в хвосте как Mono за .NET'ом. Сначала смотрят чего делает MS, потом повторяют.
Если думаете, что сделать хороший кодогенератор можно быстро и малыми силами, то это блажь. Только два примера: Small Device C Compiler (довольно качественный кодогенератор для Z80, сделанный за многие годы активной коллективной работы, но и он далёк от совершенства! За последний месяц только я зарепортил туда 3 ошибки) и TinyCC (кодогенератор довольно неэффективный, но если хотите составить впечатление о сложности работы, то посмотрите в рассылке сколько туда постится баг-репортов! Над ним активно трудится команда — ~20 человек).
Не, если бы было человек 10 в команде разработки, тогда ладно. Но заинтересованных и отмотивированных. Так что связка с Си — перманентная временная мера, костыль, без которого пока не обойтись. Ведь построить компилятор с качеством кодогенерации, сопоставимым с XDS — невероятно сложная задача. А мы и так имеем массу компиляторов-поделок Оберона. Хорошо проделанный путь энтузиаста (часто самоучки). Но кодогенерация, расширяемость и прочее — часто не на высоте.
Вот и остаётся быть мечтателем, энтузиастом собственного кодогенератора или всё же прагматиком. И в этом свете путь трансляции в Си — не роскошь, а суровая необходимость. Но главное в другом. Я не испытываю большой тяги многие годы заниматься тонкостями кодогенерации, предпочитая сконцентрировать усилия на библиотеках и интеграции с существующими технологиями, в т.ч. и аппаратными, разумеется.
Ещё с XDev достигается одна важная цель — накопление массива исходников на Обероне (и библиотек на Си). Так проще связывать Оберон с готовыми мэйнстрим-средствами. Без этого Оберон будет вещь в себе. Сферические кони в вакууме.
Считаю всё же — лучше делать что-то через трансляцию в Си, чем просто вздыхать и ждать идеального Оберона с библиотеками и нативом под все платформы.
Теперь о достоинствах подхода через трансляцию в Си.
Любой несколькоязычный компилятор, уже не говоря если он кроссплатформенный, будь то даже XDS или GPCP имеет (сюрприз!) промежуточное представление кода. Только в XDS оно наглухо закрыто, а в GPCP — нет (но разбираться с ним всё равно никто не будет; эдакая морока). В то же время, готовое стандартизированное промежуточное представление в виде текста на языке Си имеет в глазах вопрошающего важный недостаток — его можно читать глазками и править. Очень интересно! Оказывается это недостаток. Отсутствие прямой генерации в натив, заметьте. Да если бы я ждал компилятора для Z80 в натив, то не было бы и этого форума!
Есть ещё на мой взгляд важный недостаток. Это медленная трансляция Си-программ. Тут уже ничего не поделаешь, приходится мириться. Зато: есть готовый аппарат, дающий механизмы формирования новых библиотек, готовые высококачественные кодогенераторы под массу платформ (включая ретро) и готовые линкеры в готовые форматы. Есть ещё один плюс: мы можем получить в ближайшем будущем в составе XDev два новых языка — это Компонентный Паскаль и Объектная Модула-2. И это всё через трансляцию в Си. А сколько времени мы бы ждали поддержки кодогенерации языка N именно в это внутреннее представление для малоизвестного и никому не нужного компилятора M?
А угадайте кто легче и скорее перейдёт барьер x86-64 — Active Oberon, BlackBox, ETH Oberon/OPCL, компиляторы Оберона-07 энтузиастов Акрона и Рифата, та даже XDS с их рулезным нативом, или всё-таки XDev с его трансляцией в Си? Тото же.
Вот вам и трансляция в Си, господа.
Остаётся конечно ещё вариант кодогенерации с использованием готовых бэк-эндов LLVM или GCC, но будьте спокойны: этим занимаются K John Gough (Gardens Point Component Pascal) и Benjamin Kowarsch (Modula-2 Revision 2010, Objective Modula-2). Думаю, у них получится это сделать лучше, чем смог бы я один (ведь когда я среди знакомых оберонщиков кинул клич как раз за реализацию этой идеи, чтобы собрать хотя бы ядро в пару человек — все предпочли отмолчаться, из чего я сделал вывод, что в основном текущий Оберон-социум слабоват на такие проекты; и надо искать для продвижения Оберонов другие пути).
Цитата:
Зачем программировать на Обероне с трансляцией в Си, если можно писать прямо на Си?
Я читал многообъёмные талмуды "Как не следует кодировать на Си" (Ален Голуб, Стив Макконнелл и другие гуру). Так вот Оберон — это не только удобный язык с приятным синтаксисом. Это ещё и шаблон правильного стиля кодирования, заданного языком довольно жёстко. Он может по вашей воле добавлять в код проверки на корректность там, где вам даже не придумается их вставить, причём сделает это автоматически. Впрочем, проблему надёжности кода начали осознавать и сишники, например, в TinyCC введена опция контроля границ массивов. В Обероне всё это есть уже давно.Оберон — красивый и гармоничный язык, ставший таким не в последнюю очередь из-за разумного отказа от излишеств и рудиментов, к которым мы привыкли. У меня масса причин работать именно в контексте Оберон-технологий. Об этом можно говорить много и долго. Если вы с открытым умом приступите к изучению этой языковой платформы, вы поймёте её достоинства и самобытную её прелесть.
Но мы идём дальше. Мы не собираемся следовать установленным канонам, а пересматриваем их. И делаем это сознательно, с высоты полученного практического опыта. Поэтому языку Си отводится то место, где он сильнее всего — низкоуровневое программирование, где красиво смотрятся все эти #ifdef, #include и inline. Где наработана богатейшая традиция, на которой выросло не одно поколение системных программистов. Что является тормозом для новых парадигм (Оберон, я слышал, тоже очень неплох для системного программирования. Доказательств тому — масса).
Для высокоуровневой разработки я приемлю Оберон, и думаю добавить в него постепенно всё, что действительно понадобится в рамках этой языковой базы. И надеюсь, я буду не один пожинать плоды такого подхода. Да, нам нравится работать на Обероне. Мы признаём красоту идей Вирта и магию Оберона. Поэтому мы используем Си как плечи гиганта, на которых воздвигаем новую парадигму. Почему бы нет.
Поэтому, перефразируя тему: зачем писать на Си, если есть Оберон?
Цитата:
Дело в том, что я не сторонник дотошного следования стандарту языка Оберон. Мне нравится сам подход, исходный, так сказать, посыл. И не вижу ничего зазорного в том, чтобы что-то изменить в стандарте языка. Пусть в результате он будет Оберон 8, или совсем по другому называться, но главное суть — маленький, быстрый, модульный, строгий. В Обероне нет необходимости тянуть совместимость с прошлыми версиями. Даже Вирт эту совместимость не тянет. Это имеет смысл когда есть ОГРОМНЫЕ наработки. Сейчас всё идет с нуля.
Верно, подписываюсь под каждым словом.И пересмотр стандарта я бы начал с уточнения FOR, как это предлагает Saferoll.