Я также утвердился в своем мнении, что чем проще - тем лучше. Я наблюдаю все больше сложных добавлений, которые оказываются только вредными в долгосрочном плане, а иногда и в краткосрочном. Создавая программу, я включаю свой собственный "измеритель сложности": если стрелка уходит в красную зону, пора переписывать.
Порой кто-нибудь говорит мне: "Джош, глупец, ты просто не улавливаешь, что тут происходит. Тут все именно так, как должно быть, и жаль, что ты этого не понимаешь!" Но я не покупаюсь на такие разговоры. Я считаю, что если программа становится слишком сложной, то с ней что-то не так и надо искать более простые пути.
Тони Хоар как-то на вручении премии Тьюринга блестяще сказал о том, что есть два способа проектировать систему: "Один - сделать ее настолько простой, что в ней совершенно очевидно не будет недостатков, второй - сделать ее настолько сложной, что в ней не будет очевидных недостатков".
И дальше тоже прекрасно: "Первый способ намного труднее. Он требует умения, увлеченности, озарений не меньше, чем открытие простых физических законов, управляющих сложными природными явлениями. Он также требует настойчивости в достижении целей, когда приходится учитывать физические, логические и технологические ограничения, и идти на компромиссы, когда нельзя удовлетворить взаимно противоречащие требования. Никакой комитет не сможет сделать этого - или сделает слишком поздно".
Сейбел: Как по-вашему, вы будете заниматься Java до пенсии или же перейдете к другому языку?
Блох: Не знаю. Как-то так получилось, что я моментально перешел с Си на Java. После окончания школы и до 1996 года я программировал почти только на Си, а потом - почти только на Java. Конечно, при определенных обстоятельствах я могу перейти на другой язык - но на какой? Может быть, такого языка еще нет в природе. По-моему, мир созрел для нового языка программирования, но инерция платформ сегодня куда сильнее, чем раньше. Современная платформа - это не только язык и несколько библиотек. Это множество инструментов, виртуальная машина, то есть гигантский комплекс. И перспектива создания новой платформы выглядит сейчас намного более пугающей.
Что будет дальше, я не знаю. Но если действительно потребуется, я все еще могу сменить язык. Я хочу быть открытым для разных возможностей, возиться с другими языками. У меня сейчас для этого нет времени, но я хотел бы его иметь.
Сейбел: Назовите языки, с которыми вам хочется повозиться больше всего.
Блох: Например, Scala, хотя у меня есть сомнения насчет его будущей популярности. Я очень уважаю Мартина Одерски - он реализовал в своем языке немало красивых идей. Но, возможно, этот язык сложноват и слишком академичен, чтобы иметь широкий успех. Честно говоря, я еще не изучил его толком, так что могу быть неправ.
Затем Python. Из старых - Scheme. Будет неплохо несколько месяцев поизучать "Structure and Interpretation of Computer Programs" вместе с сыном. Говорят, это отличная книга. В качестве первого шага я купил ее. Но для освоения нужно время.
Сейбел: Сегодня многие озабочены созданием программ, которые бы в полной мере использовали возможности многоядерных процессоров. Java стал первым крупным языком, в котором появились встроенные механизмы для многопоточной работы. Как вы считаете, приспособлен ли он к многоядерному миру?
Блох: Скажу больше: думаю, у него лучшие средства, чем у любого другого языка. Интересно, что сейчас часто слышатся разговоры о смерти Java. Мне кажется, все это несерьезно. Между прочим, лучшие блоки для реализации многопоточности сейчас есть именно в Java. И язык готов пережить небольшое возрождение. Не знаю, куда мы зайдем в ближайшие двадцать лет и лучшее ли это средство для работы с многоядер-ностью. Но из того, что есть сегодня, Java на голову выше своих конкурентов.
Сейбел: Что это за конкуренты?
Блох: Как я считаю, C++ и С#.
Сейбел: А как насчет Erlang или транзакционной памяти?
Блох: Насколько я знаю, транзакционной памяти в рабочем виде пока еще нет ни в одном из крупных языков. Если окажется, что это того стоит, то, наверное, она появится и в Java не позже, чем в прочих языках.
У Erlang свой подход к параллелизму - акторы: если они окажутся успешной находкой, то могут быть реализованы во многих языках. Как вы знаете, Одерски с компанией уже реализовали их в Scala. Пока я не уверен, что акторы - лучшее из придуманного для многоядерного параллелизма, но если все же это так, то и в Java вы скоро увидите их.
Сейбел: Итак, Java, по вашим словам, имеет блоки, позволяющие получить портируемый доступ к параллельным потокам, предоставляемым операционной системой, а также конструкции более высокого уровня в рамках API Java.util.concurrent. Но все равно, это ведь средства довольно низкого уровня в сравнении с Erlang или транзакционной памятью?
Блох: Не уверен. Некоторые конструктивные блоки в Java действительно низкоуровневые, например Atomiclnteger; есть среднеуровневые, например CyclicBarrier, и наконец высокоуровневые - ConcurrentHash-Мар и ThreadPoolExecutor. Уверен, что транзакционная память и акторы найдут свое место в наших конструктивных блоках для многопоточных задач, как только народ убедится, что эти новинки работают хорошо. Если, конечно, они будут работать хорошо.
Некоторые виды транзакционной памяти могут получить значение в будущем, например конструктивные блоки для разработчиков параллельных библиотек. Но мне кажется, транзакционная память не избавит создателей приложений от заботы о блокировках. Она не введет нас в счастливый мир, где потоки не мешают друг другу.
Тому есть несколько причин. Первая из них состоит в том, что если вы пытаетесь делать автоматическую блокировку или оптимистичное управление параллелизмом, основываясь только на чтении и записи на уровне байтов, то между потоками происходит "мнимый конфликт": физические конфликты не соответствуют логическим. Если вам нужны блокировки, то убедитесь, что захвачены лишь те, которые помогают решить логические конфликты.
Так, например, если у вас есть два потока и оба прибавляют значения для счетчика, они должны выполняться параллельно. Они могут обращаться к одному и тому же участку памяти, но при этом не конфликтуют в логическом плане. Если один поток считывает значение счетчика, а другой увеличивает его, то есть конфликт. Но ведь у вас может быть множество потоков, которые считывают значения, и других, увеличивающих их. Я пока не видел систем, которые могли бы справляться с такими вещами самостоятельно. Может быть, мой пример несколько искусственный, но часто физические ограничения намного суровее логических.
Вторая проблема с транзакционной памятью в том, что внутри нее осуществляются не все операции, например операция ввода/вывода. А вот третья проблема: некоторые виды транзакционной памяти позволяют "обреченным транзакциям" видеть память в неустойчивых состояниях - потенциально это крайне опасно. С этими проблемами мы уже сражались, когда строили транзакционные системы общего назначения. Решения есть, но все они усложняют систему или снижают скорость работы.
Так или иначе, насколько мне известно, транзакционная память еще не вышла из стадии исследований. Прекрасно, что этим занимаются. Но по-моему, она не решит разом все проблемы параллельности - по крайней мере, в обозримом будущем.
Сейбел: Сменим тему. Каков ваш стиль работы в команде?
Блох: Я довольно уживчив, предпочитаю "приятельское программирование" - когда работаешь вместе с кем-то, но не за одной клавиатурой. Вы пишете разные части программы, обмениваетесь кодом. Можно вообще пребывать в разных полушариях. Мы с Дугом Ли таким образом плотно работали несколько лет. Один писал интерфейс, другой говорил: "Все отлично, но я поправил там кое-что, вот погляди".
Наконец получался интерфейс, который нас устраивал. Я реализовы-вал однопоточную версию, Дуг - многопоточную, во время работы мы обнаруживали разные просчеты и снова поправляли интерфейс. Мы читали код друг друга, Дуг обычно говорил: "Ты можешь сделать вот так - все заработает гораздо быстрее", - а я отвечал: "Дуг, это ты можешь". Он был очень силен во всем, что ускоряло работу системы, - виртуальные машины были для него как друзья. Этот вид программирования я очень люблю, он как бы сам подталкивает к удаленному сотрудничеству.
Мне нравится сидеть с кем-нибудь за одним терминалом и работать над кодом, но таким образом я сделал не много программ с нуля. Обычно это случается, когда я делаю ревизию кода; если вижу, что код надо сильно править, то предлагаю человеку посидеть вместе. Это полезно во многих отношениях, например как средство обучения, способ передать знания старшего поколения младшему.
А работать совсем в одиночку мне не нравится. Когда я пишу программу и обдумываю какое-нибудь сложное проектное решение, мне нужно с кем-то советоваться. Везде, где я работал, рядом был кто-нибудь, с кем я мог поделиться. Для меня это очень важно - обратная связь.
Сейбел: Так что же важнее - обратная связь или просто шанс проговорить задачу вместе?
Блох: И то и другое. Мы делаем очень хитрые вещи - часто есть не одно правильное решение или одно, но которого никто до тебя не нашел. Надо полагаться на свой инстинкт, но иногда полезно выслушать того, кто смотрит на вещи по-другому.
Я знаю тех, кто любит программировать в вакууме, но это, по-моему, им вредит. Надо замечать ошибки как можно раньше, выявлять недостатки структуры, пока они не отразились на коде. И если вы экспериментируете с разными подходами или просто с разными свойствами, то нужно обсуждать их с другими. При этом не стоит слепо верить никому - мнения могут быть разными, а за свою работу отвечаете только вы.
Сейбел: Еще один вечный вопрос - кажется, его еще в 1970-е поднимал Вайнберг в "The Psychology of Computer Programming", - дискутируется и сейчас: должен ли кодом владеть один человек, и только он и должен с ним работать, - или им должны владеть все, кто работал над проектом, и всем должно быть разрешено вмешиваться в него?
Блох: По-моему, владение кодом отрицать нельзя. Это похоже на рождение ребенка: вы даете жизнь коду, и он ваш, особенно если он большой, или сложный, или оригинальный. Прежде чем начать работать с чужим кодом, спросите разрешения, особенно если считаете, что нашли ошибки, - ведь вы можете быть неправы. Портить чужой код некрасиво.
Конечно, для компании плохо, если кодом владеет один человек. А если он покинет компанию? Поэтому важно, чтобы сразу несколько программистов знали каждый фрагмент кода и могли с ним работать. Но мечтать о том, чтобы все владели всем кодом, по-моему, не стоит.
Это возвращает нас к теме сфер компетенции. Писать код, перемалывающий биты, способны немногие, и если вы оказываетесь внутри кода, работающего с битами, поговорите с тем, кто умеет обращаться с ним, если сами не умеете. Умелые программисты это любят. Они могут днями работать над тем, чтобы сократить последовательность инструкций на одну или доказать какую-нибудь идентичность, чтобы ускорить вычисления. Но испортить код очень легко. И очень легко написать что-нибудь, что станет хорошо работать, скажем, при 2 - 1 из 2 потенциальных вариантов ввода. Модульный тест может выявить, что ваше решение не работает с этим одним значением, а может и не выявить. И тогда вы будете виноваты в том, что испортили код.
Сейбел: Если говорить о запутанном коде, я заметил вот что: у слишком умных - в определенном смысле, по крайней мере - программистов получается самый плохой код. Они держат все у себя в голове, и в итоге получается не код, а тарелка спагетти.
Блох: Согласен. Те, кто способен делать сложные вещи и лишен нужной эмпатии в отношении других, часто становятся жертвой такого подхода. "Я понимаю это и могу этим пользоваться, значит, это годится", - вот их логика.
Сейбел: А есть ли в программировании нечто, привлекающее людей именно с таким внутренним складом?
Блох: Конечно! Всяческие головоломки - наша страсть. Но эта страсть должна сдерживаться пониманием того, что мы решаем реальные проблемы реальных людей. Если же это не так, то мы занимаемся самоудовлетворением и все. Думаю, первая компания, в которой я работал, разорилась именно из-за этого. Надо было понять, что наша цель - не разработка программ сама по себе.
Мы не думали о реальных клиентах с их проблемами. Если вы теряете из виду своих клиентов - вам конец. Думаю, это нелегко осознать любителям головоломок, идущим в программисты. Но ведь можно и самому получать удовольствие от своей работы! Пробудите в себе ген эмпатии, проектируя свои API, а потом сколько угодно придумывайте всякие затейливые штуковины для ускорения их работы.
Оптимизируйте алгоритмы и структуры данных - особенно параллельные. Вот настоящие головоломки! Надо думать с математической точностью над сложными вещами, уметь по-новому сочетать примитивы, чтобы достичь своей цели. Но всегда нужно понимать, когда это уместно, а когда даст программу, трудную в использовании или поддержке.
Сейбел: Разве сейчас возможности для такого программирования не сокращаются? Многие из таких вот низкоуровневых программ уже реализованы в вашей виртуальной машине или параллельных библиотеках. И для многих программирование теперь означает склеивание блоков воедино.
Блох: Полностью согласен. Да, в относительных цифрах процент креативных программистов уменьшается. Когда-то вы покупали машину, для которой не было даже операционной системы, не говоря о языке программирования или готовых приложениях. Каждому приходилось что-то выдумывать.
Тот мир ушел или уже уходит. Но в целом потребность в креативных программистах так же велика, как и всегда. Мы хотим получать удовольствие от нашей работы. Мы хотим преимуществ от безопасных языков и одновременно - скорости вручную отлаженного ассемблерного кода. Кто-то ведь должен создавать виртуальные машины и сборщики мусора, придумывать чипы - хотя это "железо", но в то же время программные произведения.
Думаю, для любителей решать сложные задачи есть масса возможностей, но их энергию надо направлять в нужное русло. Над ними должны стоять менеджеры, использующие их способности в интересах компании.
Тут есть одна проблема: часто такие люди умнее всех прочих в компании и поэтому считают, что это они должны принимать все решения. Но только то, что они самые умные, не означает, что им можно доверять принятие решений. Ум - качество не скалярное, а векторное. Без эмпа-тии или чувственного разума вы не создадите ни API, ни графический интерфейс, ни новый язык.
Мы ставим перед собой также и эстетические цели. В нашей сфере требуются умение искусно работать, знание математики, навыки общения и написания прозы. Обычно при словах "разработчик программ" люди не думают обо всем этом, но без всего этого не выйдет хорошего разработчика. Надо постоянно об этом помнить. И все же наша профессия - одна из самых увлекательных в мире. Думаю, нам повезло, что мы выросли в те времена, когда все эти качества толкают человека на путь программирования. Что бы мы делали несколькими поколениями раньше?
6. Джо Армстронг
Джо Армстронг известен прежде всего как создатель языка программирования Erlang и Open Telecom Platform (OTP) - платформы для создания приложений на Erlang.
Среди современных компьютерных языков Erlang выглядит чудаком. Он старше и одновременно моложе многих популярных языков: Армстронг начал работу над ним в 1986 году - за год до появления Perl, - но язык был доступен лишь в качестве коммерческого продукта и использовался только в изделиях компании Ericsson, пока не был выпущен с открытым исходным кодом в 1998 году - через три года после появления Java и Ruby. Истоки Erlang кроются скорее в логическом языке Пролог, чем в каком-либо из языков семейства Алгол. Кроме того, он был разработан для специфического вида ПО с высокой доступностью и надежностью, как например АТС. Свойства, благодаря которым этот язык применялся на АТС, почти неожиданно сделали его пригодным также для написания программ, предназначенных к использованию в параллельных системах. Это привлекло к Erlang внимание программистов, когда стало понятно, что будущее за многоядерными процессорами.
Армстронг в каком-то смысле тоже чудак. Будучи физиком, он стал осваивать информатику, когда во время написания диссертации по физике, испытывая финансовые затруднения, нанялся исследователем в команду Дональда Мичи - одного из британских первопроходцев в области искусственного интеллекта. В лаборатории Мичи Армстронг познакомился со всеми достижениями в этой сфере, стал членом-основателем Британской робототехнической ассоциации и написал несколько статей о зрении роботов.
Когда финансирование работ в области искусственного интеллекта иссякло благодаря известному "Отчету Лайтхилла", Армстронг на несколько лет вернулся к программированию для целей физики, работая в научной ассоциации EISCAT и затем в Шведской космической корпорации, пока наконец не оказался в Лаборатории информатики компании Ericsson, где и создал Erlang.
Сидя на кухне стокгольмской квартиры Армстронга, мы несколько дней обсуждали подход к параллелизму, реализованный в Erlang, необходимость поиска более простых и эффективных способов связи между программами, а также важность вскрытия "черных ящиков".
Сейбел: Как вы научились программированию? Когда все это началось?
Армстронг: В школе. Я родился в 1950 году - тогда компьютеров было мало. В последнем классе, когда мне было примерно 17, местный совет приобрел мэйнфрейм - вероятно, производства IBM. На нем можно было писать программы на Фортране. Тогда все писали программы на специальных бланках и отсылали их. Через неделю программные бланки и перфокарты возвращались к вам, и надо было их одобрить. Но те, кто набивал перфокарты, часто ошибались, так что они путешествовали туда-сюда, иногда по два раза. В конце концов все это поступало в компьютерный центр.
Из компьютерного центра их опять присылали к вам, и компилятор Фортрана, споткнувшись о первую же синтаксическую ошибку, с остальной частью программы вообще не работал. Чтобы запустить свою первую программу, требовалось месяца три. Тогда я научился вместо одной программы писать несколько параллельных подпрограмм, и отсылал уже их. Я написал программку, которая выводила на печать изображение шахматной доски. Но все подпрограммы были решены как параллельные задачи, поскольку время обработки задания было невероятно большим.
Сейбел: Значит, приходилось писать подпрограммы, по сути, с модульными тестами для их проверки?