Пользователь
136,7
рейтинг
29 сентября 2015 в 00:44

Разработка → Пол Грэм: «Месть ботанов», часть 1

Продолжаем перевод эссе и книги Пола Грэма «Хакеры и Художники».
Оригинал — Revenge of the Nerds
(кто хочет присоединиться к переводу — пишите в личку)

За перевод спасибо Щёкотовой Яне.
Май 2002

«Мы гонялись за С++ программистами. Нам удалось перетащить их целую кучу на полпути к Lisp.»
Гай Стил, соавтор Java спецификации.


imageВ бизнесе программного обеспечения идет вечная борьба между вооруженными до зубов знаниями учеными, и другой, не менее грозной силой, начальниками, в арсенале которых одно сплошное невежество (* в оригинале 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.
image

Lisp и Fortran были ветвями двух различных древ эволюции. Один брал свое начало из математики, а второй – из архитектуры машин. Эти два древа с тех пор переплетаются. Lisp мощно выстрелил и на протяжении последующих 20 лет ускорился. Так называемые господствующие (mainstream) языки быстро стартовали, но на данный момент наиболее продвинутые из них едва ли могут поравняться с Lisp. Они недалеко от него ушли, но им все еще не хватает пары вещей.

Продолжение следует

Еще 80+ статей Пола Грэма на Хабре.
(Кто хочет помочь с переводом — подключайтесь)

П.С.
Если вам интересно попасть в Y Combinator и вам близки идеи Грэма, пишите в личку, есть у меня пара задумок.
Алексей @MagisterLudi
карма
110,5
рейтинг 136,7
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (16)

  • +9
    Старовата статья, немного странно читать о том, что Java — это самая последняя новинка.
  • +2
    Почему он так думает? Давайте посмотрим, что творится в это время в голове у начальника-профана. То, что он думает, выглядит вот так. Java это стандарт. Я знаю, так должно быть, потому что я постоянно читаю об этом в СМИ. Поскольку это стандарт, у меня не будет проблем из-за его использования, что также означает, что всегда будет куча Java программистов. Поэтому, если программисты, работающие сейчас на меня, уволятся, так как все программисты, работающие у меня, так всегда и делают по какой-то таинственной причине, я могу с легкостью их заменить.

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

    Вот по мне так очень странный вывод. Из первого абзаца я сделал бы вывод прямо противоположный. Что языков то много. Но типа Java это mainstream и найти ресурсы намного проще чем для других языков + у конкретного языка широкая экосистема, что облегчает внедрение новых продвинутых технологий.

    Но не как ни тот вывод что делает автор.
    • 0
      java была создана так, чтобы cpp-програмисты могли ее быстро изучить; срр был создан также, но с упрором на с… в 2002 никакой экосистемы не было ни у одного языка, все были в равной степени неадекватны, и программисты обучались с упором на быструю реакцию изменения запросов на рынке (обучали основам и принципам, но никак не языкам, а тем более экосистемам). В 90х экосистема — то, что дали операционная система и библиотека языка программирования, опенсорсные библиотеки boost+stl, gnu (libc)+… никак не могли помочь в стандартизации, образовании и работе: из-за глючных компиляторов и «уникальных» библиотек, монополизма MS, мизерной доли *nix-ов.
      В 2002 ситуация только начала исправляться, в результате бума доткомов, появилась армия неприкаяных веб-дизайнеров, которые и были вынуждены перейти с перлов и пиэчпи на принципиально средообразующию java, которая стала расти в ширь apache-ми, springo-м и jdbc (насколько tomcat и иже с ними оказали влияние, мне не ведомо, в то время был абсолютно уверен, что это будущее).

      | Но типа Java это mainstream
      Вот чем java тогда не была, так это mainstream, но она осваивала новые области, незанятые другими языками. И если бы не js(который создавался как java для бедных) она былы бы основным web-языком.

      |Такой начальник считает, что все языки программирования довольно сильно схожи.
      Не только начальник, сколько создатели языков вынужденно шли эволюционным путем, просто не было программистов на «новых» языках, как в общем, и на старых, все быстро и фатально менялось. Обучение перестало быть фундаментальным, все выродилось во вкусовщину и сию-минутность, а в этом смысле все языки одинаковы на вкус, одинаково мозгодробительны. И остается лишь плач-ярославны о CASE-системах, высокоуровневых языках с интеграцией баз данных и экспертных системах на которые молились в 90х.
      И DSL из той же слезной лужи, и чтот «меня терзают смутные сомнения»… все канет в Лету, не может борьба со сложностью победить вкусовщину, mainstream, как раз, и есть создание сложности, только за нее платят.
  • –1
    50 лет человеку, и до сих пор словно в стране эльфов живёт, честное слово.
  • +7
    Я один заметил что статья датирована маем 2002 года? А то тут уже про эльфов комменты
    • +4
      Извиняюсь, не заметил 2002 год, действительно.

      Впрочем, все эти «тупой начальник vs просветлённые математики» и «лисп — серебряная пуля» — это в любом случае детский сад.
      • +2
        думаю что в 2002 году могло быть и похуже.
        Ваша компания кстати сертифицирована SEI CMMI Level 5? Как вспомню, так вздрогну )
  • –1
    Lisp и Fortran были ветвями двух различных древ эволюции. Один брал свое начало из математики, а второй – из архитектуры машин.


    Я вот например понимаю, что из математики брал начало Fortran, а из архитектуры Lisp, но все же многие могут понять с точностью до наоборот, поскольку порядок изложения не совпадает в первом и втором предложении.
    • +2
      Поскольку чуть выше про Lisp написано, что «этот язык 1950-х годов не относят к устаревшим, является тот факт, что его основой была не технология, а математика», то понять наоборот — что Lisp берёт начало из математики, а Fortran из архитектуры, будет естественно. Тем более, что такие ключевые для фортрана вещи, как Common-блоки и Equivalence, ничем, кроме архитектуры, объяснить нельзя. А в Lisp на архитектуру завязана только реализация, и то по необходимости.
      • 0
        Вы писали на лиспе и фортране? Лисп-машины вам о чем нибудь говорят? А то что на фортран математически ориентированный язык — это знал любой школьник в мое время. Я писал на обоих языках, и поэтому обратил внимание на ошибку в подаче материала, которая может ввести в заблуждение людей которые на застали данные языки.
        • +1
          Писал. И на лиспе, и на фортране. Действительно, фортран, как следует из его названия — formula translator — язык, ориентированный на математические задачи. И не более того. Это всего лишь переводчик формул на наиболее распространённую архитектуру.
          Лисп ориентирован на что угодно, но построен на одной из математических моделей алгоритмов. К сожалению, у меня не было необходимости разбираться в нём очень глубоко, и писал я, скорее, в процедурном стиле, как ни глупо это звучит. setq был любимой функцией.
          Лисп-машины — термин я слышал, подробно не разбирался. Всегда предполагал, что это специальная архитектура, созданная под лисп, но, поскольку мы сейчас не живём в мире таких машин, то либо я был не прав, либо эта архитектура оказалась чем-то неудачной.
          • 0
            Чуть ниже я уже написал, что не прав, автор действительно имел ввиду, то что написал.

            Лисп построен исходя из математических моделей (как в общем-то и любой другой язык — теория компиляторов и все такое), но эти модели все равно ориентированны на архитектуру, т.е. делали так, чтобы язык максимально эффективно исполнялся на цифровых вычислительных машинах.

            Имхо, тут как с курицей и яйцом, можно спорить бесконечно и правых не будет.
            • 0
              Лисп построен исходя из математических моделей (как в общем-то и любой другой язык — теория компиляторов и все такое), но эти модели все равно ориентированны на архитектуру, т.е. делали так, чтобы язык максимально эффективно исполнялся на цифровых вычислительных машинах.

              Это неверно. Лисп изначально требовал сборщик мусора, поэтому считался академическим, а не практическим языком, потому что мощностей машин не хватало на автоматическое управление памятью.
              Кроме того, рекурсивные ф-ции основа Лиспа, когда первые версии Фортрана обходились без них, чтобы быть ближе к машинным архитектурам с ограниченным стеком или без него.
    • +2
      Возможно дело в том, что порядок изложения на самом деле совпадает, и резюмирует то, о чём написано в предыдущих ДЕВЯТИ абзацах. Какую кашу нужно иметь в голове, чтобы найти в статье ошибку, которой нет, потому что она согласуется с вашим представлением о мире, хоть и не согласуется с самой статьёй.
      • 0
        Перечитал статью внимательно и да — действительно, автор имел ввиду, то что имел ввиду. Я не прав — нет ошибок в изложении материала.

        Но… Лисп — брал начало из математики, а фортран из архитектуры машин? Бог ты мой — откуда такие категоричные выводы?

        1) Если подходить формально — все это математематика и архитектура — в программировании они всегда связанны.

        2) Один простой факт о лиспе говорит что он машинно ориентированный — а именно польская запись всех выражений — зачем так сделали? говорят для скорости — так быстрей происходит разбор машиной выражений — это правда, и где тут математика? Все сделано в угоду машины, но не человека.

        3) Фортран имел наиболее мощную математическую библиотеку в свое время, даже втроенный тип для комплексных чисел, огромное число математических вычислений проводилось именно на фортране. И все было сделано для людей, а не в угоду машине.

        ПС. Короче, с автором статьи можно как минимум поспорить, не все тут однозначно.
        • 0
          Один простой факт о лиспе говорит что он машинно ориентированный — а именно польская запись всех выражений — зачем так сделали?

          Чтобы записывать выражения напрямую в нотации лямбда-исчисления Чёрча, как есть, без условностей, удобных машинам ))
          Фортран имел наиболее мощную математическую библиотеку в свое время

          Пока Лисп был академическим языком, Фортран был практическим, применяемым для решения задач. Поэтому была наработана большая библиотека численных вычислений.

          даже втроенный тип для комплексных чисел

          Это потому что императивные языки доросли до задания пользовательских типов данных только с Алголом, который передал это в Паскаль и Си. Ничего не поделаешь, считать надо, а тип описать нельзя, поэтому пришлось включить в язык.
          В Лиспе с этим проблем не было изначально.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.