Сначала, надо уяснить, что Oberon-07, это язык, предназначенный для быстрой реализации с минимальными затратами и сравнительно эффективного применения в случае простейшей реализации. В связи с этим, все разговоры об умных компиляторах, современных средствах отладки, шаблонах, замыканиях и т. д. лишены смысла. Многие недостатки языка либо упрощают реализацию, либо упрощают отладку в условиях, когда есть только голый компилятор без каких-либо инструментов.
Полностью согласен. Ещё нюанс - до кучи оно еще оптимизировано под то, чтобы писать в одиночку и без IDE. Собственно как Вирт и работает над системой Оберон. В этом плане язык весьма неплохо продуман и довольно удобен.
- ран-тайм проверки (индексы, указатели). Замедляют и так небыстрые программы. Но оказывают неоценимую помощь, позволяют быстро выявить такие ошибки, которые бывает очень трудно найти без пошагового отладчика и прочих средств. Вряд ли я хоть что-нибудь написал бы на O7 без них. Конечно, люди разные, есть и такие, которые могут кодировать сразу без ошибок на любом языке, но я к таким не отношусь.
Это всё же не часть языка, в сообщении о языке про это ничего не сказано. Это часть Оберона как операционки. Ну и, бывает полезно иметь возможность их отключать.
- сильная типизация. Тоже отлавливает очень много ошибок. И да, упрощает реализацию ).
Согласен.
- единственный выход из процедуры, отсутствие прерываний циклов. Спорная фича. Затрудняет кодинг, увеличивает размер и снижает эффективность кода, немного упрощает отладку.
Идея визуализации потока управления через "отступы". Это работает не очень хорошо на таком уровне, мягко говоря.
- обязательная квалификация идентификаторов. На первый взгляд, избыточно. Раздувает и без того не очень компактный оберон-код. Но вот, как-то мне надо было просмотреть одну программу на паскале, так я задолбался искать процедуры по всем модулям. Конечно, эту проблему легко решает IDE, но ведь я говорю о простейшей реализации...
С одной стороны полезная штука, с другой стороны, можно было сделать более человечески - разрешить использовать идентификаторы без квалификации если они в импортах были явным образом перечислены. Т.е. что-то вроде IMPORT (function1, typeT, somthingElse) from MyModule, MyModule; -- тут можно без квалификации будет использовать function1, typeT, somethingElse а все остальное из модуля MyModule придется использовать с квалификатором: MyModule.something .
То есть можно было сделать лучше, можно но не обязательно, ибо ресурсы у реализатора ограничены - всё делаем в одно лицо.
- SET. Применяется нечасто, но бывает полезен, когда надо упаковать несколько булевских значений в одну переменную, чтобы не раздувать список параметров.
SET я использовал (при программировании микроконтроллеров) для работы с битиками. Весьма удобно. Железяки иногда требуют записи определенных битиков в определенные места - вот для этого оно вполне ничего себе.
- Беззнаковое целое. Я ни разу не пожалел о его отсутствии. Конечно, бывают случаи, когда этот тип был бы полезен, но для 32-битной реализации это бывает нечасто. Для 64-бит, ИМХО, вообще "не стОит выделки".
Стоит выделки. См. задачку например. Т.е. на моей практике регулярно попадается что-то такое, что требует именно беззнакового целого. И не из за того, что оно в два раза более емкое чем знаковое. Т.е. востребованность беззнаковых типов сильно зависит от множества задач решаемых человеком. Некоторым программистам наверняка беззнаковые и не потребуются, но если вдруг потребуются, будет неприятно.