Semantic gap "The Semantic Gap"

a short article from the architect of the PowerShell engine, his view of the industry is given, the article clarifies why the posh became just that.

Semantic gap

There are 2 worlds:
1. The world, as we represent it.
2. The world, how we can manage it.

The difference between the two worlds is what is called the semantic break .

Our industry (translator's note: IT industry) has been struggling with the semantic gap for many decades. A great example of a semantic break is the TechProsaic: VMWare Perl Toolkit versus Powershell V1 ToolKit blog entry, which lists 20 lines of Perl code that do the same thing with just one Get-VM cmdlet.
Someone will stop reading further with the words “PowerShell is powerful, and Perl is shit”, this exclamation will be true and not true. The truth is that PowerShell is powerful, but Perl is not shit. (take off your hat to the superstar Larry Wall and his Perl, very few people and technologies who had a level of (positive :-)) impact on our industry like them. And this world is a good place because such nice guys like him are born!). The real difference between the two examples is the semantic gap. The PowerShell example has a very small gap between what you think and what you need to do to solve the problem. The Perl example has a very wide gap.

In the end, the semantic gap is “controlled” by those people who develop tools. VMWare could easily provide PowerShell with a script that would have as many lines of Perl example, or they could send a library to Perl that would provide the semantics of the Get-VM cmdlet with a single command.

So why did tooling suppliers close or not close the semantic gap? Ahh - this is the very question!

I may be wrong about this, but I think this is just an example of the hierarchy of needs of Abraham Maslow. Technologies used by people to make it simple what to do before was very difficult to make, and it is easy for anyone to use it. If you wrote code that does something very useful, your first reaction would be to not add the section with the correct diagnostic error messages to this code, but rather, go to a bar and brag to your friends. The quintessential example of this is the text editor “ed” of the Unix operating system, which has one message for any error: “?”. (It may look ridiculous, it was advanced at that time in terms of localization :)). Once you make sure everything works, then you can worry about things like good error messages. You may later worry about higher order functions and usability. PowerShell has the edge of standing on the shoulders of giants. Some of these giants are progenitors of the concept: Bash, C #, Perl, Tcl, VMS / DCL, AS400 CL, etc. But what really made him magical was that PowerShell relies on code: .NET, XML, WMI, ADSI, ADO, etc. thanks to them, we got the opportunity to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our customers to rely on our work and close the semantic gap between what we provided them with in the form of tools and business problems that they face when solving daily tasks. Some of these giants are progenitors of the concept: Bash, C #, Perl, Tcl, VMS / DCL, AS400 CL, etc. But what really made him magical was that PowerShell relies on code: .NET, XML, WMI, ADSI, ADO, etc. thanks to them, we got the opportunity to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our customers to rely on our work and close the semantic gap between what we provided them with in the form of tools and business problems that they face when solving daily tasks. Some of these giants are progenitors of the concept: Bash, C #, Perl, Tcl, VMS / DCL, AS400 CL, etc. But what really made him magical was that PowerShell relies on code: .NET, XML, WMI, ADSI, ADO, etc. thanks to them, we got the opportunity to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our customers to rely on our work and close the semantic gap between what we provided them with in the form of tools and business problems that they face when solving daily tasks. thanks to them, we got the opportunity to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our customers to rely on our work and close the semantic gap between what we provided them with in the form of tools and business problems that they face when solving daily tasks. thanks to them, we got the opportunity to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our customers to rely on our work and close the semantic gap between what we provided them with in the form of tools and business problems that they face when solving daily tasks.

I believe that this is metaphysically impossible for CDs that we (and any supplier) send to solve business problems. Each business has its own environment, philosophy, politics, history, personality, etc. Each business should take what the developers have provided and adapt it (through actions, operations or scripts) to meet their needs (to close their ownsemantic gap). My vision of success is that PowerShell will provide the easiest, fastest, cheapest, most reliable mechanism for customers to take what developers supply them and adapt it to meet their unique needs. These needs change over time, so PowerShell must provide a solution that is easy, cheap and safe, easy to understand and support.

But back to the tools provided by developers to close the semantic gap, PowerShell itself provides very limited tools. However, he plays a huge role in this process. We do propaganda and design. PowerShell has a clear understanding of the rules for adapting to the customer experience, where the user can easily write their own high-level abstractions. We emphasize this vision for toolkit providers, and provide a lot of guidance on how to do what words to use naming for verbs, parameters, nouns, etc. The PowerShell construct urges toolkit developers to:

• Use a common naming scheme (a set of commands, rules for automatically adding prefixes to nouns of commands)
• Using uniform process of parsing commands (binding)
• General semantics support -WhatIf, -Confirm, -Verbose, -Debug
• Using common utilities for sorting, filtering, manipulating, formatting, import / export, etc.
• Support both ISA and HASA composition models
• The uniform rules of validation for errors and some parameters. Provide a complete error reporting system

I strongly believe that economics determines what people do or do not do, so PowerShell is designed from the ground up to be an extensible, high-level, task-oriented abstraction that reduces the cost of administration and support. In other words, PowerShell and .NET deal with low-level problems and the little things in the Abraham Maslow hierarchy, which frees up the time for toolkit developers to focus on higher levels of problems. This, of course, is confirmed by the experience of those teams that write PowerShell cmdlets. Constantly with feedback we hear:
1. Wow! ... Writing cmdlets is very easy.
2. Most of the time is spent thinking through the design of use by the customer.

In fact, a lot of what was omitted in this short article about the semantic break, if you put it all together you will like PowerShell. For example, we use an adaptive type system (because it allows us to think about what data you need and not think about where and what type to use. In addition, we support both composition models, ISA and HASA, and we fanatically promote the idea that things should “Just work.”

There is much to tell, but I think that's enough for Sunday morning. I'm going to go have a cup of coffee

Jeffrey Snover [MSFT]
Windows Management Partner Architect