OberonCore

Простой синтаксис проще понимать.
Минимум нюансов и частностей - проще понимать.
Граммотно составленный исходник проще понимать.

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

Если написать на ББ пошаговый отладчик? Удовлетворит ли это "поклонников" отладчика? А вот когда напишут, окажется, что нужен он будет, только как картина на стене, которая дырку закрывает, чисто для галочки... Хотя, возможно, некоторый толк от него будет.

Т.е. назначение пошагового отладчика может оказаться не совсем тем, какое предполагалось.
Вместе с тем, пользу от применения пошагового отладчика для понимания чужого кода я бы не стал преувеличивать.
По крайней мере - для модульного языка вроде Оберона. Для понимания (а не отладки) используемого модуля достаточно понимания его интерфейса, а детали реализации не важны (здесь работает абстракция).
Что касается понимания алгоритма в рамках одного модуля, то здесь, как правило, нет больших проблем, т.к. глубина вызовов небольшая. (Исключение составляют некоторые рекурсивные алгоритмы, вроде синтаксического разбора или бэктрекинга, но основные схемы таких алгоритмов хорошо известны.)
IMHO, конечно.

Вот именно. Претензия "а в ББ нет отладчика" звучит в данном контексте по-другому: "у нас есть проблема с дурно написанным кодом, и нам нужен инструмент, хоть немного облегчающий понимание такого кода".

Тут уже вопрос - откуда берётся плохо написанный текст.

С одной стороны, имеем либертарианский, "вольный" подход к написанию программ и пошаговый отладчик как компенсацию побочных эффектов. С другой стороны оберон-подход. Модульность, абстрагирование, надёжный язык, которые изначально направлены на создание правильных текстов.

Это оч-чень похоже на столкновении двух религий. И филиокве тут не поможет

Для этого прежде всего надо уметь подменять команды в точках останова на вызов отладчика (следовательно, знать адреса строк/операторов после загрузки модуля).
Для выдачи значений переменных, вероятно, можно использовать существующий отладчик ББ или его слегка модифицированную копию.
После возврата из отладчика продолжить выполнение программы до следующей точки останова.
Это, конечно, при условии, что у кого-нибудь найдутся время и энтузиазм.

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

про отладчик была пара тем:
Действительно, общие вопросы
Пошаговый отладчик? - Сделаем пошаговый просмотровщик...

Наколбасить трудный для понимания код можно в любом языке, даже на Обероне. Да и сам Оберон никак не способствует дисциплине программирования, это все миф, что Оберон способствует кристальной ясности кода. Все зависит от головы и рук программиста.
К примеру, на сайте у Зинна есть подсистема XY. По сути, это библиотека-обёртка для вызова графических функций, используя WinAPI. Откройте модуль XYLifeModel. Товарищ заюзал SYSTEM.Move() для быстрого копирования массивов. Смысл? Где варнинги?

Зависеть-то зависит. Но и "никак не способствует" - тоже неверно.
Хотя бы: не получив никаких способов завершить досрочно цикл (ни goto, ни break), человек либо будет вынужден научиться правильно этот цикл строить (обратившись к умным книжкам или умным людям), либо завязать с Обероном и пойти его хаять "по городам и весям", что в нём даже break-а нет
И в том, и в другом случае экосистема Оберона избавляется от программиста, не умеющего правильно строить циклы

И что тут сложного в цикле LOOP... END, если начинающие на Обероне так долго въезжают? Это их проблема или проблема Оберона, что не могут поставить в нужном месте EXIT, чтобы разорвать цикл?

LOOP - честный цикл, он не обещает какого-либо постусловия цикла. Как бы говорит: "Смотри в оба!"
А вот в Обероне-07 этих "поблажек" больше нет. Цикл LOOP исключен, а оператор RETURN стал часть завершения процедуры (т.е. его в цикл не вставишь).
Интересно было бы посмотреть на реальный код на O-07. Ведь, наверное, не так легко все циклы сделать правильными.

Начинающим вообще про LOOP знать не следует, также, как и про SYSTEM. И применяется LOOP в полгода раз, и только в таких случаях, которые новичку никак не встретятся.
А переходящих сразу настораживает, что конструкция полностью "ручная" (только явные выходы изнутри). На каждый день применять неудобно. Самое главное, что любимую "дубину" for+break из рук вышибли. А без for и EXIT не мил. Приходится что-то переосмыслять, земля под ногами плывёт просто

Не знаю, я ни разу в своей практике не использовал LOOP.
Даже КА строю REPEAT ... UNTIL state # exit;

Как это?? (нервно теребя 8-ю лекцию) Нет, на самом деле, как это??

Ну... (с предчувствием беды глядя на то, как info21 нервно теребит 8-ю лекцию ) ...я не говорю о линейном поиске.
Но изредка попадаются такие гадкие циклы, что хочется выйти прямо из их середины (не в дверь, так в окно). Или выйти из вложенного цикла.
Можно, конечно, попытаться преобразовать цикл. Например, повторить какой-то кусок кода дважды - до цикла и в его теле. Или завести вспомогательную переменную-флаг и проверять ее во всех вложенных циклах.
Но это как-то отягощает цикл, усложняет его понимание.
Да и пацаны будут код читать - засмеют...
(Внезапно расхрабрившись) Да что циклы... Вот в Обероне нет стандартного способа выхода сразу из нескольких вложенных вызовов процедур (речь идет не о HALT, прерывающем выполнение команды и передающем управление основному циклу системы).
Простой пример: пишу DLL с обработкой сложного запроса. В какой-то момент выясняется, что запрос некорректен (хотя бы синтаксически). Что мне делать? В DLL я хальтом не отделаюсь... Вот я и пишу на Си++, где есть исключения (если сильно повезет - на O-2 от XDS, там есть EXCEPT). А всего-то ведь нужно аккуратно вернуть управление вызывающей программе с каким-нибудь утешительным текстом (вроде "сам дурак" ).

Почему это не обсуждаем? В BB это можно сделать только изменив исходник. А хочется:
1) Сделать "это" в уже запущенной программе (да, я знаю, что в BB понятие "программы" отлично от общепринятого, но тем не менее оно там тоже есть).
2) Продолжить выполнение после "этого".
3) Избежать ненужной модификации исходного кода (да, это может стать ненужной проблемой).

Дак... Есть же еще в лекциях и про слияние, и про инвариант цикла, и про общий цикл Дейкстры.
Не говоря про пример того, как использование паттерна "генератор" тривиализует разработку кратного цикла со сложным условием выхода...

Ох... Вот я совершенно недавно исправлял баг в системе ВебСервер (джаваскрипт) + виндовый сервис (C++). Все это модифицировалось последний раз 5 лет назад и как это работает уже никто не помнит (а я вообще к этой системе никакого отношения никогда не имел). Давайте представим, что там все исходники (100%) правильно составлены (хотя это, естественно, не так). И чего? Вы будете месяц(ы) изучать миллионы строк правильного кода + соответствующие технологии (я в джаваскрипте и в веб-программировании вообще ни в зуб ногой)? Только не надо рассказывать, что все это решается и без дебагера. Решается, но с дебагером быстрее. Логов меньше писать/анализировать да по исходникам прыгать...

P.S. Эх... не в правильных циклах счастье... Это все кишки, которые никому не интересны.

Все случаи, когда у меня возникало непреодолимое желание пошагово исследовать поведение программы, в итоге решались перепроектированием (и всегда с приятным упрощением).
А рефлексия неизменно приводила к однозначному выводу: нужно просто грамотно делать программу. Грамотно -- значит, выстраивать логику, инварианты и проч.

---
Можно попытаться суммировать предыдущие годы дискуссий так.
Пошаговый инструмент нужен когда:
1) темный язык;
2) хреновый компилятор;
3) какие-то сугубо специфические ситуации типа с кросс-компилированием (AVC) или типа с чужим бинарником (Тёмный Джек) -- но тут и инструмент особый нужен.

При ясном языке и надежном компиляторе отладчик только мешает.
А уверенность в коде приходит только от логической верификации (=грамотного построения), после нахождения простейшего решения. Такую программу и тестами нагрузить приятно.

А зачем грузить тестами логически верифицированную программу?

Как зачем? Удовольствие получать.