Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер

Норвиг: Сложный вопрос. Я не думаю, что заниматься наукой — большая потеря времени: есть шанс узнать много нужного. Но вы не узнаете всего, что вам требуется для разработки или производства ПО. Мне кажется, программы в высшей школе медленно адаптируются к реальности. Кое-где есть подвижки, но в целом работать в команде учат мало. Да и этому подходу со сборкой из готовых кусков тоже не особо учат. Однако ребята как-то набираются всего этого, так что в общем дело обстоит неплохо. У нас в Google много масштабных облачных вычислений, параллельного программирования и тому подобного. Индустрия во всем этом заинтересована, однако учат этому редко. Так что высшая школа немного запаздывает, но все равно остается полезной.

Сейбел: Есть ли области, где ученые находятся на переднем крае, где программная индустрия еще не подобралась к новейшим методам?

Норвиг: Отчасти да, есть. Лучший, наверное, пример — проверка моделей, которой Intel не уделила достаточно внимания, и на отзыве ПО из-за найденной ошибки в умножении они потеряли много денег. Тогда они всполошились и пошли на поклон к ученым. Теперь проверка моделей обязательно входит во все их программы. Другой пример, пожалуй, чуть менее яркий — языки программирования. В этой сфере идет напряженная работа, но она мало отражается на новых языках. Операционные системы, в какой-то мере. Мы финансируем лабораторию RAD в Беркли с Дэйвом Паттерсоном и другими. У них есть хорошие идеи относительно надежности систем. Но это тот случай, когда у индустрии есть куда более серьезные проблемы. Не каждую из них удается решить, но поиски здесь идут более интенсивно, чем в университетах.

Сейбел: Значит, вы не считаете, что часть хороших идей, порожденных учеными, не используются просто из-за нежелания перемен? Ведь множество доморощенных PHP-программистов никогда не заинтересуются языком Haskell, пусть даже он будет удобнее?

Норвиг: Тут я настроен скептически. Будь у этого языка серьезные преимущества, его бы уже активно использовали. Не думаю, что у нас идеальный рынок информации, где все тут же бросаются применять новое оптимальное решение, но мы близки к этому. Ученые могут не видеть всю проблему, стоящую перед индустрией, и часть ее — проблема обучения. При множестве программистов, не знающих, что такое монада, не слушавших курса теории категорий, наступает разрыв.

Отчасти причина — в наследии прежних систем, которое нельзя просто так взять и отбросить, — необходим переход. Уверен, есть много областей, где промышленникам следовало бы смотреть дальше: если мы не можем осуществить переход сейчас, давайте хотя бы задумаемся, где мы будем через десять лет, в каком направлении нам двигаться.

Но мы хотим улучшений в тех областях, где это будет иметь большой резонанс. Во многих случаях языки нацелены на слишком низкий уровень, чтобы иметь тот эффект, на который рассчитывают их создатели. Человек говорит: «С моим новым прекрасным языком вот эти шесть строк кода заменяются двумя». Да, это неплохо: язык станет более эффективным, легче будет поддаваться отладке и обслуживанию. Но, возможно, ваш код — всего лишь часть большой системы. Настоящая головная боль начинается, когда надо ежедневно обновлять данные, рыться в Сети, добывать данные, переводить их в нужный формат. Нужно помнить, что вы решаете лишь небольшой подраздел громадной задачи, поэтому вам нужно преодолеть большой барьер, чтобы сделать переход на новый язык оправданным.

Сейбел: Оставляя в стороне исследования в области языков, как вы считаете — мы далеко продвинулись с тех пор, как компьютерные науки ограничивались постижением продуктов IBM?

Норвиг: Да. Сейчас она на хорошем уровне, и жаль, что ее выбирают так мало студентов — все меньше и меньше. Конечно, есть те, кто любит компьютеры и проектирование программ настолько, что в любом случае пойдут туда. Они — наша надежда. Но есть блестящие умы, которые предпочитают физику, или биологию, или еще какую-нибудь из актуальных дисциплин. А кто-то говорит: «Я вроде как люблю компьютеры, но здесь никаких перспектив — все программы пишутся в Индии. Пойду-ка лучше в юристы». Это очень обидно. Мне кажется, людей сбивают с толку.

Сейбел: Обидно потому, что иначе они получали бы удовольствие от программирования? Или потому, что эти мозги нужны отрасли?

Норвиг: И то и другое. Можно получать удовольствие от нескольких вещей сразу, в таком случае не обязательно идти в компьютерные науки. Но мне кажется, здесь просто есть некая недоработка. Нам нужны толковые люди, способные изменить мир. И если это действительно то, чего они хотят добиться, то в компьютерные науки должно идти больше студентов, чем сейчас.

Сейбел: В одной из статей Дейкстра утверждает, что компьютерные науки — это раздел математики. Поэтому те, кто их изучает, вначале — первые сколько-то лет — вообще не должны прикасаться к компьютеру, а вместо этого осваивать обращение с системами формальных символов. Как по-вашему, сколько математики нужно грамотному программисту?

Норвиг: Ну, я не считаю, что надо учиться до уровня, о котором говорит Дейкстра. Кроме того, он сосредотачивает внимание на определенной области математики — дискретные, логические доказательства. Я пришел из сферы, где это не так важно, где все в большей мере основано на вероятности. Мне редко попадаются программы, которые можно проверить формально.

Код Google — он правилен или нет? Введя в Google этот запрос, вы получите десять страниц. Если поисковик даст сбой, код неправилен. А если он даст вот эти десять ссылок вместо вон тех десяти — правилен или нет? Можно говорить о том, что вам больше нравится, но дальше этого вы не пойдете. Это немного не то, о чем мы привыкли думать. Как только сталкиваешься с задачами такого рода или задачами вроде передвижения роботизированного автомобиля по улицам города, чтобы он никого не сбил, логические доказательства отбрасываются очень быстро.

Сейбел: Есть ли базовые навыки, необходимые хорошему программисту? В разных сферах, конечно, разные требования, но есть ли нечто общее в написании кода независимо от сферы деятельности?

Норвиг: Нужно уметь двигаться вперед и улучшать сделанное. Это все, что необходимо в жизни. Нужно порождать идеи, претворять их в жизнь, а потом совершенствовать сделанное. Совершенствовать можно по-разному. Можно сказать себе: «Я сделал это не совсем правильно, некоторые случаи не охвачены». А можно сказать себе так: «Теперь я понимаю это лучше, я создам более абстрактные инструменты, и в следующий раз мне будет легче создать такую систему». «В каком направлении я иду?», «Как я сделал это?», «Можно ли сделать это лучше?» — вот какие вопросы нужно перед собой ставить.

Сейбел: Считаете ли вы, что этот навык — по сути, сделал, отладил, повторил — стоит усвоить многим, и не только программистам? Если бы составляли программу для школы или колледжа, вы бы внесли в нее обязательное программирование для всех? Или это требует особых навыков?

Норвиг: Да, это требует особых навыков. Можно привести и другие примеры для этого типа мышления. Возьмем чисто механическую задачу: есть несколько деталей, и надо сделать так, чтобы вода в конце концов попадала вот в эту чашку. Речь не обязательно о программах — речь о том, чтобы соединять разрозненные элементы и проверять, как они работают в сборе.

Сейбел: Как глубоко нужно изучать программирование? В статье «Как самому научиться программировать за десять лет» вы говорите о том, сколько времени занимает выполнение инструкции по сравнению с чтением с диска, и так далее. Нужно ли программистам, как раньше, знать язык ассемблера?

Норвиг: Не знаю. Кнут советует делать все на языке ассемблера, поскольку Си слишком неэффективен. Я с ним не согласен. Нужно знать кое-что насчет эффективности и неэффективности инструкций, но это больше не относится к каждой конкретной инструкции. Теперь это не о том, исполняется последовательность из трех или из двух инструкций, а о том, случился ли у вас сбой по странице памяти или вы не попали в кэш. Мне кажется, знать язык ассемблера уже необязательно. Нужно понимать архитектуру. Нужно понимать, что такое язык ассемблера, понимать, что есть иерархия памяти и что сбой в переходе с одного уровня на другой сильно отражается на работе программы. Но это понимание может быть и на абстрактном уровне.