Текст книги "Кодеры за работой. Размышления о ремесле программиста"
Автор книги: Питер Сейбел
сообщить о нарушении
Текущая страница: 17 (всего у книги 41 страниц) [доступный отрывок для чтения: 17 страниц]
Сейбел: В некоторых компаниях соискателям дают решать логические задачи. Вы так делаете?
Армстронг: Нет. Есть очень хорошие программисты, которые в них соображают туго. Помню одного из парней, работавших с Erlang, – у него была степень по математике, и он напоминал алмазный бур, прогрызающий гранит. Как-то раз он загрипповал и взял домой листинги из Erlang. Потом он пришел, добавил в код атомарное выражение и сказал: «Это поставит эмулятор на замкнутый цикл». Он обнаружил, что изначальное хеш-значение этого выражения равно нулю, и взял какой-то модуль для перехода к следующему выражению – оно тоже оказалось равным нулю. И он декомпилировал хеш-алгоритм для одного патологического случая. Он даже не запускал программы – посмотреть, как они работают: он читал их. Но медленно. Довольно медленно. Не знаю, как бы он решил по-быстрому логическую задачу.
Сейбел: Есть ли еще навыки, необходимые хорошему программисту?
Армстронг: Где-то я читал, что нужно иметь хорошую память. Думаю, это так.
Сейбел: Билл Гейтс однажды сказал, что до сих пор мог бы выйти к доске и написать большие фрагменты кода на Бейсике, который писал для Altair, хотя прошло уже лет десять. А вы можете вот так вспомнить свой старый код?
Армстронг: Да, кое-что восстановить по памяти могу. Иногда я забываю какой-нибудь старый код и совершенно не беспокоюсь – просто пишу его заново, и получается примерно то же самое. Могут измениться имена переменных, расстановка функций. Но код выйдет изоморфным. Или даже лучше, чем раньше, потому что я дополнительно его обдумал.
Возьмем, к примеру, сопоставление образцов в моем компиляторе десятилетней давности – я могу сесть и набрать его. Он будет отличаться от старой версии, но в лучшую сторону. Код как бы самоулучшается со временем. Но структура остается прежней.
Я не беспокоюсь о потере кода – если шаблоны в голове, я все вспомню. Даже не столько вспомню, сколько сделаю заново. Не думаю, что это припоминание, скорее воссоздание. Если Билл может вспомнить именно сам текст, то я – нет. Но, конечно, я долго помню структуру кода.
Сейбел: Скажите, обмен сообщениями в духе Erlang поможет раз и навсегда решить проблему параллельного программирования?
Армстронг: Нет, конечно. Это всего лишь усовершенствование, пусть и большое, по сравнению с разделяемой памятью. Думаю, Erlang выполнил, по крайней мере, одну задачу – продемонстрировал это. Работая над Erlang, мы всегда говорили на конференциях: «Надо будет копировать все данные». И слушатели, кажется, воспринимали наши доводы насчет безотказной работы системы – копирование всех данных вводилось для этого. Нам возражали: «Но ведь тогда все будет работать страшно медленно», – а мы отвечали: «Зато безотказно».
Удивительно, но наш язык при определенных обстоятельствах оказывается еще и более быстрым. И то, что мы делали ради безотказной работы, во многих случаях было так же эффективно, а то и лучше, чем с разделяемой памятью. Мы спросили себя: «Почему так происходит?» Потому что улучшается распараллеливаемость. В системе с общей памятью нужно блокировать данные при обращении к ним. А блокировка обходится дорого. И потом, возможно, копировать придется не так уж много данных. Если данных немного, то копирование лучше, чем бесчисленные обновления, обращения, блокировки. А на многоядерниках, если принять старую разделяемую модель, блокировка может остановить работу всех ядер. У вас тысячеядерный процессор, одна программа делает глобальную блокировку – и тысяча ядер прекращают работу.
Я также очень сомневаюсь в неявном параллелизме. В языке могут быть параллельные конструкции, но если они не отображаются на па-рале льном процессоре, а только эмулируются системой, – преимущества никакого. Вообще, есть три вида процессорного параллелизма.
Есть конвейерный параллелизм, когда в чипе создается более длинный конвейер, чтобы делать вещи параллельно. Это предопределено при создании чипа. Обычный программист не может сделать ничего с параллелизмом на уровне инструкций.
Есть параллелизм данных; это не настоящий параллелизм, скорее он связан с процессами в кэше. Если вы хотите, чтобы программа на Си выполнялась эффективно, и если *р находится на 16-байтовой границе, то при доступе к *р доступ к *(р+1) практически бесплатен, поскольку строка кэша вытягивает его. Вам надо знать, насколько широки строки кэша, сколько байтов вы сможете утянуть при одном перемещении в кэш? Этот вид параллелизма можно успешно использовать, если быть очень осторожными со структурами данных и точно знать, где что находится в памяти. Все запутанно, и разбираться с этим не очень охота.
И наконец, многоядерные процессоры. К концу десятилетия они будут 32-ядерные, а к 2019 году ядер будут миллионы. Поэтому вам нужно взять параллельные участки своей программы и отобразить на ядра компьютера. Согласен, это довольно громоздкая операция. Вычисление начинается в другом ядре, из него потом приходит ответ – это требует времени. Если надо просто сложить два числа, это не стоит усилий – больше времени потратится на перенос данных между ядрами, чем на то, чтобы сделать все на месте.
Erlang неплохо приспособлен для этого. Программист говорит: «Мне нужен процесс, и еще, и еще». Процессы распределяются между ядрами. Может быть, стоит подумать над их физическим распределением между ядрами. Не исключено, что процесс, порождающий другой процесс, обменивается с ним данными. Имеет смысл поместить его в то ядро, которое ближе. Если же обмен данными не очень интенсивен, то можно поместить и подальше. Процессы, занимающиеся вводом/выводом, стоило бы расположить у края чипа, с другими процессами, занимающимися вводом/выводом. Чипы становятся все больше, и надо задуматься над тем, что размещение данных в середине чипа обходится дороже, чем на краю. Если есть три сервера и база данных, то ее мы поместим в середину, а серверы, которые общаются с клиентами, на край. Но все это подлежит исследованию.
Сейбел: Вам дорога мысль о том, что Erlang – это средство, позволяющее организовать параллельные процессы. Что вам дороже – идея параллелизма на основе обмена сообщениями без разделения данных или Erlang как язык?
Армстронг: Конечно, идея. Меня спрашивают: «Что будет с Erlang? Станет ли он популярным языком?» Этого я не знаю. Думаю, он уже стал важным языком. Он может повторить судьбу Smalltalk – очень важного языка, который имел горячих сторонников, но широко не применялся. С Erlang может произойти то же самое. Возможно, заложенные в нем идеи придут к миллионам пользователей, если их реализует Microsoft в Common Language Runtime, добавив там-сям фигурных скобок.
7. Саймон Пейтон-Джонс
В 1987 году он стал одним из инициаторов проекта, в результате которого появился язык программирования Haskell. Сегодня Саймон Пейтон-Джонс – ведущий исследователь лаборатории Microsoft Research, находящейся в британском Кембридже. В 1998 году он выпустил переработанное описание языка Haskell, являющееся текущим стабильным описанием. Кроме того, Пейтон-Джонс – ведущий разработчик Glasgow Haskell Compiler (GHC), «стандартного компилятора де-факто», согласно сайту haskell.org. Он же снабдил язык часто приводимым официальным девизом «Избегать успеха любой ценой».
Влиятельный исследователь и бывший преподаватель, так и не получивший кандидатской степени, Пейтон-Джонс ценит как практическую, так и теоретическую красоту. Он учился программировать на машине без постоянного места хранения информации и всего со 100 ячейками памяти, а будучи студентом, писал высокоуровневые компиляторы для большого компьютера колледжа и одновременно собирал собственные простейшие машины за счет своих скудных средств. Пейтон-Джонс занялся функциональным программированием после того, как на занятии преподаватель показал способ создания цепных списков без использования мутации и раскрыл красоту «ленивых» вычислений. В функциональном программировании Пейтон Джонс увидел элегантный и дерзкий вызов всей индустрии создания программ, возможность не добавлять еще один кирпич к стене, а строить новую стену. В 2004 году был избран в члены Ассоциации вычислительной техники за «вклад в функциональные языки программирования».
Мы говорили с ним о том, почему, по его мнению, функциональное программирование обещает изменить методы создания ПО, почему транзакционная память лучше приспособлена для параллельных программ, чем блокировка и переменные условия, и почему даже в Microsoft Research трудно исследовать вопрос о влиянии языка на эффективность работы программиста.
Сейбел: Когда вы научились программировать?
Пейтон-Джонс: В школе. Intel только что выпустила 4004 – первый в мире микропроцессор. Но у нас ни 4004, ни чего-нибудь похожего не было – любители в то время могли достать его лишь с большим трудом. Был только школьный компьютер IBM – странная машина, собранная из каких-то запчастей. Системы постоянного хранения данных не было, и программу всякий раз приходилось набирать с нуля.
Всего было 100 ячеек памяти, в каждой из которых, кажется, хранились восьмизначные десятичные числа. Там располагались и программа, и ваши данные. Искусство заключалось в том, чтобы уместить программу в эти 100 ячеек. Не помню, как именно я написал свою первую программу; мы с одним парнем все время торчали за этим компьютером. Мне тогда было пятнадцать – 1973 или 1974 год.
Освоив немного эту машину, мы выяснили, что в Суиндонском техническом колледже есть компьютер. Мы стали ездить туда в один из выходных на невероятно медленном автобусе – поездка занимала около часа. То был Elliot 803; он помещался в особой комнате в полудюжине белых шкафов размером с холодильник, и управляла им женщина-оператор в белом халате.
Скоро та женщина поняла, что мы умеем обращаться с компьютером, и стала оставлять нас работать одних. Там использовались бумажные перфоленты и телетайп, в машину вводилась перфолента с программой. Мы писали на Алголе, который стал моим первым высокоуровневым языком. Писалась программа на перфоленте и правилась на ней же. Если надо было что-то изменить, мы прогоняли ленту через телетайп, распечатывали новую, останавливали ее в нужном месте и печатали, что требовалось, – очень трудоемкий способ. Что-то вроде строкового редактора с физическим носителем информации. Вот такими были мои первые опыты программирования. Я загорелся этим делом.
Сейбел: В школе ведь не было никаких уроков.
Пейтон-Джонс: Конечно, нет! Совсем ничего, никаких компьютеров не было в программе.
Сейбел: То есть просто – «Эй, ребятки, вот вам компьютер, действуйте».
Пейтон-Джонс: Именно так. Он помещался в большом шкафу, обычно закрытом. Но мы брали ключ, включали его – и вот вам дисплей, показывающий только то, что есть в регистрах, и десятичные номера – содержимое ячеек памяти. Вводишь программу, нажимаешь Go. И можно было пройти ее пошагово. Не было даже языка ассемблера за отсутствием ASCII-символов. В буквальном смысле слова машинный код, отображаемый при помощи десятичных чисел, даже не шестнадцатеричных.
Сейбел: Но экран-то был?
Пейтон-Джонс: Телевизионный экран. Единственное средство вывода информации.
Сейбел: А для ввода?
Пейтон-Джонс: Нечто вроде сенсорной клавиатуры, никаких механических кнопок – довольно сложное устройство. Надо было только коснуться кнопки. Всего их было десятка два.
Сейбел: Только для чисел?
Пейтон-Джонс: Да, и еще кнопки Go и Step. И еще – «показать данную ячейку памяти». Все крайне примитивно, но оттого раззадоривало еще больше.
Сейбел: Раз так, выходит, программу надо было продумывать заранее, в мелочах, до того как вводить ее в машину.
Пейтон-Джонс: Сначала мы рисовали блок-схему, потом разбивали ее на отдельные инструкции, переводили инструкции в этот странный цифровой формат и вводили цифры. Программа состояла обычно из 800 цифр. Потом мы нажимали Go. Если везло, мы не ошибались ни в одной из этих 800 цифр, и все работало. Поэтому у нас уходило много времени: один смотрел на экран и проверял, другой говорил: «Переходи к следующей ячейке».
Затем я поступил в Кембриджский университет; эра микропроцессоров только начиналась. В университете был компьютерный клуб. Там стояла большая машина под названием Phoenix с исключительно замысловатой системой учета ресурсов.
Было очень важно, в какое именно время ты пользовался компьютером. Тебе давали некоторое количество единиц машинной «валюты», и чем больше памяти или времени у тебя уходило, тем больше их расходовалось. Соответственно, чем меньше ресурсов отнимала твоя программа, тем меньше ты тратил. Мы, зеленые студенты, которым этих единиц давали мало, просиживали там ночи напролет – после девяти вечера все стоило дешевле.
И мы с девяти вечера до трех ночи торчали там, сочиняя программы. На чем мы писали? На BCPL. Опять сплошная самодеятельность, как видите. В то время я занимался математикой и формально совсем не учился компьютерным наукам.
Тогда, в 1976-1979 годах, не было степени бакалавра как таковой. В последний год можно было выбрать специализацию, например компьютерные науки. Но нельзя было заниматься одним предметом все три года – надо было еще изучать, скажем, математику, естественные науки. Я занимался математикой и закончил со специальностью «Науки об электричестве». Тогда я считал, что компьютеры – так, игрушка, а специализация должна быть серьезной.
Но математика оказалась нелегким делом, ведь в Кембридже отличная математическая школа. Так что я переключился на электричество.
Сейбел: «Науки об электричестве» – это то, что в Америке называется «Электротехника»?
Пейтон-Джонс: Совершенно верно. Мой школьный приятель Томас Кларк тоже учился в Кембридже. Мы с ним собирали компьютеры. Покупаешь микропроцессор, много транзисторов серии 7400 и соединяешь их проводами. Большой проблемой оставались принтеры и экраны. С ними было трудно.
Сейбел: Стоили очень дорого.
Пейтон-Джонс: Да, очень дорого. Части электрической схемы студент еще мог купить, но принтеры... Это были большие линейные принтеры размером с холодильник. Внутри было много механических частей, так что эти устройства оказывались нам не по карману. И еще устройства для хранения данных, любые. Поэтому мы старались обходиться клавиатурой, экраном, ну, еще простенький лентопротяжный механизм.
Сейбел: Значит, в 1976-1979 годах вы собирали компьютеры из подручных средств. Но ведь как раз в это время выпустили Altair.
Пейтон-Джонс: Да. Самоделки уже выходили из моды. Но нам просто нравилось все это.
С этими нашими машинами была еще одна сложность – программы. Самое продвинутое, что можно было загрузить, – конвеевская игра «Life» (Жизнь). Она работала прекрасно. Но что-то серьезное, вроде языка программирования, требовало слишком много работы – у нас были крохотные постоянные хранилища данных. Ну и, кроме того, все писалось в шестнадцатеричном коде, никакого ассемблера.
Сейбел: Машинный код в чистом виде.
Пейтон-Джонс: Конечно, большой компьютер Кембриджа понимал BCPL, и мы писали много программ на BCPL. Еще мы начали писать компилятор для языка, который сами изобрели, но забросили – слишком сложно выходило. То были два мира, которые не сообщались между собой. С одной стороны, мы писали компиляторы для большого компьютера на высокоуровневом языке, с другой – возились с железом.
Сейбел: Помните вашу первую интересную программу?
Пейтон-Джонс: Программа для извлечения 24-значных квадратных корней и помещения их в 99 ячеек памяти – это еще для школьного компьютера.
Сейбел: И одна оставалась в запасе!
Пейтон-Джонс: Правильно. Что-то вроде метода Ньютона-Рафсона для квадратных корней. Я страшно гордился этим. Что же было потом? Потом, наверное, тот самый компилятор, который мы забросили, на BCPL. Мы многое с ним связывали и разрабатывали его детально. Системы типизации не было, так что у нас имелись только громадные листы распечаток с картинками, схемами и стрелками.
Сейбел: В BCPL не было системы типизации?
Пейтон-Джонс: Нет. Поэтому мы рисовали типы на больших листах бумаги и ставили стрелки. Это и была наша система типизации. Программа оказалась слишком большой для наших возможностей, мы ее так и не закончили.
Сейбел: Вы извлекли уроки из этой неудачи?
Пейтон-Джонс: Я впервые понял, что если пишешь очень большую программу, то она просто не умещается у тебя в голове. До того все, что я писал, целиком помещалось в голове без особых проблем. И вот тогда я сделал первую попытку создать долговременную документацию.
Сейбел: Но даже ее оказалось недостаточно?
Пейтон-Джонс: Ну, у нас были и другие заботы – надо было получать степень бакалавра. А компьютерами мы занимались по вечерам и ночью.
Сейбел: Что вам не нравится в том, как вы учились программированию?
Пейтон-Джонс: Никто меня этому не учил. Но не уверен, что это большой пробел. Самый большой пробел – то, что я на глубинном уровне так и не приобрел познаний в объектно-ориентированном программировании. Нет, я знаю, конечно, как писать объектно-ориентированные программы. Но делать это в большом масштабе – дело совсем другое. Если писать большие программы, использовать сложным образом разные иерархии классов, создавать фреймворки – вот тогда приходит глубинное понимание. Это не то же самое, что прочесть книгу.
Я считаю это пробелом, так как не могу авторитетно высказываться насчет того, что можно и чего нельзя делать в объектно-ориентированном программировании. Я всегда очень осторожен в своих высказываниях, особенно стараюсь не говорить отрицательно об императивном программировании – это невероятно сложная и богатая парадигма программирования. Но жизнь сложилась так, что мне ни разу не пришлось в течение нескольких лет писать большие программы на C++. Так приобретаются глубинные познания на уровне рефлексов, и у меня их нет.
Сейбел: Что было после Кембриджа?
Пейтон-Джонс: Я подумал: «Надо бы поработать с компьютерами». И я год занимался послеуниверситетской подготовкой по компьютерным наукам; это мое единственное официальное образование в компьютерной области.
Сейбел: Что-то вроде магистратуры?
Пейтон-Джонс: Что-то вроде магистратуры. То был очень полезный для меня год. Думаю, это примерно соответствовало сегодняшней степени бакалавра по компьютерным наукам, но было рассчитано на студентов, которые начинают с нуля.
Сейбел: Вы несколько лет провели в индустрии, прежде чем вернуться в науку. Чем вы занимались?
Пейтон-Джонс: Это была крошечная компания. Мы производили оборудование и программы для компьютеров, которые устанавливались в приборы измерения веса на ленточных транспортерах. Помню, я спроектировал штуку, наблюдавшую за ячейкой загрузки углепогрузочного транспортера. Она контролировала скорость ленты в зависимости от наполнения ячейки, чтобы соблюдать норму перемещения угля за единицу времени. Небольшая система, но оперировавшая в реальном времени; я использовал для нее PL/Z, слегка похожий на Алгол. Я писал программу на компьютере Z80 с операционной системой Chromix – урезанный UNIX, так сказать.
В компании обычно работало человек шесть, временами больше – до пятнадцати. Из-за ее крошечных размеров все было довольно ненадежно. Денег то было много, то совсем не было. После двух лет я решил, что предпринимательство не для меня. Это был мой главный опыт, если говорить о мелких компаниях; чтобы стать успешным предпринимателем, надо извлекать энергию из стрессовых финансовых ситуаций, а у меня в таких случаях энергия, наоборот, расходуется. Мой начальник был управляющим директором компании. Чем хуже шли дела, тем энергичнее он выглядел. Он бегал вокруг, порождал новые идеи насчет программ, трудился как пчела и был счастлив. Именно так и нужно себя вести, а если стресс высасывает из тебя энергию, то постоянно ходишь как вареный.
Я решил, что столько напряженной работы не для меня, стал искать работу и пошел преподавателем в Лондонский университетский колледж. У меня не было ни степени, ни опыта исследовательской работы. И декан факультета облегчил мне нагрузку, чтобы я мог заниматься исследовательской работой. Но у меня не было ни малейшего понятия насчет того, что делать. Я сидел в своем кабинете перед чистым листом бумаги и ждал Великих Идей. В полной тишине я обводил комнату взглядом в поисках Великих Идей. И все.
Джон Уошбрук, старший научный специалист факультета, взял меня под свое крыло и сказал кое-что очень важное. «Начни хоть с чего-нибудь, пусть даже мелкого», – сказал он. Это относилось не к программированию, а к исследованиям. Пусть тема будет мелкой, неоригинальной, маловажной – надо взять и написать статью. Я так и сделал. Совет Джона очень много значил для меня.
Я повторял его потом каждому аспиранту. Так и нужно начинать. Как только все завертелось, компьютерные науки превращаются в некий калейдоскоп – все интересно, потому что предмет развивается быстрее тебя. Это не какая-то неподвижная вещь, которую ты изучаешь, а то, что постоянно расширяется и приближается.
Сейбел: Итак, вы вернулись в науку, но степень так и не получили. Почему?
Пейтон-Джонс: Сейчас занять должность на факультете без степени было бы крайне трудно. Тогда – это был 1982, 1983 год – я подал заявку в Лондонский университетский колледж. Моя сестра изучала там компьютерные науки и сказала мне: «Там читают лекции по этой теме, почему бы тебе не пойти туда?» И меня, к моему удивлению, приняли. Видимо, тогда преподавателей не хватало, поэтому принимали каждого, кто хоть как-то зарекомендовал себя в этой области. Иначе как бы они наняли человека без степени?
После семи лет преподавания в колледже я начал задумываться о степени. Однако писать диссертацию – это так муторно! Выяснилось, что в Кембридже можно получить степень особым образом – представить опубликованную работу и, если повезет, станешь доктором. Я начал хлопотать об этом, но тут получил место профессора в Глазго. Теперь уже никому не было дела, есть у меня степень или нет, и я оставил эту мысль. У Робина Милнера ее тоже нет, так что я оказался в неплохой компании. На этом все и закончилось.
Сейбел: А в наши дни степень имеет значение? Кто-то говорил мне, что это зависит от призвания – если хочешь быть преподавателем, то она нужна, но если нет, то не имеет смысла. Применимо ли это к компьютерным наукам?
Пейтон-Джонс: Совершенно верно. Это необходимое, хотя и недостаточное условие, если делать исследовательскую карьеру в академических учреждениях или, например, в лабораториях Microsoft Research либо Google, то есть в научных центрах крупных компаний. Без степени вы застрянете на стартовой отметке.
Если же вы не намерены заниматься исследованиями, то прислушайтесь к внутреннему голосу. Если работаешь над чем-то с воодушевлением, продуктивность возрастает пятикратно. Если вам нравится что-то и вы хотите всерьез в этом копаться, написание диссертации – фантастическая возможность провести в Британии три года, а в Штатах еще больше, занимаясь исследованиями. Невероятная свобода, потому что в некотором роде паразитируешь на обществе. Если нет желания полностью посвящать себя науке, можно сесть за диссертацию просто потому, что пытлив и полон энтузиазма. Но, вообще говоря, странная это вещь – работать для себя и писать пухлую работу, которую не прочтет почти никто, – люди будут читать только ваши статьи. Это нестандартный способ заниматься исследованиями.
Получив степень, вы начинаете работать в сотрудничестве с другими людьми над более мелкими проблемами. По-моему, написание диссертации – странный способ подготовиться к дальнейшей карьере, даже исследовательской. Совсем странный в Британии, поскольку у вас очень мало времени. В Штатах, мне кажется, иначе – там можно плодотворно поработать с другими, пока не сосредоточишься на собственных исследованиях.
Сейбел: Раз уж речь зашла о науке, надо сказать, что функциональное программирование популярно среди исследователей, но остальные часто считают его слишком близким к математике и далеким от типичных программистских задач. Это верно?
Пейтон-Джонс: Наполовину. Для меня функциональное программирование – чисто функциональное программирование, где побочные эффекты выделены в свой собственный мир; это элегантный и дерзкий вызов всей индустрии создания программ. Дерзкий, поскольку знаменует собой разрыв с тем, что есть.
А что у нас есть сейчас? Есть крупные компании, которые тратят огромные деньги на экосистемы, редакторы, профилирование, инструменты, программистов, повышение квалификации и так далее. Те, кто делает погоду, мыслят сугубо практично. Ну, а элегантное и дерзкое функциональное программирование намного менее обеспечено такой инфраструктурной поддержкой. Но погоня за этой поддержкой не всегда оправданна. Ведь только пока кто-то занимается чем-нибудь элегантным и дерзким, вы можете изменять господствующую тенденцию в лучшую сторону. Но вы никогда не достигнете тех же высот, что они.
Поэтому, на мой взгляд, прелесть академических исследований в том, что ученые могут с головой уйти в свои безумные вещи без необходимости отвечать на вопросы о том, что это дает на практике. Что-то окажется потом фантастически важным, что-то не очень, но ничего предсказать заранее невозможно. Главное оправдание для людей вроде меня, которые занимаются чисто функциональным программированием, состоит в том, что с ним связаны большие надежды. Программисты не обязательно пойдут именно по этой дороге, но с функциональным программированием связаны большие надежды. Песчаник императивного программирования выветривается, и под ним обнаруживается гранит функционального программирования.
При этом чисто функциональное программирование первоначально было слишком эксцентричным и академичным, слишком тесно связанным с математикой. За последние 20 лет – те, что я с ним работаю, – оно становится все более ориентированным на практику, не обращаясь к абстрактным идеям, а пытаясь убрать одно за другим препятствия, мешающие реальным программистам использовать функциональные языки для создания приложений. Развитие Haskell может служить примером.
Хорошо, что есть люди, может быть, слегка непрактичные, которые идут впереди общей массы. Перспективы чисто функционального мира могут стать для этой общей массы путеводной звездой. Собственно, так и происходит. Многое в системах типизации и обобщенных типах изначально было разработано в контексте языков функционального программирования – они послужили своего рода лабораторией. Еще один пример: генераторы и «ленивые» потоки. В Python есть списковые выражения на синтаксическом уровне. Есть много индивидуальных находок. Если они переходят на текущий уровень программирования, то получают новые названия, слегка видоизменяются. Не хочу показаться великим поставщиком идей, но здесь действительно есть кое-что, нигде до того не реализованное. Так что это сослужило свою службу.
Сейбел: Какова, по-вашему, связь между исследованиями и собственно программированием?
Пейтон-Джонс: Они активно взаимодействуют. Моя область исследований – языки программирования. Для чего, в конце концов, они создаются? Чтобы легче было программировать. Язык – не что иное, как пользовательский интерфейс программы. Поэтому программирование и исследования в области языков тесно между собой связаны. У нас пока плохо получается наблюдать за программистами. Нужно проводить формальное изучение того, как программисты пишут программы, чтобы понимать, что они делают. Это очень затратно, и к тому же деятельность у программистов довольно нечеткая – результат не всегда выходит однозначный.
Культура сообществ вокруг языков программирования ориентирована на доказательство качества и полноты систем типов. Мы же стараемся ответить на более важный, но и более сложный вопрос – делают ли они людей более продуктивными? На него, однако, трудно дать убедительный ответ. Что будет эффективнее для выполнения одной и той же операции – функциональная или объектно-ориентированная программа? Даже если вы потратите кучу денег на серьезные эксперименты, сомневаюсь, что люди будут заинтересованы в их результатах.
Сейбел: А вы делали опыты хотя бы в небольшом масштабе? Вы работаете на Microsoft, у которой полно денег. Почему не посадить за одну и ту же задачу команду опытных Haskell-программистов и команду опытных С#-программистов? Ведь вам именно это нужно?
Пейтон-Джонс: Да, вы правы. Отчасти это вопрос денег. Но не только: это также вопрос времени и внимания. Для такого эксперимента нужна новая методология. Нужно повернуть по-другому свое сознание. Кроме того, со стороны кажется, будто у нас много денег, но стандартная картина для Microsoft – это одинокий исследователь за своим компьютером. Мы не можем просто так взять и потратить деньги на какой-нибудь проект. Если бы могли, было бы здорово. Ближе к переднему краю стоят лаборатории в Редмонде – там исследуются прототипы продуктов. Новые версии Visual Studio проходят там широкую проверку на потребительские свойства.
Сейбел: Вероятно, там больше занимаются взаимодействием с пользователями, чем языками программирования.
Пейтон-Джонс: Они также делают кое-что интересное в плане тестирования API. Стивен Кларк и его редмондские коллеги стараются регулярно наблюдать за программистами, получившими новый API, – о чем те говорят, что пытаются сделать. Проектировщики данного API сидят за стеклянной перегородкой и наблюдают.
Иногда эти проектировщики говорят программистам: «Нет-нет, не делайте так! Это неправильно!» Часто такие ситуации бывают очень поучительными. Потом API меняют там, где нужно. Честно говоря, в этом отношении исследования языков не столь продвинулись. Отчасти потому, что там нужно решать более сложные проблемы. Кроме того, в культурном смысле мы еще мало к этому адаптированы. Я считаю это нашей слабостью. И я не чувствую лично себя в состоянии предложить для этого решение.
Сейбел: Если исследователи выдвигают интересные идеи насчет улучшения процесса программирования, достаточно ли быстро они внедряются на практике?
Пейтон-Джонс: В кратчайшее время... Даже не знаю. Я часто разговариваю с людьми, которые занимаются производством продуктов, нужных покупателю, – покупатель готов платить за них. И многое из того, что заботит меня, лежит вообще вне поля их зрения.
Им надо сделать то, что потребитель готов оценить сегодня. У них просто нет времени заморачиваться с тем, что может работать в принципе или даже с тем, что может работать прямо сейчас, но пока еще не совсем доделано.
Тут есть небольшой разрыв – снова старая задача про курицу и яйцо. Порой идеи, развитые исследователями, требуют дополнительных инженерных усилий – не фундаментальных исследований, а приспособления к практическим нуждам.
