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

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, ныне несуществующей. Мы пытались создать дефинициональный интерпретатор и даже не использовали модель Хиндли-Милнера. Мы собирались аннотировать типы и аргументы так, чтобы избежать этих безумных сообщений об ошибке, когда типы не унифицируются и подбирается наудачу фрагмент исходного кода - обычно не тот, что нужно. Это вопрос качества реализации. Возможно, это также теоретическая проблема, связанная с типами, - когда не получается унификация, трудно найти, какой фрагмент кода тому причиной.