... but then a great book (PowerShell in Action) came along.
Our in-box documentation has gotten much better as well but you pick up Bruce's book and give us a try again. I doubt you'll be disappointed.
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
I encourage you all to come kick the tires and find out what PowerShell really does/does not do. I think you'll be pleasantly surprised by its power and simplicity and might even like it. Many of us on the team have a deep background in UNIX and brought that into our work. Even if you don't like what we've done, trying it out will allow you to know enough to throw your rocks accurately.:-)
>Monad however has to have everything written for it. You can't take your existing command line apps, or GUI apps, and intermix them to create new programs or script with what you have.
We fixed this in the latest drop. We want Monad to be useful for Admins. That means that it has to address the problems they have today and provide them a substantial value proposition above and beyond that.
In addition to being an interactive Shell, Monad supports 3 styles of scripting: 1) *NIX style scripting (stitch together existing executables and provide a set of text processing utilities), 2) VBScript style scripting (Manipulate OLE Automation objects), 3).NET style scripting (stitch together Cmdlets which produce/consume objects and provide a set of object processing utilities).
You are right about the strength of UNIX - it has commands for everything (hats off to you). This is a weakness of the Windows world. Addressing this was one of the primary design centers for Monad. I believe economics talks and BS walks. Monad is designed to provide a maximal return on investment for Cmdlet developers. Monad is architected to make developing cmds very cheap and easy and once you do it, it provides a ton of functions.
I encourage you all to download the beta and let us know how we are doing, what we got wrong and where we can do better. I really would appreciate the feedback from this community as *NIX has done a wonderful job in this area from the beginning. (Though to be fair, VMS DCL and AD400 CL did good jobs as well). The command line shell is clearly an area that we (MSFT) have opportunities to improve.
The article is completely correct when it states that Monad started with the ideas from WMIC and then applied those ideas to.NET. It is however, incorrect to think that this means that WMI is in any way being "left behind".
Of the issues Admins had with WMIC is that to do non-trival processing of WMI object, you had to use XSLT or use WSH (e.g. VBSCRIPT). With Monad, Admins get full, admin-focused, command-oriented, language to manipulate WMI (as well
as.NET, ADO, ADSI, XML and OLE Automation objects).
It might be appropriate to compare and contrast the capabilities of Monad and WMIC but not Monad and WMI. WMI is a management infrastructure, Monad is an environment to present those capabilities via command line scripting.
Said another way, the value of writing new WMI providers (and the value of existing WMI providers) increases with the availability of Monad.
Jeffrey Snover
Monad Architect
Apologizes for the lack of updates. We've been heads down getting things things finished up for some deadlines. We'll be dropping a new version on betapace sometime next week. It is about 95+% language complete and interop with existing external programs has greatly improved.
We'd love you (and everyone else) to give it a try and let us know what you don't like or how we can make it better.
jps
Slashdot Mirror
... but then a great book (PowerShell in Action) came along. Our in-box documentation has gotten much better as well but you pick up Bruce's book and give us a try again. I doubt you'll be disappointed. 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
That is not the case. I gave it the name Monad because of my respect for Leibniz. Wikipedia has this right: http://en.wikipedia.org/wiki/Windows_PowerShell
I encourage you all to come kick the tires and find out what PowerShell really does/does not do. I think you'll be pleasantly surprised by its power and simplicity and might even like it. Many of us on the team have a deep background in UNIX and brought that into our work. Even if you don't like what we've done, trying it out will allow you to know enough to throw your rocks accurately. :-)
a milyId=2B0BBFCD-0797-4083-A817-5E6A054A85C9&displa ylang=en
http://www.microsoft.com/downloads/details.aspx?F
If you'd like to learn more, you can read our team blog at:
http://blogs.msdn.com/PowerShell
Enjoy!
Jeffrey Snover
PowerShell Architect
We fixed this in the latest drop. We want Monad to be useful for Admins. That means that it has to address the problems they have today and provide them a substantial value proposition above and beyond that.
In addition to being an interactive Shell, Monad supports 3 styles of scripting: .NET style scripting (stitch together Cmdlets which produce/consume objects and provide a set of object processing utilities).
1) *NIX style scripting (stitch together existing executables and provide a set of text processing utilities),
2) VBScript style scripting (Manipulate OLE Automation objects),
3)
You are right about the strength of UNIX - it has commands for everything (hats off to you). This is a weakness of the Windows world. Addressing this was one of the primary design centers for Monad. I believe economics talks and BS walks. Monad is designed to provide a maximal return on investment for Cmdlet developers. Monad is architected to make developing cmds very cheap and easy and once you do it, it provides a ton of functions.
I encourage you all to download the beta and let us know how we are doing, what we got wrong and where we can do better. I really would appreciate the feedback from this community as *NIX has done a wonderful job in this area from the beginning. (Though to be fair, VMS DCL and AD400 CL did good jobs as well). The command line shell is clearly an area that we (MSFT) have opportunities to improve.
The article is completely correct when it states that Monad started with the ideas from WMIC and then applied those ideas to .NET. It is however, incorrect to think that this means that WMI is in any way being "left behind".
Of the issues Admins had with WMIC is that to do non-trival processing of WMI object, you had to use XSLT or use WSH (e.g. VBSCRIPT). With Monad, Admins get full, admin-focused, command-oriented, language to manipulate WMI (as well
as .NET, ADO, ADSI, XML and OLE Automation objects).
It might be appropriate to compare and contrast the capabilities of Monad and WMIC but not Monad and WMI. WMI is a management infrastructure, Monad is an environment to present those capabilities via command line scripting.
Said another way, the value of writing new WMI providers (and the value of existing WMI providers) increases with the availability of Monad.
Jeffrey Snover
Monad Architect
Apologizes for the lack of updates. We've been heads down getting things things finished up for some deadlines. We'll be dropping a new version on betapace sometime next week. It is about 95+% language complete and interop with existing external programs has greatly improved. We'd love you (and everyone else) to give it a try and let us know what you don't like or how we can make it better. jps