Comments 33
Всегда мечтал о чем-то подобном в современном мире. Но современном, допустимо не старше 15 лет. Начинал учиться на DOS-программах (на WinXP в эпоху без мобильного и местами без любого интернета) — TurboPascal была первой. Немного ностальгии.
Современные экраны 1280х1024, 1366х768 и больше, на них можно отобразить больше информации, причем часть информации задать графически (что невозможно в текстовом режиме), часть информации открывать динамически — вкладки, спойлеры и другие способы узнать подробности.
Жаль, что многие современные отладчики недалеко ушли от DOS-времен, это при условии если отладчик вообще запустится. Встречались даже отладчики для ЯП высокого уровня, которые предлагают отладку только для ассемблерного кода, т.е. логическую ошибку в них найти без знания ассемблера иной раз невозможно.
Современные экраны 1280х1024, 1366х768 и больше, на них можно отобразить больше информации, причем часть информации задать графически (что невозможно в текстовом режиме), часть информации открывать динамически — вкладки, спойлеры и другие способы узнать подробности.
Жаль, что многие современные отладчики недалеко ушли от DOS-времен, это при условии если отладчик вообще запустится. Встречались даже отладчики для ЯП высокого уровня, которые предлагают отладку только для ассемблерного кода, т.е. логическую ошибку в них найти без знания ассемблера иной раз невозможно.
Честно говоря не совсем понимаю зачем анимация могла бы пригодиться (ну, кроме обучения, естественно). Медитировать на то, как программа работает мне не кажется производительным занятием. Дебаг ведь начинается с построения гипотез. Имея гипотезы можно расставить брейкпойнты как можно ближе к потенциальным ошибкам и (если удача не подведет) этого будет достаточно.
Проход по инструкциям делается только в достаточно узких местах между нормальным о ошибочным брейкпойнтом. И обычно там надо внимательно смотреть чего происходит. На неконтролируемой анимации можно легко чего-то пропустить.
А фишки типа показа важных переменных в зависимости от контекста уже давно в современных IDE есть.
Проход по инструкциям делается только в достаточно узких местах между нормальным о ошибочным брейкпойнтом. И обычно там надо внимательно смотреть чего происходит. На неконтролируемой анимации можно легко чего-то пропустить.
А фишки типа показа важных переменных в зависимости от контекста уже давно в современных IDE есть.
Имея гипотезы можно расставить брейкпойнты как можно ближе к потенциальным ошибкам и (если удача не подведет)Да, если удача не подведет. Иногда с анимацией бывает быстрее и баги найти, и просто в программе разобраться. См.:
Laurie Tunniclife, Melbourne, Australia: «I am an electronics engineer who has been using Pascal professionally and privately for 15 years. I have been recently converting a 6000 line program to Extended Pascal and was having trouble with a part of the code.… I had spent quite a few hours on the problem with traditional debugging techniques which produced a confusing variety of runtime errors… Luckily I had a copy of Dr. Pascal which had an „Extended Pascal switch“ and could run the section of code that was crashing. It took all of 30 second to find the problems. One was my error, the other a compiler bug. Being able to see the variables displayed as I stepped execution of the code enabled me to locate the errors and fix them in record time. It's great to have a tool that supports Standard Pascal and Extended Pascal… From now on, I'll probably run new code on Dr. Pascal first and confirm it's working before adding it to a project.»
6 килолиний кода???
Это или учебный проект или академический. Об этих случаях я не спорю — это другой мир.
В продакшене это вообще ни о чем.
А что не так? 6К строк — слишком мало или слишком много?
Для современного продакшена это ничтожно мало.
Любой современный продукт это сотни тысяч строк, как минимум. Поэтому и используются техники, чтобы этот бардак упорядочить, как архитектурно, так и организационно.
Наверное не стоит 100К строк в один файл впихивать? Лучше делать модули по несколько тысяч строк и отлаживать каждый отдельно.
Спасибо, Капитан Очевидность :-)
Конечно, даже за 6 KLOC неструктурированного кода надо приговаривать архитектора и/или ключевых разработчиков к смертной казни через «тумба-юмба».
Но это не отменяет того факта, что современные продукты содержат сотни тысяч строчек кода. И это задача разработчиков, архитекторов и прочих вовлеченных в деятельность, чтобы это все не привело к коллапсу продукта.
И да, это решается разделением одной большой хрени на множество иерархически (как правило) структурированных мелких хреней.
Но, если мы уж решили это так делить, то делать «атомарную» единицу в 6KLOC выглядит как-то… сомнительно, вам не кажется? Почему не разбить ее на 3 единицы в 2KLOC? А потом каждую на 1 KLOC? И так далее до некоторых величин, чтобы человек мог осознать эту величину просто на нее глядя на экране?
Где-то в 90-х вообще было мнение, что «процедура должна умещаться на одном экране» (напомню, размер экрана был 25 строк, приблизительно).
Просто надо понять, что то, что было круто 20 лет назад сейчас просто не работает.
— поменялись требования — программирование сейчас это не алгоритмы, как правило (академическую среду не рассматриваю, как я уже говорил).
— поменялись возможности — раньше считалось крутым писать «оптимальный код» (ну, там с учетом того, какая переменная пойдет в регистр, где inline функции лучше сделать и т. д.). Сейчас это весьма узкая специализация в embedded, и уже совсем не так выглядит, как раньше.
— поменялась инфраструктура программы. Раньше больше думали об алгоритмах (как я говорил), но совсем не думали о ресурсах. Сейчас больше думают о ресурсах. Уж если мы о Паскале — в Турбо Паскале моего детства sleep был реализован через цикл, который калибровался при старте программы. Сейчас за такое канделябром по голове дают.
Конечно, даже за 6 KLOC неструктурированного кода надо приговаривать архитектора и/или ключевых разработчиков к смертной казни через «тумба-юмба».
Но это не отменяет того факта, что современные продукты содержат сотни тысяч строчек кода. И это задача разработчиков, архитекторов и прочих вовлеченных в деятельность, чтобы это все не привело к коллапсу продукта.
И да, это решается разделением одной большой хрени на множество иерархически (как правило) структурированных мелких хреней.
Но, если мы уж решили это так делить, то делать «атомарную» единицу в 6KLOC выглядит как-то… сомнительно, вам не кажется? Почему не разбить ее на 3 единицы в 2KLOC? А потом каждую на 1 KLOC? И так далее до некоторых величин, чтобы человек мог осознать эту величину просто на нее глядя на экране?
Где-то в 90-х вообще было мнение, что «процедура должна умещаться на одном экране» (напомню, размер экрана был 25 строк, приблизительно).
Просто надо понять, что то, что было круто 20 лет назад сейчас просто не работает.
— поменялись требования — программирование сейчас это не алгоритмы, как правило (академическую среду не рассматриваю, как я уже говорил).
— поменялись возможности — раньше считалось крутым писать «оптимальный код» (ну, там с учетом того, какая переменная пойдет в регистр, где inline функции лучше сделать и т. д.). Сейчас это весьма узкая специализация в embedded, и уже совсем не так выглядит, как раньше.
— поменялась инфраструктура программы. Раньше больше думали об алгоритмах (как я говорил), но совсем не думали о ресурсах. Сейчас больше думают о ресурсах. Уж если мы о Паскале — в Турбо Паскале моего детства sleep был реализован через цикл, который калибровался при старте программы. Сейчас за такое канделябром по голове дают.
Сейчас больше думают о ресурсах.
Уже в MacOS 7.0 (больше 20 лет назад) много думали о ресурсах. Что поделать — GUI.
поменялись возможности — раньше считалось крутым писать «оптимальный код»ИМХО наоборот. Сейчас весь код почти оптимальный. Очень рано возникли правила, типа 1% кода жрет 99% времени, только его и надо оптимизировать. Оптимизировать приходилось руками. А сейчас современные компиляторы научились очень хорошо оптимизировать, отомизируют всё подряд, и, как правило, этого достаточно.
программирование сейчас это не алгоритмыНе понял. Каждая программа это алгоритм + структуры данных.
А потом каждую на 1 KLOC? И так далее до некоторых величин, чтобы человек мог осознать эту величину просто на нее глядя на экране?Чувство меры и здравый смысл никто не отменял.
Где-то в 90-х вообще было мнение, что «процедура должна умещаться на одном экране»Для маленьких программ это и сейчас бывает разумно. Но и в старых программах этому не всегда следовали — см., нпр., процедуру init в статье. Как удобно — так и надо делать.
Сожалею, что приходится говорить очевидные, на мой взгляд, вещи :)
Уже в MacOS 7.0 (больше 20 лет назад) много думали о ресурсах. Что поделать — GUI.
Вы о каких ресурсах??? И при чем тут GUI?
Если что, я про ресурсы энергопотребления и тепловыделения, например. И они стали актуальными с появлением мощных процессоров и массовых автономных устройств. Есть и другие ресурсы, но эти наиболее очевидны)
А сейчас современные компиляторы научились очень хорошо оптимизировать, отомизируют всё подряд, и, как правило, этого достаточно.
Да, компиляторы оптимизируют. Поэтому никто не заморачивается писать «оптимальный» код (с современными архитектурами процессоров это даже несколько проблематично). Ровно то, что я сказал.
Не понял. Каждая программа это алгоритм + структуры данных.
Ну, если вы говорите об академической среде — возможно. Но современный программный продукт это еще и взаимодействие со внешними устройствами и сложной инфраструктурой за пределами программы.
Сожалею, что приходится говорить очевидные, на мой взгляд, вещи :)
Вы о каких ресурсах???
О, да. Забавная непонятка вышла. Я о Resource fork MacOS 7.0 и в виндах понятие «ресурс» есть. Ok. Разобрались:
Если что, я про ресурсы энергопотребления и тепловыделения, например.Память — это ресурс? Если да, то раньше за каждый Кб боролись, что в ОЗУ, что на диске. А энергии в пересчете на 1 Кб та память жрала сильно больше, чем нынешняя. И стоила соответственно. И грелось это в пересчете на 1 Кб умопомрачительно.
Поэтому никто не заморачивается писать «оптимальный» кодДа. Т.е. крутизна оптимального кода осталась, но только она идет бесплатным приложением.
Но современный программный продукт это еще и взаимодействие со внешними устройствами и сложной инфраструктурой за пределами программы.Современный программный продукт может моделировать новое лекарство или нефтяную скважину на суперкомпе, при этом кроме примитивного I/O ничего не иметь, даже подключения к инету. И потом: разве взаимодействие со внешними устройствами это не алгоритм? Одних инет протоколов многие тысячи.
Извините, но это звучит настолько дико, что я даже не знаю с какого конца комментировать.
Поверьте, современное построение программного продукта ушло значительно дальше Вирта.
Почитайте хоть Буча.
Мне кажется вы не занимаетесь производством ПО, верно? :)
Мне кажется вы не занимаетесь производством ПО, верно? :)Вам кажется :)
Почитайте хоть Буча.
Он не сильно моложе Вирта ;)
Поверьте, современное построение программного продукта ушло значительно дальше Вирта.Но сильно лучше не стало. Те же самые проблемы :( Нпр., только вчера…
Хм… Вы парадигмы программирования оцениваете по возрасту тех, кто их продвигает в массы???
И почему вы приводите ссылку на проблему с unmanaged языками, в ответ на мой аргумент, что промышленная разработка ушла далеко???
Да, со времен Вирта появились новые парадигмы. Да, после С и C++ появились managed языки.
Нет, часть кода, всякие низкоуровневые вещи, алгоритмы, пишутся как раньше, и там есть проблемы 30-летней давности. Но «анимация в дебаге» где-то в стеке модема сотового телефона, поверьте, не поможет. Я знаю — я дебажил.
Возможно, ваша область производства ПО… ну, очень сильно отличается от того, с чем я знаком…
И почему вы приводите ссылку на проблему с unmanaged языками, в ответ на мой аргумент, что промышленная разработка ушла далеко???
Да, со времен Вирта появились новые парадигмы. Да, после С и C++ появились managed языки.
Нет, часть кода, всякие низкоуровневые вещи, алгоритмы, пишутся как раньше, и там есть проблемы 30-летней давности. Но «анимация в дебаге» где-то в стеке модема сотового телефона, поверьте, не поможет. Я знаю — я дебажил.
Возможно, ваша область производства ПО… ну, очень сильно отличается от того, с чем я знаком…
Вы парадигмы программирования оцениваете по возрасту тех, кто их продвигает в массы???
Обычно нет, но в данном случае (м.б. мне показалось) Вы намекнули, что Вирт устарел. М.б. и Кнут устарел? ;)
Да, со времен Вирта появились новые парадигмы. Да, после С и C++ появились managed языки.А «managed языки» это парадигма? Или я не понял — гугл отсылает на вики:
Управля́емый код (англ. managed code) — термин, введённый фирмой Microsoft, для обозначения кода программы, исполняемой под «управлением» виртуальной машины .NET[Про .NET, конечно, разные мнения, но ИМХО не вижу, что это было революцией сравнимой со структурной, модульной и ОО. Поправьте, если ошибаюсь.
Но «анимация в дебаге» где-то в стеке модема сотового телефона, поверьте, не поможет. Я знаю — я дебажил.Да. Вот мобильные устройства я не программировал. Поэтому полностью Вам верю. Телефон у меня самый простой и использую только чтобы СМС-пароли из банков получать (т.о. и как пользователю мне сказать тут нечего). А вот такой гаджет как электронная книга ИМХО явно и резко деградирует. Опасаюсь, что файлы скоро опять придется принтовать, как в конце 1990х.
Возможно, ваша область производства ПО… ну, очень сильно отличается от того, с чем я знаком…Нпр., как сказал выше, моделирование новых лекарств.
Кстати, вчитался в цитату — похоже это многое объясняет:
Тут ни слова о профессиональном разработчике — чувак занимается электроникой, и, похоже, использовал программирование для каких-то вспомогательных задач (говно вопрос — не он первый, не он последний).
Т.е. мы видим случай не профессиональной разработки, а именно случай обучения/академии.
I am an electronics engineer who has been using Pascal professionally and privately for 15 years. I have been recently converting a 6000 line program to Extended Pascal and was having trouble with a part of the code
Тут ни слова о профессиональном разработчике — чувак занимается электроникой, и, похоже, использовал программирование для каких-то вспомогательных задач (говно вопрос — не он первый, не он последний).
Т.е. мы видим случай не профессиональной разработки, а именно случай обучения/академии.
Давно сложившаяся общемировая практика — одни учебные заведения выпускают универсальных программистов, другие — программистов, которые являются еще и спецами в определенной предметной области. Таких много, нпр., в квантовой механике, в экономике, в квантовой химии, в мат. химии и т.д. Инженер электроник и программист в одном лице может разрабатывать очень сложные профессиональные программы, нпр., по моделированию новых микропроцессоров. Такие программы, нпр., описаны в публикациях Интела.
Анимация нужна, когда нет возможности остановить программу. Например, для программ управления какой либо промышленной установки.
Ну, это если только в очень узкой сфере, когда скорость исполнения должна быть достаточно быстрой для того, чтобы не получалось нажимать на step, но достаточно медленной, чтобы человек успевал понимать, что происходит.
Как правило, если нельзя останавливаться, дебажутся по логам (хотя в моей практике были случаи, когда даже добавление логов меняло поведение из-за задержки)
К тому же многие IDE позволяют условные бряки или выполнять действие на бряке, и продолжать выполнение после этого.
В очень широкой области промышленной автоматики.
Суть в том, что программы выполняются циклически.
Ну и отвечая заодно про супермена в постах ниже — ничего сложного, если программу писать с расчетом на такую отладку.
Суть в том, что программы выполняются циклически.
Ну и отвечая заодно про супермена в постах ниже — ничего сложного, если программу писать с расчетом на такую отладку.
Ни в коем случае не хочу принизить роль пром. автоматики, но хочу напомнить, что других областей ну дохрена больше.
Правда?
Окей — тебя будит электронный будильник, включаешь свет пультом, готовишь завтрак в микроволновке, выходишь из квартиры- автосвет в подъезде, садишься в лифт, заводишь машину, стоишь на светофоре, отмечаешься в метро и на входе в работу, включаешь кофеварку…
Оно просто работает, потому незаметно
Окей — тебя будит электронный будильник, включаешь свет пультом, готовишь завтрак в микроволновке, выходишь из квартиры- автосвет в подъезде, садишься в лифт, заводишь машину, стоишь на светофоре, отмечаешься в метро и на входе в работу, включаешь кофеварку…
Оно просто работает, потому незаметно
Может быть полезной для общего изучения программы, понимания куда она уходит при том или ином входе. Другими словами, можно сказать — для дебага ситуаций, когда информации для построения гипотез недостаточно, а проходить ручками тысячи шагов утомительно.
Проходить тысячи путей сложно, а анализировать куда оно пошло каждую секунду просто? Ну, может суперменам и проще.
Но простым людям проще расставить десяток бряк посреди кода, найти где между которых сломалось, поставить десяток между ними и т. д. до достижения полного просветления
Не путей, а шагов. Нажатий какой-нибудь F7 или что там у вас за Step Into отвечает в дебаггере. Десяток бряк расставлять по коду, который первый раз видишь — так себе идея, по-моему.
Десяток бряк расставлять по коду, который первый раз видишь — так себе идея, по-моему.
Почему???
Из описания баги понятны, как минимум, две точки для бряки, даже если вы код видите первый раз в жизни:
1. Там, где мы получаем данные (и было бы неплохо проверить, что они именно те, что надо).
2. Там, где мы получаем неверные данные (которые приводят к баге).
Если вы вообще ни разу не видели код и не хотите разобраться — это очевидные бряки, которые надо поставить и проверить все равно. Потому что (сюрприз-сюрприз) может оказаться, что проблема в неверных данных или неверной интерпретации результата, и дальнейшее разбирательство не имеет смысла.
Ок, бага подтверждается, и она между этих двух бряк. Тогда ищем что-то посередине этих бряк (даже если мы совсем не понимаем код, можно найти что-то близкое к середине, что мы понимаем, и ставим бряку там). В этой бряке посередине получаем верный или неверный результат. В результате снижаем область поиска приблизительно в два раза.
… повторяем сколько надо раз, пока не сужаем область поиска до реально нескольких десятков строчек кода, где уже можно походить по F7 или чего там еще…
Метод половинного деления весьма эффективен, поверьте! Супротив пошаговому исполнению, лучше прям-таки на логарифм :)
З.Ы. а какой смысл жамкать F7 или запускать анимацию на коде, который вы не понимаете? По мне так это путь к беде — симптом, может быть, и поправите, но без осознания дизайна, весьма вероятно напортачите еще больше.
Да, кстати, минутка математики — 1000 шагов в анимации в 1 секунду это более 15 минут.
Поддерживать внимание каждую секунду над непонятным процессом в течении 15 минут… Ну, возможно, кто-то это может, но Супермен, КМК, может и сам реализовать подобную опцию в IDE, если захочет.
Поддерживать внимание каждую секунду над непонятным процессом в течении 15 минут… Ну, возможно, кто-то это может, но Супермен, КМК, может и сам реализовать подобную опцию в IDE, если захочет.
Я читал Вирта, в частности, о его подходе к построению компиляторов. Т.о. в общем мне было понятно устройство PascalS, но не отдельные детали. Анимацию я крутил около часа, то ускоряя, то замедляя, а то и останавливая. И у меня нет впечатления, что я даром потратил этот час. Усталость не больше, чем от внимательного просмотра кинофильма.
Я говорил много раз, что для обучения это круто.
Я сомневаюсь в полезности при разработке современного продакшен кода.
Может я неопытный юнец. Может я старый пердун. Но за 17 лет работы я хотел разного от отладчиков, но ни разу не думал, как классно было бы анимировать. И сейчас в этом вижу больше проблем, чем пользы.
Еще раз: я говорю про продакшен.
Я сомневаюсь в полезности при разработке современного продакшен кода.Я с этим не спорю — имеете полное право сомневаться. Есть очень разные задачи и очень разные подходы к их решению. Если в поставке современной IDE будет опция анимации, то ИМХО сильно не утяжелит, но всякий сможет попробовать на своей задаче. Если почти никому не понравится — не проблема: мало ли всяких бесполезных штучек добавляют в очередную версию (а тут хотя бы для обучения подойдет :)
Про «17 лет работы» (у меня больше) — мода живет меньше — отвыкайте от привычки следовать моде (я про это писал).
Bret Victor делает очень крутые инструменты по очеловечиванию процесса отладки:
www.youtube.com/watch?v=PUv66718DII
www.youtube.com/watch?v=PUv66718DII
Sign up to leave a comment.
Старые секреты быстрой отладки: анимация исходного кода