Есть языки, в которых API непрозрачны, чтобы реализации могли иметь инварианты; но это опять же ничего не говорит о более глобальных моделях коммуникации. Например, одна распространенная модель: у тебя есть объект, ты передаешь его кому-то еще, просишь этого кого-то выполнить с этим объектом определенное действие и затем в какой-то момент просишь вернуть этот объект. Это модель совместного владения. Ты, вызывающий, можешь никогда на самом деле не отдавать все указатели на объект, который ты передал. Но ты говоришь себе, что не будешь ссылаться через этот указатель до тех пор, пока это третье лицо не выполнит те действия, о которых ты просил.
Это очень простой пример модели организации программы — если бы был способ выразить его языковыми средствами, это помогло бы людям обеспечивать соответствие кода цели, которую они для себя установили.
Возможно, самая серьезная причина, по которой я на самом деле не предпринимаю попытку создать язык, — я не уверен, что знаю, как нужно описывать модели совместного владения и коммуникации на достаточно высоком уровне и так, чтобы их можно было реализовать. Но я считаю, что именно поэтому индустрия разработки ПО так мало продвинулась за последние 30 лет.
Моя диссертация была посвящена доказательствам корректности программы — сейчас я этот термин больше не использую. Смысл его в том, чтобы система разработки давала как можно больше уверенности в том, что ваш код делает именно то, что вы от него хотите.
Раньше идея корректности программы заключалась в существовании неких утверждений, которые являлись выражениями того, что вы хотели от своего кода, — причем чтобы это можно было механическим способом проверить в самом коде. Этот подход был связан с множеством проблем. Сейчас я считаю, что путь к ПО, которое с большей вероятностью будет делать то, чего мы от него хотим, лежит не через использование утверждений или индуктивных утверждений, а через использование более качественных, более мощных и глубоких декларативных систем обозначения.
Джим Моррис, автор одних из самых остроумных высказываний касательно IT-индустрии, как-то сказал, что проверка типов — это первобытный способ доказательства корректности. Если и стоит ожидать прорыва в этой области, то он может произойти только тогда, когда появятся более мощные методы декларативных высказываний о том, как наши программы должны быть организованы и что наши программы должны делать.
Сейбел: То есть, например, можно будет каким-либо образом выразить мысль «Я передаю ссылку на этот объект вот этой подсистеме, которая с ним повозится сколько-то времени, и я ничего не буду с ним делать, пока не получу его обратно»?
Дойч: Да. Когда в начале 1990-х я работал в Sun, там проводились экспериментальные исследования по созданию языка, в котором использовалось схожее понятие. И достаточно много исследований проводил в MIT Дэйв Гиффорд по созданию языка FX — в нем тоже старались сделать более очевидной разницу между функциональными и нефункциональными частями процесса вычисления и сделать более очевидным смысл передвижений указателя от одного места к другому.
Но мне все эти подходы кажутся чрезмерно узкими. Если случится прорыв, после которого уже будет либо невозможно, либо не нужно создавать чудовища вроде Windows Vista, то нам придется начать по-новому воспринимать программы — что они из себя представляют и как их нужно создавать.
Сейбел: Поэтому, несмотря на то что Python качественно не превосходит Smalltalk, вы все равно предпочитаете именно Python?
Дойч: Это так. И на это есть несколько причин. Что касается Python, то там предельно ясно, что такое программа, что значит запустить программу и что значит быть частью программы. Там есть понятие модуля, и модули объявляют, какая информация им нужна от других модулей. Поэтому там можно разработать модуль или группу модулей и давать их другим людям, и эти другие люди смогут работать и смотреть на эти модули, и они будут знать довольно точно, от чего модули зависят и в каких пределах.
Что касается Smalltalk, то там это делать неудобно — если вы работаете в Smalltalk в режиме образов, то там не бывает программы как таковой. В VisualWorks — Smalltalk от ParcPlace — есть три или четыре разных понятия того, как сделать так, чтобы вещи превосходили лишь один класс, и они изменились со временем, и они не очень-то хорошо поддерживаются инструментами разработки, по крайней мере визуально. Есть несколько инструментов, позволяющих сделать ясными, очевидными и механически проверяемыми взаимозависимости в программе. То есть работая в режиме образов, вы не можете никому ничего передать — только образ целиком.
Если вы делаете то, что называется filing out, то есть пишете программу в текстовой форме, у вас нет абсолютно никакого способа узнать, возможно ли считать только что записанную программу еще раз, вернуть ее и сделать ту же операцию еще раз, потому что состояние образа совсем не обязательно совпадает с тем, которое было произведено или которое могло быть произведено путем считывания из набора в исходном коде. Вы могли сделать любые вещи в рабочем пространстве, у вас могли быть статические переменные, значения которых изменились с течением времени. Вы этого просто не знаете. Вы не можете уверенно выполнить ни одно действие.
Я подписан на рассылку разработчиков Visual Works, и темы, которые там постоянно обсуждаются, — их просто нет в языках, не использующих понятие образа. Понятие образа похоже на множество других вещей, характерных для мира, в котором все стремятся быстро набросать опытную модель, быстро сделать программу. Это идеальный вариант для проектов, которые ведутся одним человеком и которые навсегда останутся только в собственном пользовании этого человека. Но это ужасный вариант, если вы хотите сделать ПО активом, если вы хотите, чтобы вашим ПО пользовались другие. Мне кажется, что именно в этом заключается настоящий минус подхода к разработке ПО, исповедуемого Smalltalk, — и минус очень серьезный.
Вторая причина, по которой мне нравится Python, — и, может быть, дело просто в том, как мой мозг изменился за эти годы, — что я больше не могу удерживать столько информации в голове, сколько раньше. Теперь для меня более важно, чтобы вся информация была перед моими глазами. Поэтому тот факт, что в Smalltalk вы фактически не можете использовать больше одного метода на экране, меня просто бесит. По мне, тот факт, что я редактирую программы, написанные на Python, с помощью Emacs, является преимуществом, поскольку я могу видеть больше 10 строк одновременно.
Я говорил с друзьями, которые до сих пор работают в VisualWorks, о том, чтобы открыть код ядра, JIT-генератора кода, который, несмотря на то, что его написал я, превосходит, по моему мнению, многие из современных аналогичных программ. Подумать только, у нас есть Smalltalk, у которого действительно великолепные инструменты для генерации кода, это проверенная технология — ей уже около 20 лет, и она очень надежна. Это сравнительно простой, сравнительно легко перенастраиваемый и достаточно эффективный JIT-генератор кода, который разработан для эффективной работы с языками без объявления типа. С другой стороны, у нас есть Python — прекрасный язык с прекрасными библиотеками и очень медленной реализацией. Было бы неплохо совместить их, не так ли?
Сейбел: Разве не эта же идея легла в основу вашего проекта pycore — переписать Python на Smalltalk?
Дойч: Эта. Я дошел с этим проектом до того этапа, когда понял, что мне нужно будет сделать намного больше работы, чем я думал, чтобы эта затея по-настоящему удалась. Несоответствия между объектными моделями в Python и в Smalltalk были достаточно серьезными, поэтому были вещи, которые нельзя было просто отобразить один к одному, это нужно было делать с помощью дополнительных уровней вызовов методов, и еще много чего нужно было сделать.
Даже тогда Smalltalk с JIT-генерацией кода был — для кода, только что написанного на Python, — того же уровня, что и интерпретатор, написанный на Си. Я-то думал, что если бы была возможность открыть исходный код генератора кода Smalltalk, то задача совместить этот генератор кода с объектной моделью и представлением данных в Python не должна быть особенно сложной.
Но это нельзя сделать. Элиот Миранда, возможно, наиболее радикально настроенный из всех моих знакомых, связанных с VisualWorks, попытался, но Cincom заявила: «Нет, это стратегический актив, мы не можем открыть его исходный код».
Сейбел: Что ж, вы и сами говорили, что ПО нужно рассматривать как долгосрочный актив.
Дойч: Но это не должно означать, что ваша лучшая стратегия — не давать другим пользоваться этим активом.
Сейбел: Помимо того что вы еще в незапамятные времена были приверженцем Smalltak, вы еще были и одним из первых фанатов Лиспа. Но и его вы сейчас уже не используете.
Дойч: Моя диссертация представляла из себя 600-страничную программу на Лиспе. Я преданный фанат Лиспа, начиная с PDP-1, Alto, Byte и заканчивая Interlisp. Причина, по которой я больше не программирую на Лиспе, — мне ненавистен его синтаксис. Синтаксис имеет значение, это правда жизни.
Языковые системы держатся на трех китах — язык, библиотеки и инструменты. Успешность языка зависит от сложного взаимодействия между этими тремя вещами. Python — отличный язык, у него отличные библиотеки и практически никаких инструментов.
Сейбел: Под «инструментами» вы в том числе подразумеваете и непосредственную реализацию языка?
Дойч: Конечно, можно и это сюда включить. Лисп как язык фантастически гибок, но его невозможно читать. Не знаю, как сегодня обстоят дела с библиотеками для Common Lisp, но мне кажется, что синтаксис — это очень важно.
Сейбел: Кому-то синтаксис Лиспа очень нравится, кто-то его на дух не переносит. Почему так?
Дойч: Я говорю только за себя. И могу сказать, почему я больше не хочу работать с синтаксисом Лиспа. На это есть две причины. Во-первых, и я об этом уже говорил, чем старше я становлюсь, тем для меня важнее высокая плотность информации на квадратный дюйм экрана перед моими глазами. Плотность информации на квадратный дюйм в инфиксных языках выше, чем в Лиспе.