Коллеги, а давайте не идеализировать Оберон-компиляторы с прямой генерацией машинного кода, что-де они такие простые и надёжные. Нам с Олегом Комлевым ещё "посчастливилось" столкнуться с ошибкой деления 64-битных целых чисел в BlackBox 1.6. Несколько серьёзных ошибок Александр Ильин нашёл в XDS за годы работы с ним. Я даже думаю, что их до сих пор никто не исправил.
По личным ощущениям компиляторы с генерацией машкода это некая теневая область, в которую вторгаться не очень любят, и правильно делают. Иными словами, больше проблем с тем, чтобы исправить баг или внести фичу осмысленно. Йозеф Темпл при всём моём уважении не до конца понимает как устроен генератор кода в BlackBox, хотя он сейчас основной разработчик.
Что такого есть у Си, чего нет у Оберона, это, даже в худшем случае, наличие более или менее сносного компилятора практически под каждую архитектуру. А есть компиляторы и очень сильные: Clang, GCC, Intel C. Да, это громадные шкафы, но там решена одна проблема, которая всегда будет у слишком простых компиляторов: рыхлость и низкая эффективность порождаемого машинного кода. Я не могу и не хочу с этим мириться, хотя и не обладаю достаточными ресурсами для разработки серьёзного эффективного компилятора.
Pimbom, теперь по Вашему вопросу. Я боюсь, что нет хорошей реализации Оберона, чтобы можно было строить графические интерфейсы визуально и работать с мультимедиа. Что-то в этом направлении сделано в BlackBox, обязательно посмотрите видео-уроки Ивана Денисова, чтобы примерно понять, подойдёт ли это для Ваших задумок:
В Оберонах масса задач подобного класса ещё ждёт своего решения. Здесь просто крутится очень мало денег или их нет вовсе. Поэтому мы стараемся использовать библиотеки на других языках, например, SDL (которая может использоваться внутри Graph во Free Oberon), просто чтобы облегчить себе жизнь. Для GUI такие библиотеки слишком сложные, чтобы так просто ими пользоваться из Оберона. Хотя можно. Надо экспериментировать. Мне очень понравилась библиотека Nuklear:
Для неё на GitHub ищутся биндинги практически для всех известных языков программирования. Ну кроме Оберона конечно. Вот такое красивое, портабельное и весьма минималистичное решение хотелось бы видеть написанным на Обероне. Что-то подобное разрабатывает и Артур Ефимов. Посмотрим, что у него получится. GUI для текстового режима, на котором работает Free Oberon, уже получилось, и весьма недурно.
Ещё, разумеется, остаётся возможность писать графические интерфейсы на WinAPI, однако это не для слабонервных. И это тупиковый путь, так как поддержка Linux и других систем тоже важна.
Pimbom, и не слишком идеализируйте ни Оберон, ни Аду. Сертификация языка сама по себе ничего не гарантирует, а надёжность "от языка" лишь увеличивает вероятность нахождения багов на ранних стадиях, но программисты делают массу ошибок такого рода, которые компилятор не сможет найти никогда, даже если в него встроить подобие ИИ. А "надёжность передачи и отображения данных чтобы была не меньше, чем при управлении летательными аппаратами" никак не сочетается с веб-браузерами. Сеть может упасть в любой момент или браузер всю память съест.
Оберон сам по себе лишь в какой-то мере придаёт процессу разработки предсказуемость и надёжность, но очень зависит ещё кто и как на нём пишет. В Обероне есть нерешённые проблемы, которые и нельзя решить, не выходя за рамки заявленной простоты: компиляторы никак не предотвращают зацикленную рекурсию, есть неоднозначности с поведением управляющей переменной цикла FOR, да и вообще возможность иметь её не локальной, а сам цикл FOR для простоты описан через WHILE, поэтому всегда будет зациклен для максимального граничного значения типа ( FOR i := n TO MAX(IntType) ), кстати, Йозеф не считает это проблемой, а я считаю.
По Ofront+ скажу, что важно не только вылизывание багов, но и вообще жизнеспособность проекта. Им мы активно занимаемся, используем в своей деятельности, поддерживаем пользователей. Может кто ещё не в курсе, но проект Free Oberon переходит с voc на Ofront+