Weekend Scripter: That’s Not Very PowerShell-Like


Summary: Ed Wilson, Microsoft Scripting Guy, talks about what is Windows PowerShell-like scripting.

Microsoft Scripting Guy, Ed Wilson, is here. Before Internet streaming, before Nabster, before CD-ROMs, before cassette tapes, and before 8-track tapes, there were things called records. Now it seems that all technology related to music (unless you are talking about live acoustic performances) are subject to some kind of something that will cause them to fail.

With records, it was a scratches. Not the invisible sorts of scratches that cause DVDs to fail—no, I mean serious scratches that came from someone bumping the record player while the record was playing, which created a new groove in the record. When that happened, the same portion of the record would play over and over and over in an infinite loop that required manual intervention.

It is the same thing with Windows PowerShell. Specifically, conversations about Windows PowerShell and scripting. I hear it over and over and over—the criticism “that is not very PowerShell-like.”

What is PowerShell-like?

The conversation goes something like this…

You can do the same thing in Windows PowerShell more than a dozen different ways, and that is bad for noobies because they learn bad habits. And although their code might work now, later when they need to do xyz, it will not be very effective, and they will have to learn a different technique.

And your point is?

The thing is that the reason Windows PowerShell is so flexible, is so that you can work the way that you want to work. You can quickly come up to speed writing Windows PowerShell code in the manner that you like.

For example, I have seen Windows PowerShell scripts that were basically .NET C# code, but it was written using Windows PowerShell syntax—so instead of calling Get-Date, the writer used [System.DateTime]::Now.

Is there anything wrong with that? Not really. If the Windows PowerShell script runs without errors, guess what? It is a Windows PowerShell script. You may not be taking advantage of all the neat things that Windows PowerShell has to offer, but it is a Windows PowerShell script.

I have also seen Windows PowerShell scripts that were basically VBScript script, but it was written in Windows PowerShell. And once again, the script worked. It ran without errors—but yeah, they could have leveraged the Windows PowerShell advantage.

I have also seen Windows PowerShell scripts that were basically C++ code, and they called the Win32 APIs. Sometimes they were doing things that could not be done any other way. Other times, I think they were just experimenting—or maybe that is the way they like to write code. Who knows…

There are people who seem to insist on using WMI to access the registry, instead of using the Windows PowerShell registry provider, and others who insist on using .NET registry classes to read the registry. I have even seen some people use the VBScript RegRead and RegWrite to do the same. You know what? If it works for you, that is cool with me.

Can’t learn everything at once

We learn by doing. So if you come to a complete halt and start over, it will take you several weeks before you can begin to do anything in Windows PowerShell. Or, if you take a class, you will be out for at least a week. Some places run so lean, that they can’t afford that level of disruption. So Windows PowerShell makes it easy to transition.

You learn a few minor syntax things, learn a few concepts, and immediately you are becoming productive. You will, hopefully, begin to learn new things each week, and add to your level of Windows PowerShell knowledge.

Now, what about the standard argument that a noobie will run into problems trying to do new things in the old way? Well, that is what I call a teachable moment. Maybe before learning “the Windows PowerShell way of doing things,” the noobie thought it was simply syntax changes. But when the noobie finds out there is a reason or a real advantage to learning a more PowerShell-centric method of doing things, he will move forward.

So many PowerShell advantages

Windows PowerShell offers many powerful features, and it continues to add to these features with every new release of the operating system and every iteration of Windows PowerShell. It is certainly possible to get away without these new features, but they do offer substantial advantages, and they can shorten your learning curve and increase your productivity. DSC is a major new example, but so are workflows, CIM, WINRM, and so on.

Writing as if Windows PowerShell is VBScript, C#, or C++misses a whole raft of new features that can make easier-to-read code and easier-to-write code.

So fire up the Windows PowerShell ISE and start writing. Whatever your style, whatever your technique, it is your code in the end, after all. You can learn all of the nuances of Windows PowerShell later.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Comments (3)

  1. David Johnson says:

    I’m "guilty" of the .net C# approach sometimes. My logic being if the get-date cmdlet is just a wrapper around [datetime]::Now, surely avoiding the wrapper is more efficient. I would hazard that sometimes that’s probably right, others not so.

    Other times, the raw method is just more flexible. There are things you can do by manual calculations with a stopwatch object than you can with measure-command. PS will gradually catch up, I’m sure. On the whole I agree though, it’s good to learn multiple ways
    of achieving the same end result as much as it is that there are multiple ways to achieve them; when one method doesn’t give you the result you want, you’ve always got multiple angles of back up attack

  2. Nazi G. says:

    NaPster 😉

Skip to main content