Правило наименьшей мощности

В программировании правило наименьшей мощности — это принцип проектирования, который «предлагает выбрать наименее мощный [компьютерный] язык, подходящий для данной цели». ^[1] Другими словами, при наличии выбора среди компьютерных языков , классы которых варьируются от описательных (или декларативных ) до процедурных , чем менее процедурный и более описательный язык выбирается, тем больше можно делать с данными, хранящимися на этом языке.

Это правило представляет собой применение принципа наименьших привилегий при разработке протоколов. ^[2] Правило наименьшей мощности является примером в контексте многовекового принципа, известного в философии как бритва Оккама . В частности, аргументы за и против правила наименьшей силы подлежат тому же анализу, что и бритва Оккама . ^{[ нужна ссылка ]}

Обоснование

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

чисто описательные (например, содержимое большинства баз данных или прогрессивное улучшение в сети),
логические языки ограниченной пропозициональной логики (такие как списки контроля доступа ),
декларативные языки на грани того, чтобы стать Тьюринг-полными ,
те, которые на самом деле являются полными по Тьюрингу, хотя их не следует использовать таким образом ( XSLT , SQL ),
те, которые являются функциональными и полными по Тьюрингу языками программирования общего назначения , чтобы
те, которые «беззастенчиво императивны ». ^[1]

Как объяснил Тим Бернерс-Ли : ^[3]

Информатика в 1960-80-х годах потратила много усилий на создание максимально мощных языков. Сегодня нам приходится осознавать причины выбора не самого мощного решения, а наименее мощного. Причина в том, что чем менее мощный язык, тем больше вы можете сделать с данными, хранящимися на этом языке. Если написать это в простой декларативной форме, любой сможет написать программу для его анализа разными способами. Семантическая сеть — это, по сути, попытка отобразить большие объемы существующих данных на общем языке, чтобы их можно было анализировать способами, о которых даже не мечтали ее создатели. Если, например, веб-страница с данными о погоде имеет RDF , описывающий эти данные, пользователь может получить их в виде таблицы, возможно, усреднить, построить график, сделать выводы из нее в сочетании с другой информацией. На другом конце шкалы находится информация о погоде, отображаемая хитрым Java-апплетом. Хотя это может позволить создать очень крутой пользовательский интерфейс, его вообще невозможно проанализировать. Поисковая система, обнаружившая страницу, не будет иметь представления о том, что это за данные и о чем они. Единственный способ узнать, что означает Java-апплет, — запустить его перед человеком.

См. также

Чем хуже, тем лучше

Ссылки

↑ Перейти обратно: Перейти обратно: ^а ^б W3C. «Правило наименьшей мощности» . Проверено 24 февраля 2016 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
^ Мередит Л. Паттерсон (28 декабря 2011 г.). Наука небезопасности . 28-й Конгресс Хаос-коммуникаций.
^ Бернерс-Ли, Тим . «Аксиомы веб-архитектуры» . Проверено 14 января 2002 г.

Правило наименьшей мощности , W3C , Вывод TAG, 23 февраля 2006 г.
Б. Карпентер, редактор: «Архитектурные принципы Интернета», Совет по архитектуре Интернета, июнь 1996 г., RFC 1958.

[ruleofleastpower-1] Перейти обратно: Перейти обратно: ^а ^б W3C. «Правило наименьшей мощности» . Проверено 24 февраля 2016 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )

[2] Мередит Л. Паттерсон (28 декабря 2011 г.). Наука небезопасности . 28-й Конгресс Хаос-коммуникаций.

[3] Бернерс-Ли, Тим . «Аксиомы веб-архитектуры» . Проверено 14 января 2002 г.

[1]

[2]

[3]