Automating the world one-liner at a time…
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:
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 ArchitectVisit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShellVisit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
So, in many ways, you're almost positioning PowerShell as an "immediate window" for C# programmers. Interesting... and funny that, what, close to ten years of Visual Studio never really gave us that? Careful, Mr. Snover, or you'll be labeled an insurrectionist :)
Jeffrey, thanks for putting into the public something I've been telling people at work for some time. One of the powerful aspects of PowerShell is as a prototyping environment for .NET. Granted, you can't do EVERYTHING in PowerShell that you can in C# (threading, for example), but most of the capability is there. Your reference of the 'glide path' to C# reinforces this idea.
PingBack from http://testsubdomain.netmoviehost.com/the-virtuous-cycle-net-developers-using-powershell/
> Careful, Mr. Snover, or you'll be labeled an insurrectionist
You should have heard what they called me when I first brought up the need for a Command Line Shell. They looked at me like I had a rat's tail hanging out of my mouth! :-)
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
Too bad, that PS isn't available on Windows 2000. This was mentioned in the article, too. Is there any technical reason why is that so, or this is just because the W2K is over its Mainstream Support phase?
There was no technical reason not to support W2K. We wanted to do it but decided not to after we balanced out the test costs, the benefits and the features we would have had to cut to support it.
The virtuous cycle is working for me rather well. I sometimes joke that I am a permanent network enginner/black box test enginner because I am the victim of a ten year failed experiment to learn C++. Nonetheless, you can only imagine what some of us can do with a few lines of cmd after ten years of administrating Windows and Unix Systems. Powershell really takes you to the next step in Windows. From there I am planning on learning F# and ML next. After awhile, I may have the courage to tackle whatever object-oriented programming looks like then.
The idiosyncracies of most scripting languages make their learning curves steep. To follow that path into manipulating objects requires more than memorization, it requires the ability to abstract concepts, understand machine architecture, market needs, etc. The power of powershell is in getting you there if you need that, but being very functional in scope and application
In my point of view the Virtuous Cycle is broken on two Points, so the flow is even broken.
Administrators are no developers! They want to quick solve problems or tasks. They can do that with cmdlets or an easy to learn Script Syntax. To learn the Powerful .NET Framework is not to that Quick Point. So the Future of Administration is that the Administration World is divided into two Steps: If a problem comes often enough, so that is it useful to develop a script, a Powershell developer doe the job and the administrator use it.
So you have Powershell developers and Powershell "users" (Administrators)
The relationship between Powershell and .NET Framework is a one-way road Powershell uses the .Net Framework. The .NET Framework has no benefit of Powershell!
In .NET Framework 1 there was no Ping Class so I have to develop it by my self.
In .NET Framework 4 there is neither a Class for UNC Paths nor a Class for CSV File support or a Class to use the Pipe technique in other Programming languages.
Here are growing two Frameworks without having symbiosis!
So the learn curve drifting apart like a pair of scissors.
So I mean, bring the .NET Framework to a Management Skill, that I can easy use the Powershell Power in both Worlds.
Historical Windows Administrators are using Basic Syntaxes like VBscript, Kixtart or AutoIT. This you can use as a good ramp up to VB.NET and further.
I think Powershell Script Syntax is too hard to learn! Make it Basic ;-)