ну такие только на железе можно делать

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

ну еще gpu есть

Но всегда встаёт вопрос экономической эффективности

Дебаггер просто есть, а писать супер хороший код дорого и долгого

Пара мыслей вдогонку вчерашнему разговору.

1. Я тут недавно писал что-то на C и внезапно вспомнил, насколько же это страшно неудобно, когда ты не можешь покрутить отдельный кусочек кода, а должен писать огромный код, потом весь целиком его запускать и верить, что ты нигде не ошибся. Думаю, что дебаггер для компилируемых языков был как раз ответом на эту проблему, по сути давая возможность работать с языком в интерпретируемом режиме. Ну и здесь поэтому и лежит частично ответ на вопрос, как можно жить без дебаггера - используйте REPL, это и есть ваш дебаггер. Язык уже имеет возможность запускать отдельные куски кода и исследовать получающиеся объекты, по сути это и есть то, что даёт дебаггер.

2. Разумеется есть и отличие у простого REPL от дебаггера. В дебаггере вы можете добежать до какой-то точки программы за один проход, а если это делать руками, то нужно воспроизводить множество промежуточных шагов. Ну и если есть какая-то большая сложная функция, которая внутри себя создаёт много промежуточных структур, то их тоже может быть достаточно затруднительно воспроизвести, выглядит как довольно много лишней работы.

Но тут хочу сравнить с немного другой вещью. В питоне есть рекомендация, писать строки не шире 80 символов. Когда я поначалу с этим столкнулся, то меня это ужасно раздражало, я думал "что за ерунда и наследие 90-х годов, у нас уже давно гораздо больше на экран влезает". Однако, когда я начал придерживаться этого правила, то внезапно выяснил, что оно тянет за собой много чего. По другому начинаешь структурировать программу, перекомпонуешь какие-то куски кода, чтобы не было глубоких вложений, что-то выносишь в функции-хелперы и так далее. И на выходе, получается не просто код шириной в 80 символов, а получается гораздо более легко читаемый и более лего рефакторизуемый код.

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

Извиняюсь за стену текста 😊))

1. Тут по сути мне надо выполнять часть работы интерпретатора, с дебаггером удобнее)

принтовать = дебаггер?)

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

Ммм... Да, я хотел заключительную мысль написать, что я не хочу доказывать лучше дебаггер или хуже, нужен он или нет. Просто его использование или неиспользование ведёт к двум разным стилям разработки. Ну а дальше как говорится, все фломастеры на вкус разные.

И я, если что, согласен, что без дебаггера жить можно. Но все по ситуации, если у меня упадет прод, код можно прогнать в дебаге, то я буду против того, чтобы от него отказываться

Я скорее за комбинирование, писать стараться так, чтобы дебаг был не нужен, но инструмент этот нужно держать наготове

ещё кстати Rebugger есть

REPL debugger

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

У меня опыт отладки совершенно разных вещей. Туда входят и варианты с пошаговой отладки ранних C++/OWL программ, когда ещё не было кэша прекомпиляции и время сборки было чуть ли не до получаса. И C-сборки во всяких маршрутизаторах, когда вообще никакого варианта пошаговой отладки просто потому, что нет у этих микроконтроллеров достаточных флешки/оперативки под них, а любая пересборка значит не просто пересборку программы, но и перепрошивку устройства. Или же надо отладить протокол взаимодействия, где критичны задержки….  Ну и разные варианты скриптовых языков. Привыкается со временем 🙂

Кстати, а кто какие тестовые обвязки использует для проектов на С++?

И всегда ли они привязаны к конкретной IDE?

не буду комментировать. Уже лет 10 ничего на С++ не пишу. Последнее, что писал - были Qt программы