Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
- Название:Кодеры за работой. Размышления о ремесле программиста
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2011
- Город:Санкт-Петербург
- ISBN:978-5-93286-188-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста краткое содержание
Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.
Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.
Кодеры за работой. Размышления о ремесле программиста - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Сейбел:Вероятно, там больше занимаются взаимодействием с пользователями, чем языками программирования.
Пейтон-Джонс:Они также делают кое-что интересное в плане тестирования API. Стивен Кларк и его редмондские коллеги стараются регулярно наблюдать за программистами, получившими новый API, - о чем те говорят, что пытаются сделать. Проектировщики данного API сидят за стеклянной перегородкой и наблюдают.
Иногда эти проектировщики говорят программистам: “Нет-нет, не делайте так! Это неправильно!” Часто такие ситуации бывают очень поучительными. Потом API меняют там, где нужно. Честно говоря, в этом отношении исследования языков не столь продвинулись. Отчасти потому, что там нужно решать более сложные проблемы. Кроме того, в культурном смысле мы еще мало к этому адаптированы. Я считаю это нашей слабостью. И я не чувствую лично себя в состоянии предложить для этого решение.
Сейбел:Если исследователи выдвигают интересные идеи насчет улучшения процесса программирования, достаточно ли быстро они внедряются на практике?
Пейтон-Джонс:В кратчайшее время... Даже не знаю. Я часто разговариваю с людьми, которые занимаются производством продуктов, нужных покупателю, - покупатель готов платить за них. И многое из того, что заботит меня, лежит вообще вне поля их зрения.
Им надо сделать то, что потребитель готов оценить сегодня. У них просто нет времени заморачиваться с тем, что может работать в принципе или даже с тем, что может работать прямо сейчас, но пока еще не совсем доделано.
Тут есть небольшой разрыв - снова старая задача про курицу и яйцо. Порой идеи, развитые исследователями, требуют дополнительных инженерных усилий - не фундаментальных исследований, а приспособления к практическим нуждам.
Я не хотел бы утверждать, что компьютерные “практики” зомбированы и не желают внедрять хорошие идеи, которые могут облегчить им жизнь. То, что они делают, имеет под собой основания. Расстояние между прототипами и практически применимыми вещами часто бывает большим. Думаю, Microsoft здесь неплохо справляется. Microsoft Research позволяет сократить это расстояние и располагает кое-какими механизмами - инкубационными группами и так далее, - которые сближают исследователей и разработчиков ПО, позволяют пересечь разделяющую их границу. Поэтому я считаю, что MSR полезен настолько, насколько дает возможность преодолеть эту границу.
Если копнуть глубже, встают новые вопросы. Для разработчика-практика, имеющего дело с Java, дело не только в том, что функциональное программирование - принципиально иной подход. Дело еще и в способности программ к взаимодействию. Достаточно ли книг и библиотек? Способ программирования формирует вокруг себя целую экосистему - люди, навыки, библиотеки, операционные среды, инструменты и так далее.
Если таких камней преткновения довольно много, застреваешь. Мне кажется, различные элементы исследовательских подходов к языку живут в разных точках спектра. Некоторые довольно близки к тому, что уже есть. Вы можете сказать, что эта штука подключается прямо в фреймворк, не требует модификации Java, это инструмент статического анализа, позволяющий найти ошибки в коде. Ура! Такие вещи воспринимаются куда легче, чем “вот вам полностью новый способ программирования”.
Если же говорить конкретно о функциональном программировании, то отношение к нему сильно изменилось в последнее время. Гораздо больше народа знают теперь, что это такое. Уже не приходится всякий раз объяснять, что такое Haskell. Некоторые говорят: “Я читал про него недавно на Slashdot, по-моему, это круто”. Еще несколько лет назад такого не было.
Но что за этим реально кроется? Случайный всплеск интереса? Или просто все больше бывших студентов, узнавших в университете о функциональном программировании, занимают теперь менеджерские и руководящие должности? Возможно, и так. Но, может быть, причина в том, что с усложнением программных систем становится все важнее справляться с последствиями неконтролируемых побочных эффектов, иметь больше гарантий корректности и лучше использовать параллелизм. Думаю, стрелка на шкале “цена-качество” постепенно смещается.
Сейбел:А как вы сами начали заниматься функциональным программированием?
Пейтон-Джонс:Я ничего о нем не знал до последнего года в Кембридже, когда прослушал небольшой курс Артура Нормана. Норман был блестящим, слегка эксцентричным лектором. Он интересовался символической алгеброй, так что хорошо разбирался в Лиспе. На лекциях он объяснял нам, как составлять двунаправленные списки без каких-либо побочных эффектов. Отлично помню это, потому что впервые столкнулся с такой удивительной вещью - составляешь список, выделяешь ячейки и заполняешь их так, чтобы они указывали друг на друга. Кажется, будто нужно как-то использовать побочные эффекты.
Но он показал, как в чисто функциональном языке делать это без побочных эффектов. Я понял, что функциональное программирование, о котором я тогда знал очень мало, - это средство создания интересных программ, а не только безделушек.
Сейбел:Думаю, многие после такой лекции сказали бы: “Занятно!” - и вернулись к своему BCPL. Почему же вы пошли дальше, занялись исследованиями, стали объяснять людям, как пользоваться этими программами?
Пейтон-Джонс:Еще сыграли роль статьи Дэвида Тернера о комбинаторах S и К, которые помогают преобразовывать и затем выполнять лямбда-вычисления. О лямбда-вычислениях я знал немного больше - тогда эта идея набирала популярность. Тернер показывал, как преобразовывать лямбда-вычисления в три комбинатора: S, К и I, которые представляют собой закрытые лямбда-термы. Фактически речь шла о том, чтобы преобразовать сколь угодно сложные лямбда-термы в эти три комбинатора. Можно даже обойтись без I, так как он равен SKK.
Довольно странное преобразование - берешь лямбда-терм, который хоть как-то понимаешь, и получаешь набор из S и К, в котором не понимаешь ничего. Но вот применяешь их к аргументу, и случается чудо - ответ выходит тот же, что и с применением изначального терма. Что-то очень умное - для меня по тем временам невероятное. Но это всегда работает!
Я обратился к функциональным программам по вдохновению. Отчасти, думаю, потому, что был связан с “железом”, а это выглядело способом реализации лямбда-вычислений. Ведь сперва кажется, что в них вообще нет механизма реализации, что это чистая математика, далекая от компьютеров. A S-K комбинаторы, как мне показалось, позволяют применять их на практике - и так оно и было.
Сейбел:Значит, вы решили, что достаточно заложить эти комбинаторы в машину, а потом уже на их основе выполнять операции?
Читать дальшеИнтервал:
Закладка: