Automating the world one-liner at a time…
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:
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.
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
I love the design of the language, the composability and the easy drop-down to .net, but there is also another form of "scalability" where PowerShell unfortunately don't look as good.
When the data sets grows, I have frequently found PowerShell grind to a halt. That have to be addressed.
A simple task (parsing a log file and turning the lines to objects) just didn't cut it when writing it in PowerShell.
It was 25 times slower that the Cmdlet that did just the same thing.
You have to make it possible to write scripts that can handle larger data sets.
Right now, it is limited to those that have small data sets, or those who know how to write cmdlets.
Don't get me wrong. I love the work you have done. It is truly impressive. But you can't keep putting of perf work.
PingBack from http://www.simplynetdev.com/powershell-and-jaoo/
Performance improvements have already started sneaking into the v2 CTPs, so I believe Microsoft is really listening to the community's feedback on performance in v1.
Several months ago, I had exchanged emails with an upcoming book on problem solving (now out, but I won't mention it). The subject of PowerShell came up, to which the author replied something like "the problems are meant to be solved by real programming languages, so PowerShell doesn't really apply".
Out to prove him wrong, I did buy the book, but haven't been able to find the time outside of my other projects to make a point.
For me at least, until Powershell runs on more than one platform (via Mono for eg), it's hard to justify putting much effort into it.
I would like to see powershell material grow beyond system administrators.
As a database analyst with many years invested in vbscript I had really hoped powershell would be something I could dig in and begin using. The problem I am having is that all of the introductory material is aimed at admins, WMI, ADSI, etc.
Until I can figure out how to get data from SQL Server to Excel I am stuck with vbscript no matter how much fun I have playing with posh.
Tell us what scripts you need! SQL Server 2005 or 2008?
Give me an example data structure you'd like to copy to Excel.
If you can use the "AdventureWorks" database to provide an example that would be even easier...
Eric, here is a script to help you get started:
Richard Siddaway, MVP, has recently started authoring a book, and it looks promising:
Looks like it will cover the application specific examples like what SQL admins may want to see.
Hey, guys. Thanks for the responses.
The beginning of the month is hectic for me, but I will post more information as soon as I can (after I check the link above). Thanks again!
I am a developer and I love Powershell - the automation work it has allowed me to do is amazing. However I do work with a lot of infrastructure folks and their take on PowerShell suprises me. Not one of them is actively using it. Couple of reasons they state - slow, requires .NET whereas VB Script is natively enabled on Windows platform, last but not the least is "I don't want to learn programming". The last thing resonated with me - why should a system's administrator care about things like Closures, .NET Framework's rich API and other esoteric progamming language topics. I am just wondering that by adding all the greatest and coolest capabilities in the language, are you missing the exact audience you should be reaching out to?
> I am just wondering that by adding all the greatest and coolest capabilities in the language, are you missing the exact audience you should be reaching out to?
Potentially. But the thinking is that what Admins REALLY need is CMDLETs - high level, task-oriented abstractions. One of the reasons we have added these more sophisticated scripting facilities is to allow a wider range of people to develop cmdlets more easily.
In Volleyball, there is the "setup" and the "spike". We are providing the "setup" and the community has to provide the "spike" (develop and share the cmdlets that admins need). I'm convinced that that will occur and the over time, more and more admins will find that PS provides them the value that they want/need with minimal onboarding costs. Once they get onboard, they'll discover that they can incrementally invest for great reward.
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