Why do I have thoughts about this? Why do I share them with you? Because I’ve been writing code since 1988, and I’m a cranky old bastard. It’s been said that I taught Moses how to work with COBOL.
Anyhow. I like PowerShell. At first I didn’t. I viewed it as yet another shiny, bouncing ball, latest fad, cool hipster thing. Then I actually read a book or two, figured out how to use it to work with XML, ADO.NET and WMI and I was rubbing my ugly chin and making “hmmm” sounds a lot. Then came WMF 5 and I was ready. I’m still on the fence about the significance of the language, with regards to the orbiting of planets and curing cancer. My hunch is that sometime around 2020, Microsoft will do as it’s always done: replace it with something shinier. But until then…
So, what’s this “pipeline” stuff, anyway?
There’s basically two (2) general ways to stick your PowerShell code together. People have different names, but I refer to them as “stacked” and “pipeline”. Stacked is the relatively familiar, old-fashioned, method of writing code in a functional paradigm, whereby each general statement of logic is performed on its own distinct line. Pipeline code is glued together in a line, whereby the result of each subset of code is fed directly into the next, from left-to-right, using a “pipe” or “|” character to delineate the mediation point. This is the pipe in the pipeline.
I prefer stacking my code if it involves more than what will fit on a single line. That’s just me. My illogical brain follows the old guideline for modularity, wherein any repeat of more than a line of code needs to be a defined function call. And more often than not, the scripts I write have a lot of lines and things get reused. I don’t feel repeating a pipeline is good structure, but again, that’s just me.
Before you argue that VBScript allows you to serialize code processing using the colon (:) separator, that’s not true pipeline processing. The : separator is really a semi-linefeed indicator.
Dim something : Set something = CreateObject(“Foo.Bar”)
is the same as …
Set something = CreateObject(“Foo.Bar”)
I’ve helped quite a few people learn to read and write script code in various languages. Notice I don’t say “teach“? That’s because I don’t want to teach, as much as offer a path and encourage the person to follow it on their own. Because “teach” infers a sense of guided instruction; brainwashing. I don’t want other people adopting my habits, good or bad. They need to adhere to general “best practices”, but beyond that, they have to figure out their own path to the Matrix. “Best practices” may seem nefariously nebulous (whatever the &&#& that means), but I’m simply referring to documenting, commenting, indenting, and all that mumbo-jumbo. How they prefer to document and comment is their own choice.
It’s like showing someone how to set up a camping tent, versus going out in the woods with them so you can set up the tent for them every time.
Back to the blabbering…
When they stare at something like this (below), I can see their minds melting down and I can almost hear the heart muscle straining to keep up with the adrenaline rush that comes with panic.
(Get-WmiObject -Namespace root\cimv2 -Class Win32_ComputerSystem | Select-Object Model).Model
Then after I break it down by subset, they start to nod as their eyes widen and they start offering more free food favors.
$m = Get-WmiObject -NameSpace root\cimv2 -Class Win32_ComputerSystem
They enter $m and press return. They view the output and start to see the data structure behind it all. Then I show them how to fish out one piece from the bucket…
After all that, THEN I show them the pipeline example and it starts to make sense.
Basically, in my humble, meaningless, insignificant, arcane opinion, starting out with pipeline examples for inexperienced programmers is bad. Just bad. It seems to break the model we’ve all absorbed from Algebra classes, where we get a glimpse of polynomials, but then immediately get to work on breaking them down from the inside out.