Здравствуйте, 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 не имея представления что "под капотом"), а можно пользуясь теми-же средствами — программировать на языках высокого уровня, умея их правильно и эффективно использовать и иметь достаточно широкий кругозор чтоб уметь выбирать.
ЗЫ: Я тоже вожу машину с АКПП, но мне удаётся выжать из неё практически всё что мне может дать ручник, при этом имея преимущества (руки свободы) АКПП
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
WR>Я думаю, что не всякий ассемблер нужно изучать. Образцовой считаю систему команд PDP-11. Там всё очень компактно и красиво продуманно в 16 разрядах восьмеричной системы. WR>Когда я попытался изучить ассемблер х86, то пришёл в ужас.
Э, батенька — Вы просто не видели ассемблер VAX-11 Вот где действительно красота и симметрия! Там даже команды редактирования текста были! Программы на тамошнем ассемблере получались ну разве что чуть длиннее программ на тамошнем паскале
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>Аналогия: Человек хорошо ездит на машине. Но знает ли он досконально, как она устроена? Надо ли ему это?
Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет
Здравствуйте, vdimas, Вы писали:
V>Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет
Ну, имхо это только довод в пользу ABS и АКПП. Моя жена, к примеру, не имеет никакого представления ни о трансмиссии, ни об инжекторных ДВС. Она даже не знает, как работают тормоза. Это не мешает ей ездить получше иных экспертов устройству автомобиля.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Если нету, например, ABS и АККП — то обязательно, иначе ездить толком не сможет S>Ну, имхо это только довод в пользу ABS и АКПП. Моя жена, к примеру, не имеет никакого представления ни о трансмиссии, ни об инжекторных ДВС. Она даже не знает, как работают тормоза. Это не мешает ей ездить получше иных экспертов устройству автомобиля.
А автомобили являются объектом ее профессиональной деятельности?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Правда есть один случай когда используемый мной метод немного не эффективен. Это случай когда программа не может сообщить где она изломалась по той причине, что "изломанность" заключается в её зависании. Зависла и молчит — хуже нету случая. Тут помогает только универсальный (годный на все случаи жизни) "метод пристального вглядывания в исходный текст программы".
А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>А нормальные люди в таких случаях берут отладчик, цепляются к программе и тормозят ее. После этого смотрят где и что зациклилось, какие значения у переменный, что в стеке и тп
Ага, а по моему, так делают как раз только "ненормальные" люди, а именно только те, кому нравится сидеть в отладчике. На самом деле для устранения возникшей проблемы отладчик не нужен. Сидение в отладчике — это что-то из области (азартных) компьютерных игр, затягивает оно. Последний раз когда я боролся с зависанием, дело было в следующем: две программы (на разных компьютерах) общались друг с другом через .Net Remoting. Как выяснилось, иногда их диалог заканчивался зависанием. Чтобы понять почему происходило зависание надо было всего лишь ясно представить себе протокол диалога. Как только я это сделал, сразу понял в чем смысл ошибки и где нужно чего исправить (обычный deadlock). Поиграться с отладчиком, конечно, для кого-то было бы более интересным, а мне вот интересно сколько времени бы этот гипотетический некто искал бы в чём там дело роясь внутрях отладчика (занимался бы поиском чёрной кошки в чёрной комнате) ведь: зацикливаний нет (просто нет циклов и нет рекурсий), смотреть значения переменных — смысла нет (если бы они были плохими — программа сама об этом бы мне сообщила),... Смотреть через отладчик порядок вызовов процедур в разных программах в разных потоках? — Так я и так его знаю, остается только подумать...
Здравствуйте, Sinclair, Вы писали:
S>С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, prVovik, Вы писали:
V>>А автомобили являются объектом ее профессиональной деятельности? S>Нет, но работать таксистом она вполне бы смогла.
История не терпит сослагательного наклонения
Да и потом, сравнивать двигательные рефлексы, требуемые для вождения автомобиля с интеллектуальной деятельностью при программировани, совсем некорректно.
Здравствуйте, Sinclair, Вы писали:
S>Это от недостатка опыта С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно.
Ну мой дан позволяет отлаживать программу еще до того как она была написана...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ага, а по моему, так делают как раз только "ненормальные" люди, а именно только те, кому нравится сидеть в отладчике. На самом деле для устранения возникшей проблемы отладчик не нужен. Сидение в отладчике — это что-то из области (азартных) компьютерных игр, затягивает оно. Последний раз когда я боролся с зависанием, дело было в следующем: две программы (на разных компьютерах) общались друг с другом через .Net Remoting. Как выяснилось, иногда их диалог заканчивался зависанием. Чтобы понять почему происходило зависание надо было всего лишь ясно представить себе протокол диалога. Как только я это сделал, сразу понял в чем смысл ошибки и где нужно чего исправить (обычный deadlock). Поиграться с отладчиком, конечно, для кого-то было бы более интересным, а мне вот интересно сколько времени бы этот гипотетический некто искал бы в чём там дело роясь внутрях отладчика (занимался бы поиском чёрной кошки в чёрной комнате) ведь: зацикливаний нет (просто нет циклов и нет рекурсий), смотреть значения переменных — смысла нет (если бы они были плохими — программа сама об этом бы мне сообщила),... Смотреть через отладчик порядок вызовов процедур в разных программах в разных потоках? — Так я и так его знаю, остается только подумать...
Последний раз когда у меня был дедлок (года два назад) я его искал именно отладчиком. Заняло это у меня меньше минуты. Все что нужно было это посмотреть стек вызовов в двух потоках. Я дольше думал как его убрать.
А вот теперь объясни мне как искать такие
Однако его последняя реинкарнация (взять postscript-овское описание можно тут http://www-cs-faculty.stanford.edu/~knuth/mmix.html) по сравнению с той, что изложена в "Искусстве программирования" показалась мне чересчур навороченной 
1.1.4 stable rev. 510
С ростом експы, разработчики все чаще и успешнее применяют т.н. медитативную отладку. Начиная с определенного дана даже в исходик заглядывать становится необязательно. 
