Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Ингаллс: Это был отладчик более низкого уровня, чем тот прекрасный отладчик Smalltalk. Деталей сейчас не приведу, но если находишь ошибку, она приводит к низкоуровневым отладчикам. То есть смотришь на память как на восьмеричные значения. И потом видишь, что один объект указывает на другой, а этого быть никак не может. И начинаешь думать: «Как такое могло случиться?» Там были закономерности, были догадки по поводу того, что именно могло вызвать ту или иную неполадку, так что на их основе и нужно было работать.
Сейбел: Это было на самом низком уровне. Но работая в такой замечательной среде, как Smalltalk, вы, скорее всего, используете символические отладчики.
Ингаллс: Честно говоря, не знаю никого, кто бы так делал, имея возможность пользоваться хорошим отладчиком. Потому что куда вы помещаете print? Туда-то. А не лучше ли самому быть там-то и посмотреть все, а не распечатывать? Сейчас я довольно часто применяю отладку с помощью вывода на печать, но это потому, что нередко у меня нет под рукой хорошего отладчика для JavaScript.
Сейбел: Чем так хорош отладчик для Smalltalk?
Ингаллс: Можно остановиться на любом месте программы и посмотреть на все связывания всех переменных. Можно исполнять фрагменты кода и вычислять выражения прямо в контексте.
Сейбел: В любом месте стекового фрейма?
Ингаллс: Да, и далее можно внести существенные изменения и продолжить. Затем можно вернуться к ошибке, вывести ее на экран, сохранить полностью состояние системы, перебросить его кому-нибудь другому, кто сидит за компьютером с Windows, а не на Маке; он может запустить тот же самый образ, попасть туда же, где сейчас находитесь вы, внести исправление и продолжить. Полное сохранение состояния, несмотря на различные варианты операционных систем.
Сейбел: Инварианты — это другой тип инструментов отладки. Многие очень озабочены формальными входными и выходными условиями всех их методов и инвариантами классов. Некоторые относятся к этим вопросам проще. Каково ваше мнение относительно инвариантов?
Ингаллс: Вероятно, я принадлежу к менее формальному лагерю. Во многом из-за того, что считаю, что вещи должны быть насколько возможно простыми. То же самое я думаю относительно типов. Типы по сути являются предположениями по поводу программы. И я думаю, что очень полезно делать все максимально простым, даже не заикаясь о каких-либо типах. Думаю, если серьезно подходить к системе, то неплохо иметь возможность добавлять подобные вещи: например, можно ввести подразумеваемые типы и видеть их только при желании.
Но типы — только одна вещь из многих, к которым относятся блоки и все другие варианты операторов утверждений, которые вы можете внедрить. Это часть той поразительно интересной отрасли, которую нам еще только предстоит изучить с помощью синтетической математики. Думаю, с течением времени мы сможем все лучше понимать вычислительные сферы и документировать их с помощью живой документационной системы, настоящей программной документации. То есть существуют такие операторы утверждений, которые могут действительно помочь вам, притом что вы их обычно не видите. Но если у вас затруднения, то можно запустить их и тестировать с их помощью самые различные вещи.
Сейбел: Что вы думаете по поводу формального доказательства корректности программ?
Ингаллс: Я никогда этим не занимался. Я больше склонен к тому, чтобы сосредоточиться на архитектуре — так проще делать утверждения для разных вещей. Если внутри программы можно делать самые разные опасные вещи, то искать формальное доказательство оказывается очень трудно, так как на каждом шагу приходится говорить: «Это могло случиться, вот это могло случиться, да и вот это тоже». Если архитектура хорошая, то и формальное доказательство
Сейбел: Вы когда-нибудь работали с C++?
Ингаллс: Нет. И с Си — тоже.
Сейбел: Но вы программировали на BCPL и ассемблере, то есть нельзя сказать, что низкоуровневым программированием вы не занимались вовсе.
Ингаллс: Да. Кстати, мы действительно немного писали на Си для отладки некоторых вещей, сгенерированных с помощью Squeak. Но я помню, что когда мы делали Squeak, то моей целью, среди всего прочего, было создать такую систему, для управления которой не нужно было бы знать ничего, кроме Squeak. Так что я решил даже ничего другого не учить. Джон Мэлоуни сделал транслятор с Squeak на Си в качестве практического примера. По правде говоря, я мог посмотреть код на Си, но сделал так, чтобы ничего этого делать было не нужно.
Сейбел: Но вы наверняка смотрели C++, когда он вышел, поскольку вы входили в группу, которая — возможно, наряду с изобретателями Симулы — может с наибольшими основаниями заявлять о том, что придумала объектно-ориентированное программирование.
Ингаллс: Я им особенно не интересовался. Конечно, во многих отношениях это был шаг вперед по сравнению с Си, но все же этот язык не оправдал тех надежд, которые мы на него возлагали. Если бы нужно было проводить еще одно внедрение с нуля, мы бы, возможно, использовали вместо машинного кода C++. Я знаю пару человек — настоящих мастеров C++, и мне нравится смотреть, как они с ним работают, потому что, думаю, они не полагаются на него при работе с теми областями, в которых он не особенно хорош, часто используют его как язык мета-программирования.
Сейбел: Поговорим о чтении кода. Как вы работаете с новым куском кода?
Ингаллс: Мне сложно дать какой-то общий ответ. Когда начинаешь, то как-то сразу понимаешь, что вот это делает или должно делать. Думаю, я просто читаю сверху вниз и пытаюсь понять, каковы отдельные элементы и как они работают вместе. Смотрю, какие классы и методы определены и что они делают. Дальше все зависит от того, почему мы смотрим этот код. Возможно, это что-то новенькое, о нем хочется узнать побольше. Или тут проблемы с производительностью, тогда нужно профилировать и анализировать.
Сейбел: Мы уже упоминали интервью Кнута. Еще одна его любовь — литературное программирование. Занимались ли вы им когда-нибудь или, может быть, читали такой код?
Ингаллс: Мне нравится так работать, когда у меня достаточно времени. Когда я только начинаю писать, никаких комментариев не делаю. Когда все начинает работать, я пишу комментарии. Если мне нравится то, что я сделал, или мне кажется, что разобраться с этим будет сложно, я пишу более подробные комментарии. Но мне не нравится идея комментировать все подряд. И еще мне кажется, что чем лучше язык, тем меньше нужны комментарии. Лучше использовать разумные имена переменных. Вот почему мне нравятся именованные параметры в Smalltalk. Они действительно существенно облегчают читаемость. Есть еще такая отличная штука, которую можно использовать в различных местах JavaScript. Хотя это несколько расточительно, в JavaScript применяется запись объекта в фигурных скобках, так что можно использовать ключевые слова, и они действительно похожи на ключевые слова Smalltalk, потому что заканчиваются двоеточиями; поэтому можно применять объекты в фигурных скобках для передачи нескольких аргументов. Так получаются и впрямь очень симпатичные программы.