Эрик Реймонд - Искусство программирования для Unix

Иначе обстоит дело с программами dc(1) и bc(1) . Пользователь может исправлять ошибки в выражении по мере его создания. Интерфейс данных программ более прозрачен, поскольку пользователь может просмотреть выполняемые вычисления на каждой стадии. Интерфейс более выразителен, так как интерпретатор dc/bc , не будучи ограниченным подходящей визуальной моделью калькулятора, может включать в себя гораздо более широкий ассортимент функций (и такие средства, как условные переходы, хранимые переменные и циклы). Следствием данных преимуществ, естественно, является большая мнемоническая нагрузка.

Лаконичность в данном случае — это случайная характеристика. Пользователь, хорошо владеющий навыками машинописи, сочтет CLI-интерфейс более лаконичным, тогда как для не владеющего машинописью пользователя, возможно, будет быстрее выбирать и нажимать клавиши в GUI-интерфейсе. Возможность использования в сценариях совсем не случайна. Комбинацию dc/bc можно легко использовать в качестве фильтра, a xcalc вообще невозможно задействовать в сценарии.

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

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

Результаты этого часто описываются как интерфейсы, созданные "программистами для программистов". Однако это значительно упрощает проблему. Когда Unix-программист делает выбор в пользу возможности конфигурирования и выразительности вместо простоты, он не обязательно считает свою аудиторию состоящей исключительно из других программистов. Скорее он поступает так инстинктивно, из-за отсутствия знаний о целях конечных пользователей он выбирает наилучший путь — не опекать пользователей и не предугадывать их действия.

Недостатком данной позиции (родственной подходу "механизм, а не политика") является склонность предполагать, что когда высококонфигурируемый и выразительный интерфейс создан, то работа окончена, даже если для кого-либо другого результат почти невозможно использовать без длительного обучения. Обратной стороной конфигурируемости является неотложная потребность в хороших стандартных установках и простом способе устанавливать все настройки в стандартные значения. Обратной стороной выразительности является потребность в руководстве, в самой программе или в документации, где указано, с чего необходимо начинать и как добиваться наиболее распространенных результатов.

Правило прозрачности также оказывает свое влияние. При написании программы, удовлетворяющей требованиям RFC или другого стандарта, который определяет набор управляющих параметров, Unix-программист часто предполагает, что его работа заключается в обеспечении совершенного и прозрачного интерфейса ко всем данным параметрам, причем независимо от того, будет ли, по его мнению, использоваться какой-либо из параметров. Его работа — механизм, а политика принадлежит пользователю.

Эта позиция гораздо меньше допускает неполную поддержку функций. В тех случаях, когда Macintosh или Windows-разработчик сказал бы: "Нам не нужна поддержка данной функции стандарта, большинство пользователей не обратит на это внимания, и она является слишком сложной для них", Unix-разработчик, вероятно, скажет: "Пока не ясно, потребуется ли данная функция или параметр в будущем, следовательно, ее необходимо поддерживать".