13.1.2. Компромиссы между сложностью интерфейса и реализации
13.1.2. Компромиссы между сложностью интерфейса и реализации
Одно из наиболее ярких замечаний о Unix-традиции, сделанных когда-либо сторонним наблюдателем, содержится в статье Ричарда Гэбриэла (Richard Gabriel), которая называется "Lisp: Good News, Bad News, and How to Win Big" [25]. Гэбриэл в течение многих лет является бессменным лидером Lisp-сообщества, и данная статья главным образом была доводом в пользу особого стиля Lisp-конструкции. Однако сам автор статьи признает, что сейчас она вспоминается в основном из-за раздела, который называется "The Rise of Worse Is Better".
В статье утверждалось, что Unix и С обладают характеристиками вирусов и что в эволюционной борьбе конструкций программного обеспечения такие особенности, как простота реализации и переносимость, которые ведут к быстрому распространению (заражаемости), являются более эффективными, чем корректность и завершенность конструкции. Гэбриэл в своем предвидении так близко подошел к влиянию экспертной оценки на программное обеспечение с открытым исходным кодом, что сообщество открытого исходного кода приняло его как одного из своих теоретиков.
Не так часто вспоминается то, что главный аргумент Гэбриэла относился к весьма специфическому компромиссу между сложностью реализации и сложностью интерфейса, который довольно точно вписывается в рассмотренные выше категории. Гэбриэл сопоставляет философию MIT, в которой наиболее ценится простота интерфейса, с философией Нью-Джерси, где выше всего ценится простота реализации. Затем он утверждает, что хотя MIT-философия приводит к появлению программного обеспечения, которое абстрактно лучше, модель Нью-Джерси (худшая) обладает лучшими характеристиками распространения. Со временем люди уделяют больше внимания программному обеспечению, написанному в стиле Нью-Джерси, поэтому оно быстрее улучшается, и худшее становится лучшим.
В действительности, философия MIT и Нью-Джерси имеет аналоги как конфликтующие направления в самой Unix-традиции проектирования. Один тип Unix-мышления придает особое значение небольшим точным инструментам, конструкциям, разработанным с нуля, а также простым и последовательным интерфейсам. Дуг Макилрой решительно отстаивает данную точку зрения. Другой тип мышления акцентирует внимание на простых реализациях, которые работают и быстро распространяются, даже если используются методы грубой силы, а некоторые граничные случаи необходимо устранить. Код Кена Томпсона, а также его принципы программирования часто и очевидно склоняются к этому направлению.
Конфликт между данными подходами возникает именно потому, что иногда программист может получить простой интерфейс, если согласен заплатить за него сложностью реализации, и наоборот. Оригинальный пример Гэбриэла о том, как системные вызовы, выполняющие длительные операции, обрабатывают прерывания, которые не способны удержать или замаскировать, до сих пор остается одним из лучших. В MIT-философии правильный путь заключается в выходе из системного вызова и автоматическом его возобновлении, как только прерывание будет обработано. Данную методику труднее реализовать, однако она ведет к созданию более простого интерфейса. В философии Нью-Джерси системный вызов возвращает ошибку, указывающую на то, что вызов был прерван и пользователь должен перезапустить его. Такой подход значительно проще в реализации, но приводит к программному интерфейсу, который труднее использовать.
На практике применяются оба подхода. Unix-разработчики старой школы немедленно подумают о сравнении System V и BSD-стилей обработки программных сигналов. Последний следует MIT-философии, тогда как System V-стиль происходит из Нью-Джерси. В основе выбора между ними лежит сложный вопрос, который непосредственно не касается распространения программного обеспечения: если цель заключается в ограничении глобальной сложности, что разработчик охотнее всего принесет в жертву? Что ему следует принести в жертву?
Одним эпохальным примером, не упомянутым Гэбриэлом, являются распределенные гипертекстовые системы. Ранние проекты распределенных гипертекстовых систем, такие как NLS и Xanadu, были жестко ограничены предположениями MIT-философии о том, что ссылки, указывающие на несуществующий объект, являются недопустимой неполадкой в пользовательском интерфейсе. Это ограничивало системы либо просмотром только контролируемого, закрытого набора документов (как, например, на одном CD-ROM), либо реализацией различного тиражирования со все возрастающей сложностью, кэширующих и индексирующих методов в попытке предотвратить случайное исчезновение документов. Тим Бернерс-Ли (Tim Berners-Lee) разрубил этот гордиев узел, разрешив проблему в классическом стиле Нью-Джерси. Простота реализации, достигнутая им благодаря разрешению ответа "404: Not Found", была тем, что сделало систему World Wide Web достаточно легковесной, чтобы она могла успешно распространяться.
Сам Гэбриэл придерживался мнения о том, что "худшее" более заразительно и, в конце концов, стремится к победе. Несмотря на это, он неоднократно публично менял свое мнение относительно основополагающего вопроса, связанного со сложностью: сложность — это хорошо или плохо? Его непостоянство отражает множество продолжающихся споров в Unix-сообществе.
Автору данной книги не представляется возможным сформулировать универсальный ответ. Как и большинство других важнейших вопросов в данной главе, хороший вкус и инженерное мышление предполагают различные ответы в разных ситуациях. Важно развить привычку тщательно обдумывать данную проблему для всех и для каждой разрабатываемой конструкции. Как отмечалось ранее при обсуждении модульности программного обеспечения, сложность сопряжена с затратами, которые необходимо весьма тщательно предусматривать.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Опасность, связанная со сложностью алгоритмов
Опасность, связанная со сложностью алгоритмов Очевидно, что будет разумным избегать алгоритмов, которые масштабируются, как О(n!) или O(2?). Более того, замена алгоритма, который масштабируется, как O(n), алгоритмом, который масштабируется, как O(1), — это обычно серьезное
Реализации процессора AS/400
Реализации процессора AS/400 Первые использовавшиеся в AS/400 RISC-процессоры поддерживали только режим активных тегов и только структуру ввода-вывода AS/400. Поэтому они выполняли приложения, но не операционные системы, написанные для стандартного процессора PowerPC. Любая другая
Стратегии реализации TCP
Стратегии реализации TCP Рассмотренный стандарт протокола TCP определяет взаимодействие между удаленными объектами, достаточное для обеспечения совместимых реализаций. Другими словами, модуль протокола, в точности следующий спецификации стандарта, является
15.1.4 Реализации NFS и RPC
15.1.4 Реализации NFS и RPC NFS и RPC были реализованы многими разработчиками систем Unix, а также перенесены во многие лицензированные операционные системы. Например, IBM VM, IBM MVS и DEC VAX VMS могут работать как файловые серверы NFS.Некоторые разработчики объединили программное
Отделение интерфейса от реализации
Отделение интерфейса от реализации Концепция инкапсуляции основана на разделении того, как объект выглядит (его интерфейса), и того, как он в действительности работает (его реализации). Проблема в C++ в том, что этот принцип неприменим на двоичном уровне, так как класс C++
13.1.2. Компромиссы между сложностью интерфейса и реализации
13.1.2. Компромиссы между сложностью интерфейса и реализации Одно из наиболее ярких замечаний о Unix-традиции, сделанных когда-либо сторонним наблюдателем, содержится в статье Ричарда Гэбриэла (Richard Gabriel), которая называется "Lisp: Good News, Bad News, and How to Win Big" [25]. Гэбриэл в течение
13.3.2. Компромиссы не действуют
13.3.2. Компромиссы не действуют Сопоставление редакторов Sam и vi явно указывает на то, что, по крайней мере, если рассматривать редакторы, попытки достичь компромисса между минимализмом ed и всеохватывающей полнотой Emacs не имеют значительного успеха. Такие попытки
Правило 34: Различайте наследование интерфейса и наследование реализации
Правило 34: Различайте наследование интерфейса и наследование реализации Внешне простая идея открытого наследования при ближайшем рассмотрении оказывается состоящей из двух различных частей: наследования интерфейса функций и наследования их реализации. Различие
13.3.2. Компромиссы не действуют
13.3.2. Компромиссы не действуют Сопоставление редакторов Sam и vi явно указывает на то, что, по крайней мере, если рассматривать редакторы, попытки достичь компромисса между минимализмом ed и всеохватывающей полнотой Emacs не имеют значительного успеха. Такие попытки
Реализации. NET
Реализации. NET В настоящий момент существует несколько реализаций того, что мы называем. NET.1. NET Framework – версия среды выполнения для серверных и настольных компьютеров с операционной системой Microsoft Windows. Она поставляется в составе операционных систем Windows XP Tablet Edition и Windows
2.2. Обнаружение столкновений между компонентами пользовательского интерфейса и реагирование на них
2.2. Обнаружение столкновений между компонентами пользовательского интерфейса и реагирование на них Постановка задачи Требуется задать на экране границы столкновений между компонентами вашего пользовательского интерфейса так, чтобы эти компоненты не перекрывали друг
Raskin — попытка реализации масштабирующегося интерфейса Андрей Письменный
Raskin — попытка реализации масштабирующегося интерфейса Андрей Письменный Опубликовано 12 августа 2010 года Любая приличная картографическая программа позволяет менять масштаб. При минимальном масштабе можно рассмотреть всю карту целиком, если же
Компромиссы
Компромиссы В данном обзоре внешних факторов качества ПО мы встретились с требованиями, которые могут конфликтовать друг с другом. Как можно достичь целостности, если не вводить защиты различного рода, что неизбежно затруднит простоту использования? Экономичность