коротенькая статья от архитектора движка 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 и т.д. благодаря им мы получили возможность подняться по иерархии потребностей Маслоу и сосредоточить наши усилия на закрытие семантического разрыва. Очевидно, наша цель в том, чтобы позволить нашим клиентам опереться на нашу работу и закрыть семантический разрыв между тем, что мы предоставили им в виде инструментария и деловыми проблемами, с которыми они сталкиваются решая ежедневные задачи.
Я считаю, что это метафизически невозможно для CD дисков, которые мы (да и любой поставщик) высылаем для решения бизнес задач. Каждый бизнес имеет свою собственную среду, философии, политику, историю, личности и т.д. Каждый бизнес должен взять то, что разработчики предоставили ему и адаптировать это (с помощью действий, операций или сценариев) для удовлетворения своих потребностей (чтобы закрыть их собственный семантических разрыв). Мое видение успеха это то что PowerShell обеспечит самый простой, самый быстрый, самый дешевый, самый надежный механизм для клиентов, чтобы брать то что разработчики поставляют им и адаптировать это для удовлетворения своих уникальных потребностей. Эти потребности меняются с течением времени, поэтому PowerShell должен предоставить решение, которое легко, дешево и безопасно, просто для понимания и поддержки.
Но вернемся обратно к инструментарию, предоставляемому разработчиками для закрытия семантического разрыва, сам PowerShell обеспечивает очень ограниченный инструментарий. Тем не менее, он играет огромную роль в этом процессе. Мы делаем пропаганду и дизайн. PowerShell имеет четкое представление о правилах адаптации к опыту клиента, где пользователь может легко написать свои абстракций высокого уровня. Мы подчеркиваем это видение для поставщиков инструментария, и обеспечиваем много указаний о том, как что делать, какие слова использовать именования для глаголов, параметров, существительных и т.д. Конструкция PowerShell настоятельно требует от разработчиков инструментария:
Я твердо верю, что экономика определяет, что люди делают или что не делают, поэтому PowerShell разработан с нуля, чтобы быть расширяемой, высоко уровневой, задаче ориентированной абстракцией, удешевляющей расходы на администрирование и поддержку. Другими словами, PowerShell и .NET имеют дело с низкоуровневыми проблемами и мелочами иерархии Абрахама Маслоу, которая позволяет высвободить время разработчиков инструментария для концентрации на более высоких уровнях проблем. Это, безусловно, подтверждается опытом тех команд, что пишут PowerShell командлеты. Постоянно при обратной связи мы слышим:
1. Вау!… Писать командлеты очень легко.
2. Большую часть времени тратится на продумывание дизайна использования заказчиком.
На самом деле очень много того что было опущено в этой небольшой статье о семантическом разрыве, если собрать все вместе то PowerShell понравится вам. Например мы используем адаптивную систему типов (поскольку она позволяет думать о том, какие данные вам нужны, а не обдумывать где и какой тип нужно использовать. Кроме того, мы поддерживаем обе модели композиции, ISA и модель HASA и мы фанатично продвигаем идею что вещи должны «просто работать».
Существует много чего о чем можно было бы поведать, но я считаю что достаточно для воскресного утра. Я собираюсь пойти выпить кофе
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Семантический разрыв
Есть 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 и т.д. благодаря им мы получили возможность подняться по иерархии потребностей Маслоу и сосредоточить наши усилия на закрытие семантического разрыва. Очевидно, наша цель в том, чтобы позволить нашим клиентам опереться на нашу работу и закрыть семантический разрыв между тем, что мы предоставили им в виде инструментария и деловыми проблемами, с которыми они сталкиваются решая ежедневные задачи.
Я считаю, что это метафизически невозможно для CD дисков, которые мы (да и любой поставщик) высылаем для решения бизнес задач. Каждый бизнес имеет свою собственную среду, философии, политику, историю, личности и т.д. Каждый бизнес должен взять то, что разработчики предоставили ему и адаптировать это (с помощью действий, операций или сценариев) для удовлетворения своих потребностей (чтобы закрыть их собственный семантических разрыв). Мое видение успеха это то что PowerShell обеспечит самый простой, самый быстрый, самый дешевый, самый надежный механизм для клиентов, чтобы брать то что разработчики поставляют им и адаптировать это для удовлетворения своих уникальных потребностей. Эти потребности меняются с течением времени, поэтому PowerShell должен предоставить решение, которое легко, дешево и безопасно, просто для понимания и поддержки.
Но вернемся обратно к инструментарию, предоставляемому разработчиками для закрытия семантического разрыва, сам PowerShell обеспечивает очень ограниченный инструментарий. Тем не менее, он играет огромную роль в этом процессе. Мы делаем пропаганду и дизайн. PowerShell имеет четкое представление о правилах адаптации к опыту клиента, где пользователь может легко написать свои абстракций высокого уровня. Мы подчеркиваем это видение для поставщиков инструментария, и обеспечиваем много указаний о том, как что делать, какие слова использовать именования для глаголов, параметров, существительных и т.д. Конструкция PowerShell настоятельно требует от разработчиков инструментария:
- Использовать общую схему присвоения имен (набор команд, правила автоматического добавления префиксов к существительным команд)
- Использования однообразных процессов парсинга команд (биндинг)
- Поддержки общей семантики -WhatIf, -Confirm, -Verbose, -Debug
- Использование общих утилит для сортировки, фильтрации, манипуляции, форматирование, импорт / экспорт, и т.д.
- Поддерживать обе ISA и HASA модели композиции
- Однообразные правила валидации на ошибки и одни параметры. Предоставляют целостную систему сообщений об ошибках
Я твердо верю, что экономика определяет, что люди делают или что не делают, поэтому PowerShell разработан с нуля, чтобы быть расширяемой, высоко уровневой, задаче ориентированной абстракцией, удешевляющей расходы на администрирование и поддержку. Другими словами, PowerShell и .NET имеют дело с низкоуровневыми проблемами и мелочами иерархии Абрахама Маслоу, которая позволяет высвободить время разработчиков инструментария для концентрации на более высоких уровнях проблем. Это, безусловно, подтверждается опытом тех команд, что пишут PowerShell командлеты. Постоянно при обратной связи мы слышим:
1. Вау!… Писать командлеты очень легко.
2. Большую часть времени тратится на продумывание дизайна использования заказчиком.
На самом деле очень много того что было опущено в этой небольшой статье о семантическом разрыве, если собрать все вместе то PowerShell понравится вам. Например мы используем адаптивную систему типов (поскольку она позволяет думать о том, какие данные вам нужны, а не обдумывать где и какой тип нужно использовать. Кроме того, мы поддерживаем обе модели композиции, ISA и модель HASA и мы фанатично продвигаем идею что вещи должны «просто работать».
Существует много чего о чем можно было бы поведать, но я считаю что достаточно для воскресного утра. Я собираюсь пойти выпить кофе
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Поделиться с друзьями
tumikosha
>>Perl не дерьмо.
Ну, как-то даже не знаю. Мне он очень не нравится. В особенности из-за его любви к регуляркам. Слишком часто в них ошибаюсь.
romy4
И всё же, дело не в Perl.
potan
Регулярные выражения во всех языках примерно одинаковы.
tumikosha
В некоторых языках функция поиска подстроки в строке по дефолту на регулярках сделана и поэтому нельзя предсказать как она себя поведет при странном вводе пользователя.
Не сталкивались?