Комментарии 15
сразу закрывает проблему отладки принтами и неумение многих программеров пользоваться дебагером.

Интересно, в чем проблема с отладкой принтами?
Я практически всегда отлаживаюсь принтами и только очень редко лезу в дебаггер.
ИМХО, принты примерно в 10^3 раз универсальнее и лучше, чем дебаггер.
Самый раздражающий меня — необходимость рестартить после изменения. Хоть и я чаще дебаггером пользуюсь, чем принтами, но с сессией дебаггера иногда этого ограничения нет (с кучей оговорок).
А обычно проблема в том, что отладочные принты легко забыть удалить.
Поэтому если и отлаживать таким образом, то рекомендуют использовать логгер вместо принта, т.к., как минимум, можно извне регулировать уровни.
Забыть, это не проблема, это мелочь. Достоинства перевешивают. Главное достоинство это то, что в многопоточном или многопроцессорном режиме принты печатаются в момент выполнения.
Что касается логгера, то я использую и принты и логгер. Логгер для того, что должно остаться в программе после отладки. Принты, для того, что дожно быть после отладки удалено.
И гораздо быстрее вставить принт в нужные места, чем шагать в дебаггере. ИМХО.
Если в дебаггере надо шагать, то вы делаете что-то неправильно.
По остальному — +- да.
А если не шагать, то чем дебаггер отличается от принта?
Конечно в нужном месте ставим точку останова и потом шагаем и смотрим что к чему. Возможно я что-то и делаю не так, редко использую.
принты (ок, логи) лучше дебагера
1) при отладке многопоточного\процессорного кода еще иногда с дебагером нет тех ошибок, которые есть без дебагера (это иногда решается запуском дебагера над релизной версией, но иногда — и это не помогает).
2) Не на всех платформах вообще есть этот самый дебагер (впрочем сейчас это реже, на самых массовых платформах он все-таки есть).
3) не всегда есть доступ к клиентскому оборудованию для запуска дебагера. Зато «создайте пустой файл print_debug.log, повторите свой сценарий, закройте приложение и пришлите нам этот файл» — это по силам сделать даже австралийскому аборигену (да, был и такой случай в практике).
хмм… а на чем вы код пишете, и где его запускаете, если не нужно рестартить после изменения?
Часто операций «отредактировал\запустил\посмотрел» несколько и они идут подряд. По сути, первые N перезапусков — это проверка гипотез. Часто можно проверять гипотезы непосредственно в дебаггере, подменяя результаты промежуточных вычислений.
Тогда можно их проверять не перезапуская сессию дебаггера через джампы с брейками в точках конца инициализации основного массива используемых данных и точке проверки.

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

К слову: статью отредактировал, чтобы убрать намеки на антагонизм дебаггер-журналирование. Потому что, это, во-первых, не то, что я хочу донести, а во-вторых, подобные противопоставления некорректны, потому что подходов к отладки больше, чем 2.

Очень странное заключение.
Современные IDE, безусловно, не идеальны. Идеальными они вряд ли станут раньше, чем остановится прогресс (да и тогда не станут) — так как всегда есть к чему стремиться, и всегда есть вещи, которые были бы приятны и полезны, но реализация которых экономически не оправдана — дешевле и/или проще сделать ручками.


Например, рабочее окружение (E) в моей практике — результат штучной работы. Ну не стоит оно автоматизации, реально — не стоит. А где стоит, там Докеры и иже с ним IAAC, которые вполне интегрированы в среду разработки.


Я впервые учился на третьем ещё (если не ошибаюсь) Турбо Паскале. Его среда разработки, интегрированная (таки I!) с компилятором и отладчиком весьма далека от того, что я использую сейчас или о чём мечтаю. Является ли заявленная интегрированность данной среды "спекуляцией"? Безусловно, нет!


Спекуляция — это, всё-таки разговор на пустом месте, без реальных обоснований. Несоответствие пусть даже на 100% обоснованному желанию — нормальное состояние для вещей, существующих в объективной реальности.

Вот как раз я и говорю, что рабочее окружение на совести пользователя, и ни о какой «изкоробочности» речи быть не может. А требования — следствие из этого.
О TP — это причина, почему я сделал акцент на современных. Я учился на нем же, там интеграция 100%, простота окружения позволяет.
Про обоснованное желание: описанные (пусть и шапочно) мной потенциальные системы рефакторинга, в общем-то, реализуемы без особого геморроя для отдельно взятого языка.
Построение экспертных систем — это, на самом деле, еще более горячая задача.
Цель статьи не нажаловаться, что, де, ИДЕ плохие, а показать, где можно выкопать решения.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.