The Virtuous Cycle: .NET Developers using PowerShell
I recently did an interview with Thomas Caywood of Redmond Developer Magazine about how .NET developers where finding PowerShell to be a useful tool for their development environments. I was pleased to see that he contacted a number of developers to get their stories and he included them in the article (HERE).
If you think about the typical Unix developer, they are proficient in at least 3 languages:
Systems programming language of choice: C, C++, Java, etc
Shell programming: ksh, Bash, sh
Scripting language: Perl, Python, Tcl
From there they also are proficient at many more little languages: make, awk, sed, grep, etc.
While this has been wildly successful, the fact remains that there is little to no virtuous cycle here. Energy spent learning shell programming does not feed into improvements in systems programming or scripting. Energy spent on scripting languages does not feed into improvements in systems programming or shell programming.
Developers love about PowerShell because it is both a shell and a scripting language but more because it creates a virtuous cycle with their systems programming. PowerShell is .NET based. As such, when you use PowerShell as a shell, you are actually learning the .NET object model – what the objects are, what their properties are, etc. When you run a command and format the results as a table, the columns are the .NET properties of the .net object that was emitted (modulo that fact that PowerShell sometimes extends these for greater consistency).
If you are a .NET programmer, you’ll know that there is a learning curve to learn your language of choice but then the bulk of your effort is spent learning the .NET objects themselves. By having PowerShell be .NET based, it creates a virtuous cycle with your systems programming. The more you invest in using PowerShell, the more you explore that .NET objects which improves your systems programming. The more you invest in your systems programming, the more you improve your shell and scripting skills.
Note: Just to drive this point home: PowerShell is written in C# but a number of developers do their prototyping using PowerShell itself because it is such a nice environment to learn the .NET objects. It is easy to create the objects, you can easily explore and manipulate the objects to get their semantics well in focus and PowerShell language eliminates so much of the low level crap that you can focus on your algorithms and processing steps.
Now if your systems programming language is C#, the virtuous cycle is even stronger. We made the explicit decision to design the PowerShell syntax to create a glide path the C#. In the end, we are a Shell and Scripting language and that forces us to have a different syntax from a systems programming language (we need to optimize the syntax for the command line) but wherever we could, we used C# syntax. As such, there is an even stronger syntax between PowerShell and C#.
I strongly believe that there will be IT Pros that use PowerShell as a shell, over time they’ll start to use it as a scripting language and then one day they’ll pick up a C# book and say to themselves, “that looks pretty easy and obvious”. So too, I expect .NET programmers (especially C# programmers) to look at PowerShell and start to use it like their left arm. Your left arm is not the same as your right arm (or vice versa for lefties) and one is used more often than the other but when used in combination – they are much more powerful and capable than a single arm.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx