Господа, кто что думает, современный программист должен в этом ориентироваться или это уже не надо ?
Причиной такого вопроса стало, во-первых, то, что я веду спецкурс по этому предмету, и на посещение студентами не жалуюсь (а спецкурсы у нас выбирают студенты сами). Более того, этот спецкурс вообще-то рассчитан на третьекурсников и старше, а приходят обычно на 2 курсе, что для меня создает определенные проблемы (они Win32 еще не знают).
С другой стороны, пришлось мне тут в одной дискуссии участвовать, и в ходе нее выяснилось, что многие довольно серьезные программисты в этом плане очень многое не понимают. Мне больших трудов стоило объяснить, в чем различие между виртуальной памятью процесса и его рабочим множеством. Не скажу, что мне это удалось до конца...
текущие результаты которого показывают, что примерно половина такой курс не изучала или не собирается. Это, конечно, не значит, что они ничего не знают (я сам в вузе тоже не изучал его , но все же...
Иными словами , вопрос звучит так. Уровень абстрагирования в программировании все больше повышается. В DOS времена стыдно было не знать ассемблер, сейчас это вряд ли обязательно. В .Net необязательно знать и про указатели, виртуальную память и т.д. И вообще современное программирование имеет склонность к превращению в конструирование из крупных блоков — компонент сюда, класс туда, интерфейс оттуда. Может, действительно знание кирпичей и сопромата уже и не требуется ?
А с другой стороны, я все же никак в это не могу поверить.
PD> Может, действительно знание кирпичей и сопромата уже и не требуется ?
PD>Кто что думает ?
сам программист, системщик, приходится изучать
вчера девушке объяснял что ее нежелании учить основую пищевой технологии, когда у в современном питании — ресторанах и кафе — всегда дело имеют с полуфабрикатами, и незачем ей знать как разделывать тушу, как устроена тестомесилка, ...
считаю, что некую основу знать полезно, откуда ноги растут, хороший специалист должень знать не только общность, но и когда это применимо,
посчет этого спорил с экономистами, которые чертят графики спроса предложения, не договаривая, что есть простые рамки, когда действуют эти правила,
потом было по линейному программированию — пытались народ решать задачу заданных не в строгих неравенствах, а ведь там работа с вершинами полигона
короче, уйдем от офтопа — в серднем, незнание основы не столь критично.
но специалиста от кустарника отличает как раз это, что он знает, почему что-то работает или не работает
PD>Иными словами , вопрос звучит так. Уровень абстрагирования в программировании все больше повышается. В DOS времена стыдно было не знать ассемблер, сейчас это вряд ли обязательно. В .Net необязательно знать и про указатели, виртуальную память и т.д. И вообще современное программирование имеет склонность к превращению в конструирование из крупных блоков — компонент сюда, класс туда, интерфейс оттуда. Может, действительно знание кирпичей и сопромата уже и не требуется ?
PD>А с другой стороны, я все же никак в это не могу поверить. PD>Кто что думает ?
А что тут думать? Каждому свое. Кому-то нравится формочки клепать, кто-то ядро винды дизассемблирует и изучает. Мое имхо в том, что знающий кирпичи и сопромат найдет куда эти знания применить(пусть даже неосознанно) и при конструировании крупных блоков.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами , вопрос звучит так. Уровень абстрагирования в программировании все больше повышается. В DOS времена стыдно было не знать ассемблер, сейчас это вряд ли обязательно. В .Net необязательно знать и про указатели, виртуальную память и т.д. И вообще современное программирование имеет склонность к превращению в конструирование из крупных блоков — компонент сюда, класс туда, интерфейс оттуда. Может, действительно знание кирпичей и сопромата уже и не требуется ?
PD>А с другой стороны, я все же никак в это не могу поверить. PD>Кто что думает ?
И мне и многим моим знакомым время от времени приходится сталкиваться с приоритетами потоков, межпроцессным взаимодействием, утечкой хендлов (потоковых и процессных), случяайной передачей указателя другому процессу и т.д.
Не буду спорить об ассемблерных кирпичиках, но знание основ операционных систем мне и многим моим знакомым действительно требуется, пусть и не ежедневно. Хотя junior-программисту, эти знания, наверное, без особой практической пользы
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Chief Software Engineer,
Scrum Master, Symbian
Re: внутреннее устройство ОС
От:
Аноним
Дата:
16.05.06 04:01
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Господа, кто что думает, современный программист должен в этом ориентироваться или это уже не надо ?
PD> Может, действительно знание кирпичей и сопромата уже и не требуется ?
PD>А с другой стороны, я все же никак в это не могу поверить.
PD>Кто что думает ?
Не знаю, где Вы преподаете, но в моем любимом МГУ жутко не хватало хороших (и даже средних) курсов по IT. Поэтому Ваш курс нужен!
А теперь ответ на вопрос "почему"
1. (банальный) никогда не знаешь, какие знания пригодятся в жизни, поэтому в студенческие годы полезно набрать широкий кругозор фундаментальных знаний
2. (практичный) ОС, как программа, — это прекрасный (или не очень ) образец хорошо продуманной проги. Идеи воплощенные в ОС полезно изучить как классические решения классических проблем. Мне, например, пришлось столкнуться с распределением ограниченных ресурсов сервера для обслуживания запросов клиентских приложений. Принцип решения (использовать приоритеты) пришел в голову довольно быстро. Может быть от того, что когда-то я посещал курс по Unix'у?
Re: внутреннее устройство ОС
От:
Аноним
Дата:
16.05.06 04:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Господа, кто что думает, современный программист должен в этом ориентироваться или это уже не надо ?
PD> Может, действительно знание кирпичей и сопромата уже и не требуется ?
PD>А с другой стороны, я все же никак в это не могу поверить.
PD>Кто что думает ?
Не знаю, где Вы преподаете, но в моем любимом МГУ жутко не хватало хороших (и даже средних) курсов по IT. Поэтому Ваш курс нужен!
А теперь ответ на вопрос "почему"
1. (банальный) никогда не знаешь, какие знания пригодятся в жизни, поэтому в студенческие годы полезно набрать широкий кругозор фундаментальных знаний
2. (практичный) ОС, как программа, — это прекрасный (или не очень ) образец хорошо продуманной проги. Идеи воплощенные в ОС полезно изучить как классические решения классических проблем. Мне, например, пришлось столкнуться с распределением ограниченных ресурсов сервера для обслуживания запросов клиентских приложений. Принцип решения (использовать приоритеты) пришел в голову довольно быстро. Может быть от того, что когда-то я посещал курс по Unix'у?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Господа, кто что думает, современный программист должен в этом ориентироваться или это уже не надо ?
Когда я учился, в нашем универе таких курсов не было... Тогда только начали выходить книжки по осям IBM-360...
Изучал по книжкам — было интересно...
А в 80-е годы неожиданно пришлось самому руководить и писать ось на бортовую ЭВМ — вот тогда все и попробовали вживую...
Сейчас ось вряд ли писать придется (хотя, фиг знает, мож вояки опять заказы начнут делать?), но курс однозначно нужен...
А иначе как АПИ объяснять, если не лезть в теорию-то?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Господа, кто что думает, современный программист должен в этом ориентироваться или это уже не надо ?
PD>Причиной такого вопроса стало, во-первых, то, что я веду спецкурс по этому предмету, и на посещение студентами не жалуюсь (а спецкурсы у нас выбирают студенты сами). Более того, этот спецкурс вообще-то рассчитан на третьекурсников и старше, а приходят обычно на 2 курсе, что для меня создает определенные проблемы (они Win32 еще не знают).
У меня глубокая убежденность, что объяснить такие нетривиальные вещи, как устройство ОС, защищенный режим работы процесссора, виртуальная память и тд. тп. так, чтобы человек это понял, возможно только при глубокой заинтересованности этого человека в предмете, при огромном желании разобраться, понять и спать спокойно Я сам пытался объяснить нескольким людям подобные вопросы (им просто это было сиюминутно необходиомо, ну или в споре возникала такая тема), так они вроде понимающее кивают (причем, до понимающего кивка приходится попотеть), но я уверен, что через несколько минут полностью перестают понимать суть.
Что касается меня, то я в этой области самообразовывался, и очень жестко — пока не приходило полное понимание происходящего тему не закрывал Эх, сколько я студенческих денег потратил на книжки...
Зато возникали забавные ситуаци. Представь — студенческая пьянка, выжили только трое (в их числе я, еще один заинтересованный студент — живой, как я таких называю — и обычный студент-посетитель курсов), разговор незаметно и плавно перешел на особенности адресации в защищенном режиме; обычный студет слушал полчаса, слушал час, потом тихо свалил. Когда мы решили лечь спать, то обнаружили его заснувшего со стаканом перед зеркалом — он с зеркалом решил пить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>С другой стороны, пришлось мне тут в одной дискуссии участвовать, и в ходе нее выяснилось, что многие довольно серьезные программисты в этом плане очень многое не понимают. Мне больших трудов стоило объяснить, в чем различие между виртуальной памятью процесса и его рабочим множеством. Не скажу, что мне это удалось до конца...
У меня, к сожалению, подобного курса не было.
За дискуссией следил, именно она заставила начать читать книгу Соломона "Внутреннее устройство Microsoft Windows 2000".
Так что спасибо, за рекоммендацию хорошей литературы. Может еще посоветуете какую?
PD>В результате я устроил голосование PD>http://rsdn.ru/poll/1495.aspx
Здравствуйте, Arboz, Вы писали:
A>За дискуссией следил, именно она заставила начать читать книгу Соломона "Внутреннее устройство Microsoft Windows 2000". A>Так что спасибо, за рекоммендацию хорошей литературы. Может еще посоветуете какую?
Шрайбер. Недокументированные возможности Windows 2000 (название даю по памяти).
Фень Юань. Программирование графики для Windows (это, конечно, не по ядру, но многое там интересно, подсистема графики хорошо описана)
PD>>В результате я устроил голосование PD>>http://rsdn.ru/poll/1495.aspx
Здравствуйте, LaptevVV, Вы писали:
LVV>А иначе как АПИ объяснять, если не лезть в теорию-то?
В том-то и дело, что определенное и даже довольно большое подмножество можно объяснить без того, чтобы лезть в теорию. К примеру, тот же механизм вирт. памяти прозрачен для 3 кольца, так что можно вообще-то о нем ничего не знать. Есть процесс, у него адресное пространство, у каждого свое, а как это адресное пр-во и коммитированная память маппируется на RAM и swap — черный ящик. И на этой основе можно много-таки объяснить, и писать программы будут, но не эффективно, и то смотря какие.
А уж если до .Net дело дойдет, то там вообще и "адресное пространство" — термин чуть ли не ругательный. Есть экземпляры классов, они живут в хипе, есть ссылки, ими и оперируйте, остальное от лукавого Зачем мне это все знать, если и работа с адресами ОП там прозрачна ?
Меня вот это больше всего и интересует. Иными словами, если некая среда программирования скрывает в своей идеологии подлежащий слой , то знание, как этот слой функцтонирует, прямо не помогает писать программу. Получается. что это надо либо для общего развития, либо для того, чтобы это эффективно учитывать, если это хоть как-то возможно. А если совсем невозможно, то и знать не обязательно ? К примеру, знаю я как устроен и работает контроллер HDD или не знаю — от этого мои программы ни лучше ни хуже не станут, если, конечно, это не HDD драйвер
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Arboz, Вы писали:
A>>За дискуссией следил, именно она заставила начать читать книгу Соломона "Внутреннее устройство Microsoft Windows 2000". A>>Так что спасибо, за рекоммендацию хорошей литературы. Может еще посоветуете какую?
PD>Шрайбер. Недокументированные возможности Windows 2000 (название даю по памяти). PD>Фень Юань. Программирование графики для Windows (это, конечно, не по ядру, но многое там интересно, подсистема графики хорошо описана)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И все же мне этот подход не кажется правильным.
Конечно! Я считаю, что программист обязан знать, что происходит "под капотом". Понимаю, что программирование — это не столь знание техники, сколь умение алгоритмизировать и записывать алгоритмы в виде программы, но не можем же мы работать на черном ящике! Это, хотя бы, в этом форуме видно — большая вопросов именно про техническую составляющую программирования, а не алгоритмическую.
Здравствуйте, Demiurg, Вы писали:
PD>>И все же мне этот подход не кажется правильным.
D> Конечно! Я считаю, что программист обязан знать, что происходит "под капотом". Понимаю, что программирование — это не столь знание техники, сколь умение алгоритмизировать и записывать алгоритмы в виде программы, но не можем же мы работать на черном ящике! Это, хотя бы, в этом форуме видно — большая вопросов именно про техническую составляющую программирования, а не алгоритмическую.
Добавлю — знание сабжа все же в общем случае поможет написать более правильную программу, так как в сабже очень много интересных алгоритмов и подходов. Иногда может помочь.
PD>Иными словами , вопрос звучит так. Уровень абстрагирования в программировании все больше повышается. В DOS времена стыдно было не знать ассемблер, сейчас это вряд ли обязательно. В .Net необязательно знать и про указатели, виртуальную память и т.д. И вообще современное программирование имеет склонность к превращению в конструирование из крупных блоков — компонент сюда, класс туда, интерфейс оттуда. Может, действительно знание кирпичей и сопромата уже и не требуется ?
ИМХО для системного программиста знание ассемблера обязательно. Я бы с удовольствием сходил на такой курс.
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>А иначе как АПИ объяснять, если не лезть в теорию-то? PD>В том-то и дело, что определенное и даже довольно большое подмножество можно объяснить без того, чтобы лезть в теорию. К примеру, тот же механизм вирт. памяти прозрачен для 3 кольца, так что можно вообще-то о нем ничего не знать. Есть процесс, у него адресное пространство, у каждого свое, а как это адресное пр-во и коммитированная память маппируется на RAM и swap — черный ящик. И на этой основе можно много-таки объяснить, и писать программы будут, но не эффективно, и то смотря какие.
PD>А уж если до .Net дело дойдет, то там вообще и "адресное пространство" — термин чуть ли не ругательный. Есть экземпляры классов, они живут в хипе, есть ссылки, ими и оперируйте, остальное от лукавого Зачем мне это все знать, если и работа с адресами ОП там прозрачна ?
ИМХО, действительно очень полезно изучать тот уровень абстракции, над которым работает твой код, немного полезно — следующий, остальное — интересно, но нечасто приносит конкретную пользу.
Например, для Win программиста очень полезно изучать принципы работы WinAPI и OLE, в общих чертах внутренности ОС, а вот адресацию регистров процессора — исключительно для любознательных.
Для C-шарпера и Java'иста аналогом наверное будет изучение виртуальной машины (ну там, когда и почему работает garbage collector) и немного операционной системы (чтобы иметь понятие о реальных потоков, например).
Для будущего прикладного математика-MatLab'вца — внутренности MatLab и немного ОС (чтобы иметь понятие о том как работает распараллеливание, например).
, но все же...
) образец хорошо продуманной проги. Идеи воплощенные в ОС полезно изучить как классические решения классических проблем. Мне, например, пришлось столкнуться с распределением ограниченных ресурсов сервера для обслуживания запросов клиентских приложений. Принцип решения (использовать приоритеты) пришел в голову довольно быстро. Может быть от того, что когда-то я посещал курс по Unix'у? 
