одолели дьявола”. Год назад я подарил ему в Лондоне шуточный слайд: Дуг в виде Гэндальфа на мосту в Казад-Думе, глядящий вниз на ниспровергнутого ES4pora. Ему очень понравилось. Я впервые подшутил так над ним - его порой оставляет чувство юмора, когда он касается этих проблем. Но ему понравилось. Может, он и герой, но ES4 совсем не был чудовищем.

ES4, как мне кажется сейчас, был слишком объемным. Но нам нужно было прагматично подойти к стандартам. Мы не могли сказать: “Все, что вам нужно, - это лямбда-выражения”. Алонзо Чёрч доказал, что это не так. И мы не могли вставлять еще больше таких выражений. Такой подход, предполагающий высокую квалификацию каждого, многого не учитывает, например того, что многих программистов в Java-вузах научили плохому. JavaScript однажды умрет, но можно совершенствовать его, поддерживать его конкурентоспособность как в теоретическом, так и практическом плане. При условии, конечно, что мы не откажемся от сахара ради чистоты.

Язык должен совершенствоваться, чтобы можно было решить стоящие перед программистами задачи. С некоторыми можно справиться, если писать собственные библиотечные абстракции. Но возможность написания абстракций для языка очень ограничена, если нет расширений - вы не можете написать геттеры и сеттеры[47]. Объекты будут смотреться чужеродно, свойства не смогут стать кодом и так далее. Кроме того, вопросы безопасности нельзя будет разрешать неявно или автоматически.

Сейбел: Как вы полагаете, языки в целом со временем улучшаются?

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

Есть, например, Ruby, испытавший влияние языков Ada и Smalltalk. Это прекрасно. Я не имею в виду эклектичность. Но Ruby перехваливают. Нет, ничего плохого сказать не могу, просто некоторые мальчики- фанаты трубят, что он решит все проблемы, а это не так. Новые языки нужны, но хвалить их надо в меру, не как C++ - “шаблоны проектирования нас спасут”. Конечно, может быть, это реакция на консерватизм приверженцев Си-мира UNIX 1980-x.

Но в какой-то момент нам требуются более совершенные языки. Ведь необходимо иметь инструменты для доказательства, производящие автоматическую верификацию некоторых постулатов, сделанных в вашем коде. Вам ведь не нужны ответы на все, правильно? Динамические инструменты, такие как Valgrind и его детекторы состояний гонки[48], тоже очень полезны. Простых решений нет, но есть более совершенные языки, на которые надо переходить.

Сейбел: В какой степени языки должны предотвращать ошибки программистов?

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

Мне кажется, с JavaScript мы стремились именно к этому, в противоположность диким, неуправляемым французам, которые хотели видеть JavaScript чем-то вроде #86 с лямбда-выражениями. Нам совершенно незачем вводить оператор call/cc. Предположим на минуту, что обойдется без проблем с реализацией: народ будет сбит с толку. Не обязательно большинство, но многие из тех, кто считает себя крутыми программистами. Есть нечто вроде программистской пирамиды, на вершине которой располагается Правильная вещь. Люди карабкаются к вершине, даже если некоторые срываются, получая травмы.

В JavaScript можно нарваться на неприятности разными способами. Есть функции первого класса. Есть малопонятные для людей прототипы - они не отвечают классическим стандартам объектно- ориентированного программирования.

Многовато. Я не минималист и не утверждаю, что мы должны прекратить развитие языка. Это удобная отговорка в Microsoft, которая меня бесит, потому что люди тратят время, а ошибки не устраняются. Даже при наличии лямбда-выражений вы все равно не избавитесь от кое-каких трудноустранимых ошибок.

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

Сейбел: Многое из того, что вы делаете, от статического анализа вашего C++ до работ в области компиляции “на лету” и добавления новых свойств в JavaScript, говорит о том, что вы стараетесь держаться на переднем крае компьютерных исследований.

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

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

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

Сейбел: Почему так происходит? Они не решают реальных проблем - или решение было бы половинчатым?

Айк: Мы делали кое-что с SML/NJ для размещения на резидентном сервере эталонной реализации четвертой версии JavaScript, ныне несуществующей. Мы пытались создать дефинициональный интерпретатор и даже не использовали модель Хиндли-Милнера. Мы собирались аннотировать типы и аргументы так, чтобы избежать этих безумных сообщений об ошибке, когда типы не унифицируются и подбирается наудачу фрагмент исходного кода - обычно не тот, что нужно. Это вопрос качества реализации. Возможно, это также теоретическая проблема, связанная с типами, - когда не получается унификация, трудно найти, какой фрагмент кода тому причиной.

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

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

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

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

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

Отметить Добавить цитату