Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Язык должен совершенствоваться, чтобы можно было решить стоящие перед программистами задачи. С некоторыми можно справиться, если писать собственные библиотечные абстракции. Но возможность написания абстракций для языка очень ограничена, если нет расширений - вы не можете написать геттеры и сеттеры [47] . Объекты будут смотреться чужеродно, свойства не смогут стать кодом и так далее. Кроме того, вопросы безопасности нельзя будет разрешать неявно или автоматически.
47
Геттер, сеттер - специальные методы, используемые в объектно-ориентированном программировании
Сейбел: Как вы полагаете, языки в целом со временем улучшаются?
Айк: Думаю, да. Может быть, сейчас наступает второй “золотой век” - растет интерес к языкам и их созданию. Мы говорим о программировании: нужно совершенствовать свои навыки, как в писательском ремесле или музыке. Но используемый язык - “тональная система” - тоже важен. Надо поэтому совершенствовать языки, а не довольствоваться тем, что есть. Сеть требует совместимости, и JavaScript, возможно, склонен оставаться таким, каков он есть. Но не стоит зацикливаться на этом. Мы обязаны улучшать JavaScript, даже если он не заменит тот, что применяется для веб-разработок. Другой вариант - создать нечто совсем новое.
Есть, например, Ruby, испытавший влияние языков Ada и Smalltalk. Это прекрасно. Я не имею в виду эклектичность. Но Ruby перехваливают. Нет, ничего плохого сказать не могу, просто некоторые мальчики-фанаты трубят, что он решит все проблемы, а это не так. Новые языки нужны, но хвалить их надо в меру, не как C++ - “шаблоны проектирования нас спасут”. Конечно, может быть, это реакция на консерватизм приверженцев Си-мира UNIX 1980-x.
Но в какой-то момент нам требуются более совершенные языки. Ведь необходимо иметь инструменты для доказательства, производящие автоматическую верификацию некоторых постулатов, сделанных в вашем коде. Вам ведь не нужны ответы на все, правильно? Динамические инструменты, такие как Valgrind и его детекторы состояний гонки [48] , тоже очень полезны. Простых решений нет, но есть более совершенные языки, на которые надо переходить.
48
Race conditions - ошибки в многопоточном коде из-за одновременного изменения объекта в памяти несколькими потоками, оставляющими объект в некорректном состоянии.
– Прим. науч.ред.
Сейбел: В какой степени языки должны предотвращать ошибки программистов?
Айк: Язык для “синих воротничков”, такой как Java, должен иметь четкую и логичную базовую систему, так как “синим воротничкам” трудно понять, что это за вывороченный синтаксис с ковариантными и контравариантными ограничениями типов. Я немало пострадал из-за того, что порой выкидывают Си и C++. Программирование отчасти состоит в конструировании, а конструирование отчасти состоит в решении проблем безопасности. Они важны при разработке броузера и еще больше - если вы делаете программу для аппарата лучевой терапии. Так или иначе, речь идет о более совершенных языках для написания параллельных программ или эффективного использования аппаратного параллелизма. Мы не всегда будем использовать синхронизированные блоки и уж точно не будем использовать мьютексы или взаимные блокировки. Поэтому языки могут служить для установления разумного компромисса между безопасностью и выразительностью.
Мне кажется, с JavaScript мы стремились именно к этому, в противоположность диким, неуправляемым французам, которые хотели видеть JavaScript чем-то вроде #86 с лямбда-выражениями. Нам совершенно незачем вводить оператор call/cc. Предположим на минуту, что обойдется без проблем с реализацией: народ будет сбит с толку. Не обязательно большинство, но многие из
В JavaScript можно нарваться на неприятности разными способами. Есть функции первого класса. Есть малопонятные для людей прототипы - они не отвечают классическим стандартам объектно-ориентированного программирования.
Многовато. Я не минималист и не утверждаю, что мы должны прекратить развитие языка. Это удобная отговорка в Microsoft, которая меня бесит, потому что люди тратят время, а ошибки не устраняются. Даже при наличии лямбда-выражений вы все равно не избавитесь от кое-каких трудноустранимых ошибок.
Дуг стал учить народ применению различных шаблонов, но я согласен с Питером Норвигом: эти шаблоны выявили определенный дефект языка. Они не бесплатны. Бесплатного ланча не бывает. Мы должны добиваться эволюции языка в верном направлении. Не исключено, что появится необязательная типизация, и она может напоминать систему контрактов PLT.
Сейбел: Многое из того, что вы делаете, от статического анализа вашего C++ до работ в области компиляции “на лету” и добавления новых свойств в JavaScript, говорит о том, что вы стараетесь держаться на переднем крае компьютерных исследований.
Айк: Мы ведем справедливую борьбу, но надо делать это с умом. Надо также изменить направление исследований, так как - для меня это было очевидным еще в школе - академическая наука выглядит чем-то ненормальным. Она сильно оторвана от практики.
Надо это исправлять. Мы успешно работали с практически мыслящими учеными. Денег у нас немного, поэтому отчасти мы занимаемся тем, что попросту разговариваем с людьми, служим для них объединяющим центром.
Если ученые охотятся за правительственными грантами и никак непричастны к вашей деятельности, это в какой-то степени потеря для вас. Далее, вы наблюдаете бурный взлет динамических языков, слушаете безумные заявления насчет того, как они убьют Java, и что статические языки - просто смешно. Но ученые убеждены, что статическая типизация - это венец эволюции, они исследуют особые ее виды - язык ML, вывод типов Хиндли-Милнера. Это полный отрыв от практики.
Сейбел: Почему так происходит? Они не решают реальных проблем - или решение было бы половинчатым?
Айк: Мы делали кое-что с SML/NJ для размещения на резидентном сервере эталонной реализации четвертой версии JavaScript, ныне несуществующей. Мы пытались создать дефинициональный интерпретатор и даже не использовали модель Хиндли-Милнера. Мы собирались аннотировать типы и аргументы так, чтобы избежать этих безумных сообщений об ошибке, когда типы не унифицируются и подбирается наудачу фрагмент исходного кода - обычно не тот, что нужно. Это вопрос качества реализации. Возможно, это также теоретическая проблема, связанная с типами, - когда не получается унификация, трудно найти, какой фрагмент кода тому причиной.
Итак, вы можете проводить дополнительные исследования и разрабатывать высокоуровневую модель когнитивных ошибок, допускаемых программистами, чтобы лучше определить этот фрагмент кода. Может быть, я касаюсь мелкой проблемы, но, скорее всего, она значительна.
Академическая наука не способна предложить нам более совершенную модель. Мне кажется, сейчас это негодная вещь - но, возможно, не по вине ученых. Экономические основы этой науки прогнили. Мы все знали, что придем к массовому параллелизму, - никто не предложил решения. Сейчас все только и говорят, что о транзакционной памяти. Но это не решение. Вы не хотите иметь дело с тем, как вложенные транзакции отменяются и распространяются на один процессор за другим. Это неэффективно, это не будет работать в отдельных случаях. Вы не сможете переложить на это все свои конкурентные или параллельные алгоритмы, даже пытаться не будете.