Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться. Писать программы не ассемблере сейчас действительно редко когда нужно — а вот знать обязательно. Сколько раз я уже наблюдал как программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи. Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию. Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча. Да, можно программировать не зная основ, вопрос как и зачем? Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

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

Z>Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию. Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча.

Это примеры того, когда ассемблер действительно нужен. Но этим не исчерпывается IT.

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

Z>Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться. Писать программы не ассемблере сейчас действительно редко когда нужно — а вот знать обязательно. Сколько раз я уже наблюдал как программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи. Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию. Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча. Да, можно программировать не зная основ, вопрос как и зачем? Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?

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

Z>>Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться. Писать программы не ассемблере сейчас действительно редко когда нужно — а вот знать обязательно. Сколько раз я уже наблюдал как программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи. Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию. Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча. Да, можно программировать не зная основ, вопрос как и зачем? Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?

Неверная аналогия. На машине разъезжают (см. пользуются софтом) юзеры. А разработчики — это скорее работники СТО.
И вообще. Приводить аналогии не корректно, поскольку софт все-таки не машины и не строительство. И именно по-этому правила и обычаи в этих индустриях разные. Сильно разные. Да, и еще, не стоит приводить в пример то, сколько лет существует то же машиностроение, а сколько к примеру сайтостроение. Это тоже будет не аргумент.

Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?
ИМХО, это неверная аналогия. Скорее должен ли автомеханик знать физику и химию? Нодо ли ему? Ведь он может и без этого колесо поменять...

Здравствуйте, Mystic, Вы писали:
M>Это примеры того, когда ассемблер действительно нужен. Но этим не исчерпывается IT.
Естественно. Это было мнение на тему того, что многие в IT слишком зацикливаются на отдельных парадигмах. Я, например, не раз слышал как люди рассуждали о скорости Java/C#/Python/(...) против C++/C/(...), даже не представляя себе как работает виртуальная машина этих языков.

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

_>Здравствуйте, Mikhail Polykovsky, Вы писали:

Z>>>Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться. Писать программы не ассемблере сейчас действительно редко когда нужно — а вот знать обязательно. Сколько раз я уже наблюдал как программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи. Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию. Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча. Да, можно программировать не зная основ, вопрос как и зачем? Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

MP>>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?

_>Неверная аналогия. На машине разъезжают (см. пользуются софтом) юзеры. А разработчики — это скорее работники СТО.

Неа. Когда я делаю программу, я _пользуюсь_ языком. Насколько хорошо или плохо — другой вопрос. Но пока я им успешно пользуюсь, внутренности мне не нужны. Так же, как программистам sql-запросов не нужно внутреннее устройство СУБД. Достаточно знать, как и на что она реагирует.

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

Z>Естественно. Это было мнение на тему того, что многие в IT слишком зацикливаются на отдельных парадигмах. Я, например, не раз слышал как люди рассуждали о скорости Java/C#/Python/(...) против C++/C/(...), даже не представляя себе как работает виртуальная машина этих языков.

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

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

Z>Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться.

А я вот dot.net разработчик. Для меня возможно править код только уровня IL и не шагом ниже. Я уже почти забыл 90% ассемблерных команд.
И как быть с джавистами или флешерами. У них p-код даже достать сложно, не то что знать его на зубок.
Лично я на стороне тех кто знает как сменить фильтр у машины и знает для чего это делать... Но для них далеко по фигу какой фильтрующий коэффициент у одного фильтра и насколько он отличается от другого. Главное что бы ездило и не пыхтело.

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

MP>Так же, как программистам sql-запросов не нужно внутреннее устройство СУБД. Достаточно знать, как и на что она реагирует.

До определенного момента. Например, документация по Oracle достаточно подробно описывает внутреннее устройство СУБД, и без этих знаний постоение эффективных приложений очень проблематично.

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

M>Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>>Так же, как программистам sql-запросов не нужно внутреннее устройство СУБД. Достаточно знать, как и на что она реагирует.

M>До определенного момента. Например, документация по Oracle достаточно подробно описывает внутреннее устройство СУБД, и без этих знаний постоение эффективных приложений очень проблематично.

Ага. И мы пришли к стандартному, давно обжеванному факту, что 80% программистов пользуются 20% возможностей языка/процессора/компьютера. И им этого хватает за глаза. А тем 20%, кто лезет глубже, действительно нужен ассемблер, коды и прочая электроника.

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

MP>Ага. И мы пришли к стандартному, давно обжеванному факту, что 80% программистов пользуются 20% возможностей языка/процессора/компьютера. И им этого хватает за глаза. А тем 20%, кто лезет глубже, действительно нужен ассемблер, коды и прочая электроника.

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

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

Z>программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи.

Однако, железный аргумент...

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

По этому поводу Guy Steele хорошо сказал в интервью DDJ:

DDJ: It seems to me that the best programmers I hire do know computing machinery down to the bits and gate level, often from embedded control experience. People who start with high-level languages frequently get frustrated because they don’t understand why certain limits impinge on their perfect world of highlevel language.

GS: I had the opportunity to take courses which tackle all levels of how a computer works, from high-level languages down to quantum mechanics. I’ve taken signals and systems courses, basic electrical engineering courses, architecture courses…I had the good fortune to be in on the first VLSI class that Lynn Conway [Carver Mead and Lynn Conway, Introduction to VLSI Systems, Addison-Wesley, 1980 ISBN 0201043580] taught at MIT. The very best programmers will be so fanatical that they spent their youth learning all this stuff top-to-bottom. But people have different balances and strengths. You can’t expect every programmer to have done this.

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Нет, Вы не подумайте, я совсем не против использования вставок машинных команд в текст программы на языке программирования высокого уровня, но аргумент Ваш уж больно мне "понравился"... Просто я никогда не пользуюсь дебагером.
Круто, вы пишите программы без ошибок?
Я не говорил про вставки ассемблерных комманд, а про случаи когда приходится отлаживать С/С++ аппликцию упавшую без callstack-а или доступной отладочной информации. Такое достаточно часто бывает.

СГ>>Нет, Вы не подумайте, я совсем не против использования вставок машинных команд в текст программы на языке программирования высокого уровня, но аргумент Ваш уж больно мне "понравился"... Просто я никогда не пользуюсь дебагером.
Z>Круто, вы пишите программы без ошибок?

Иногда отладчики недоступны/невозможны.
В этом случае ошибки надо искать с помощью трассировки в лог файл или (если и трассировка недоступна) по лампочкам/бипами.

Здравствуйте, MShura, Вы писали:
MS>Иногда отладчики недоступны/невозможны.
MS>В этом случае ошибки надо искать с помощью трассировки в лог файл или (если и трассировка недоступна) по лампочкам/бипами.
Конечно. Только я сомневаюсь, что найдется програмист, который работает на платформе на которой нету отладчика (т.е. embedded) и не знает ассемблера/железа

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

Z>Здравствуйте, MShura, Вы писали:
MS>>Иногда отладчики недоступны/невозможны.
MS>>В этом случае ошибки надо искать с помощью трассировки в лог файл или (если и трассировка недоступна) по лампочкам/бипами.
Z>Конечно. Только я сомневаюсь, что найдется програмист, который работает на платформе на которой нету отладчика (т.е. embedded) и не знает ассемблера/железа

Под многие функциональные языки нет (или очень плохие) отладчиков.

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

[]

Я думаю, что не всякий ассемблер нужно изучать. Образцовой считаю систему команд PDP-11. Там всё очень компактно и красиво продуманно в 16 разрядах восьмеричной системы.
Когда я попытался изучить ассемблер х86, то пришёл в ужас.

Z>Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию.

Для оптимизации не всегда ассемблер нужен, а элементарные (ладно, не всегда элементарные) знания алгоритмов.

Z>Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов. И таких примеров куча.

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

Z>Да, можно программировать не зная основ, вопрос как и зачем? Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

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

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

M>Идет, не спорю. Я бы, правда, предпочел, чтобы учили некому абстрактному ассемблеру вроде Кнутовского, без привязки к той или иной архитектуре.
Поддерживаю Однако его последняя реинкарнация (взять postscript-овское описание можно тут http://www-cs-faculty.stanford.edu/~knuth/mmix.html) по сравнению с той, что изложена в "Искусстве программирования" показалась мне чересчур навороченной

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

_>>Неверная аналогия. На машине разъезжают (см. пользуются софтом) юзеры. А разработчики — это скорее работники СТО.

MP>Неа. Когда я делаю программу, я _пользуюсь_ языком. Насколько хорошо или плохо — другой вопрос. Но пока я им успешно пользуюсь, внутренности мне не нужны. Так же, как программистам sql-запросов не нужно внутреннее устройство СУБД. Достаточно знать, как и на что она реагирует.

Насчет БД — ты абсолютно не прав. Да, конечно, чтобы что-то достать из БД — знать ее устройство не надо. Но чтобы на боевой базе или в работающем проекте что-то сделать эффективно — надо знать и схему БД и устройство БД. В частности оптимизатор.

К примеру, на оракловых форумах когда приходят новички и начинают спрашивать "что бы мне почитать, чтобы начать работать" — сразу отсылают к Oracle Concept. Это документ, в котором устройство Оракла описано. Достаточно подробно. Причем действительно, без знания этого работать эффективно на более-менее крупных БД не реально.

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

СГ>>Просто я никогда не пользуюсь дебагером.

Z>Круто, вы пишите программы без ошибок?

Хотелось бы ответить "Да!", но это было бы не правдой. Стараюсь, но иногда ошибаюсь. Поэтому я пишу такие программы, которые сами сообщают где они изломались. Это можно сделать с помощью проверки всяких инвариантов, пред- и пост- условий. Вобщем, Дейкстра рулит....

Z>Я не говорил про вставки ассемблерных комманд,

И я тоже . Я говорил про вставки машинных кодов.

Z>а про случаи когда приходится отлаживать С/С++ аппликцию упавшую без callstack-а или доступной отладочной информации. Такое достаточно часто бывает.

В моих программах этого делать не надо — они сами сообщают что не так. После этого я её исправляю (т.е. как бы отлаживаю), но без отладчика (дебагера).

P. S.
Правда есть один случай когда используемый мной метод немного не эффективен. Это случай когда программа не может сообщить где она изломалась по той причине, что "изломанность" заключается в её зависании. Зависла и молчит — хуже нету случая. Тут помогает только универсальный (годный на все случаи жизни) "метод пристального вглядывания в исходный текст программы".

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

MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?
Что значит досконально? Никто и не говорит, что он должен знать все технические подробности всех деталей машины включая химический состав и пр. Но ведь он знает, что у машины есть двигатель, который заставляет крутиться колеса. Что этот двигатель работает на основе закона "при нагревании тела расширяются и т.д.", что для нагревания и последующего расширения используется топливо. Водитель должен знать, для чего нужна трансмиссия, и хотябы в общих чеертах, как она работает. Представте, что водителя будут учить переключать передачи примерно так: "когда вот эта стрелочка дойдет вот до сюдова, нажми на вот эту педальку, и дерни вон тот рычажок вот так", при этам не рассказывая, что обозначает стрелочка, что это за педалька и для чего нужен рычажок. Водитель, конечно, не должен знать подробности конструкции своего автомобиля. Но он должен иметь представление, о том, как автомобиль работает.

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

Расскажу личный опыт. Я учился в университете как раз по специальности "программист". У нас с первых же занятий в первом семестре началось преподавание паскаля. К тому времени я уже не плохо на нем писал довольно сложные программы и чувствовал себя программистом . Но у меня в голове, в моем сознании была некая, не дававшая мне покоя пустота. Вы когда-нибудь задумывались о бесконечности вселенной, и о ее устройстве? Вам знакомо чувство, когда в сознании что-то не сходится, что-то не сростается, когда происходит некий stack overflow (как же вселенная может быть бесконечной, что таоке простарство и пр.)? Вот примерно такие же чувства у меня были, когда я пытался понять, что заставляет работать написанную мною же самим программу на паскале. Точно также что-то не сросталось. Я прекрасно разбирался в высокоуровневых конструкциях языка и пр., при этом понимал, что это лишь некоторая модель, предстваление. Но представление ЧЕГО? Вот в этом месте была пустота.

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

Просто человеческое сознание так устроено, что оно всегда требует разъяснений по поводу того, "откуда растут ноги". Как появился человек? Как работает разум? Что такое вселенная? Вот и программист рано или поздно неизбежно задастся вопросом, кто и как выполняет написанную им программу?

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

MP>Неа. Когда я делаю программу, я _пользуюсь_ языком. Насколько хорошо или плохо — другой вопрос. Но пока я им успешно пользуюсь, внутренности мне не нужны. Так же, как программистам sql-запросов не нужно внутреннее устройство СУБД. Достаточно знать, как и на что она реагирует.

Возможно, внутренности действительно не нужны автомату, который действует так, как его обучили. Но разве вас, как человека, не мучает вопрос, что происходит, когда вы пишете программу, и каким образом ваша программа выполняется? Разве вы пишете программы по принципу "нажми на кнопку — получишь результат"? Сомневаюсь...

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

V>Здравствуйте, Mikhail Polykovsky, Вы писали:

MP>>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?
V>Что значит досконально? Никто и не говорит, что он должен знать все технические подробности всех деталей машины включая химический состав и пр. Но ведь он знает, что у машины есть двигатель, который заставляет крутиться колеса. Что этот двигатель работает на основе закона "при нагревании тела расширяются и т.д.", что для нагревания и последующего расширения используется топливо. Водитель должен знать, для чего нужна трансмиссия, и хотябы в общих чеертах, как она работает. Представте, что водителя будут учить переключать передачи примерно так: "когда вот эта стрелочка дойдет вот до сюдова, нажми на вот эту педальку, и дерни вон тот рычажок вот так", при этам не рассказывая, что обозначает стрелочка, что это за педалька и для чего нужен рычажок. Водитель, конечно, не должен знать подробности конструкции своего автомобиля. Но он должен иметь представление, о том, как автомобиль работает.

Извините, не могу не привести контр-пример. Машины с АКПП именно так и управляются.

С остальным полностью согласен.

Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>Извините, не могу не привести контр-пример. Машины с АКПП именно так и управляются.
Это, кстати, очень хорошая аналогия. Если знаешь для чего нужно коробка передач, но позволяешь ей сделать часть работы за тебя — это одно. А совсем другое, когда человек даже не представляет зачем эта ручка нужна... Я сам видел — у меня мать никогда не водила с ручной коробкой передач. В результате она ездит исключительна на "D" и совершенно не представляет как заставить машину разгоняться, как тормозить двигателем, зачем нужен кик-даун, и какая связь между оборотами двигателя, передачей и мощностью/скоростью на колёсах.
Это как раз очень близкая аналогия — можно ездить ничего не зная (или программировать на Java/VB не имея представления что "под капотом"), а можно пользуясь теми-же средствами — программировать на языках высокого уровня, умея их правильно и эффективно использовать и иметь достаточно широкий кругозор чтоб уметь выбирать.
ЗЫ: Я тоже вожу машину с АКПП, но мне удаётся выжать из неё практически всё что мне может дать ручник, при этом имея преимущества (руки свободы) АКПП

WR>Я думаю, что не всякий ассемблер нужно изучать. Образцовой считаю систему команд PDP-11. Там всё очень компактно и красиво продуманно в 16 разрядах восьмеричной системы.
WR>Когда я попытался изучить ассемблер х86, то пришёл в ужас.

Э, батенька — Вы просто не видели ассемблер VAX-11 Вот где действительно красота и симметрия! Там даже команды редактирования текста были! Программы на тамошнем ассемблере получались ну разве что чуть длиннее программ на тамошнем паскале

Эх, началась тоска по ностальгии

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

MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?

Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет

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

V>Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет
Ну, имхо это только довод в пользу ABS и АКПП. Моя жена, к примеру, не имеет никакого представления ни о трансмиссии, ни об инжекторных ДВС. Она даже не знает, как работают тормоза. Это не мешает ей ездить получше иных экспертов устройству автомобиля.

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

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

V>>Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет
S>Ну, имхо это только довод в пользу ABS и АКПП. Моя жена, к примеру, не имеет никакого представления ни о трансмиссии, ни об инжекторных ДВС. Она даже не знает, как работают тормоза. Это не мешает ей ездить получше иных экспертов устройству автомобиля.

А автомобили являются объектом ее профессиональной деятельности?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Правда есть один случай когда используемый мной метод немного не эффективен. Это случай когда программа не может сообщить где она изломалась по той причине, что "изломанность" заключается в её зависании. Зависла и молчит — хуже нету случая. Тут помогает только универсальный (годный на все случаи жизни) "метод пристального вглядывания в исходный текст программы".
А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп

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

V>А автомобили являются объектом ее профессиональной деятельности?
Нет, но работать таксистом она вполне бы смогла.

Здравствуйте, WolfHound, Вы писали:
WH>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.

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

WH>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп

Ага, а по моему, так делают как раз только "ненормальные" люди, а именно только те, кому нравится сидеть в отладчике. На самом деле для устранения возникшей проблемы отладчик не нужен. Сидение в отладчике — это что-то из области (азартных) компьютерных игр, затягивает оно. Последний раз когда я боролся с зависанием, дело было в следующем: две программы (на разных компьютерах) общались друг с другом через .Net Remoting. Как выяснилось, иногда их диалог заканчивался зависанием. Чтобы понять почему происходило зависание надо было всего лишь ясно представить себе протокол диалога. Как только я это сделал, сразу понял в чем смысл ошибки и где нужно чего исправить (обычный deadlock). Поиграться с отладчиком, конечно, для кого-то было бы более интересным, а мне вот интересно сколько времени бы этот гипотетический некто искал бы в чём там дело роясь внутрях отладчика (занимался бы поиском чёрной кошки в чёрной комнате) ведь: зацикливаний нет (просто нет циклов и нет рекурсий), смотреть значения переменных — смысла нет (если бы они были плохими — программа сама об этом бы мне сообщила),... Смотреть через отладчик порядок вызовов процедур в разных программах в разных потоках? — Так я и так его знаю, остается только подумать...

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

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

Это действительно так. Смайлики излишни.

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

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

V>>А автомобили являются объектом ее профессиональной деятельности?
S>Нет, но работать таксистом она вполне бы смогла.
История не терпит сослагательного наклонения

V>История не терпит сослагательного наклонения

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

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

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ага, а по моему, так делают как раз только "ненормальные" люди, а именно только те, кому нравится сидеть в отладчике. На самом деле для устранения возникшей проблемы отладчик не нужен. Сидение в отладчике — это что-то из области (азартных) компьютерных игр, затягивает оно. Последний раз когда я боролся с зависанием, дело было в следующем: две программы (на разных компьютерах) общались друг с другом через .Net Remoting. Как выяснилось, иногда их диалог заканчивался зависанием. Чтобы понять почему происходило зависание надо было всего лишь ясно представить себе протокол диалога. Как только я это сделал, сразу понял в чем смысл ошибки и где нужно чего исправить (обычный deadlock). Поиграться с отладчиком, конечно, для кого-то было бы более интересным, а мне вот интересно сколько времени бы этот гипотетический некто искал бы в чём там дело роясь внутрях отладчика (занимался бы поиском чёрной кошки в чёрной комнате) ведь: зацикливаний нет (просто нет циклов и нет рекурсий), смотреть значения переменных — смысла нет (если бы они были плохими — программа сама об этом бы мне сообщила),... Смотреть через отладчик порядок вызовов процедур в разных программах в разных потоках? — Так я и так его знаю, остается только подумать...
Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках. Я дольше думал как его убрать.
А вот теперь объясни мне как искать такие

Автор: WolfHound
Дата: 04.06.05

ошибки без отладчика и декомпилятора?
А как быть в случае если пишешь программу не один и не знаешь весь код?

Здравствуйте, WolfHound, Вы писали:
WH>А вот теперь объясни мне как искать такие

Автор: WolfHound
Дата: 04.06.05

ошибки без отладчика и декомпилятора?
WH>А как быть в случае если пишешь программу не один и не знаешь весь код?

Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически

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

V>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически
Интересно сколько таких программ ты написал?

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

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

V>>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически
WH>Интересно сколько таких программ ты написал?
Я, ниодной, потому и несчастен

V>Да и потом, сравнивать двигательные рефлексы, требуемые для вождения автомобиля с интеллектуальной деятельностью при программировани, совсем некорректно.

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

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

V>>Да и потом, сравнивать двигательные рефлексы, требуемые для вождения автомобиля с интеллектуальной деятельностью при программировани, совсем некорректно.

MP>Ну ладно, уговорил. Вот тебе другой пример. Художник пишет картину. Красками. Ему достаточно знать, как краски ложатся на холст и как выглядят потом. Как их делают, какой химический состав — не знаю, надо ли ему это.
Аналогий можно придумать много, но все они будут некорректны. Вот и эта аналогия с художником также некорректна. Поясняю. Объект, для которого художник пишет картину — это человек. Хороший художник должен понимать, как человечек воспринимает избображение, как человеческий мозг обрабатывает перспективу и пр. Художнику проще, потому что он сам является человеком. Но если бы он писал картины для инопланетян, ему бы пришлось изучить особенности зрительного восприятия инопланетян. Понять это, химический состав красок художнику никак не поможет, а потому он не нужен. Но понять, как процессор "воспринимает" программы очень наглядно и просто поможет ассемблер.

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

MP>>Извините, не могу не привести контр-пример. Машины с АКПП именно так и управляются.
Z>Это, кстати, очень хорошая аналогия. Если знаешь для чего нужно коробка передач, но позволяешь ей сделать часть работы за тебя — это одно. А совсем другое, когда человек даже не представляет зачем эта ручка нужна... Я сам видел — у меня мать никогда не водила с ручной коробкой передач. В результате она ездит исключительна на "D" и совершенно не представляет как заставить машину разгоняться, как тормозить двигателем, зачем нужен кик-даун, и какая связь между оборотами двигателя, передачей и мощностью/скоростью на колёсах.

А где про это можно почитать? У меня тоже недавно появилась машина с АКПП и я весьма приблизительно себе представляю все то, что вы написали. Но, как программиста, меня постоянно гложет это чувство неизвестности

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Правда есть один случай когда используемый мной метод немного не эффективен. Это случай когда программа не может сообщить где она изломалась по той причине, что "изломанность" заключается в её зависании. Зависла и молчит — хуже нету случая. Тут помогает только универсальный (годный на все случаи жизни) "метод пристального вглядывания в исходный текст программы".


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

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

S>Здравствуйте, WolfHound, Вы писали:
WH>>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
S>Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.

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

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

K>Это проходит для программ, которые можно осознать человеческим разумом за приемлимое время. "Начиная с определенного дана" люди работают с кодом, понять который до конца не может даже автор.
Ничего. Если не получается, значит просветление еще не наступило. Wax on, wax off

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

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

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

V>>>Рецепт счастья прост, как все гениальное — надо всего лишь навсего писать программы, полная коректность которых доказана математически
WH>>Интересно сколько таких программ ты написал?
V>Я, ниодной, потому и несчастен

Моя твоя понимай, а есть же счастливые люди

V>Аналогий можно придумать много, но все они будут некорректны.

"Все аналогии лживы" (C) Сергей Лукьяненко

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

WH>Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках.

Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик...
А в уме эту задачку решить слабо было?

WH>А вот теперь объясни мне как искать такие

Автор: WolfHound
Дата: 04.06.05

ошибки без отладчика и декомпилятора?

0) Привлекать к ответственности авторов. Если авторы непривлекаемы, а в их компонентах констатирован факт существования ошибок, то:
1) Во-первых, использовать компоненты с ошибками НЕЛЬЗЯ ни в коем случае (если сам себе не враг).
2) Во-вторых, если ты такой отважный сорви-голова и готов взять на себя ответственность, то декомпилируй, отлаживай и т.п., но автором отлаженного компонента будешь уже ты, со всеми вытекающими...т.е. если ты после отладки всё-равно не сможешь гарантировать отсутсвие других ошибок, то см. пункты 0 и 1.

WH>А как быть в случае если пишешь программу не один и не знаешь весь код?

А чужой исходный текст знать и не надо.
Надо использовать компонентный подход.
Компоненты должны использовать оборонительную

Автор: Сергей Губанов
Дата: 05.12.05

стратегию.

Сергей Губанов wrote:
> Ха, всего два потока внутри всего одной программы! И ради такой ерунды
> надо было залазить в отладчик...
> А в уме эту задачку решить слабо было?
Бывают ведь задачи и посложнее 100 параллельных "Hello world"...

Здравствуйте, Сергей Губанов, Вы писали:

WH>>Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках.

СГ>Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик...
СГ>А в уме эту задачку решить слабо было?

Ради чувства полного обалдения от себя можно и SuperPI на бумажке вычислять, а вот не залезть в отладчик при наличии сопутствующих факторов ( приложение с отладочной инфой + есть отладчик + приложение уже залочилось => есть возможность воспользоваться отладчиком ) ИМХО не есть гуд.
Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.

Если наблюдается отсутствие сопутствующих факторов, то это уже другой вопрос.

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

S>Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.

Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!

Например,
1) в .Net программа сама выводит свой call stack через который пролетело исключение.
2) в Blackbox можно увидеть не только call stack,
но и значения всех локальных переменных и полей объектов во всём этом call stack:



этой информации более чем достаточно, чтобы легко обходиться без отладчика.

Здравствуйте, Сергей Губанов, Вы писали:


S>>Call stack в дальнейшей медитации может сыграть ( и играет ) роль катализатора.
Мы же говорим о медитации при поиске причины дедлока ?

СГ>Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!
Случаи разные бывают. При дедлоке аттачимся к приложению стопим его и смотрим call stack.

СГ>Например,
СГ>1) в .Net программа сама выводит свой call stack через который пролетело исключение.
При дедлоке бросается Исключение ?

СГ>2) в Blackbox можно увидеть не только call stack,
СГ>но и значения всех локальных переменных и полей объектов во всём этом call stack:
Ничего не знаю про Blackbox так что судить не могу.

СГ>этой информации более чем достаточно, чтобы легко обходиться без отладчика.
Да, если есть call stack то можно без дебагера, я лично, подразумевал С++ с попыткой поиска дедлока в нём, там с этим сложней.

СГ>Но чтобы увидеть call stack (и значения переменных) отладчик (дебагер) не нужен!!!!!!!!!!

СГ>Например,
СГ>1) в .Net программа сама выводит свой call stack через который пролетело исключение.
СГ>2) в Blackbox можно увидеть не только call stack,
СГ>но и значения всех локальных переменных и полей объектов во всём этом call stack:

СГ>

СГ>этой информации более чем достаточно, чтобы легко обходиться без отладчика.

Ага, "закат солнца вручную". Это первый шаг на пути встраивания самодельного отладчика в саму программу. Не могу не согласится что иногда это всё-таки нужно, но вот только не ради того чтобы гордо сказать "мы не используем отладчик".

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

MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?

Все люди делятся на юзеров и хакеров
Знает ли Шумахер, как устроена его машина?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ха, всего два потока внутри всего одной программы! И ради такой ерунды надо было залазить в отладчик...
Всего два зависших потка. А потоков там было несколько десятков + куча таймеров + протокол который проектировали какието Гашиш Кумары... ни понять ни запомнить... вот и иди найди тут дедлок.
Нужнае потоки я нашол просто посмотрев на последний вызов в стеке вызовов. Я искал потоки которые висели на примитивах синхронизации. Вероятность того что не зависший поток в момент остановки приложения висел бы на примитиве синхронизации была незначительной.
Конечно еслибы небыло отладчика я бы его и без отладчика нашол вот только зачем если есть отладчик?

СГ>А в уме эту задачку решить слабо было?
А где я по твоему искал решение этой проблемы?

СГ>0) Привлекать к ответственности авторов. Если авторы непривлекаемы, а в их компонентах констатирован факт существования ошибок, то:
СГ>1) Во-первых, использовать компоненты с ошибками НЕЛЬЗЯ ни в коем случае (если сам себе не враг).
СГ>2) Во-вторых, если ты такой отважный сорви-голова и готов взять на себя ответственность, то декомпилируй, отлаживай и т.п., но автором отлаженного компонента будешь уже ты, со всеми вытекающими...т.е. если ты после отладки всё-равно не сможешь гарантировать отсутсвие других ошибок, то см. пункты 0 и 1.
Те ты предлагаешь не использовать .NET? Круто. А в чем альтернатива? Только не говори про оберон... там такие ошибки тоже можно наделать...
А не использовать этот самый EventDescriptorCollection я не мог. Тез него никак. Изменить его тоже было нельзя ибо этот класс вшит в поставку .NET.

СГ>А чужой исходный текст знать и не надо.
СГ>Надо использовать компонентный подход.
СГ>Компоненты должны использовать оборонительную

Автор: Сергей Губанов
Дата: 05.12.05

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

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

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

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

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

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

Может даже не писать ее, чтобы избежать багов?

Здравствуйте, Сергей Губанов, Вы писали:


СГ>этой информации более чем достаточно, чтобы легко обходиться без отладчика.

Так это и есть отладчик, только кастрированный.

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

Z>Тут в в нескольких соседних темах проскакивали мнения на тему того, что мол, ассемблер умер и знать/учить его не нужно. Позволю не согласиться. Писать программы не ассемблере сейчас действительно редко когда нужно — а вот знать обязательно. Сколько раз я уже наблюдал как программист С/С++ оказавшись в дебагере и увидев ассемблерный код впадал в ступор и терял дар речи.

А что он должен был делать?

Z>Не зная ассемблера и как работает процессор, невозможно понять очень многих вещей, включая оптимизацию.

Например каких вещей? Оптимизацию в какой области?

Z>Как объяснить человеку, который не представляет, что такое процессор сколько "стоит" вызов функции, что такое дефрагментация памяти и переключение контекстов.

Но таки на моем курсе в институте преподаватель смог обьяснить "дефрагментацию памяти" обычным дельфистам примерно за 15 мин. Оптимизация на уровне "сколько "стоит" вызов функции" имхо вообще вредна. Оптимизировать нужно в конце разработки используя профайлер, ускорять реально тормозные концепции. А это как правило ведет к рефакторингу, а не к исследованиям "сколько "стоит" вызов функции".

Z>И таких примеров куча.

Ну еще хотя бы 3...

Z>Да, можно программировать не зная основ, вопрос как и зачем?

Согласно требованиям и проектной документации. А основы это — ООП, алгоритмы и знание концепций операционной системы.

Z>Так что, языка высоко уровня это удобно и полезно, но про "корни" тоже забывать не следует. И, кстати, в нормальных учебных заведениях, в обязательном порядке идет курс-другой по микропроцессорам, электронике и ассемблеру.

А реальному процессу разработки учат в "нормальных учебных заведениях"? Имхо приоритеты несравнимы.

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

Z>Здравствуйте, Mystic, Вы писали:
M>>Это примеры того, когда ассемблер действительно нужен. Но этим не исчерпывается IT.
Z>Естественно. Это было мнение на тему того, что многие в IT слишком зацикливаются на отдельных парадигмах. Я, например, не раз слышал как люди рассуждали о скорости Java/C#/Python/(...) против C++/C/(...), даже не представляя себе как работает виртуальная машина этих языков.

А для большинства задач имеет смысл изучать как работает виртуальная машина? Ее реализация может меняться каждые полгода. Может лучше фрейморки с applicaton block-ами поизучать?

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

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

Знаете, боюсь. Переполнение может случиться. И дан станет отрицательным

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

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

J>Может лучше фрейморки с applicaton block-ами поизучать?
Одно другое не исключает. Тем более, что изучение какого-нибудь ассемблера — это ТРИВИАЛЬНЫЙ курс, который не сравнится по сложности, например, с курсом по базам данных. При этом, курс ассемблера, несомненно расширит кругозор студента, поможет ему более глубоко и полно понять компьютерную науку. Ведь чем бы он потом не занимался: писал бы SQL запросы, писал бы на JavaScript, или драйверы — всеравно результат его деятельности будет рано или поздно проебразован в последовательность ассемблерных команд, которые выполнит процессор. И я не вижу причин, чтобы скрывать сей факт от студентов, опасаясь за их психологическое здоровье. Ведь это и есть те самые фундаментальные знания, которые должен давать университет. Там же не "Гашишей Кумаров" должны готовить, верно?

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

WH> Ты вобще в комманде работал? Тут как не обороняйся, а если большую часть кода проекта ты в глаза не видел ты не сможешь со 100 процентной уверенностью сказать что сломалось. Може ты чего накосячил, а может и кто-то другой. Болие того этот кто-то другой может уже и не работать над этим проектом, а может и в этой конторе...
WH>А даже если и работает со словами что-то сломалось к другому разработчику не пойдешь. Болие того нужно еще выяснить к какому именно идти.
WH>А самое интересное что в большинстве случаев проще и быстрее самому исправить ошибку в чужом коде. Бывают конечно случае когда приходится пинать автора но они в сильной комманде редки.

В точку!

Да и вообще нигелизм в отношении дебагера на мой взгляд с родни плевкам любителей "нотпада" в сторону студии. Я понимаю что и круглое можно нести, и квадратное — катить, но отрицать прогрессивные (только не надо смеяться) технологии, однозначно облегчающие жизнь в том или оном смысле, — на мой взгляд, — признак шаловливого детства, играющего в известном месте


Любителям обходиться без дебагера очень рекомедую смотреть в сторону М. Фаулера "Рефакторинг: улучшение существующего кода", в особеннсоти методологии самотестирующихся классов


ПС ИМХО дебагер рулит однозначно

Здравствуйте, Kemsky, Вы писали:
K>Знаете, боюсь. Переполнение может случиться. И дан станет отрицательным
Не волнуйся. Задолго до переполнения ты сможешь удовлетворять нужды пользователей вообще без программирования и отладки.

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

СГ>>этой информации более чем достаточно, чтобы легко обходиться без отладчика.

FR>Так это и есть отладчик, только кастрированный.

Это уже терминология...

В отладчике можно "сидеть". Есть такое словосочетание — "сидеть в отладчике", т.е. выполнять программу по шагам, видеть всю память, все регистры процессора, исполняемые машинные команды. Короче, "сидеть в отладчике" — это самая увлекательная компьютерная игра на свете.

То что я показал в предыдущем сообщении, есть визуализатор "посмертной" информации с гиперссылками на исходный текст. Информация для него добывается с помощью средств метапрограммирования, т.е. никакой такой дебажной или релизной версий программ в Blackbox нет — все программы можно с равным успехом считать как дебажными так и релизными. Метапрограммирование не даёт произвольного доступа к памяти, регистрам процессора, не покажет исполняемые машинные команды и т.п. Этот визуализатор посмертной информации можно использовать в целях отладки программ, но под отладчиком (дебагером) обычно понимают нечто иное.

Сергей Губанов wrote:
> В отладчике можно "сидеть". Есть такое словосочетание — "сидеть в
> отладчике", т.е. выполнять программу по шагам, видеть всю память, все
> регистры процессора, исполняемые машинные команды. Короче, "сидеть в
> отладчике" — это самая увлекательная компьютерная игра на свете.
Да. И намного эффективнее отладочной печати.

> То что я показал в предыдущем сообщении, есть визуализатор "посмертной"
> информации с гиперссылками на исходный текст.
И? У меня это есть для С++ (см.
http://www.codeproject.com/debug/XCrashReportPt4.asp). Заменой отладчика
это не является.

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

S>Здравствуйте, WolfHound, Вы писали:
WH>>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
S>Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.
Совершенно верно! В бытность свою программером бывалыча при ошибке в программе даже распечатывать не нужно — лезешь сразу в нужное место и находишь там ошибку...

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

J>А основы это — ООП, алгоритмы и знание концепций операционной системы.

Основа (или фундамент) — то, на чем строится остальное. Можно ли построить программу, не зная ООП или "концепции" ОС? (как Вам UNIX в качестве примера? ). А можно ли построить программу, не зная, что такое байт?

А как насчёт объяснить смысл выделенного терминами любого ЯВУ ?

Следует делать то, что интересно.

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

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

_>Интересно постигать премудрости работы процессора — изучай ассемблер.
_>Интересно быстро создавать функциональные программы — изучай язык высокого уровня и фреймворки.
_>Интересно зарабатывать деньги — зарабатывай деньги.

Сори, а если интересно тратить деньги, что делать?