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