1: # The below Perl is equivalent to just typing “Get-Vm” in powershell.
2:
3: use VMware::VILib;
4: Opts::parse();
5: Opts::validate();
6: Util::connect();
7: my $datacenter = “.”
8: my $datacenter_view = Vim::find_entity_view(view_type => ‘Datacenter’, filter => { name => $datacenter });
9: my $host_views = Vim::find_entity_views(view_type => ‘HostSystem’, begin_entity => $datacenter_view);
10: my $counter = 1;
11: print “Hosts found:\n”;
12: foreach (@$host_views) {
13: print “$counter: “ . $_->name . “\n”;
14: $counter++;
15: }
16: $counter = 1;
17: print “\nVM’s found:\n”;
18: my $vm_views = Vim::find_entity_views(view_type => ‘VirtualMachine’, begin_entity => $datacenter_view);
19: foreach (@$vm_views) {
20: print “$counter: “ . $_->name . “\n”;
21: $counter++;
22: }
23: Util::disconnect();
‘Nuff said.
[…] 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 […]
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
Hi, can you tell me where I can get VI toolkit ?
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.
[…] VMware Perl Toolkit versus PowerShell VI Toolkit […]
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.
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.
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.
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.
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.
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.
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.
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.