Там весь текст прекрасен, но это лучшая шутка за сегодня.

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

Я всего лишь говорю о том, что нет оснований считать, что "пошаговый отладчик - это разврат мозга на уровне импринтинга"

Запишем формулу:
A+B+C=D+E+F

А мне надо заняться, наконец, словарём, ради которого я вообще сюда и зашёл.

рекламную лапшу заказчики снимать с ушей умеют.

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

Работает всегда пара базовая техника+инструмент.

Оберон максимально поддерживает агрессивный рефакторинг на уровне проектирования.

Нигде в этой картине не нужен пошаговый отладчик.

Серьёзнаааа???!!! Покажи мне в репорте, где там про контроль целостности памяти.
Там ещё что=то про шарп было, да ну ты чтооо, погугли хотя бы про утечки памяти и стоны страждущих)))) В Расте сами разработчики говорят, их решение не про утечки, и целостность)))) там тоже утечки и нарушение целостности. Я тебя умоляю, давай не будем доводить до абсурда.
В Обероне нет никаких, еще раз напишу, совершенно никаких, средств для решения описанной тобой проблемы. Если речь сейчас пойдет про сборщик мусора....))))

2) There is no DISPOSE procedure. Memory cannot be deallocated manually, since this would
introduce the safety problem of memory leaks and of dangling pointers, i.e., premature deallocation.
Except for those embedded systems where no dynamic memory is used, or where it can be allocated
once and never needs to be released, an automatic garbage collector is required.

Strangely enough, despite the existence of viable alternatives, many software components — including safety-critical ones — get produced using languages that either provide dynamic safety only, only partial static/dynamic safety, or no safety at all.
Some examples of programming languages in each of the above categories are:
* Static and Dynamic Safety. Oberon [22], garbage-collected versions of Ada 2 , Java [23], Sather [20].
* Dynamic Safety Only. Smalltalk [11], Lisp.
* Partial Static/Dynamic Safety. Pascal, Modula-2, and Ada (using explicit deallocation).
* Unsafe C, C++.

Programming Language

A real-time version of Oberon will be used as the programming language of choice. Oberon is a
descendant of Pascal and was originally designed by N. Wirth in the late 1980s at the ETH Zürich.
Simplicity in combination with full type safety makes this language superior to other languages such
as the C-family and perfectly suitable for the programming of safety-critical systems. Another
significant advantage of our choice is the “malleability” of the language, coming as an immediate
benefit from our complete control of both the compiler and the runtime. For example, constructs for
the support of ONBASS-specific issues such as fault tolerance, reconfiguration capabilities and real
time control may be added freely on demand at any later stage.

As a starting point, Oberon SA will be used. This is a simplified version of the traditional Oberon
language plus embedded systems support. It cannot be emphasized enough again that in sharp contrast
to the usual C-based low-level systems programming culture no “unsafe” features are supported by
Oberon SA, and the virtues of strong type safety and early detection of programming errors at compile
time are maintained uncompromisingly. Most of the kinds of errors that typically lead to runtime
catastrophes and that necessitate the use of complex static analyzers or model checkers are a
conceptual non-issue in Oberon SA programs. In particular, Oberon SA does not support “inline
assembler” code. Instead, some carefully selected low-level features like interrupt procedures and
register access are built into the language in a clear and secure way.

It may be worth noting at this point that the choice of Oberon as an implementation language in
ONBASS influences developers of both system software and application software for the onboard
computer (including gathering and evaluation of flight data) but not or less so developers of auxiliary
software such as development tools and simulators.

Или тут предлагается запретить мысленные размышления о том как поведёт себя алгоритм при тех или иных входных данных?

Меня волнует то, что из-за одного замечания про отладчик уже столько времени идёт всё расширяющееся по набору тем обсуждение, при том, что речь вообще шла о русификаторе BB.

Вы об этом - Словарь переводчиков?

Касаемо того, что профессионалы, на ваш взгляд, туповаты.