Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Думаю что ты не пишешь ничего сложного просто (no offence). Попробуй поработать над действительно сложным чем-нибудь и сразу появится необходимость в отладчике. Когда я работаю над прикладными приложениями, то отладчиком не пользуюсь. Чаще всего хватает логов и анализа исходников (даже отладочная печать не нужна, т.к. это форма отладки). Когда я работал над реализацией B-tree в колоночной OLAP системе — использовал отладчик постоянно. Отладочная печать не секйлится, ты там получишь столько выхлопа в stdout что придется писать приложение для его анализа. Движущихся частей очень много, даже отдельный блок Б-дерева в реальной СУБД — довольно сложная штука с кучей стейта, там есть сжатие, поиск, поиск без полного разжатия, интерполяция, concurrency control.
Помимо анализа состояния отладчик можно использовать и для того, чтобы смоделировать какие-нибудь ситуации. Ну например интересно тебе, что будет если потоки изменят состояние переменных в определенном порядке — ставишь точки останова, фризишь потоки по очереди, сначала исполняешь один поток, фризишь, потом другой — можно race condition так смоделировать очень легко. В системе с оптимистичным concurrency control так очень многие баги можно воспроизвести. Всякие элементарные проверки, вроде — что будет если клиент зависнет, отвалится ли все по таймауту и тд. Ну или нужно тебе понять, что будет если с диска прочитается битый блок и контрольная сумма не сойдется. Портить реальный блок? Зачем, если можно под отладчиком поменять контрольную сумму и посмотреть как программа отработает эту ошибку? Так можно моделировать очень многие вещи, всякие редкие ошибки ввода-вывода например. Т.е. понятно что должны быть автоматизированные тесты, но даже когда ты добавляешь тест, ты должен удостовериться в том, что тест ловит то что нужно, это проще всего сделать под отладчиком, смоделировать ошибку под отладчиком и посмотреть что тест реально работает или просто потрассировать тест и убедиться что он реально что-то тестирует так как ты думаешь.
Еще отладчик, это единственный способ разобраться в проблеме после того как приложение упало. Postmortem debugging никто не отменял. Есть еще всякие неприятные штуки, вроде порчи памяти или стека. Ты не локализуешь эту проблему без нормальных отладочных инструментов (aka valgrind, или asan). Та же ситуация с багами многопоточности.
В общем, я считаю что программисты, говорящие кругом о том что они не пользуются отладчиком вовсе не познали дзен, а наоборот. Им просто пока везло.
Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
Сейчас пишу в основном на C++, Python и JS, и вместо debugger'а прибегаю к отладочной печати в Release-сборке (ну, это если мы про C++, например, говорим).
Сейчас, когда задумался, вроде бы и плюсы нашёл:
Банально меньше проверять. Так мы должны протестировать Debug-сборку, а потом ещё и Release.
Нет необходимости привыкать к особенностям работы какого-то отладчика. Вывод в лог / stdout универсален, т.к. реализуется обычно средствами языка или его стандартной библиотеки.
Легче "отлаживать" многопоточные приложения. Во-первых, меньше вероятность изменить поведение программы из-за уменьшения "производительности" приложения в Debug-сборке (да, логгирование тоже может повлиять, но, как показывает практика, гораздо меньше, чем запущенный отладчик или бряки). Во-вторых, в логах явно будет прослеживаться параллельная работа потоков, легче отследить взаимосвязь и меньше контекста придётся запоминать самостоятельно.
???
Есть, конечно, у такого подхода и минусы. Если сходу, то на ум приходит:
Если надо часто узнавать контекст приложения в какие-то моменты времени (значения переменных, элементов коллекций и т.д.), то окно "Variables" в отладчике гораздо удобнее и быстрее реализуется. Да, если перегружать операторы вывода / преобразования к строке для каждого имеющегося объекта, то ещё ничего, но я так обычно не делаю.
Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release.
???
Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Для шарпа всё просто, т.к. там инструментарий здорового человека. Подрубился к уже запущенному процессу / запустил под отладчиком, поставил точки останова, нашёл-поправил налету ошибку, отрубился. Done.
В 90% случаев даж точек останова не требуется, расставленные ассерты сами прерывают выполнение в нужном месте.
Если этого нет — каменный век, да.
Ну и понятно, что собственно обнаружение / воспроизведение ошибок лучше делать тестами, для отладки оставлять только диагностику и исправление (если ошибка тривиальная м легко чинится).
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, зачем же так утрировать...
Для КСВ, разумеется.
LVV>Помнится, когда мы переходили на с перфокарт дисплеи, я сам отметил, что перестал думать над программой глубоко: проще попробовать непосредственно во время работы набрать вариант на клавиатуре...
Это когда на машине ресурсов хватает. А то, помню, на ЕС 1033 главной консолью был РИН 609. Примус на ней даже не пытались запустить. Все либо только с перфокарт, либо мегаредактор IEBUPDTE, если программа уже в библиотеке исходников. Плюс драки за машинное время на планерках. У нас компьютеризация поздно началась, так что застал.
LVV>Я тут в Астрахани в 90-х зарплату видел на одном заводе... LVV>Пришлось ихних программистов учить.
На Паскале? Я тоже какую-то видел. Та, которой я занимался, была на порядок лучше. И это был Бэйсик на Искре-226. Но накладные расходы при разработке — лучше я промолчу.
LVV>Ну, ты ж старый мастодонт, как и я. А нынешние формошлепщики в этом точно не разобрались бы.
Я сейчас тоже формошлепствую иногда. Там хороший юзабилист нужен. И внимание разработчика к деталям. Не забывать, что, кроме мыши, народ пользуется клавиатурой. А то ведь запустишь что-нибудь, и можно ставки на тотализаторе делать, какое поле активным станет при следующем нажатии на TAB..
Здравствуйте, b0r3d0m, Вы писали:
B>Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
B>Сейчас пишу в основном на C++, Python и JS, и вместо debugger'а прибегаю к отладочной печати в Release-сборке (ну, это если мы про C++, например, говорим).
... B>А вы что думаете?
Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи.
Здравствуйте, b0r3d0m, Вы писали:
B>Есть, конечно, у такого подхода и минусы. Если сходу, то на ум приходит: B> Если надо часто узнавать контекст приложения в какие-то моменты времени (значения переменных, элементов коллекций и т.д.), B> то окно "Variables" в отладчике гораздо удобнее и быстрее реализуется.
трейс-логи? удобнее окана variables. там не только переменные можно смотреть в различные моменты времени (причем, автоматически без пошаговой отладчки и точек останова) но и control-flow (это когда по каким-то причинам программа не заходит в нужный вам цикл или преждевременно выходит из него -- графический control-flow, построенный скриптом на питоне на базе трейс-логов, намного быстрее покажет).
и тут мы приходим к более важным вопросам. вы внесли изменения в программу и что-то там поломали. скажем, функция foo не вызывается или вызывается через раз. как найти где собака порылась? сравнение трейс-логов до и после изменений покажут вам разницу. искать будет намного проще, быстрее, надежнее. интерактивный отладчик в принципе способен на такое, но либо прогонять старую и новую версию в параллель на двух больших мониторах, либо же трассировать по памяти.
B> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время.
autotools вы не используете? зачем ее убирать? она же просто отключается. автоматически.
B> На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release.
debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм.
B> А вы что думаете?
мне нравится ход ваших мыслей. отладчик, безусловно, полезен в определенных ситуациях, но когда у вас в руках молоток, то все кажется гвоздями. ну или это как забивать гвозди логарифмической линейкой.
я не против отладчиков. я против тех, кто не хочет расширять свой кругозор и тратит на интерактивную отладчку часы, когда работу можно выполнить за минуты.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, b0r3d0m, Вы писали:
B>>А вы что думаете?
L>Я тут давно в роли городского сумасшедшего выступаю на этой ниве. При разработке отладчик и правда не нужен. Использование его — контрпродуктивно.
при разработке проекта с нуля без кривых зависимостей или с зависммостями, покрытыми тестами и с хорошей документацией.
FTFY.
а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
Здравствуйте, b0r3d0m, Вы писали:
A>>У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает. B>Что-то не понял. Пример можно?
Здравствуйте, b0r3d0m, Вы писали:
_>>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи. B>Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных...
Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...)
Принципиальное изменение логики без исходников (обычно используются специализированные отладчики).
Здравствуйте, b0r3d0m, Вы писали:
B>Так я тоже ими пользуюсь, просто со временем всё реже и реже.
Опыт видимо, у меня тоже так — если скомпилилось — то 99,999999% код без багов. Но сказать, что они не нужны — это нонсенс. В случае чего я лучше пройдусь отладчиком и за пару минут пофикшу баг (со всеми удобствами, когда видно всё-всё execution окружение/состояние), чем буду ковыряться в логах.
А то, что можно и без отладчика жить — то можно, но зачем? (также можно и без IDE, профайлеров и т.д.)
B>А вы что думаете?
В систему BlackBox Component Builder отладчик не включен сознательно. Пользуются assert'ами.
Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден:
провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим.
Есть задачи, в которых отладчик бесполезен.
Например, матрица заполняется методом монте-карло.
На маленьких матрицах типа 10 на 10 еще можно посмотреть процесс.
А на реальных матрицах размера 10000 на 10000 — нереально.
Приходится продумывать отладочную инфраструктуру и писать отладочные функции...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>В систему BlackBox Component Builder отладчик не включен сознательно. Пользуются assert'ами.
Экий артефакт... LVV>Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден: LVV>провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим.
И где сейчас этот ваш оберон, стал мейнстримом уже? Или так и остался игрушкой фанатиков, никому кроме них не нужной?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Когда я работал над реализацией B-tree в колоночной OLAP системе — использовал отладчик постоянно.
Отлично покрывается юнит-тестами.
CK>Помимо анализа состояния отладчик можно использовать и для того, чтобы смоделировать какие-нибудь ситуации.
С помощю автотестов можно смоделировать любые ситуации, которые можно смоделировать отладчиком. И огромное количество ситуаций, которые отладчиком смоделировать либо невозможно, либо очень сложно/очень долго/очень запарно.
CK>Ну например интересно тебе, что будет если потоки изменят состояние переменных в определенном порядке — ставишь точки останова, фризишь потоки по очереди, сначала исполняешь один поток, фризишь, потом другой — можно race condition так смоделировать очень легко.
При всем уважении, но это называется "закат солнца вручную".
CK>Еще отладчик, это единственный способ разобраться в проблеме после того как приложение упало.
Если нужно именно разобраться и починить, то как раз не единственный.
Правда, колстек все равно нужен.
_>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи.
Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
N>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных...
Ничоси "помощь". Надо дополнительно запоминать команды отладчика, научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами) и т.д.
N>Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...)
Если они header-only, то да. А как Вы отладите какие-нибудь lib / dll-файлы по-нормальному?
N>Принципиальное изменение логики без исходников (обычно используются специализированные отладчики).
Попахивает, нет? Впрочем, это субъективное мнение.
P>Если тебе не нужны — не пользуй
Спасибо, что разрешили!
P>а мы всё же будем пользоваться достижениями прогресса.
Так я тоже ими пользуюсь, просто со временем всё реже и реже.
Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Да вобщем нечто кэповское — отладчики нужны тогда, которая для упрощения поиска багов требуется мониторить большое количество переменных одновременно — в отладчике это удобнее, чем печать. У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает.
Здравствуйте, b0r3d0m, Вы писали:
N>>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных... B>Ничоси "помощь". Надо дополнительно запоминать команды отладчика
Их крайне мало. Step over, step in, continue, toggle breakpoint.
Иногда ещё и step out. Но все в меню есть, основная идея понимается за минуту, запомнить клавиатурные сокращения — максимум на 20-м вызове каждой команды.
B> научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами)
Махинации? С конфигами?? О каком случае речь??? Step over спасает от захода в любую функцию, неважно, свою или чужую, если в ней не сработал останов.
B> и т.д.
Никакого "и т.д.", всё банальности.
N>>Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...) B>Если они header-only, то да. А как Вы отладите какие-нибудь lib / dll-файлы по-нормальному?
Случай, когда есть исходники, или хотя бы IL. Это не так редко, как кажется со стороны. Хедера тут ни при чём (какие хедера, например, в Python, Java, Javascript, C#?)
N>>Принципиальное изменение логики без исходников (обычно используются специализированные отладчики). B>Попахивает, нет? Впрочем, это субъективное мнение.
ZEN>Это вы ещё автоматизированное тестирование не изучили!
Selenium юзаю, например. Но протестировать можно далеко не всё, и это немного другая стихия.
N>>>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных... B>>Ничоси "помощь". Надо дополнительно запоминать команды отладчика
N>Их крайне мало. Step over, step in, continue, toggle breakpoint. N>Иногда ещё и step out. Но все в меню есть, основная идея понимается за минуту, запомнить клавиатурные сокращения — максимум на 20-м вызове каждой команды.
Особенно круто, когда переключаешься между разными средами, каждая из которых обладает своими хоткеями на обозначенные операции. Переназначить можно не везде, да и время тратит, плюс привыкаешь. Помню, как прыгал между отладчиками в VS и OllyDbg.
B>> научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами)
N>Махинации? С конфигами?? О каком случае речь??? Step over спасает от захода в любую функцию, неважно, свою или чужую, если в ней не сработал останов.
A>Да вобщем нечто кэповское — отладчики нужны тогда, которая для упрощения поиска багов требуется мониторить большое количество переменных одновременно — в отладчике это удобнее, чем печать
Отладчики, кстати, зачастую ещё готовить надо перед таким употреблением. Вспомнить хотя бы отображение C++ коллекций в gdb. Да, один раз сделал и забыл, не спорю, но всё же.
A>У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает.
Что-то не понял. Пример можно?
Здравствуйте, b0r3d0m, Вы писали:
B> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.
B>> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
M>Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.
Ну, я же как раз написал:
>Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым"
Здравствуйте, b0r3d0m, Вы писали:
M>>Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.
B>Ну, я же как раз написал:
>>Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым"
Я о том, что по возможности (если только это не вопрос производительности) ее не надо даже и препроцессингом отключать. Так чтобы включить можно было передачей параметра исполняемому файлу (или в реестре, в конфиге). Очень полезно, если у пользователя что-то заглючило в его конфигурации. Насчет засоренности, можно по разному к этому относиться, да и слегка косметически прикрыть тоже можно.
Здравствуйте, b0r3d0m, Вы писали:
B>Особенно круто, когда переключаешься между разными средами, каждая из которых обладает своими хоткеями на обозначенные операции. Переназначить можно не везде, да и время тратит, плюс привыкаешь. Помню, как прыгал между отладчиками в VS и OllyDbg.
Чел походу бесцельно блуждает по коду не вникая в суть и надеясь случайным образом отладить баг, иначе я не понимаю его проблем. Тут ничем не поможешь, пока он не включит мозг.
LVV>>Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден: LVV>>провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим. Ops>И где сейчас этот ваш оберон, стал мейнстримом уже? Или так и остался игрушкой фанатиков, никому кроме них не нужной?
Мэйнстрим — не обязательно лучшее...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, b0r3d0m, Вы писали:
B>Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
Примерно то же самое. Использую gradle / gulp как системы авоматической сборки + tracing / logging API + тесты. Помогает эффективно писать и отлаживать код в 99 процентах случаев. Все еще редко использую jdb
LVV>>Мэйнстрим — не обязательно лучшее... Ops>Есть такое. Однако мейнстримовость связана в т.ч. с удобством использования, и отсутствие отладчика тут отнюдь не достоинство.
Насчет удобств использования — позвольте усомниться в "кошерности" удобств.
Всякие удобства в конечном итоге ведут к деградации...
И наоборот — всякие неудобства являются развивающим стимулом...
Кроме того, мэйнстрим почти всегда является мэйнстримом от бизнеса, а не от ИТ.
Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.
Бизнес — это дофига рекламы.
А я сильно не люблю, когда мне чего-то рекламой навязывают...
Поэтому часто смотрю по сторонам.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Насчет удобств использования — позвольте усомниться в "кошерности" удобств. LVV>Всякие удобства в конечном итоге ведут к деградации... LVV>И наоборот — всякие неудобства являются развивающим стимулом...
И потому удобства у тебя на дворе. Или все же нет, и ты пользуешься ведущим к деградации, некошерным, но теплым туалетом в квартире?
LVV>Кроме того, мэйнстрим почти всегда является мэйнстримом от бизнеса, а не от ИТ.
Да, бывает и такое. Однако, если взять какой-нибудь питон, или, прости господи, пхп, то они совсем не из-за корпораций и бизнеса приобрели популярность и пошли в мейнстрим.
LVV>Пока паскаль был в универах — типа не было мэйнстрима. Только когда Борланд стала продавать — появился мэйнстрим.
Да нифига. Борланд предложил офигенно удобный на тот момент RAD, а паскаль лишь как клей к нему. И то, мне вот у них билдер куда больше нравился, несмотря на баги и тупые ограничения (спасибо паскалю).
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, b0r3d0m, Вы писали:
_>>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи. B>Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
Какие плюсы у jtag отладчика или осцилографа? Просто инструмент для определённого круга задач.
Если вы вдруг бросили курить это совершенно не означает что все должны последовать вашему примеру.
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я.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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-го века, пришлось разбираться со всем этим. И ничего, не помер.
Ну, ты ж старый мастодонт, как и я. А нынешние формошлепщики в этом точно не разобрались бы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, мыщъх, Вы писали:
М>и тут мы приходим к более важным вопросам. вы внесли изменения в программу и что-то там поломали. скажем, функция foo не вызывается или вызывается через раз. как найти где собака порылась?
Юнит-тесты сами покажут. Все остальное — каменный век.
Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Я тут давно в роли городского сумасшедшего выступаю на этой ниве. При разработке отладчик и правда не нужен. Использование его — контрпродуктивно.
Отладчик — хороший инструмент. Только всякий инструмент хорош для своего предназначения.
Тут его удачно сравнили с ломом. Есть вещи, котрые без лома не сделать.. или не сломать. Ковырять окаменелые говны мамонта на предмет очередного WTF, например. Но вот написание нового кода и верификация его к ним не относятся.
Здравствуйте, b0r3d0m, Вы писали:
B>Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
Многие замечают такое. Называется опыт и долгое время работы в одной области. Стоит радикально сметь область деятельности, как отладчик тут же понадобится, сам собой.
Кстати говоря, очень много 'учителей программированию' после таких наблюдений всерьез задвигают идею о том, что отладчик не нужен вовсе, типа
'я написал гигантскую софтину ХХХ без отладчика, потому и вам отладчик не нужен'
'я умею (пользоваться логами, тестами, компилятором, проектировать), поэтому и вам отладчик не нужен'
Здравствуйте, мыщъх, Вы писали:
B>> На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release. М>debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм.
Здравствуйте, IID, Вы писали:
М>>debug сборка она не только для прогона под отладчиком. в дебаг сборке она сама может себя отлаживать. в частности ловить обращение к освобожденной памяти или выходы за пределы блока. там же практически у всех компиляторов совершенно разный рантайм. IID>+1
Только если уж быть совсем честными по отношению к самим себе, то в нынешних плюсах подобные детские ошибки нужно создавать практически специально.
Это если уж забыть о выделенном. Из чего следует, что в дебаге могут никак не проявляются баги, которые потом портят много крови в релизной сборке.
Вот, кстати, наткнулся однажды на интересное видео о возможностях gdb: https://www.youtube.com/watch?v=PorfLSr3DDI
всего 15 минут, показывает как найти stack corruption используя reverse debugging
Здравствуйте, Privalov, Вы писали:
P>Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше,
QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Здравствуйте, aloch, Вы писали:
A>QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Я не работал с Quick Pascal, но видел Quick C. Насколько я понимаю, MS выпустила его в качестве конкурента Turbo C. Скорость компиляции у него была охренительная. Но на этом все преимущества и заканчивались. Quick C стоил дешевле, но в 90-е в бСССР мало кто этим заморачивался.
MS C был существенно лучше Quick-а. MS C 5.0 еще отставал от Turbo C 2.0, а 6.0 уже выровнял ситуацию.
Правда, у Borland уже был нормальный C++ 2.0, а у MS что-то не получалось. Пока они выпустили свой MS C++ 7.0, у Borland появился C++ 3.0, который уже знал про шаблоны и, ЕМНИП, про исключения.
Документацию к системам от Borland очень быстро перевели на русский. Тоже поспособствовало распространению их продуктов.
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, Privalov, Вы писали:
P>>Кроме Борланд, Паскаль продавали и другие конторы. Та же Микрософт. Но среда у Борланд была намного лучше,
A>QuickPascal от MS, вышедший во времена TP 5 был намного лучше продукта от Borland. В нем была многооконная ИДЕ с поддержкой цветной подсветки кода (у Борланд это появилось в 6.0), была поддержка ООП (раньше, чем вышел TP 5.5). Можно было программировать в режиме VGA 320*200*256 цветов. Почему он не пошел в массы — неизвестно.
Скорее всего из-за сговора — Borland и Microsoft договорились не мешать друг другу.
В конце 1980-х Borland уже играла на поле Microsoft со своим Turbo Basic, конкурируя с QBasic/QuickBASIC.
давйте угадаю, речь о проектах до 10 файлов которые писали только вы?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, nigh, Вы писали:
N>а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, nigh, Вы писали:
N>>а в реальной жызне разработка предполагает ковыряние в кишках кода, который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда.
L>Ой, не наступай на больной мозол
ну вот вы все понимаете и разделяете чужую боль. Зачем же выступать клоуном в этом паноптикуме и агитировать а юнит-тесты против дебаггинга?
Здравствуйте, nigh, Вы писали:
L>>Ой, не наступай на больной мозол N>ну вот вы все понимаете и разделяете чужую боль. Зачем же выступать клоуном в этом паноптикуме и агитировать а юнит-тесты против дебаггинга?
Потому что есть слабая надежда, что кто-то подумает и сделает правильно. И может быть, ковыряться в коде, "который не документирован, не покрыт тестами или делает то, что заявлено не совсем так или не всегда", нужо будеть немного реже.
Там хороший юзабилист нужен. И внимание разработчика к деталям. Не забывать, что, кроме мыши, народ пользуется клавиатурой. А то ведь запустишь что-нибудь, и можно ставки на тотализаторе делать, какое поле активным станет при следующем нажатии на TAB..
.jpg)
