Кодеры за работой

Дойч: Это так. И на это есть несколько причин. Что касается 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 заявила: «Нет, это стратегический актив, мы не можем открыть его исходный код».

Сейбел: Что ж, вы и сами говорили, что ПО нужно рассматривать как долгосрочный актив.