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

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

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