OberonCore

Статический анализ (то, что минимально грамотный программер на автомате делает, работая на Обероне/КП) нашел ошибку в OpenSSL -- high severity risk.

https://www.theregister.co.uk/2020/04/2 ... erability/

Как обычно у носителей манипулятивно-комбинаторного интеллектуса, задача решается меганашлёпкой -- статическим анализатором в GCC 10.

Можете прояснить мысль?
Исправление выглядит так:Что спасает от такой ошибки минимально грамотного писателя на Обероне?

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

Привыкнуть можно к чему угодно, но ресурс привычка будет съедать, и обнаружится это только вот в такой ситуёвине.

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

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

На уровне языка такие ошибки тоже режутся. У носителей манипулятивно-комбинаторного интеллектуса, не связанных с потребностью поддерживать совместимость полувекового наследия, популярны вариации Option type. Такая вещь, введённая ad hoc, усложняет язык и транслятор, но повышает ошибкоустойчивость. Ошибкоустойчивые конструкции, которые не усложняют язык и транслятор, почти исчерпаны самим Обероном, поэтому я не вижу иного выхода кроме усложнения языка, если хочется больше автоматического контроля.

Насчет ошибок у грамотных программеров.
В далеком примерно 1984 году работали мы с Авророй - писали ось бортовую.
На ассемблере. К тому времени у меня было уже около 15 лет стажа самой разнообразной работы,
в том числе на ассемблере и даже в кодах.
Сидим как-то вечером вдвоем с другом-начальником в подвале Авроры, пишем проги.
Написал я функцию в 22 команды. Запускаю - не работает!
22 команды - ошибаться просто негде! При почти 15 лет стажа.
Лев - говорю - что за фигня?!
Он - ищи 2 ошибки.
Я - почему?
он - 10% кода всегда ошибочные...
И ведь через полчаса после тщательной ручной прокрутки покомандно я нашел 2 ошибки...

Еще могу сказать: всегда ошибался в repeat-until на паскале.
Поэтому на С++ в do-while не ошибаюсь никогда - там как в while - do

Ошибки - это индивидуально

Согласен, но не вижу противоречия сказанному мною.

Прозрачность и "защитность" Оберона позволяет программисту перевести фокус своего умственного процесса с дежукинга на доказательность, и разница получается качественная.

***

Кстати, не хватает слова для ключевого понятия, вышеобозначенного в кавычках.
Робастность?
Надо бы что-то, что входит в мозг как шило в пенопласт.

Не, робастность - иностранный термин. Или научный.
Надо попроще.
Безглючность

Безглючность -- это свойство самого компилятора.

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

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

Если я правильно понимаю, то в Блэкбоксе такая ошибка привела к аварийной остановке при первом обращении к неразмещенному указателю и выявили бы её давным давно.

О способности языков+компиляторов защищать от тривиальных ошибок - читал уже давно. Поднимался вопрос, да.
Но терминов придумано не было.
Обращалось внимание, что язык должен быть боле дружественным к программисту и не позволять ему совершать дурацкие ошибки. Собственно RUST возник как некоторый ответ на эту проблему.
Английский термин есть какой-нибудь?

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

Спасибо за разъяснение. Наверное, я понял посыл Фёдора Васильевича.
Если в голове остаётся место для анализатора, то и ошибки такого рода реже появляются.
У меня нет статистики и забавных примеров, а вот у ФВ есть много в запасе.
Однако загрузка головы связана не только со сложностью инструментов и языков.
Еще много других факторов.

А строгий? Rigorous? Вирт использует это слово по отношению к своим языкам, в частности в его гугл-лекции неоднократно.

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

На мой взгляд, это в гораздо большей степени полезно не при написании нового кода, а при рефакторинге старого. А рефакторить приходится примерно всегда - чужой код и свой код, написанный 3 месяца назад. Преподавая же программирование, обычно фокусируются как раз на новом коде; поэтому ценность строгости учащимся труднее осознать.

Еще в Блэкбоксе есть анализатор, который подобные баги ищет.

На мой взгляд, можно использовать термин "ergonomic language" или "ergonomical language", что означает people-friendly.
Кроме того, это значит "удовлетворяющий требованиям когнитивной эргономики".

На форуме относительно недавно упоминали новый компилятор от Huawei. Результаты его статического анализа позволяют выдвинуть претензии к особенностям языка, способствующим появлению ошибок. Напр.:
https://habr.com/ru/company/pvs-studio/blog/478284/

Перечисления OP_intrinsiccall и OP_intrinsiccallassigned имеют ненулевые значения, в итоге условие всегда детерминировано как положительное, else-часть содержит недостижимый код.


С другой стороны, отсутствие в Паскаль/Оберон "если как выражение" это не только "защита", но и игнорирование удобств для пользователя (конечно же, не на каждый чих нужен immediate if). В Ada, например, "встроенный if" (и "встроенный for") аля:

Среди языков, авторы которого награждают своё творение титулом "робастный", вспоминается Zig, как раз "иностранный" (альтернатива C/C++/Rust и пр.):
https://ziglang.org/documentation/master/

Как правило, вариативные результаты запаковываются в опциональные типы (указатели также по сути есть вариативный тип), для чего имеется соответствующая система типизации и вспомогательные облегчающие средства для "доставания" значений из упаковки, явного указания компилятору "уверенности" разработчика (мол "здесь всё в порядке и лишние проверки ненужны") и пр. Иными словами, язык максимально "нагибает" в compiletime и старается как можно меньше допускать ситуаций с "паникой/"исключением". Аварийный останов, по сути-то, есть крах системы, что не вяжется с робастностью. В Оберонах проще язык, но защита больше основана на авостах.

За что люблю этот форум, так это за то, что тут можно увидеть ссылки на интересные языки программирования. То V промелькнул, теперь Zig.

Правда, V под Виндой у меня так ни разу и не запустлся, сколько разных версий я ни пробовал.

А чего там интересного?
Один раз пролистать какого-нибудь Баррона -- и на всю жизнь оскомина.