quote:


It's definitely worth learning over the next year or so while it is still not a requirement.  A side effect of the learning may be that we all become more familiar with the Windows programming model which could  help with vbscrting.

A WSC is a COM object that exposes a vbscript or jscript class object.  It is still script but with a COM wrpper.  It is not light weight at all.  On teh other hand a CmdLet is a fully compile, secured piece of code that can directly interoperate with a PowerShell pipeline.

Along with Exchange and MOM, IIS7 will also be ported over to PowerShell  from what I have been reading.  I fully expect all major MS subsystems will ether be moved to PowerShell fo management access or will be enhaced to support PowerShell scrpt access.

Consider also that all new work being done at Microsoft is being done on teh NET Framework.  WSH has and will never have direct access to the NET Framework and the CLR (Common Language Runtime).  Gaining access would require building COM wrappers for NET objects.  This defeats some of the major benefits of NET and would create another codedom to support.

WSH languages can directly call PowerShell as a process (Exec or Run) and get access to StdOut, StdIn and all files created.  This would be a good way to continue to use WSH while taking advantage of the enhanced functionality of PowerShell.

PowerShell is a true "shell" just like CMD.EXE and COMMAND.COM before it.  PS can provide great management functionallity "from the prompt" without ever scripting or writing a CmdLet.  Just start PS insttead of CMD and pretend it's a CMD prompt.  You will find that most things work transparently.  The builtin commands like "CD" and "DIR" have PowerShell equivalents.  Some commands like the CMD "FOR" command can be enhanced by using the PowerShell "for" statement. "for" is an easier and more direct way of dionfg the same things as the CMD "FOR" statement.
for (<init>; <condition>; <repeat>) {<command_block>}

Debugging in PowerShell is instantaneous in many cases as you can write a script or execute a script one line at a time and inspect all varaibles and messages immediately.  No need to fire up a debugger.  You are basicall running inside of a very sophisticated debugger when at the PS prompt.

PowerShell also has a form of Intellisence builit in at teh prompt.  This works like a comand history combined with statement completion.

PowerShell is in Version 1.  As we all know, Microsoft generally  produces a Version 1 of anything tha is fairly trivial but functional enough to get some using it.  Version 2 then adds compelling technology (when the product is well placed).  PowerShell is one of the best V1 products I have seen for some time.  It promises to be a tru "killer" app for admins.  In the past I alwys waited for at least V3 of a product before taking it really seriously but PowerShell has captured my attention since the first beta.  It is a technically excellent re-think of the concept of the "command shell".  It's not, as some continue to claim, just a competitor of Unix shells.  Listen to the following audio of teh Hansellman interview with Jeff Snover the lead Architect for PowerShell describe the history of PowerShell. (Admins can ignore the programmer techy comments as they are not important for using PS.)

http://hanselminutes.com/default.aspx?showID=47

Performance:  Well it should perform as well as WSH or better.  The NE runtime is alwasy running so that is a help for performance.  All optimizations tor CLR and NET will immediately propagate to PS.  Code execution should be and seems to be much faster in PowerShell although I haven't performed any direct benchmarks.  Other things like remoting WMI should be identical in performance as they use all of the same subsystems.

In a future release of PS remoting will become one of the major stregths of PowerShell as it will be able to leverage advances in remoting in teh NET Framework that go well beyond what is currently available to COM.  This will provide enhanced security, improved error management and better code recovery for remote error xcenarios.  It shoul;d also simplify coding dure to it's "declaritive" model.