[Перевод] Семантический разрыв «The Semantic Gap»
коротенькая статья от архитектора движка PowerShell, дается его взгляд на индустрию, статья проясняет почему пош стал именно таким.
Семантический разрыв
Есть 2 мира:
1. Мир, как мы его представляем.
2. Мир, как мы можем им управлять.
Разница между этими двумя мирами это то что называется семантическим разрывом.
Наша индустрия (прим переводчика: IT индустрия) борется с семантическим разрывом в течение многих десятилетий. Отличным примером семантического разрыва это запись в блоге «TechProsaic: VMWare Perl Toolkit versus Powershell V1 ToolKit», в котором показаны 20 строк кода на Perl необходимых чтобы сделать то же самое что делает один командлет «Get-VM».
Кто-то мог прочитать это бросить читать дальше со словами «PowerShell мощный, а Perl это дерьмо», он был бы прав и не прав. PowerShell мощный, но Perl не дерьмо. (снимите шляпу перед суперзвездой Larry Wall и его Perl, очень мало людей и технологий, которые имели уровень (положительного :-)) воздействия на нашу отрасль как они. Этот мир хорошее место потому что рождаются такие хорошие парни как он!). Настоящей разницей между этими двумя примерами является семантический разрыв. Пример на PowerShell имеет очень небольшой разрыв между тем, что вы думаете и что вы печатаете чтобы решить задачу. Пример на Perl имеет очень большой разрыв.
В конце концов, семантический разрыв «контролируется» людьми, которые разрабатывают инструментарий. VMWare мог бы так же легко предоставить PowerShell скрипт, который имел бы столько строк как например на Perl или они могли бы прислать библиотеку для Perl или сценарий на нем, который обеспечивает семантику командлета Get-VM одной или парой команд.
Так почему же поставщики инструментария закрыли или не закрыли семантический разрыв? Ааа — это и есть тот самый вопрос!
Я могу ошибаться по этому вопросу, но я думаю, что это всего лишь пример иерархии потребностей Абрахама Маслоу. Технологии, используются для того чтобы сделать простым то что сделать ОЧЕНЬ сложно, и предоставить возможность ЛЮБОМУ использовать ее просто. Если вы написали код, делающий что-то очень полезное, ваша первая реакция была бы не дописать в этот код раздел с правильными диагностическими сообщениями об ошибках, а, пойти в бар и похвастаться перед друзьями. Квинтэссенцией примером этого может служить текстовый редактор «ed» операционной системы Unix, который имеет одно сообщение на любую ошибку:»?». (Может выглядеть смешно, но это было передовым в то время с точки зрения локализации). Как только вы убедитесь, что все работает, то вы можете побеспокоиться о таких вещах, как хорошие сообщения об ошибках. Позже вы можете беспокоиться о функциях высшего порядка и юзабилити. PowerShell имеет преимущество, стоя на плечах гигантов. Некоторые из этих гигантов являются концептуальными, как: Bash, C#, Perl, Tcl, VMS / DCL, AS400 CL, и т.д. Но что действительно сделало его таким волшебным, это то что PowerShell опирается на код: .NET, XML, WMI, ADSI, ADO и т.д. Поэтому мы получили возможность подняться по иерархии потребностей Маслоу и сосредоточить наши усилия на закрытие семантического разрыва. Очевидно, наша цель в том, чтобы позволить нашим клиентам опереться на нашу работу и закрыть семантический разрыв между тем, что мы предоставили им в виде инструментария и деловыми проблемами, с которыми они сталкиваются решая ежедневные задачи.
(Прим переводчика: достаточно сложно перевести,» Obviously our goal in this is to allow our customers to stand on our shoulders and close the semantic gap between what we providefor and the business problems that they face.»)
Я считаю, что это метафизически невозможно для CD дисков, которые мы (и любой поставщик) высылаем для прямого решения бизнес задач. Каждый бизнес имеет свою собственную среду, философии, политике, истории, личности и т.д. Каждый бизнес должен взять то, что разработчики предоставили и адаптировать его (с помощью действий, операций или сценариев) для удовлетворения своих потребностей (чтобы закрыть их СОБСТВЕННЫЙ семантических разрыв). Мое видение успеха для PowerShell является то, что он обеспечит самый простой, быстрый, самый дешевый, самый надежный механизм для клиентов, чтобы принять то, что продавцы стали поставлять их и адаптировать его для удовлетворения своих уникальных потребностей. Эти потребности меняются с течением времени, поэтому PowerShell должен предоставлять решение, которое легко, дешево и безопасно, простое для понимания и поддержки.
Но вернемся обратно к инструментарию, предоставляемому разработчиками для закрытия семантического разрыва, сам PowerShell обеспечивает очень ограниченный инструментарий. Тем не менее, он играет огромную роль в этом процессе. Мы делаем это путем пропаганды и дизайна. PowerShell имеет четкое представление о правиле адаптации к опыту клиента, где пользователи могут легко писать свои абстракций высокого уровня. Мы подчеркиваем это видение для поставщиков инструментария, и обеспечиваем много указаний о том, как делать вещи, и какие слова использовать для глаголов, параметров, существительное-схемы и т.д. Конструкция PowerShell настоятельно требует от поставщиков инструментария:
• Использовать общую схему присвоения имен (набор команд, правила автоматического добавления префиксов к существительным команд)
• Использования однообразных процессов парсинга команд (биндинг)
• Поддержки общей семантики -WhatIf, -Confirm, -Verbose, -Debug
• Использование общих утилит для сортировки, фильтрации, манипуляции, форматирование, импорт / экспорт, и т.д.
• Поддерживать обе ISA и HASA модели композиции
• Однообразные правила валидации на ошибки и одни параметры. Предоставляют целостную систему сообщений об ошибках
Я твердо верю, что экономика определяет, что люди делают и не делают, поэтому PowerShell разработан с нуля, чтобы быть расширяемой, высоко уровневой, задаче ориентированной абстракцией, удешевляющей расходы на задачи администрирования и поддержки. Другими словами, PowerShell и .NET имеют дело с низкоуровневыми проблемами и мелочами иерархии Абрахама Маслоу, которая позволяет высвободить поставщиков инструментария для концентрации на более высоких уровнях проблем. Это, безусловно, подтверждается опытом тех команд, которые пишут PowerShell командлеты. Постоянно при обратной связи мы слышим:
1. Вау! … Писать командлеты очень легко.
2. Большую часть времени тратится на продумывая дизайн использования заказчиком.
На самом деле очень много того что было опущено в этой небольшой статье о семантическом разрыве, если собрать все вместе то PowerShell начинает иметь смысл. Например мы используем адаптивную систему типов (поскольку она позволяет думать о том, какие данные вы хотите, а не обдумывать где и какой тип используется [например XML hell]). Кроме того, почему мы поддерживаем обе модели композиции, ISA и модель HASA и мы фанатично продвигаем идею что вещи должны «просто работать», и вам не придется тратить энергию на типы данных.
Существует много чего о чем можно было бы поведать, но я считаю что достаточно для воскресного утра. Я собираюсь пойти выпить кофе
Ура!
Jeffrey Snover [MSFT]
Windows Management Partner Architect
