Реферат: Как готовить системных программистов
"Нам нужны не приборы в принципе, а приборы в корпусе". Давайте, все-таки, поговорим о программировании. Я много раз читал лекции в Гамбурге, и в Классическом университете, и в Техническом университете, там даже поговорить о программировании часто не с кем. Две крайности: или "коробочники", которые умеют пользоваться стандартными программами, или теоретики, которые занимаются чем-нибудь таким, что неизвестно когда на практике осуществится. А людей, занимающихся нормальным программированием, часто и не встретить.
Я приведу еще один пример. Примерно в 1975 году мы получили первую ЕС ЭВМ 1030 среди гражданских организаций СССР, об этом даже в газетах писали. Первые ЕС ЭВМ шли только на оборону. И вот ленинградский мат-мех получил за счет того, что мы делали много программ для ЕС ЭВМ, самую первую машину. Пример состоит в следующем. Машина часто ломалась, а мы сидели вечерами, ночами. Делать было нечего, все темы были обсуждены, весь чай выпит. И вот я начал одну девицу-оператора учить своему любимому языку АЛГОЛ-68. Такой сложный язык программирования, и редко какой студент мог его освоить в полном объеме. Но времени было много, девица была симпатичная, надо было о чем-то говорить. И за длительное время, несколько месяцев, я научил ее так, что не каждый студент мог с ней сравниться. Говорю ей: "Теперь тебе надо переходить работать программистом. И зарплата выше, и работа интересная. Ведь что такое работа оператора? Поставить диск, загрузить машину". И тут я с ужасом понял, что она не знает, что программировать. Она не знает, как можно итеративно вычислить квадратный корень, она не знает, как устроен транслятор. Она знает язык программирования, экзамен сдать может, а программировать не может. На меня этот эпизод произвел очень сильное впечатление.
Прошло 25 лет, вроде бы многое изменилось. Но посмотрите, мы с Вами здесь сидим, каждые 10 минут дверь открывается. Каждый третий приходит с вопросом: "Андрей Николаевич, я хочу у Вас работать. Я слышал, что у Вас много людей занимается интересной работой". "Отлично, что ты знаешь?" "Я умею программировать на Паскале". "А что ты знаешь-то?". "Ну как, я же научусь". "Посмотри на список спецкурсов кафедры. Что из этого ты знаешь?". "Ничего". "И как ты будешь работать? Я тебя определю в группу "Телефония". Ты знаешь, что как устроено? Что ты там будешь программировать? Ты умеешь писать a:=b, a:=b+c, но ведь это не программирование. Надо знать, что программировать".
Результатом таких разговоров может быть одно из двух. Кто-то всю жизнь меня после этого ненавидит за то, что он хотел заниматься интересным делом, а злобный Терехов на него ушат холодной воды вылил, а бывают такие упрямцы, которые говорят: "Ничего, я научусь". Хорошо, первые три месяца стажировка, и если выяснится, что человек работать не может, ему просто вежливо скажут: "Извини, друг, нам надо двигаться дальше". Это не значит, что человек пропадет, может быть, он в другую группу попадет. Бывает, что люди с третьей попытки свое место находят. Бывает так, что человек научится в процессе работы, но это скорее исключение, чем правило. Правда, это обходится большими усилиями, чем у студента в процессе учебы, но зато закрепление совсем другое, и мотивация другая.
Итак, третий тезис был примерно такой. Между собой взаимосвязаны практика, границы между теорией и практикой, границы применимости теории, некоторые личные знания. Студент учил теорию, учил, куда не надо ходить, но я не хочу, чтобы это превращалось в основу науки. Я считаю, что все-таки основа науки в том, как надо делать. Я объясняю своим студентам, что системный программист - это сфера обслуживания. Мы не делаем конечных продуктов. Например, человек производит расчеты. У него есть какой-то результат. При этом он пользуется трансляторами, операционными системами, вычислительными машинами, которые придумали другие люди. И системщики - как раз те люди, которые делают трансляторы, инструментальные средства, разрабатывают методологии по их использованию. А потом уже прикладные программисты этими средствами и методологиями пользуются и получают конечный результат. Очень часто, кстати, люди видят только конечный результат, особенно когда идет речь о делении денег, и совсем не видят той дороги, тех трудностей, которые были потрачены, чтобы этот результат получить. Системное программирование - это довольно старое название. По-русски мы хорошо знаем, что такое системное программирование. Но были проблемы, как перевести это словосочетание на английский язык. Есть наука computer science, она более теоретическая. Аестьнаука software engineering. Вот я заведующий кафедрой software engineering. Еngineering - это разработка программного обеспечения. И мне кажется, что это довольно четко сейчас определилось.
Теперь следующий тезис, следующая проблема. Вот защищается мой аспирант у нас на Совете. Я сам член Ученого Совета. И каждый раз попадается какой-нибудь, мягко сказать, недоброжелатель, который, поскольку на Ученом Совете может выступать кто угодно, говорит: "Вы знаете, я не понимаю, почему это математика. Нет теорем, нет доказательств сходимости, почему эта диссертация защищается на математическом факультете?" В реальной действительности самый лучший ответ - сказать: "Вы ничего не понимаете в этой области". Времена, когда математика была только в теоремах, кончились, как минимум, 100 лет назад, а, может быть, и больше. В середине XIX века Ч. Бэббидж придумал вычислительную машину, в которой были все основные элементы (процессор, память, программа, хранящаяся в памяти). Дочь Байрона, Ада Августа леди Лавлейс, пятистраничный доклад на итальянском языке этого Ч. Бэббиджа преобразовала в 100-страничный английский текст, где впервые ввела слова "Переадресация", "Процедура", "Цикл" - это что, не математика? Это было сделано больше 150 лет назад. Была разработана новая модель.
Проблема решается просто, если говорить серьезно и без злобы. Просто мне уже надоело 20 лет объяснять одно и то же. Есть специальность - "Математическое обеспечение вычислительных машин, сетей и систем". Это не мат. анализ, не мат. физика. Есть критерии, предъявляемые к кандидатской диссертации. Новые результаты с практическим внедрением, языки программирования, их реализация, операционные системы, и, самое главное, модели. Математика начинается тогда, когда мы можем что-то формализовать, когда мы можем сформулировать задачу настолько точно, что можно построить алгоритм.
Почему возникли потребности в строгой формализации? Потому что пришло понимание того, что некоторые задачи в принципе нельзя решить, потребовалась алгоритмическая формализация, и с помощью этих формальных методов удалось доказать неразрешимость нескольких проблем. Первые такие доказательства были корректно получены в 30-х годах XX века. Почему это, когда я доказал, что этого нет и быть не может, это математика, а когда я построил формальную модель и по ней сделал алгоритм, который работает - это уже не математика? Никто не сказал, что только отрицательные результаты являются математическими. В нашей стране такой консерватизм особенно силен. Когда в 1953 году появилась БЭСМ, сразу появились диссертации, например, такого содержания: "Расчет скоса железнодорожного полотна". ВАК принял решение о недопущении к защите работ, носящих чисто расчетный характер. Это было правильное решение, но вместе с водой выплеснули и ребенка. Хорошо, чистый расчет по формулам - это не наука, все признают. Но, например, как сделать систему программирования для БЭСМ? Когда БЭСМ-6 появилась, в 1966 году, 6 коллективов делали операционную систему. И победили не самые известные академики страны. Я помню все фамилии, но не хотел бы их напоминать, чтобы никого не обидеть. Это в самом деле трудная задача.
Граница между "наукой" и "не наукой" в данном случае достаточно понятная, профессионал ее знает, но достаточно трудно формализуемая, и поэтому вызывает массу проблем в нашей науке. И постоянно на Ученом Совете кто-нибудь начинает объяснять, что это "не наука". Важно создать новую модель, новый язык, новый метод, новый алгоритм, показать, что он отличается от других. Я уже много раз был оппонентом, а не только руководителем диссертации. Для новичка, для человека со стороны это, может быть, будет даже удивительно. В задачу оппонента входит не только оценить, хорошая диссертация или плохая. Главная задача - оценить соотношение этой работы с другими известными работами. Не забыл ли диссертант, что это уже сделано? Он сравнивал свою работу с другими? Не забыл ли он какой-то важный результат, который был получен другим, а у него даже не упомянут? И второе - насколько корректно проведено сравнение собственной работы с другими известными работами? В требованиях ВАК четко указаны задачи двух оппонентов: насколько полно диссертант осветил другие работы в этой области и насколько корректно сравнил свою работу с ними. Если известен результат, перекрывающий результат диссертанта, а диссертант об этом не упомянул, то задача оппонента - об этом вспомнить.
Это проблема, которая есть до сих пор, и об этом надо писать в самых разных, и в научных, и в публицистических материалах. Есть такая наука, которая называется software engineering, в ней есть своя область деятельности, свои требования, свои критерии. Профессионалы знают, что сделать хороший транслятор - это очень трудно. Сделать технологию, которой будет пользоваться широкий круг людей - это тоже очень трудно. И так далее.
Например, сейчас у нас пора защиты дипломных работ. У меня защищается в этом году 19 человек. Итак, приходит студент V курса, проведший полгода где-то на практике. Показывает свою программу. Я говорю: "Хорошо, давай посмотрим, насколько научна твоя работа. Что здесь самое главное? Во-первых, насколько это новый результат? Писал ли кто-нибудь об этом раньше?". "Не знаю". "Ты делал обзор литературы?". "Нет"... Чем отличается исследователь от практика в худшем понимании этого слова? Исследователь поймет, что не надо изобретать велосипед. В наше время, когда есть Интернет, другие каналы получения информации, имеет смысл посмотреть, что сделали другие. С этого надо начинать. Далеко не всем это приходит в голову. Второе. Нашел, что такого результата нет, и ты его сам получаешь. Но есть похожие результаты. Проведи сравнительную характеристику. Меня раздражает такая ситуация: люди работали, писали дипломы, писали диссертации. Спрашиваешь: "Чем ваша технология лучше, чем остальные?" И следуют аргументы: "С одной стороны нельзя не признать, с другой стороны нельзя не согласиться..." Спрашиваю: "Ребята, вы потратили на эту работу столько сил и времени. Мы интуитивно понимаем, что это хорошо. Но разве так трудно все это четко сформулировать? У многих программ есть демо-версии, и сравнение их с вашим вариантом входит в работу". Нынешняя молодежь с трудом понимает, что просто сделать что-то, что работает, это меньше половины дела. Настоящий исследователь должен смотреть, как работают другие, скачивать демо-версии, читать инструкции - как у них запускается программа, научиться запускать, посмотреть, поработать, понять, что хорошо, что плохо, может быть, заимствовать какие-то идеи. Необходимо четко сформулировать, в чем твоя заслуга. Что ты такого сделал, чего у других нет? Сейчас этим занимаются только бедные диссертанты, и то, к сожалению, есть такая десятилетиями сложившаяся практика, что они занимаются этим в последний момент, когда уже "кирпич" пишут. Положено иметь обзор литературы по теме, они и сидят в библиотеке по 3 месяца в самом конце. И, между прочим, на моих глазах была ситуация, когда аспирант защищается по отладке, а его на Совете спрашивают: "Как это соотносится с такими-то методами отладки?" Оказалось, что он в библиотеке Академии Наук сравнивал свой метод с американскими работами, а то, что в СССР есть такие работы, и не знал...
Сейчас я попытаюсь еще раз сформулировать эту идею. Дали тебе работу - не поленись, потрать время, посмотри, что есть у других. Какие есть методы. Не изобретай велосипед. И в то же время - никакого низкопоклонничества перед Западом, даже если там есть какие-то публикации. Посмотри, насколько они хороши. Если хороши - используй, со ссылкой. Для этого и существует вся мировая наука, чтобы пользоваться ее результатами. Не надо ничего высасывать из пальца. Но плохо, когда человек не потратил времени на то, чтобы лишний раз посмотреть, а потом ему кто-то другой указывает на точно такие же, если не лучшие, результаты других исследователей.
Итак, важно умение сформулировать задачу, умение посмотреть на нее со стороны "что есть в мире", умение четко объяснить, что у тебя нового.