PowerShell and JAOO

PowerShell and JAOO

  • Comments 12

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

Leave a Comment
  • Please add 1 and 5 and type the answer here:
  • Post
  • Jeffrey,

    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.

    Regards,

    /Staffan

  • PingBack from http://www.simplynetdev.com/powershell-and-jaoo/

  • @Staffan,

    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.

  • Eric,

    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:

    http://www.leeholmes.com/blog/InteractingWithSQLDatabasesInPowerShellInvokeSqlCommand.aspx

  • Richard Siddaway, MVP, has recently started authoring a book, and it looks promising:

    http://www.manning.com/siddaway/

    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

Page 1 of 1 (12 items)