Интерфейс: новые направления в проектировании компьютерных систем

Другой программист, работавший на 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), написание комментария до или во время создания кода может помочь процессу написания, улучшить структуру алгоритмов, снизить число ошибок и повторных написаний программы, необходимых для завершения проекта, а также дает другие преимущества, которые обычно упоминаются по поводу комментариев. По всей видимости, правильность выводов Кнута имеет основания с точки зрения когнетики.

Когда мы как опытные программисты разрабатываем алгоритмы и пишем код, этот процесс отчасти происходит на бессознательном уровне. Как уже было отмечено, эта ментальная область может быть подвержена противоречиям. Предполагаю, что причина некоторых программных ошибок заключается в том, что когнитивное бессознательное переживает противоречие между тем, что мы хотим сделать, и тем, что должен сделать компьютер в соответствии с нашим кодом.

Однако для того, чтобы ясно выразить свои намерения на естественном языке, нам следует сделать процесс мышления сознательным, и именно в когнитивном сознательном эти противоречия быстро становятся очевидными. Даже если эта гипотеза неправильна, написание комментариев вынуждает нас тщательнее обдумывать решаемую задачу для разных условий и с разных точек зрения.