On Saturday I arrived in Aarhus Denmark for the JAOO conference.  JAOO stands for Java And Object Oriented but it is definitely NOT a Java conference - it is a language conference with lots of .NET, Ruby, Ajax content and then just a lot of really smart people talking about software in general. 

I'm honored to be invited to talk about Windows PowerShell at a language conference because it allows me to start the process of setting the record straight regarding PowerShell as a language.

People parse the world according to their past experience.  What that means is that a lot of people have put PowerShell into the Bash bucket - it is an interactive shell and a tiny bit of a glue language.  That is most certainly true - you can successfully use PowerShell for years and years and never go any deeper than that.   

What is ALSO true is that PowerShell is a rich SCALABLE language.  By "scalable" I mean that it seamlessly scales from a simple ad hoc Bash-style language to a sophisticated (near) Ruby-style programming language.  I say "near" because in V2, we still don't provide a easy "native" way to create your own classes and to subclass existing classes (you can do it easily with embedded C# or VB but there is no native mechanism). 

Did you realize that people are writing WinForms, WPF, and Web applications using PowerShell?  Check out: the PowerShell Player (A podcast player written in PowerShell using the awesome Admin Script Editor which provides a form-builder for PowerShell.

The motivations for allowing the language to scale from simple to sophisticated include:

• Our eyes are totally on the prize - cmdlets - high level, task-oriented abstractions.  It is going to take us a long to dig ourselves out of the 30 year hole we've created and the customers need these for EVERYTHING they use not just the Microsoft stuff.  As such, the community is going to be the primary providers of Cmdlets.  PowerShell needs to be capable of generating cmdlets (it is in V2) and it needs to be able to do whatever it takes to do get the job done. 
• The model here is that advanced users will take advantage of the sophisticated parts of PowerShell to produce simple abstractions for the rest of the community to share. 
• Problems tend to grow as you solve them, we didn't want to you be 75% into solving a problem and then have the tool run out of steam on you and you have to restart with a new language.  PowerShell should be simple for ad hoc things, and then allow you to ask it to do more and more as your solution demands it.  It is important to note that PowerShell is not binary - simple and sophisticated.  It provides a glide path from simple to sophisticated.  You pick what you need and use it when you need it. This also means that you can learn it as you need it.
• Career growth.  PowerShell allows you to start off simple and then invest to grow your career.  You can grow your career in 2 directions with PowerShell - you can producing increasingly more productive solutions to your environment and become a rock-star admin and you can easily grow your programming skills for fun or to get into programming.  We designed the syntax of PowerShell to provide a nice glide path to C# for people that want to go down this path. 
• At Teched I ran into someone that thanked me for PowerShell because it gave him a path to write his first C# program.  He said he always wanted to do this but was intimidated.  He was writing some PowerShell scripts and asked a programmer buddy a question and the guy said something to the effect of, "you're already programming in C#".  He bought a book and found it easy to start programming in C#.
• We want a large community of admins and programmers to efficiently communicate and cooperate with one another.  In the previous bullet I talked about how an admin got a programmer buddy to help him with his script and how smoothly that went.  Image how pear shaped that would have gone if the script was in Perl.  The essence of automation is communities sharing artifacts to help one another.  We want the largest community of people producing common artifacts and speaking the same language.

I want to restate that we are TOTALLY COMMITTED to the simple PowerShell experience. People will always be able to run interactive PowerShell and just type cmdlets and be blissfully ignorant of they power 2 inches away.  (It's like swimming in the ocean - if you're staying on the surface - it doesn't really matter whether the water is 20 feet deep or 2,000 feet deep.)

You walk away for the day is this:  IF and WHEN I want to, I can use PowerShell as a rich general purpose language.

Cheers!

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