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

Это возвращает нас к теме сфер компетенции. Писать код, перемалывающий биты, способны немногие, и если вы оказываетесь внутри кода, работающего с битами, поговорите с тем, кто умеет обращаться с ним, если сами не умеете. Умелые программисты это любят. Они могут днями работать над тем, чтобы сократить последовательность инструкций на одну или доказать какую-нибудь идентичность, чтобы ускорить вычисления. Но испортить код очень легко. И очень легко написать что-нибудь, что станет хорошо работать, скажем, при 2 32- 1 из 2 32потенциальных вариантов ввода. Модульный тест может выявить, что ваше решение не работает с этим одним значением, а может и не выявить. И тогда вы будете виноваты в том, что испортили код.

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

Блох:Согласен. Те, кто способен делать сложные вещи и лишен нужной эмпатии в отношении других, часто становятся жертвой такого подхода. “Я понимаю это и могу этим пользоваться, значит, это годится”, - вот их логика.

Сейбел:А есть ли в программировании нечто, привлекающее людей именно с таким внутренним складом?

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

Мы не думали о реальных клиентах с их проблемами. Если вы теряете из виду своих клиентов - вам конец. Думаю, это нелегко осознать любителям головоломок, идущим в программисты. Но ведь можно и самому получать удовольствие от своей работы! Пробудите в себе ген эмпатии, проектируя свои API, а потом сколько угодно придумывайте всякие затейливые штуковины для ускорения их работы.

Оптимизируйте алгоритмы и структуры данных - особенно параллельные. Вот настоящие головоломки! Надо думать с математической точностью над сложными вещами, уметь по-новому сочетать примитивы, чтобы достичь своей цели. Но всегда нужно понимать, когда это уместно, а когда даст программу, трудную в использовании или поддержке.

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

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

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

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

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

Мы ставим перед собой также и эстетические цели. В нашей сфере требуются умение искусно работать, знание математики, навыки общения и написания прозы. Обычно при словах “разработчик программ” люди не думают обо всем этом, но без всего этого не выйдет хорошего разработчика. Надо постоянно об этом помнить. И все же наша профессия - одна из самых увлекательных в мире. Думаю, нам повезло, что мы выросли в те времена, когда все эти качества толкают человека на путь программирования. Что бы мы делали несколькими поколениями раньше?

Джо Армстронг известен прежде всего как создатель языка программирования Erlang и Open Telecom Platform (OTP) - платформы для создания приложений на Erlang.

Среди современных компьютерных языков Erlang выглядит чудаком. Он старше и одновременно моложе многих популярных языков: Армстронг начал работу над ним в 1986 году - за год до появления Perl, - но язык был доступен лишь в качестве коммерческого продукта и использовался только в изделиях компании Ericsson, пока не был выпущен с открытым исходным кодом в 1998 году - через три года после появления Java и Ruby. Истоки Erlang кроются скорее в логическом языке Пролог, чем в каком-либо из языков семейства Алгол. Кроме того, он был разработан для специфического вида ПО с высокой доступностью и надежностью, как например АТС. Свойства, благодаря которым этот язык применялся на АТС, почти неожиданно сделали его пригодным также для написания программ, предназначенных к использованию в параллельных системах. Это привлекло к Erlang внимание программистов, когда стало понятно, что будущее за многоядерными процессорами.

Армстронг в каком-то смысле тоже чудак. Будучи физиком, он стал осваивать информатику, когда во время написания диссертации по физике, испытывая финансовые затруднения, нанялся исследователем в команду Дональда Мичи - одного из британских первопроходцев в области искусственного интеллекта. В лаборатории Мичи Армстронг познакомился со всеми достижениями в этой сфере, стал членом-основателем Британской робототехнической ассоциации и написал несколько статей о зрении роботов.

Когда финансирование работ в области искусственного интеллекта иссякло благодаря известному “Отчету Лайтхилла”, Армстронг на несколько лет вернулся к программированию для целей физики, работая в научной ассоциации EISCAT и затем в Шведской космической корпорации, пока наконец не оказался в Лаборатории информатики компании Ericsson, где и создал Erlang.

Сидя на кухне стокгольмской квартиры Армстронга, мы несколько дней обсуждали подход к параллелизму, реализованный в Erlang, необходимость поиска более простых и эффективных способов связи между программами, а также важность вскрытия “черных ящиков”.