OberonCore

Вы же говорили про заработок, а не про продажи, как одного из способа заработка

Поверю в доход от продаж суппорта и бинарей, но каким магическим образом закрытый код материализует деньги?
Открытые. Каждый волен исследовать и изменять код.
И я абсолютно уверен что разработчики того же gcc не откажут в пояснении непонятных моментов в кишках gcc.

Отличный опрос! Многие оберонщики не удовлетворены качеством доступных имеющихся Оберон-компиляторов. Есть "эталонные", самый Оберон-мэнйстрим, например, BlackBox. Но это совсем не значит, что все готовы пользоваться только им. У него свои ограничения, в частности, по поддержке разных архитектур. Чуть-чуть спасает то, что на платформах x64 можно запускать код от x86.

Мы уже примерно видим, что больше всего людей за доработку готового открытого компилятора. Какого именно? Давайте выскажемся по этому вопросу. Я считаю, он должен быть максимально портабельным и мультитаргетным. И путём наименьшего сопротивления здесь было бы разработать на основе готового фронт-энда новый бэк-энд к LLVM. Работа слишком трудоёмкая, чтобы ею занимались люди на энтузиазме. А хватит ли пороху, чтобы вообще вести такую работу на энтузиазме? Разработка компилятора требует инженерной дисциплины, большого набора тестов. Есть у нас эти тесты? Нету. Разработка тестов это тоже большая работа.

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

Пробиваем барьер сложности? Ну что тут сказать. Кому и кобыла невеста, а кому Оберон хорош и с полуторами недоработанными библиотеками, поддержкой одной платформы и компилятором для очень старого процессора. Вопрос вкуса. Я тоже люблю простоту, но у меня чешутся руки взять Оберон для тех задач, для которых сейчас приходится брать что-то другое.

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

P.S. Нам бы также что-то подобное для Оберона: http://www.drkb.ru

Взять VSCode, прикрутить к нему CLang, дописать плагин к VSCode для Оберона,
дописать к нему конвертер из Оберона в CLang.
Каркас - готов! Работает - ВЕЗДЕ.
Основная трудоемкость - писать плагин для Оберона.
Тут надо делать весь нужный учет и контроль.
Остальное пишется быстро - силами студентов 3 курса вполне осиливается за 1-2 семестра.

Если юзать биткод llvm, а не интерфейс на крестах, то и не так-то и проблемно должно быть. Эффективно генерировать инструкции не надо, распределять регистры не надо. Т. е. не сложнее чем сделать кодогенератор в jvm. А может даже и проще за счёт дополнительной свободы доступа к низкоуровневым штукам.

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

Забавно, что когда он только появился, говорили, что это хороший, прогрессивный способ избежать высокой сложности GCC.

Не-не, это кардинально НЕ ТОТ каркас.

Почему LLVM, когда есть своё-родное IR в A2? К тому же не монструозное. И насколько я понял, там уже и Оберон-07 поддерживается. 32/64 бита до кучи, ARM...
Но А2 традиционно испытывает неоднозначный интерес...

Потому-что в llvm куча готовых бакэндов, оптимизация. Впрочем, можно транслировать Fox-IR в LLVM-IR.
в А2 традиционно всё плохо с документацией, приходится тратить время на низкоуровневое "копание" в коде, чтобы понять, как оно там работает и правильно ли это вообще работает. ну и по понятным причинам уровень сложности несколько выше - для мозга, вмещающего только четыре десятка ключевых слов это практически непосильная задача.

Я тоже об этом думал. По-идее должно быть не слишком сложно.
Да, система постоянно развивается. Что-бы быть в курсе изменений, нужно быть постоянно в неё погруженным

Что забавного? Это и сейчас верно.

"Простите, не нам а Вам".

Это потом можно будет использовать? Кстати, есть какие-нибудь численные результаты по использованию семантического редактора?

Главное, что всего этого не будет. Кому это очень нужно, не стоит тратить время на Оберон.

Можно пока фронтэнд написать к Оберону. Пока решим с кодогенерацией уже будет где её опробывать.

Про недостатки с монструозностью и постоянной переменчивостью LLVM — соглашусь.

Тогда в качестве бэк-энда с максимальной мультитаргетностью, по-моему, остаётся только трансляция в Си, т.е. Ofront+. Вот его-то и надо присобачивать к VSCode. Опять же, кому нужно.

Ещё слово за Ofront+: есть поддержка Оберона, Оберона-2, готовится для Оберона-07 и КП. Для продакшена такой подход лишним не будет.

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

В каком смысле - численные?
Мы сравниваем на примере курсовых.
На семантике пишут первую курсовую. Какой-нить тренажер типа работа с восьмеричными числами.
Особых проблем с написанием не наблюдается - пишут на русской лексике практически все.
Кто изучал в школе программирование - тот быстро переходит на англоязычную лексику.
Не все сдают вовремя, но 50-75% - сдают.

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

А вот во 2-м семестре у них на С++ курсовая.
И вот тут начинаются реальные проблемы.
Ибо среда профессиональная, кнопочек - как в кабине самолета приборов.
И язык - с массой подводных камней.
И сама курсовая, конечно, сложнее.
Тут уже вовремя сдают не более 25%. Да еще норовят содрать один у другого.

Мы вот решили на 2 семестр сделать некую переходную среду - англоязычный семантик с переводом в С++.
И чтоб можно было видеть обе программы в редакторе.

А со 2 курса уже полноценно включать С++.
Там тоже 2 курсовых: по ООП, и по алгоритмам.

В общем, пока вывод тот самый, который я в докладе на конференции делал.
У Ермакова слайды должны быть. Или я пришлю.

К примеру, замеряли время выполнения задания для разных сред, и в семантическом редакторе воплощали готовый продукт в среднем в 2.32 раза.
Но если сравнивали с С++ да ещё и не на сопоставимых задачах, то не интересно

Время сейчас особо не позамеряешь - лабы делаются практически всегда дома. А на занятия приходят, если вопросы появились.
Да и министрВство нам подгаживает - разрешено не выгонять ГОД.
Сильно развращает студентов-середняков. Кому интересно - так и работает нормально.
Но таких - единицы.
А середняки расслабляются неслабо... )))
Хвосты - потом сдам, не к спеху типа.
Отсюда - проблемы.

Точно не мне.