Интерфейс: новые направления в проектировании компьютерных систем.
7.1.1. Системное окружение и среда разработки.
Исследования в области когнетики для сред программирования нашли еще меньшее применение, чем для пользовательских интерфейсов. Нечего и говорить, что современные системы становятся все более сложными и что инструменты программирования должны соответствовать этой сложности. Простые вещи стали излишне сложными, и мы не смогли пока создать достаточно хорошие инструментальные программные средства для облегчения этих сложностей работы в современных компьютерных средах.
Я начну с простого примера. В давно исчезнувшем компьютере Apple II для того, чтобы написать программу сложения двух чисел, требуется включить компьютер (время загрузки не заметно!) и нажать «Control»+«b», после чего вы переходите в BASIC. Если вы теперь наберете PRINT 3+4 и нажмете «Return», то сразу же и без трудностей получите 7. С момента запуска BASIC до получения результата прошло 5 с. Как хорошо известно, в компьютерной промышленности простота использования достигается с помощью довольно больших ресурсов памяти и скорости. Поэтому мы понимаем, что компьютер Apple II способен выполнять вычисления с такой быстротой и простотой именно потому, что он обладает мощнейшими ресурсами: имея 2-мегагерцовый 8-битный процессор, 48 Кбайт памяти (и это все, что можно вместить!) и 400 килобайтовый диск, машина работает как зверь. В 1999 году на выполнение этой операции у компьютера с 400-мегагерцовым 32-битным процессором, 192 мегабайтовый RAM-памяти и несколькими гигабайтами памяти на жестком диске уходит более 3 минут. Судя по разрядности системной шины и тактовой частоте процессора, новая машина работает приблизительно в 1500 раз быстрее, чем старая. Если же оценивать по времени, которое требуется для написания программы, новая машина оказывается медленнее приблизительно в 36 раз.
Я попросил двух профессиональных программистов написать программу на Visual Basic (VB), которая бы выполняла сложение 3+4 и выдавала результат на экран. Первый программист начал жаловаться, что у машины всего только 8 Мбайт памяти и что у нее устаревший 75-мегагерцовый 32-битовый процессор. Не считая времени загрузки (2 мин.), среда программирования была открыта через 54 с. После этого требовалось открыть модуль вставки (Insert Module), потом открыть окно опций (Option Box) и установить соответствующие настройки, создать кнопку и рабочую форму, после чего программист должен был набрать среднюю строку из следующего текста:
Private sub Command1_Click () MsgBox 3 + 4 End SubДля того чтобы воспользоваться этой программой, ее нужно было сначала запустить, а потом нажать кнопку для ее включения. В течение этого процесса, который занял 3 мин. 40 с (опять же, не считая времени начальной загрузки), было сделано всего только две или три ошибки.
Другой программист, работавший на 64-битовом процессоре с тактовой частотой 75 Мгерц и 40 Мбайт памяти, запустил VB и выполнил ту же задачу за 28 с (что приблизительно в 5 раз медленнее, чем на компьютере Apple II). Программа, созданная несколько иным способом, была следующей:
Private sub Form-Load () MsgBox Str (3 + 4) End SubЯ спросил у этого программиста, почему он не написал вторую строку так же, как ее написал первый программист:
MsgBox 3 + 4Он ответил, что не был уверен, что это будет работать. Другими словами, он не знал точно, как VB будет работать в этом случае. Здесь нет ничего странного: как и другие современные компьютерные языки, VB имеет довольно сложное и непоследовательное построение. Оправданием его громоздкости может быть то, что он позволяет сделать большие проекты проще, однако это не может быть оправданием для того, чтобы делать простые вещи сложными. Большие вещи состоят из множества малых, поэтому чем проще сделаны составные задачи, тем проще становится вся задача в целом. Именно плохая организация системы и языка является причиной того, почему один опытный программист допустил ошибки, а другой – не был уверен в правильности синтаксиса простой программы. Те же самые результаты я получил и с тремя другими программистами, работающими со Smalltalk; это показывает, что данные проблемы относятся не только к VB. Очевидно, что каждый из этих языков обладает множеством преимуществ, но если бы они и особенно их среды были хорошо разработаны с точки зрения человеческих факторов, эти преимущества достигались бы с меньшими неудобствами и меньшим числом ошибок со стороны человека.
Таким образом, было утрачено нечто удивительно непосредственное, в частности, немедленная обратная связь, в которой человек нуждается для того, чтобы иметь возможность быстро создавать эффективные программы. Я не настолько наивен, чтобы думать, что мы можем вернуться к прежней простоте и достичь того уровня сложности, который требуется от современных программ. Но я уверен, что мы можем сделать в этом много улучшений.
7.1.2. Важность ведения документации при создании программ.
Во многих источниках сообщается, что для программистов важно подробно документировать машинный код, который они пишут. Для этого обычно приводятся две причины: во-первых, чтобы помочь понять программу при ее чтении (Knuth, 1992, с. 99), и, во-вторых, чтобы упростить адаптацию программы к новым условиям (Weinberg, 1971, с. 164). Обычно в программе рядом со строками кода можно встретить комментарии (чаще однострочные). Многие программы бывают почти полностью лишены комментариев.
Как отметил Кнут (Knuth), написание комментария до или во время создания кода может помочь процессу написания, улучшить структуру алгоритмов, снизить число ошибок и повторных написаний программы, необходимых для завершения проекта, а также дает другие преимущества, которые обычно упоминаются по поводу комментариев. По всей видимости, правильность выводов Кнута имеет основания с точки зрения когнетики.
Когда мы как опытные программисты разрабатываем алгоритмы и пишем код, этот процесс отчасти происходит на бессознательном уровне. Как уже было отмечено, эта ментальная область может быть подвержена противоречиям. Предполагаю, что причина некоторых программных ошибок заключается в том, что когнитивное бессознательное переживает противоречие между тем, что мы хотим сделать, и тем, что должен сделать компьютер в соответствии с нашим кодом.
Однако для того, чтобы ясно выразить свои намерения на естественном языке, нам следует сделать процесс мышления сознательным, и именно в когнитивном сознательном эти противоречия быстро становятся очевидными. Даже если эта гипотеза неправильна, написание комментариев вынуждает нас тщательнее обдумывать решаемую задачу для разных условий и с разных точек зрения.
К сожалению, среды программирования были разработаны таким образом, что вносить комментарии в создаваемые программы не просто. Например, комментарии во многих языках программирования ограничиваются одной строкой, а если многострочные комментарии допустимы, то в них часто не используется перенос текста или другие возможности, которые должны быть в простейших текстовых редакторах (исключения составляют UCSD Pascal и Oberon). Чтобы в языке Visual Basic, появившемся в 90-х годах, написать комментарий размером с абзац, вам приходится вручную делать перенос текста. По легендам, программисты не особенно грамотно умеют писать, поэтому проверка орфографии должна быть включена в каждую среду программирования, однако в программных средах эта служба почти никогда не встречается. В существующей версии Mathematica, которая является в общем превосходной программой для работы с математическими выражениями, комментарии были убраны из программ и помещены в специальное окно, что является совершенно неправильным шагом. Только некоторые системы (как, например, созданная Кнутом программа WEB (1992)) были разработаны таким образом, чтобы способствовать ведению документации. Другой, менее сложный, но достаточно эффективный метод, был использован автором этой книги (Lammers, 1986, с. 226).
Для сохранения работоспособности программы любым вносимым в нее изменениям должны предшествовать изменения в сопровождающих ее комментариях. Аналогично тому, как нет необходимости разделять разные формы использования компьютера в виде приложений, программирование не должно как-то особенно отличаться от других видов работы, которые пользователь выполняет с помощью компьютера. Опыт показывает, что большинство пользователей компьютеров с неохотой относятся даже к попыткам программирования. Наверное, некоторые преимущества программирования были бы более понятны, если бы процесс программирования был настолько интегрирован со средой, что отдельные программные структуры могли бы использоваться без необходимости учить весь язык или среду программирования. Было бы также полезно иметь возможность комбинировать функции из разных языков, однако это не должно быть смесью, подобной PL/I, но, скорее, должен использоваться метод слияния, предложенный в этой книге для приложений. Вероятно, весьма ценным был бы вариант, в котором комбинировались бы структуры LISP для обработки списков, структуры APL (или разновидности этого языка J) для обработки массивов, мощные методы обработки строк из языка SNOBOL, механизмы наследования и объекты из Smalltalk и т. д.
Разработчики языков программирования и эксперты по интерфейсам слишком редко работают вместе, и хотя когнетика позволяет усовершенствовать компьютерные интерфейсы, следует в максимальной степени использовать также сочетание современных методов разработки языков программирования с нашими знаниями о человеческих факторах. Этот вопрос, до сих пор сохраняющий свою актуальность, был рассмотрен в одной из самых ранних книг Вейнберга в области разработки интерфейсов человек-машина «Психология компьютерного программирования» (Weinberg, «Psychology of Computer Programming», опубликована в 1971 г.), которая намного опередила свое время и до сих пор остается для нас откровением.