Comments on: VMware Perl Toolkit versus PowerShell VI Toolkit http://halr9000.com/article/460 (powershell & other stuff) Thu, 18 Mar 2010 14:11:31 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: halr9000 http://halr9000.com/article/460/comment-page-1#comment-6543 halr9000 Mon, 17 Mar 2008 15:58:49 +0000 http://halr9000.com/article/460#comment-6543 While yes, VMware did learn and so did the creators of PowerShell, I have to disagree that things would be the same if the order of the two toolkits were reversed. There is a higher level interface here, one that is encouraged by the structure of the language. What VMware did was great, but the results were singularly specific to that implementation/toolkit. What they've done with PowerShell is more consistent and easier to use than anything they've done before. Also, you can plug this stuff into anything else in the .NET world keeping that same consistency and discoverability which makes PowerShell so cool. While yes, VMware did learn and so did the creators of PowerShell, I have to disagree that things would be the same if the order of the two toolkits were reversed. There is a higher level interface here, one that is encouraged by the structure of the language. What VMware did was great, but the results were singularly specific to that implementation/toolkit. What they’ve done with PowerShell is more consistent and easier to use than anything they’ve done before. Also, you can plug this stuff into anything else in the .NET world keeping that same consistency and discoverability which makes PowerShell so cool.

]]> By: Ian http://halr9000.com/article/460/comment-page-1#comment-6542 Ian Mon, 17 Mar 2008 14:58:40 +0000 http://halr9000.com/article/460#comment-6542 The other main point here is VMware is learning. The VI Perl Toolkit was version 1.0. The Powershell one took everything learned from people using the VI Perl Toolkit (which was a HUGE leap in API usage over the VI API) and put it into the Powershell system. If Powershell was first I'd argue that it'd look alot like the VI Perl Toolkit is today and the story would be reversed. Powershell is just another language like anything else. It has learned from languages that came before it. The other main point here is VMware is learning. The VI Perl Toolkit was version 1.0. The Powershell one took everything learned from people using the VI Perl Toolkit (which was a HUGE leap in API usage over the VI API) and put it into the Powershell system. If Powershell was first I’d argue that it’d look alot like the VI Perl Toolkit is today and the story would be reversed.

Powershell is just another language like anything else. It has learned from languages that came before it.

]]> By: halr9000 http://halr9000.com/article/460/comment-page-1#comment-6504 halr9000 Sat, 01 Mar 2008 20:19:34 +0000 http://halr9000.com/article/460#comment-6504 I actually knew you were going to say CPAN. I guess you can say the coolest thing about PowerShell is that making .NET so accessible is like giving CPAN to VBScripters. But even so, PowerShell has the benefit of starting fresh with many of the concepts that Perl and Python have had time to bring to maturity. Microsoft can really set the stage and drive the show moving forward. With the third-party support coming in so fast like it is, it is hard not to get excited at the potential that PowerShell is bringing to the sysadmin game. I think I'll keep my PowerShell fanboy-like bias for now. But that being said, I agree with everything you've said. My other hobby outside of Posh evangelism is webmaster for the <a href="http://psi-im.org" rel="nofollow">Psi instant messaging client</a>. It is cross-platform software written in C++ and uses the QT toolkit. I do get the cross-platform arguments. What will be interesting to see in maybe a couple of years is if Mono will have a powershell-like port. I actually knew you were going to say CPAN. I guess you can say the coolest thing about PowerShell is that making .NET so accessible is like giving CPAN to VBScripters.

But even so, PowerShell has the benefit of starting fresh with many of the concepts that Perl and Python have had time to bring to maturity. Microsoft can really set the stage and drive the show moving forward. With the third-party support coming in so fast like it is, it is hard not to get excited at the potential that PowerShell is bringing to the sysadmin game. I think I’ll keep my PowerShell fanboy-like bias for now.

But that being said, I agree with everything you’ve said. My other hobby outside of Posh evangelism is webmaster for the Psi instant messaging client. It is cross-platform software written in C++ and uses the QT toolkit. I do get the cross-platform arguments. What will be interesting to see in maybe a couple of years is if Mono will have a powershell-like port.

]]> By: Andrew Kutz http://halr9000.com/article/460/comment-page-1#comment-6503 Andrew Kutz Sat, 01 Mar 2008 19:22:21 +0000 http://halr9000.com/article/460#comment-6503 Well, I don't want to turn this into a "You can do it Perl, I can do it in PS" conversation, because obviously both have their pros and cons. For me though, the litmus test that I apply to tools is "How many users does this help? How many users does this reach? How can I ensure that this tool is helpful to as many users as possible?" That is why I think cross-OS compatibility is so terribly important. VI Perl lets you create tools that Windows users, OS X users, and Linux users can all use. What is more powerful and helpful than that? Another maxim that I try to remember is that tools are just that, tools. These things we create should not be the end, they should be the means. Therefore, I try to look past how cool a framework is, or how nice a language is, but instead attempt to (and I do not always succeed) remember that I am creating this tool to serve a user, not another developer (unless it is an IDE or something like that of course). And since I am creating it for the user, well, see my previous paragraph : ) However, I also do not want to end this comment without directly addressing your points, because they are good and valid points. Point 1 - PowerShell lets you pass around object references. Counterpoint 1 - So does Perl. I can actually create a VI Perl view *from* a .NET VirtualMachine object and then pass that reference around. Remember, VI Perl view are just hash tables. Point 2 - Output formats. Counterpoint 2 - See CPAN for all the Perl modules that are available to format output. I am a *huge* .NET advocate. I frequently evangelize it for the fact that the Microsoft provided framework gives developers almost anything they could want when it comes to building tools. However, since we create tools for users, we should keep the users in mind when creating them. Well, I don’t want to turn this into a “You can do it Perl, I can do it in PS” conversation, because obviously both have their pros and cons. For me though, the litmus test that I apply to tools is “How many users does this help? How many users does this reach? How can I ensure that this tool is helpful to as many users as possible?” That is why I think cross-OS compatibility is so terribly important. VI Perl lets you create tools that Windows users, OS X users, and Linux users can all use. What is more powerful and helpful than that?

Another maxim that I try to remember is that tools are just that, tools. These things we create should not be the end, they should be the means. Therefore, I try to look past how cool a framework is, or how nice a language is, but instead attempt to (and I do not always succeed) remember that I am creating this tool to serve a user, not another developer (unless it is an IDE or something like that of course). And since I am creating it for the user, well, see my previous paragraph : )

However, I also do not want to end this comment without directly addressing your points, because they are good and valid points. Point 1 – PowerShell lets you pass around object references. Counterpoint 1 – So does Perl. I can actually create a VI Perl view *from* a .NET VirtualMachine object and then pass that reference around. Remember, VI Perl view are just hash tables. Point 2 – Output formats. Counterpoint 2 – See CPAN for all the Perl modules that are available to format output.

I am a *huge* .NET advocate. I frequently evangelize it for the fact that the Microsoft provided framework gives developers almost anything they could want when it comes to building tools. However, since we create tools for users, we should keep the users in mind when creating them.

]]> By: halr9000 http://halr9000.com/article/460/comment-page-1#comment-6502 halr9000 Sat, 01 Mar 2008 18:23:45 +0000 http://halr9000.com/article/460#comment-6502 Well obviously, I can write a powershell script that does the same, which is to say, I can write a script that returns textual information about a virtual machine. However, there are a lot of differences when you look at the big picture. All of the below are examples drawn from the VMware Perl Toolkit versus their PowerShell one, but you could just as easily replace the word VMware with Citrix and compare their <a href="http://www.sessioncomputing.com/cmd.htm" rel="nofollow">last gen stuff</a> with BSonPosh's PowerShell <a href="http://bsonposh.com/modules/wordpress/?p=49" rel="nofollow">Citrix management scripts</a> or Citrix's as of yet unannounced future plans which they have said will include PowerShell. VMware is providing 70+ cmdlets with their PowerShell Toolkit. Each one manipulates an object. These 70 cmdlets can be combined with each other, or with the hundreds of others that either come with PowerShell or are available as external snapins. Cmdlets can take objects as input, and can emit them as output. You are a .NET developer, so you can appreciate that I can instantiate most any .NET object in PowerShell and manipulate it. You can do that at a command-line shell, or inside of a script. This is a pervasive concept upon which PowerShell is built. Perl doesn't have a shell. At this time (to my knowledge), you can't do the sort of ad-hoc experimentation and one-off scripting that I do all day in Posh. (I found this <a href="http://dev.perl.org/perl6/rfc/184.html" rel="nofollow">old Perl6 RFC</a> amusing.) But really, it *is* the big picture which is the point. Not only can I do all of the above with VMware's stuff, but I can use the same consistent interface for Exchange 2007 management, or WebSphere MQ or System Center Virtual Machine Manager. Vminfo.pl may use a --fields parameter to determine what information is displayed. But is IBM going to release a perl utility to view queues that has a --fields parameter? Not likely. With PowerShell it is irrelevant because of the abstracted output formatting. I can take get-vm, pipe it through select-object or format-table and get exactly the output I want. Same for Get-Mailbox. Well obviously, I can write a powershell script that does the same, which is to say, I can write a script that returns textual information about a virtual machine.

However, there are a lot of differences when you look at the big picture. All of the below are examples drawn from the VMware Perl Toolkit versus their PowerShell one, but you could just as easily replace the word VMware with Citrix and compare their last gen stuff with BSonPosh’s PowerShell Citrix management scripts or Citrix’s as of yet unannounced future plans which they have said will include PowerShell.

VMware is providing 70+ cmdlets with their PowerShell Toolkit. Each one manipulates an object. These 70 cmdlets can be combined with each other, or with the hundreds of others that either come with PowerShell or are available as external snapins. Cmdlets can take objects as input, and can emit them as output. You are a .NET developer, so you can appreciate that I can instantiate most any .NET object in PowerShell and manipulate it. You can do that at a command-line shell, or inside of a script. This is a pervasive concept upon which PowerShell is built. Perl doesn’t have a shell. At this time (to my knowledge), you can’t do the sort of ad-hoc experimentation and one-off scripting that I do all day in Posh. (I found this old Perl6 RFC amusing.)

But really, it *is* the big picture which is the point. Not only can I do all of the above with VMware’s stuff, but I can use the same consistent interface for Exchange 2007 management, or WebSphere MQ or System Center Virtual Machine Manager. Vminfo.pl may use a –fields parameter to determine what information is displayed. But is IBM going to release a perl utility to view queues that has a –fields parameter? Not likely. With PowerShell it is irrelevant because of the abstracted output formatting. I can take get-vm, pipe it through select-object or format-table and get exactly the output I want. Same for Get-Mailbox.

]]> By: Andrew Kutz http://halr9000.com/article/460/comment-page-1#comment-6499 Andrew Kutz Sat, 01 Mar 2008 15:49:39 +0000 http://halr9000.com/article/460#comment-6499 Okay, you're arguing that it is a matter of complex interfaces. Well then, Perl wins. While all that is needed to list VMs in PS is Get-VM, remember that you must also connect to the server with Get-VIServer or Get-VC... or Get-ESX... In VI Perl you can list all of the VMs via a single command: vminfo.pl --server 192.168.0.47 --username akutz --password mypassword That's it. That is all it takes. Sure, the code beneath that is doing what you listed above, but I would argue that a Perl script is analogous to a a CmdLet, and that a CmdLet is not the same thing as a single Perl function as your original post seems to assert. Okay, you’re arguing that it is a matter of complex interfaces. Well then, Perl wins. While all that is needed to list VMs in PS is Get-VM, remember that you must also connect to the server with Get-VIServer or Get-VC… or Get-ESX… In VI Perl you can list all of the VMs via a single command:

vminfo.pl –server 192.168.0.47 –username akutz –password mypassword

That’s it. That is all it takes. Sure, the code beneath that is doing what you listed above, but I would argue that a Perl script is analogous to a a CmdLet, and that a CmdLet is not the same thing as a single Perl function as your original post seems to assert.

]]> By: halr9000 http://halr9000.com/article/460/comment-page-1#comment-6498 halr9000 Sat, 01 Mar 2008 15:41:21 +0000 http://halr9000.com/article/460#comment-6498 Andrew, in a way I agree, but the point is not one of Perl vs PowerShell but complex interfaces to simple ones and it really typifies the architecture behind PowerShell. Besides, the creators of PowerShell openly admit their admiration of Perl and its influences on PowerShell's creation. I could have made this more clear when I wrote the blog post, but at the time I was in the middle of something else and did not feel like writing a longer article. Luckily, Jeffrey Snover (the PowerShell team lead) took up the challenge. If you have not read his article, please do, he explains it much better than I could. Andrew, in a way I agree, but the point is not one of Perl vs PowerShell but complex interfaces to simple ones and it really typifies the architecture behind PowerShell. Besides, the creators of PowerShell openly admit their admiration of Perl and its influences on PowerShell’s creation. I could have made this more clear when I wrote the blog post, but at the time I was in the middle of something else and did not feel like writing a longer article. Luckily, Jeffrey Snover (the PowerShell team lead) took up the challenge. If you have not read his article, please do, he explains it much better than I could.

]]> By: Andrew Kutz http://halr9000.com/article/460/comment-page-1#comment-6497 Andrew Kutz Sat, 01 Mar 2008 15:27:21 +0000 http://halr9000.com/article/460#comment-6497 This is an unfair example. I could write a function called Get-VM in Perl that encapsulates that code. And besides, Perl is completely cross-OS compatible and PS is not. This is an unfair example. I could write a function called Get-VM in Perl that encapsulates that code. And besides, Perl is completely cross-OS compatible and PS is not.

]]> By: TechProsaic - I write about great software, Internet technology, cool gadgets, and The Next Big Thing. » Call for Script Ideas: VMware PowerShell Toolkit http://halr9000.com/article/460/comment-page-1#comment-6466 TechProsaic - I write about great software, Internet technology, cool gadgets, and The Next Big Thing. » Call for Script Ideas: VMware PowerShell Toolkit Thu, 21 Feb 2008 14:10:44 +0000 http://halr9000.com/article/460#comment-6466 [...] VMware Perl Toolkit versus PowerShell VI Toolkit [...] [...] VMware Perl Toolkit versus PowerShell VI Toolkit [...]

]]> By: halr9000 http://halr9000.com/article/460/comment-page-1#comment-6440 halr9000 Mon, 11 Feb 2008 13:56:00 +0000 http://halr9000.com/article/460#comment-6440 It's still in closed beta, but you can always ask. See the <a href="http://blogs.vmware.com/vipowershell/2007/10/early-access-te.html" rel="nofollow">announcement</a> on the VI PowerShell blog. The beta is supposed to open to all in March. It’s still in closed beta, but you can always ask. See the announcement on the VI PowerShell blog. The beta is supposed to open to all in March.

]]> By: nicozozo http://halr9000.com/article/460/comment-page-1#comment-6439 nicozozo Mon, 11 Feb 2008 13:20:53 +0000 http://halr9000.com/article/460#comment-6439 Hi, can you tell me where I can get VI toolkit ? Hi, can you tell me where I can get VI toolkit ?

]]> By: Jeffrey Snover http://halr9000.com/article/460/comment-page-1#comment-6435 Jeffrey Snover Sun, 10 Feb 2008 23:51:14 +0000 http://halr9000.com/article/460#comment-6435 Thanks for this post. It inspired me to write: http://blogs.msdn.com/powershell/archive/2008/02/10/the-semantic-gap.aspx 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 Thanks for this post. It inspired me to write:

http://blogs.msdn.com/powershell/archive/2008/02/10/the-semantic-gap.aspx

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

]]> By: Windows PowerShell : The Semantic Gap http://halr9000.com/article/460/comment-page-1#comment-6434 Windows PowerShell : The Semantic Gap Sun, 10 Feb 2008 23:48:37 +0000 http://halr9000.com/article/460#comment-6434 [...] An excellent example of the semantic gap is provided by the TechProsaic blog entry:  VMWare Perl Toolkit verses Powershell V1 ToolKit which shows the 20 lines of Perl required to do the same as the Get-VM [...] [...] An excellent example of the semantic gap is provided by the TechProsaic blog entry:  VMWare Perl Toolkit verses Powershell V1 ToolKit which shows the 20 lines of Perl required to do the same as the Get-VM [...]

]]>