OberonCore

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

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

Мне думается, что выбор более "готового" средства разработки "из коробки" (передача контроля над средством разработки полностью в руки "третьей силы") вызван полным нежеланием в процессе работы над проектом отвлекаться на само средство разработки. И пусть даже развитие средства разработки может быть повёрнуто "третьей силой" "не в ту сторону" — это никого не смущает. Так мы получаем проекты, которые можно собрать, к примеру, только определённой версией Borland C++ Builder.

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

И, опять же, многие разработчики исходят из того, что "где-то в этом готовом средстве разработки фича X уже сделана, и не надо делать снова". Хотя чем крупнее разрабатываемый проект — тем, как правило, больше смысла делать его на средстве разработки, которое сам полностью контролируешь на всех уровнях. Лично моё мнение. А на практике 99% коллективов всё равно выбирают другие средства, готовые. По разным причинам, даже не всегда связанным с навязыванием их менеджерами, далёкими от программирования. Ещё ведь есть аспект "платформы X и программных средств для её поддержки производителем": например, Android и Android SDK. Ну кто переплюнет Android SDK на Обероне? В лучшем случае, можно к нему пристыковаться, но кривенько, самопально. Вот и получается, что у нас чаще проекты встраиваются в готовую инфраструктуру, поэтому для них разрабатывать на заточенных под эти инфраструктуры средствах — просто тупо проще для программистов и экономически выгоднее для менеджеров. Вот когда каждый второй проект будет мало завязан на интеграции в существующие инфраструктуры — тогда может будет больше смысла проектировать всё с нуля на Обероне. Да и то — делать это именно на Обероне смогут (и захотят) только те программисты, кто понимает достоинства Оберона. Или те, у кого к Оберону (Паскалю) привязки из ВУЗа или школы.

Ещё судя по моему пиару среды разработки XDev на форуме ZX-PK.ru, люди попросту не понимают зачем транслировать Оберон в Си, если можно сразу писать на Си. И таких людей не так уж и мало. И объяснить им что-то чрезвычайно сложно. В процессе такого диалога всё обычно скатывается в срачики "Паскаль vs Си", "Страуструп vs Вирт", "реальное программирование в продакшене" vs "академическое теоретизирование" и т.п. В конце концов, это надоедает. Надо с младых ногтей оберонщиков формировать. И тогда пусть мы даже не получим широкое использование самого Оберона, но такие программисты будут всё равно тяготеть к более правильным инструментам разработки, что в целом благоприятно скажется на отрасли.

Олег правильно сказал, что есть среды, которые уже являются "родными" для какой-то среды. И их сложно превзойти в плане поддерживаемых возможностей. И про то, что некоторые не понимают, почему сразу не разрабатывать в Си. По сути, трансляция одного языка в другой язык заставляет знать программистов сразу два языка, что увеличивает сложность. Поэтому многие думают, зачем мне разбираться с особенностями двух языков, если достаточно разобраться с одним языком, без которого все равно нельзя обойтись. Лично мне примерно по этим же причинам не нравятся трансляторы одного языка в другой. Я думаю, что если нравится Оберон, то надо на нем создавать программы, а не транслировать в какое-то промежуточное представление, ведь это тоже ухудшает какие-то параметры, например, на чистом Оберона можно сделать Mark&Sweep сборщик мусора, а при трансляции в Си надо уже использовать другой сборщик мусора, который получится использовать из Си.

Коллеги, Вы, на мой взгляд, отвечаете совсем не на тот вопрос.
1. Если люди хотят использовать X, то естественно, они не захотят использовать транслятор Oberon в X. Но я спрашивал не об этом.
2. Если программирование сводится, в основном, к связке готовых решений(SDK, framework, rich library), то, естественно, бессмысленно связываться с чем-то кроме предложенного, так как роль самого языка кода уже невелика. Но я спрашивал и не об этом.

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

1. С Mark&Sweep сборщиком мусора в С нет никаких проблем. Или я что-то путаю?
2. Правильно ли я понимаю, что если бы понадобилось предоставить написанный код на C, Вы бы предпочли написать его на C, а не сгенерировать из Oberon, потому что код Oberon->C->машина будет в чём-то хуже, чем Oberon->машина?

Можно подробнее? Было требование предоставить код на C, которое удалось удовлетворить таким способом?

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

Кстати, транслятор в ЯВУ обслуживать на несколько порядков легче, чем в нативный код. Это тоже немаловажно. Под первое хватит ремесленника типа меня. Но под второе нужен специально обученный (и желательно талантливый) человек с особым складом ума.

Неа. В случае 1) было просто требование решить задачу пофиг на чём. А в случае 2) задача уже была реализована на КП, надо было только перевести её на 64-битность. Тут-то и пригодилась поддержка КП в Ofront+. К счастью, тащить весь ББ не пришлось. Ofront+ пока не умеет генерировать мета-информацию для модулей в духе BlackBox или CPfront. Я над этим ещё думаю.

Не хватет транслятора X -> Oberon.

А мне не надо в общем и не надо за других.

Иногда сигара, это только сигара. А конкретный вопрос - это только конкретный вопрос.

Конечно, нет. Вы же используете другие языки для работы? Значит, чего-то не хватает. И я, например, использую, трансляторы, но не сказал бы, что мне всего хватает.

Вы переоцениваете задачу и недооцениваете себя. Спросим у независимого эксперта - adimetrius, что скажете о порядке сложности КП->JS и КП->AMD64?

Какой именно X? Правильно ли я понимаю, что речь о проектах с поддержкой, где нет концентрированного нового кода, а есть только размазанный по уже созданному?

Я не эксперт (пока:). JS-синтезатор - это один модуль; АМД-синтезатор - с полдюжины.
Субъективно - JS занял 2 месяца, АМД уже 8. Конечно, в АМД и задач гораздо больше и проработка их серьезнее, в т.ч. тестовая инфраструктура 1-1,5 мес. Полтора-два месяца ушли на борьбу с PE и ELF. Но в целом мое ощущение - в АМД синтезатор объемнее => декомпозиция на много модулей, т.е. сложнее.

Если не эксперт, тем лучше в контексте вопроса. То есть, разница не на 2-3 порядка(в 100-1000 раз), а в 4-8 раза, то есть, на те же 2-3 порядка, но в двоичной системе.

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

Для хобби-проектов, притом довольно разношёрстных, средств Ofront'а+ более чем достаточно. А чего нет, но оно вписывается в существующий набор идей, то я доделываю на коленке, и уже много чего сделано.

А не хватает: нормальной библиотеки для создания GUI-программ, желательно с возможностью конструировать интерфейс мышкой; поддержки самых нужных платформ, в частности, мобильных; хорошего пошагового отладчика; удобного IDE в стиле Delphi, где всё из коробки, чтобы проекты собирались одним нажатием кнопки Build; не хватает простого и мощного веб-фреймворка, на котором легко клепать сайты; не хватает целой кучи нормальных библиотек, из-за чего приходится припиливаться к сишным и прочим.

Да Вы и сами всё это знаете. Но это не из-за недостатков фич в языке или даже в трансляторе.

Лично для меня не так страшен Х, как его экосистема. После доклада Д.В.Дагаева хотел опробовать одну идею, для нее нужен некий эмскриптен. Вынудили скачать 1ГБ неизвестночего. Сделал все по инструкции, и с первого же раза незавелось. И что теперь? Копаться сидеть в ихнем миллиарде байт? Чтобы потом выяснить, что на моей убунте, например, нужно волшебное слово сказать, без которого не заводится? Нет уж, увольте.

Для меня ЖС в определенном смысле - низкоуровневая архитектура, поскольку "ниже" ЖС не приходится спускаться, это браузер делает прозрачно для меня. В этом смысле КП->ЖС это не трансляция в промежуточную форму, которую нужно еще потом куда-то транслировать, а это "прямой" транслятор; как и КП->АМД64.

И еще, чаще всего же авторы экосистемы Х - с марсианскими мозгами. Вот например ELF. Есть спецификация, она чего-то там позволяет (уже не помню детали). А есть реализация, она этого не позволяет, спотыкается. Я спрашиваю (спецов на стаковерфлоу): как же так?! А мне в ответ: ты чо, марсианин? спецификация - это одно, а загрузчик - это совсем другое; авторы загрузчика не обязаны исполнять требования спецификации.

И это - риск, в т.ч. бизнес-риск: поменяют что-то в экосистеме Х - это потянет изменения в трансляторе Оберон->Х.

"Заметьте, не я это предложил"

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

Что касается Востока, раз уж Вы затронули эту тему, то он никогда не был ответом на вопрос, чего не мне не хватает в Обероне из mainstream, а был ответом, хотя и не ограничивался им в единстве ближних и дальних целей, на противоположный вопрос - чего мне не хватает в mainstream, из-за чего нужно использовать Обероно-подобный язык. Здесь подобие используется в широком смысле, т.е. не сводится к пресловутым BEGIN END. Это было заявлено прямым текстом в первом же сообщении соответствующего блога.

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

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

ЖС - это и есть частный случай X. Кто-то хотел X, они его получили.

О том и вопрос к людям. Зачем вы колетесь, но используете X, если хотите Oberon? Чего конкретно не хватает?

Прям как везде, включая инфраструктуру Oberon.

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

Дело в том, что "думают" и "так оно и есть" - это разные вещи.
Таких примеров несколько, но главным я считаю следующий Oberon, у которого была и mainstream IDE - MS Visual Studio, был и прямой доступ к широчайшему mainstream framework вместе с сателитами - .NET, и проникновение "must have" возможностей в язык - это Zonnon. Кстати, где он?

Знаю, что некоторые разработчики хотят сделать или уже делают ещё IDE для Oberon, и это хорошо. Стоило бы даже обсудить это в отдельной теме. Но! Если это делается с целью сделать то, из-за чего люди, наконец, начнут пользоваться Oberon массово, то не стоит - это не поможет.

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

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

В любом случае надо развивать инструментарий, так как прогресс не стоит на месте.