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 kit has become 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 these two worlds is what is called the semantic gap .
Our industry (note translator: IT industry) has been struggling with a semantic gap for many decades. A great example of a semantic gap is the “TechProsaic: VMWare Perl Toolkit versus Powershell V1 ToolKit” blog entry, which contains 20 lines of Perl code that do the same thing that only one Get-VM cmdlet does.
Someone will stop reading further with the words “PowerShell is powerful, and Perl is shit,” in this exclamation will be true and not true. The truth is that PowerShell is powerful, but Perl is not crap. (take off your hat in front of superstar Larry Wall and his Perl, very few people and technologies who had a level (positive :-)) of impact on our industry like them. And this world is a good place because good guys like it are born!). The real difference between these 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 the people who develop the toolkit. VMWare could easily provide PowerShell with a script that would have the same number of Perl examples, or they could send a library for Perl that would provide the semantics of the Get-VM cmdlet with a single command.
So why did the tool vendors close or did not close the semantic gap? Ahh - this is the very question!
I may be wrong on this point, but I think this is just an example of the hierarchy of needs of Abraham Maslow. The technologies used by people to make simple what was previously done was very difficult, and allowing anyone to use it is simple. If you wrote code that does something very useful, your first reaction would be not to add a section with the correct diagnostic error messages to this code, but go to the bar and brag to your friends. A quintessential example of this is the ed text editor Unix, which has one message for any error: “?”. (It may look funny, it was advanced at the time in terms of localization :)). Once you make sure everything works, then you can worry about things like good error messages. Later, you can worry about higher order functions and usability. PowerShell has the advantage of standing on the shoulders of giants. Some of these giants are the founders of the concept: Bash, C #, Perl, Tcl, VMS / DCL, AS400 CL, etc. But what really made it magical is that PowerShell relies on code: .NET, XML, WMI, ADSI, ADO, etc. thanks to them, we were able to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our clients to rely on our work and close the semantic gap between what we have provided in the form of tools and business problems that they face in solving daily tasks.
I believe that it is metaphysically impossible for CDs that we (and any supplier) send out to solve business problems. Every business has its own environment, philosophy, politics, history, personalities, etc. Each business must take what the developers have provided to it and adapt it (through actions, operations or scenarios) to meet their needs (to close their own semantic gap). My vision of success is that PowerShell will provide the easiest, fastest, cheapest, most reliable mechanism for customers to take what developers deliver to 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 secure, easy to understand and support.
But back to the toolkit provided by developers to close the semantic gap, PowerShell itself provides very limited tools. However, it plays a huge role in this process. We do promotion and design. PowerShell has a clear understanding of the rules for adapting to customer experience, where the user can easily write their own high-level abstractions. We emphasize this vision for toolbox vendors, and provide many guidelines on what to do, which words to use naming for verbs, parameters, nouns, etc. The design of PowerShell urgently requires developers to toolkit:
I firmly believe that economics determines what people do or do not do, so PowerShell is designed from scratch to be an expandable, high-level, task-oriented abstraction that reduces the cost of administration and support. In other words, PowerShell and .NET deal with the low-level problems and small things of the Abraham Maslow hierarchy, which allows you to free up the time of tool developers to concentrate on higher levels of problems. This is certainly confirmed by the experience of those commands that write PowerShell cmdlets. Constantly with feedback, we hear:
1. Wow! ... Writing cmdlets is very easy.
2. Most of the time is spent on thinking through the design of use by the customer.
In fact, a lot of what was omitted in this small article on the semantic gap, 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, rather than pondering where and which type you should use. In addition, we support both composition models, ISA and HASA model, and we fanatically promote the idea that things should "Just work".
There is a lot to talk about, but I think that is enough for a Sunday morning. I'm going to go have some coffee
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Semantic gap
There are 2 worlds:
1. The world as we represent it.
2. The world, how we can manage it.
')
The difference between these two worlds is what is called the semantic gap .
Our industry (note translator: IT industry) has been struggling with a semantic gap for many decades. A great example of a semantic gap is the “TechProsaic: VMWare Perl Toolkit versus Powershell V1 ToolKit” blog entry, which contains 20 lines of Perl code that do the same thing that only one Get-VM cmdlet does.
Someone will stop reading further with the words “PowerShell is powerful, and Perl is shit,” in this exclamation will be true and not true. The truth is that PowerShell is powerful, but Perl is not crap. (take off your hat in front of superstar Larry Wall and his Perl, very few people and technologies who had a level (positive :-)) of impact on our industry like them. And this world is a good place because good guys like it are born!). The real difference between these 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 the people who develop the toolkit. VMWare could easily provide PowerShell with a script that would have the same number of Perl examples, or they could send a library for Perl that would provide the semantics of the Get-VM cmdlet with a single command.
So why did the tool vendors close or did not close the semantic gap? Ahh - this is the very question!
I may be wrong on this point, but I think this is just an example of the hierarchy of needs of Abraham Maslow. The technologies used by people to make simple what was previously done was very difficult, and allowing anyone to use it is simple. If you wrote code that does something very useful, your first reaction would be not to add a section with the correct diagnostic error messages to this code, but go to the bar and brag to your friends. A quintessential example of this is the ed text editor Unix, which has one message for any error: “?”. (It may look funny, it was advanced at the time in terms of localization :)). Once you make sure everything works, then you can worry about things like good error messages. Later, you can worry about higher order functions and usability. PowerShell has the advantage of standing on the shoulders of giants. Some of these giants are the founders of the concept: Bash, C #, Perl, Tcl, VMS / DCL, AS400 CL, etc. But what really made it magical is that PowerShell relies on code: .NET, XML, WMI, ADSI, ADO, etc. thanks to them, we were able to climb the Maslow hierarchy of needs and focus our efforts on closing the semantic gap. Obviously, our goal is to allow our clients to rely on our work and close the semantic gap between what we have provided in the form of tools and business problems that they face in solving daily tasks.
I believe that it is metaphysically impossible for CDs that we (and any supplier) send out to solve business problems. Every business has its own environment, philosophy, politics, history, personalities, etc. Each business must take what the developers have provided to it and adapt it (through actions, operations or scenarios) to meet their needs (to close their own semantic gap). My vision of success is that PowerShell will provide the easiest, fastest, cheapest, most reliable mechanism for customers to take what developers deliver to 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 secure, easy to understand and support.
But back to the toolkit provided by developers to close the semantic gap, PowerShell itself provides very limited tools. However, it plays a huge role in this process. We do promotion and design. PowerShell has a clear understanding of the rules for adapting to customer experience, where the user can easily write their own high-level abstractions. We emphasize this vision for toolbox vendors, and provide many guidelines on what to do, which words to use naming for verbs, parameters, nouns, etc. The design of PowerShell urgently requires developers to toolkit:
- Use a common naming scheme (command set, rules for automatically adding prefixes to command nouns)
- The use of uniform processes of command parsing (binding)
- Supports common semantics -WhatIf, -Confirm, -Verbose, -Debug
- Use common utilities for sorting, filtering, manipulating, formatting, importing / exporting, etc.
- Support both ISA and HASA composition models
- Same rules for validating errors and some parameters. Provide a complete error reporting system
I firmly believe that economics determines what people do or do not do, so PowerShell is designed from scratch to be an expandable, high-level, task-oriented abstraction that reduces the cost of administration and support. In other words, PowerShell and .NET deal with the low-level problems and small things of the Abraham Maslow hierarchy, which allows you to free up the time of tool developers to concentrate on higher levels of problems. This is certainly confirmed by the experience of those commands that write PowerShell cmdlets. Constantly with feedback, we hear:
1. Wow! ... Writing cmdlets is very easy.
2. Most of the time is spent on thinking through the design of use by the customer.
In fact, a lot of what was omitted in this small article on the semantic gap, 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, rather than pondering where and which type you should use. In addition, we support both composition models, ISA and HASA model, and we fanatically promote the idea that things should "Just work".
There is a lot to talk about, but I think that is enough for a Sunday morning. I'm going to go have some coffee
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Source: https://habr.com/ru/post/301834/
All Articles