Здравствуйте, b0r3d0m, Вы писали:

M>>Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.

B>Ну, я же как раз написал:

>>Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым"

Я о том, что по возможности (если только это не вопрос производительности) ее не надо даже и препроцессингом отключать. Так чтобы включить можно было передачей параметра исполняемому файлу (или в реестре, в конфиге). Очень полезно, если у пользователя что-то заглючило в его конфигурации. Насчет засоренности, можно по разному к этому относиться, да и слегка косметически прикрыть тоже можно.

Здравствуйте, b0r3d0m, Вы писали:

B>Особенно круто, когда переключаешься между разными средами, каждая из которых обладает своими хоткеями на обозначенные операции. Переназначить можно не везде, да и время тратит, плюс привыкаешь. Помню, как прыгал между отладчиками в VS и OllyDbg.

Сам то понимаешь, что это просто мелочные придирки?

B>Например, http://www.cprogramming.com/debugging/visual-studio-msvc-debugging-NoStepInto.html

Чел походу бесцельно блуждает по коду не вникая в суть и надеясь случайным образом отладить баг, иначе я не понимаю его проблем. Тут ничем не поможешь, пока он не включит мозг.

LVV>>Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден:
LVV>>провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим.
Ops>И где сейчас этот ваш оберон, стал мейнстримом уже? Или так и остался игрушкой фанатиков, никому кроме них не нужной?
Мэйнстрим — не обязательно лучшее...

Здравствуйте, LaptevVV, Вы писали:

LVV>Мэйнстрим — не обязательно лучшее...

Есть такое. Однако мейнстримовость связана в т.ч. с удобством использования, и отсутствие отладчика тут отнюдь не достоинство.

Здравствуйте, b0r3d0m, Вы писали:

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

Примерно то же самое. Использую gradle / gulp как системы авоматической сборки + tracing / logging API + тесты. Помогает эффективно писать и отлаживать код в 99 процентах случаев. Все еще редко использую jdb

LVV>>Мэйнстрим — не обязательно лучшее...
Ops>Есть такое. Однако мейнстримовость связана в т.ч. с удобством использования, и отсутствие отладчика тут отнюдь не достоинство.
Насчет удобств использования — позвольте усомниться в "кошерности" удобств.
Всякие удобства в конечном итоге ведут к деградации...
И наоборот — всякие неудобства являются развивающим стимулом...
Кроме того, мэйнстрим почти всегда является мэйнстримом от бизнеса, а не от ИТ.
Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.
Бизнес — это дофига рекламы.
А я сильно не люблю, когда мне чего-то рекламой навязывают...
Поэтому часто смотрю по сторонам.

Здравствуйте, LaptevVV, Вы писали:

LVV>Насчет удобств использования — позвольте усомниться в "кошерности" удобств.
LVV>Всякие удобства в конечном итоге ведут к деградации...
LVV>И наоборот — всякие неудобства являются развивающим стимулом...

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

LVV>Кроме того, мэйнстрим почти всегда является мэйнстримом от бизнеса, а не от ИТ.

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

LVV>Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.

Да нифига. Борланд предложил офигенно удобный на тот момент RAD, а паскаль лишь как клей к нему. И то, мне вот у них билдер куда больше нравился, несмотря на баги и тупые ограничения (спасибо паскалю).

Здравствуйте, b0r3d0m, Вы писали:

_>>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи.
B>Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
Какие плюсы у jtag отладчика или осцилографа? Просто инструмент для определённого круга задач.
Если вы вдруг бросили курить это совершенно не означает что все должны последовать вашему примеру.

Здравствуйте, b0r3d0m, Вы писали:

B>Есть, конечно, у такого подхода и минусы. Если сходу, то на ум приходит:
B> Если надо часто узнавать контекст приложения в какие-то моменты времени (значения переменных, элементов коллекций и т.д.),
B> то окно "Variables" в отладчике гораздо удобнее и быстрее реализуется.
трейс-логи? удобнее окана variables. там не только переменные можно смотреть в различные моменты времени (причем, автоматически без пошаговой отладчки и точек останова) но и control-flow (это когда по каким-то причинам программа не заходит в нужный вам цикл или преждевременно выходит из него -- графический control-flow, построенный скриптом на питоне на базе трейс-логов, намного быстрее покажет).

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

B> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время.
autotools вы не используете? зачем ее убирать? она же просто отключается. автоматически.

B> На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release.
debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм.

B> А вы что думаете?
мне нравится ход ваших мыслей. отладчик, безусловно, полезен в определенных ситуациях, но когда у вас в руках молоток, то все кажется гвоздями. ну или это как забивать гвозди логарифмической линейкой.

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

LVV>>Насчет удобств использования — позвольте усомниться в "кошерности" удобств.
LVV>>Всякие удобства в конечном итоге ведут к деградации...
LVV>>И наоборот — всякие неудобства являются развивающим стимулом...
Ops>И потому удобства у тебя на дворе. Или все же нет, и ты пользуешься ведущим к деградации, некошерным, но теплым туалетом в квартире?

В детстве были во дворе.
Сейчас двора нет, приходится пользоваться тем, что есть.
Но ведь я привычный и в поле присесть.
А вот тот, кто пользовался ТОЛЬКО унитазом — он в поле сможет ли?
Или "ср..ть захочешь — штаны снимешь" сработает?
В программировании это частенько не срабатывает.
Формошлепщики практически не способны работать из командной строки...
Удобства развратили.
LVV>>Кроме того, мэйнстрим почти всегда является мэйнстримом от бизнеса, а не от ИТ.
Ops>Да, бывает и такое. Однако, если взять какой-нибудь питон, или, прости господи, пхп, то они совсем не из-за корпораций и бизнеса приобрели популярность и пошли в мейнстрим.
Насчет пхп — улыбнуло "прости, Господи"...
Почему пхп в мэйнстриме — я понятия не имею.
Наверное потому, что порог вхождения мал, и туда рванула масса малоквалифицированных программеров?
По Питону — вопроос: в каком мэнстриме он плыет?
Хотя литературы по нему море. И у меня есть достаточно много прекрасных книжек.
Но каков его мэйнстрим — не представляю.

LVV>>Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.
Ops>Да нифига. Борланд предложил офигенно удобный на тот момент RAD, а паскаль лишь как клей к нему. И то, мне вот у них билдер куда больше нравился, несмотря на баги и тупые ограничения (спасибо паскалю).
А почему он взял паскаль, а не фортран?
У билдера хелп прекрасный. Остальное — плохо.

Здравствуйте, LaptevVV, Вы писали:

LVV>Или "ср..ть захочешь — штаны снимешь" сработает?
Можно и не снимать. Вопрос-то в удобстве.
LVV>В программировании это частенько не срабатывает.
LVV>Формошлепщики практически не способны работать из командной строки...
LVV>Удобства развратили.
Да брехня. Просто не надо противопоставлять и бросаться в крайности. Для одних задач удобны одни инструменты, а для других — другие. Мне вот в консоли приходится довольно часто работать, но в то же время, я на нее не молюсь и не отказываюсь от удобных гуевых инструментов, на всякие труЪ-юниксовые фетиши, вроде vim, "отлично работающие на говне мамонта vt52", не покупаюсь.
LVV>Почему пхп в мэйнстриме — я понятия не имею.
LVV>Наверное потому, что порог вхождения мал, и туда рванула масса малоквалифицированных программеров?
Порог вхождения — это в т.ч. и удобство.
LVV>Но каков его мэйнстрим — не представляю.
По сравнению с паскалем — очень даже мэйнстрим.

LVV>А почему он взял паскаль, а не фортран?
А хз, взял и взял. А как делфи сдох, так и паскаль стал историей. В отличие от.
LVV>У билдера хелп прекрасный. Остальное — плохо.
Да говно там хелп, стоит только копнуть.

Здравствуйте, b0r3d0m, Вы писали:

N>>>>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных...
B>>>Ничоси "помощь". Надо дополнительно запоминать команды отладчика

N>>Их крайне мало. Step over, step in, continue, toggle breakpoint.
N>>Иногда ещё и step out. Но все в меню есть, основная идея понимается за минуту, запомнить клавиатурные сокращения — максимум на 20-м вызове каждой команды.

B>Особенно круто, когда переключаешься между разными средами, каждая из которых обладает своими хоткеями на обозначенные операции. Переназначить можно не везде, да и время тратит, плюс привыкаешь. Помню, как прыгал между отладчиками в VS и OllyDbg.

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

B>>> научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами)

N>>Махинации? С конфигами?? О каком случае речь??? Step over спасает от захода в любую функцию, неважно, свою или чужую, если в ней не сработал останов.

B>Например, http://www.cprogramming.com/debugging/visual-studio-msvc-debugging-NoStepInto.html

А, то есть нужно сделать step into для одной функции из нескольких, вызов которых записан в строке? Тогда варианты:
1. Если видишь, что зашёл не туда — сделать просто step out, для того эта команда и придумана. Ну да, пару лишних нажатий.
2. Запинать авторов отладчика, чтобы давали вариант — открывается мини-диалог, в котором выбираешь, в какие именно функции из тех, что тут можно зайти, заходить на этот раз. (Например, набором checkbox'ов.) Это особенно полезно, если учесть, что часть из этих функций окажется результатом раскрытия макроса/шаблона и явно в коде не видна.

А предлагать на такие вещи прописывать что-то в реестр(!) (вместо хотя бы свойств конфигурации сборки в проекте) — это тот же уровень ума. что требовать ребут на сдвиг курсора мыши. Накодивших такое вообще нельзя допускать к любой разработке, даже в говносайтинг. Моё мнение про VS резко упало вниз, спасибо за информацию.

Здравствуйте, netch80, Вы писали:

N>2. Запинать авторов отладчика, чтобы давали вариант — открывается мини-диалог, в котором выбираешь, в какие именно функции из тех, что тут можно зайти, заходить на этот раз.
Вижуалка это кстати умеет. Как минимум 2008я.

Здравствуйте, CreatorCray, Вы писали:

N>>2. Запинать авторов отладчика, чтобы давали вариант — открывается мини-диалог, в котором выбираешь, в какие именно функции из тех, что тут можно зайти, заходить на этот раз.
CC>Вижуалка это кстати умеет. Как минимум 2008я.

Значит, ТС не в курсе и рассказывает про методы 20-летней давности?

Здравствуйте, LaptevVV, Вы писали:

LVV>Насчет удобств использования — позвольте усомниться в "кошерности" удобств.
LVV>Всякие удобства в конечном итоге ведут к деградации...
LVV>И наоборот — всякие неудобства являются развивающим стимулом...

Получается какой-то замкнутый круг. Избавиться от перфокарт, используя возможности виртуальной машины, по-твоему, развивающий стимул. Отлично, согласен. Но в таких условиях программисту не нужно помнить наизусть все свои пакеты-задания на случай, если его разбудят в 2 часа ночи и скажут, что 5-я карта застряла в считывателе (6012) и нет возможности прочитать, как она подписана. Это деградация программиста? Следует вернуться обратно к считывателям? А считыватель 6019 не зажевывал карты. Это тоже деградация?

LVV>Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.

Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше, компилятор очень быстрый, и Паскаль от Борланд — это не Паскаль Вирта. Крупный проект, сделанный на этом Паскале, мне известен всего один. Это СУБД Paradox от той же Борланд.

LVV>Бизнес — это дофига рекламы.
LVV>А я сильно не люблю, когда мне чего-то рекламой навязывают...
LVV>Поэтому часто смотрю по сторонам.

Конечно. Однако же, мне в качестве описания структур присылали data division (или как оно там называется) на Коболе. Разработчики на рекламу не повелись, и продолжали пилить свой проект дальше, а не переделывать с нуля на современные технологии. И это тоже бизнес. А мне, разбалованному GUI и прочими плюшками 21-го века, пришлось разбираться со всем этим. И ничего, не помер.

LVV>>И наоборот — всякие неудобства являются развивающим стимулом...
P>Получается какой-то замкнутый круг. Избавиться от перфокарт, используя возможности виртуальной машины, по-твоему, развивающий стимул. Отлично, согласен. Но в таких условиях программисту не нужно помнить наизусть все свои пакеты-задания на случай, если его разбудят в 2 часа ночи и скажут, что 5-я карта застряла в считывателе (6012) и нет возможности прочитать, как она подписана. Это деградация программиста? Следует вернуться обратно к считывателям? А считыватель 6019 не зажевывал карты. Это тоже деградация?
Ну, зачем же так утрировать...
Помнится, когда мы переходили на с перфокарт дисплеи, я сам отметил, что перестал думать над программой глубоко: проще попробовать непосредственно во время работы набрать вариант на клавиатуре...

LVV>>Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.
P>Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше, компилятор очень быстрый, и Паскаль от Борланд — это не Паскаль Вирта. Крупный проект, сделанный на этом Паскале, мне известен всего один. Это СУБД Paradox от той же Борланд.
Я тут в Астрахани в 90-х зарплату видел на одном заводе...
Пришлось ихних программистов учить.

LVV>>А я сильно не люблю, когда мне чего-то рекламой навязывают...
P>Конечно. Однако же, мне в качестве описания структур присылали data division (или как оно там называется) на Коболе. Разработчики на рекламу не повелись, и продолжали пилить свой проект дальше, а не переделывать с нуля на современные технологии. И это тоже бизнес. А мне, разбалованному GUI и прочими плюшками 21-го века, пришлось разбираться со всем этим. И ничего, не помер.
Ну, ты ж старый мастодонт, как и я. А нынешние формошлепщики в этом точно не разобрались бы.

Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, зачем же так утрировать...

Для КСВ, разумеется.

LVV>Помнится, когда мы переходили на с перфокарт дисплеи, я сам отметил, что перестал думать над программой глубоко: проще попробовать непосредственно во время работы набрать вариант на клавиатуре...

Это когда на машине ресурсов хватает. А то, помню, на ЕС 1033 главной консолью был РИН 609. Примус на ней даже не пытались запустить. Все либо только с перфокарт, либо мегаредактор IEBUPDTE, если программа уже в библиотеке исходников. Плюс драки за машинное время на планерках. У нас компьютеризация поздно началась, так что застал.

LVV>Я тут в Астрахани в 90-х зарплату видел на одном заводе...
LVV>Пришлось ихних программистов учить.

На Паскале? Я тоже какую-то видел. Та, которой я занимался, была на порядок лучше. И это был Бэйсик на Искре-226. Но накладные расходы при разработке — лучше я промолчу.

LVV>Ну, ты ж старый мастодонт, как и я. А нынешние формошлепщики в этом точно не разобрались бы.

Да, я стар. Более того, я суперстар! ©

Я сейчас тоже формошлепствую иногда. Там хороший юзабилист нужен. И внимание разработчика к деталям. Не забывать, что, кроме мыши, народ пользуется клавиатурой. А то ведь запустишь что-нибудь, и можно ставки на тотализаторе делать, какое поле активным станет при следующем нажатии на TAB..

Здравствуйте, b0r3d0m, Вы писали:

B>А вы что думаете?

Думаю что ты не пишешь ничего сложного просто (no offence). Попробуй поработать над действительно сложным чем-нибудь и сразу появится необходимость в отладчике. Когда я работаю над прикладными приложениями, то отладчиком не пользуюсь. Чаще всего хватает логов и анализа исходников (даже отладочная печать не нужна, т.к. это форма отладки). Когда я работал над реализацией B-tree в колоночной OLAP системе — использовал отладчик постоянно. Отладочная печать не секйлится, ты там получишь столько выхлопа в stdout что придется писать приложение для его анализа. Движущихся частей очень много, даже отдельный блок Б-дерева в реальной СУБД — довольно сложная штука с кучей стейта, там есть сжатие, поиск, поиск без полного разжатия, интерполяция, concurrency control.

Помимо анализа состояния отладчик можно использовать и для того, чтобы смоделировать какие-нибудь ситуации. Ну например интересно тебе, что будет если потоки изменят состояние переменных в определенном порядке — ставишь точки останова, фризишь потоки по очереди, сначала исполняешь один поток, фризишь, потом другой — можно race condition так смоделировать очень легко. В системе с оптимистичным concurrency control так очень многие баги можно воспроизвести. Всякие элементарные проверки, вроде — что будет если клиент зависнет, отвалится ли все по таймауту и тд. Ну или нужно тебе понять, что будет если с диска прочитается битый блок и контрольная сумма не сойдется. Портить реальный блок? Зачем, если можно под отладчиком поменять контрольную сумму и посмотреть как программа отработает эту ошибку? Так можно моделировать очень многие вещи, всякие редкие ошибки ввода-вывода например. Т.е. понятно что должны быть автоматизированные тесты, но даже когда ты добавляешь тест, ты должен удостовериться в том, что тест ловит то что нужно, это проще всего сделать под отладчиком, смоделировать ошибку под отладчиком и посмотреть что тест реально работает или просто потрассировать тест и убедиться что он реально что-то тестирует так как ты думаешь.

Еще отладчик, это единственный способ разобраться в проблеме после того как приложение упало. Postmortem debugging никто не отменял. Есть еще всякие неприятные штуки, вроде порчи памяти или стека. Ты не локализуешь эту проблему без нормальных отладочных инструментов (aka valgrind, или asan). Та же ситуация с багами многопоточности.

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

Здравствуйте, мыщъх, Вы писали:

М>и тут мы приходим к более важным вопросам. вы внесли изменения в программу и что-то там поломали. скажем, функция foo не вызывается или вызывается через раз. как найти где собака порылась?

Юнит-тесты сами покажут. Все остальное — каменный век.

Здравствуйте, b0r3d0m, Вы писали:

B>А вы что думаете?

Я тут давно в роли городского сумасшедшего выступаю на этой ниве. При разработке отладчик и правда не нужен. Использование его — контрпродуктивно.

Отладчик — хороший инструмент. Только всякий инструмент хорош для своего предназначения.
Тут его удачно сравнили с ломом. Есть вещи, котрые без лома не сделать.. или не сломать. Ковырять окаменелые говны мамонта на предмет очередного WTF, например. Но вот написание нового кода и верификация его к ним не относятся.