Пол Грэм: «Месть ботанов», часть 1
Продолжаем перевод эссе и книги Пола Грэма «Хакеры и Художники».
Оригинал — Revenge of the Nerds
(кто хочет присоединиться к переводу — пишите в личку)
За перевод спасибо Щёкотовой Яне.
Май 2002
«Мы гонялись за С++ программистами. Нам удалось перетащить их целую кучу на полпути к Lisp.»
Гай Стил, соавтор Java спецификации.
В бизнесе программного обеспечения идет вечная борьба между вооруженными до зубов знаниями учеными, и другой, не менее грозной силой, начальниками, в арсенале которых одно сплошное невежество (* в оригинале pointy-haired boss – персонаж серии комиксов «Дилберт» Скота Адамса, отличается необразованностью и полнейшим отсутствием базовых знаний области, которой он управляет). Все ведь знают, что это за зверь такой? Полагаю, большинство людей в мире технологий не только распознают этого карикатурного персонажа, но и знакомы с реальным человеком из своей фирмы, с которого этот образ срисован.
Невежественный начальник чудесным образом сочетает в себе два качества, которые сами по себе довольно распространены, но редко, когда объединяются в одном лице: (а) он ровным счетом ничего не знает о технологиях, и (б) у него всегда есть самые твердые убеждения по любому касающемуся их вопросу.
Предположим, например, Вам надо написать некоторую программу. Ваш начальник-невежда не имеет ни малейшего понятия о том, как она должна работать, и не может отличить один язык программирования от другого, и все же, он знает, на каком языке Вам следует писать эту программу. А именно, он считает, что Вам следует писать ее на Java.
Почему он так думает? Давайте посмотрим, что творится в это время в голове у начальника-профана. То, что он думает, выглядит вот так. Java это стандарт. Я знаю, так должно быть, потому что я постоянно читаю об этом в СМИ. Поскольку это стандарт, у меня не будет проблем из-за его использования, что также означает, что всегда будет куча Java программистов. Поэтому, если программисты, работающие сейчас на меня, уволятся, так как все программисты, работающие у меня, так всегда и делают по какой-то таинственной причине, я могу с легкостью их заменить.
Ну, это не лишено смысла. Но это все основано на одном негласном предположении, которое на самом деле ложно. Такой начальник считает, что все языки программирования довольно сильно схожи. Если бы это было так, он бы попал в самую точку. Если бы все языки были бы взаимозаменяемы, то конечно, можно было бы использовать любой язык, которым пользуются другие.
Но все языки разные, и я полагаю, что могу доказать это Вам без излишних подробностей об их различиях. Если бы Вы спросили начальника в 1992 году на каком языке программирования следует писать программу, он бы без сомнения ответил так, как и сегодня. Программное обеспечение следует писать на С++. Но если все языки равносильны, почему тогда мнение начальства должно вообще измениться? То есть почему Java разработчикам вообще следовало беспокоиться о создании нового языка?
По всей видимости, если Вы создаете новый язык, то только потому, что думаете, что он, в некотором роде, лучше, чем то, что уже есть у людей. И действительно, Гослинг дает понять в первой официальной документации по Java, что тот (язык программирования Java), в свою очередь, был создан, чтобы решить некоторые проблемы С++. И вот, пожалуйста. Не все языки равносильны. Если Вы проследите за ходом мыслей в голове нашего начальника до Java и обратно, через историю Java к его истокам, у Вас возникнет догадка, идущая в разрез с предположением, с которого Вы начали.
Так кто же прав? Джеймс Гослинг, или наш невежественный начальник? Неудивительно, что прав Гослинг. Некоторые языки лучше других для конкретных задач. И, знаете ли, это поднимает ряд интересных вопросов. Java был разработан, чтобы быть лучшим для некоторого круга задач, по сравнению с С++. Каких задач? Когда лучше использовать Java, а когда С++? Существуют ли ситуации, когда другие языки лучше, чем эти.
Как только Вы начнете раздумывать над этим вопросом, Вы попадете в запутанную ситуацию. Если бы начальнику пришлось думать о задачах комплексно, у него бы мозги взорвались. Как только он определит все языки программирования как равнозначные, все, что ему нужно сделать, это выбрать тот, у которого окажутся наиболее мощные темпы развития. И, т.к. это больше вопрос моды, чем технологий, даже он, вероятно, сможет получить верный ответ. Но если языки разные, ему, вдруг, приходится решать две системы уравнений, пытаясь найти оптимальный баланс между двумя вещами, о которых ему ничего неизвестно: относительная приемлемость 20, или около того, ведущих языков для задачи, которую ему нужно решить, и сложность поиска программистов, библиотек, и т.д. для каждого из них. Если это то, что кроется за дверью, неудивительно, что невежественный начальник не захочет ее открывать.
Недостаток убеждения в том, что все языки программирования эквивалентны, состоит в том, что это на самом деле не так. Но преимущество заключается в том, что это значительно упрощает Вашу жизнь. И я думаю, это основная причина, по которой данное убеждение так широко распространено. Так удобно.
Нам известно, что Java должен быть довольно хорош, потому что это новый, современный язык программирования. Так ли это? Если взглянуть на мир языков программирования свысока, то будет казаться, что Java это самая последняя новинка. (Если смотреть с достаточно большой дистанции, все, что можно будет увидеть, это большой сияющий рекламный щит, оплаченный корпорацией Sun.) Но если взглянуть на этот мир с довольно близкого расстояния, обнаружится, что существует некоторая степень этой крутости. В субкультуре хакеров есть другой язык, под названием Perl, который считается намного круче Java. Сайт Slashdot, например, сгенерирован на Perl. Я не думаю, что Вы бы увидели, как эти парни используют Java Server Pages. Но существует еще один, более новый язык, который называется Python, чьи пользователи стараются смотреть на Perl свысока, но и это еще не все.
Если рассмотреть эти языки в таком порядке Java, Perl, Python, то можно заметить интересную схему. По крайней мере, эта схема заметна, если Вы используете Lisp. Каждый из них все больше и больше похож на Lisp. Python копирует даже такие особенности, которые многие Lisp программисты принимают за ошибки. Можно было бы построчно перевести простые Lisp программы на Python. На дворе 2002 год, и языки программирования почти сравнялись тем, что было разработано в 1958 году.
Идя в ногу с математикой
Что я хочу сказать, так это то, что Lips был впервые открыт Джоном Маккарти в 1958 году, а популярные языки программирования только сейчас подхватывают идеи, которые он в то время развивал.
Итак, как же такое может быть? Разве компьютерные технологии не меняются очень быстро? Я только хочу сказать, что в 1958 году компьютеры были гигантами величиной с холодильник с мощностью процессоров как у наручных часов. Как могла такая старая технология оставаться актуальной, не говоря уже о том, чтобы превзойти последние разработки?
Я расскажу Вам как. Все потому, что Lisp, в действительности, не разрабатывался как язык программирования, по крайней мере, не в том смысле, что мы понимаем сегодня. То, что мы подразумеваем под языком программирования, является тем, чем мы пользуемся для указания компьютеру, что делать. Маккарти, в конце концов, планировал разрабатывать язык программирования в этом смысле, но Lisp, к которому мы пришли, был основан на некоторой отдельной его работе, чисто теоретического характера, — попытке определить более удобную альтернативу машине Тьюринга. Как Маккарти позже говорил:
«Другой способ показать, что Lisp точнее машин Тьюринга, это написать универсальную Lisp функцию и показать, что она короче и более понятна, чем описание универсальной машины Тьюринга. Таковой была Lisp функция eval …, которая вычисляет значение Lisp выражения…. Описание eval требовало создания нотации, представляющей Lisp функции как данные языка Lisp, и такая нотация была разработана ради самого исследования, не задумываясь о том, что она будет использоваться для выражения Lisp программ на практике.»
А потом произошло вот что. Спустя некоторое время в конце 1958 года, Стив Рассел, один из аспирантов Маккарти, взглянул на определение eval и осознал, что если бы он перевел это в машинный язык, то результатом был бы интерпретатор для Lisp.
Это было большой неожиданностью в те времена. И вот что позже в интервью Маккарти сказал по этому поводу:
Стив Рассел сказал: «Послушай, почему бы мне не запрограммировать эту eval функцию.» А я ответил ему: «Ха, ты путаешь теорию с практикой. Эта eval функция предназначена для чтения, а не вычислений.» Но он продолжил работу и сделал ее. Таким образом, он скомпилировал eval функцию из моей работы в машинный код IBM 704, исправил ошибки, а потом представил это как интерпретатор для Lisp, чем это на самом деле и являлось. Таким образом, с этой точки зрения Lisp обладал в основном той формой, какую имеет сегодня…
Внезапно, полагаю, за какие-то несколько недель, Маккарти обнаружил, что это чисто теоретическое мероприятие преобразовалось в настоящий язык программирования, и даже более мощный, чем он предполагал.
Таким образом, кратким объяснением того, почему этот язык 1950-х годов не относят к устаревшим, является тот факт, что его основой была не технология, а математика. Ведь математика не обладает сроком годности. Будет правильнее сравнивать Lisp не с аппаратурой 1950 года, а, скажем, с алгоритмом быстрой сортировки, который был открыт в 1960 году и все еще является самым быстрым алгоритмом сортировки общего назначения.
Существует другой язык, выживший со времен 1950-х годов, Fortran, и он представляет противоположный подход к разработке языков. Lisp был теорией, которая неожиданно превратилась в язык программирования. Fortran изначально разрабатывался как язык программирования, но, как бы мы сейчас оценили, в качестве низкоуровневого.
Fortran I, разработанный в 1956 году, был совсем другого поля ягода, в отличие от нынешнего языка Fortran. Fortran I в большей степени был языком ассемблера с математикой. В некотором роде он был слабее более новых языков ассемблера. Например, в нем отсутствовали подпрограммы, только операции перехода. Современный Fortran сейчас, возможно, ближе к Lisp, чем к Fortran I.
Lisp и Fortran были ветвями двух различных древ эволюции. Один брал свое начало из математики, а второй – из архитектуры машин. Эти два древа с тех пор переплетаются. Lisp мощно выстрелил и на протяжении последующих 20 лет ускорился. Так называемые господствующие языки быстро стартовали, но на данный момент наиболее продвинутые из них едва ли могут поравняться с Lisp. Они недалеко от него ушли, но им все еще не хватает пары вещей.
Продолжение следует
