How VBScript's Friction Produced PowerShell's Object Pipeline

If you started in the cloud era, infrastructure as code is JSON, HCL and YAML: declare a state, and the provider makes it so. In the Windows environments I managed in the early 2000s, state wasn’t declared. It was coerced, one script at a time, and the language was VBScript.

My claim: VBScript’s friction is what produced PowerShell’s object pipeline, and the same friction is what moved cloud tooling from imperative scripts to declarative templates. The history is worth a few minutes because it predicts what the next tool will fix.

On Error Resume Next

In 2003, mapping a printer by security group or reading the BIOS version of 500 servers had no command. It had Notepad, and a .vbs file run by Windows Script Host.

VBScript had no safety rails. The line that opened most production scripts was:

On Error Resume Next

It tells the interpreter to ignore any failing line and carry on. Distributed systems talk about failing fast; a VBScript failed silently and left the system in whatever state the last successful line produced. Nobody wrote it out of carelessness. Without it, one missing printer stopped that user’s logon script at that line, and every mapping after it was skipped. Structured error handling in VBScript was awkward enough that swallowing errors was the pragmatic choice.

WMI as the engine, VBScript as the crank

The lasting legacy of that era isn’t VBScript’s syntax. It’s that VBScript was how a generation of administrators met WMI, Windows Management Instrumentation, Microsoft’s implementation of the DMTF’s WBEM standard. WMI exposed the operating system as a queryable database: disks, services and processes as rows, with a SQL-like language to select them.

The database was good. The interface to it was this:

' Free space per logical disk
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_LogicalDisk")

For Each objItem in colItems
    Wscript.Echo "Disk: " & objItem.Name & " Free Space: " & objItem.FreeSpace
Next

Seven lines to read one property, and every line is ceremony: a COM moniker, a query string, a loop and string concatenation to print. The verbosity forced administrators to learn loops, variable types and COM objects, which is the one thing VBScript did for the profession. It was a high barrier, and it separated the people who clicked from the people who scripted.

From parsing text to passing objects

Every VBScript that read another program’s output parsed text. Jeffrey Snover’s Monad Manifesto (2002), the design document behind PowerShell 1.0 (2006), names that practice as the problem. Text output is a contract nobody declared, so a script is coupled to the exact formatting of whatever it reads. When “Free Space” became “FreeSpace”, the script broke.

PowerShell separated the data from its presentation. The same query, in the modern cmdlet:

# Objects, not text
Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID, FreeSpace

Side by side, the two snippets show a change of model, not of syntax. VBScript was imperative: you told the computer how to connect, how to iterate and how to print. PowerShell is declarative at the call site: you ask for the object and the pipeline handles the rest. Formatting happens once, at the end, by a formatter that knows the object’s type.

Why this matters for cloud work

Cloud tooling made the same move, a decade later. The first generation of AWS automation was imperative scripts around the CLI: create an instance, wait, attach a volume, tag it. CloudFormation (2011) and Terraform (2014) replaced that with a declared end state and an engine that computes the steps.

VBScript was the imperative-scripts phase of Windows administration. It was hard to debug and didn’t scale past the person who wrote it. It was also necessary: it’s how administration got from the GUI to anything automated at all, and the pain of it is what made the next model’s advantages legible.

What would change my mind

The argument rests on one causal claim: that text-parsing friction, not some other pressure, is what produced the object pipeline. The Monad Manifesto supports it in Snover’s own words, which is the best evidence available short of the design meetings. The account could be a retrospective tidying of decisions made for other reasons, such as .NET adoption inside Microsoft. If it is, the lineage still holds but the lesson doesn’t.

I still keep a folder of old .vbs scripts. I do not run them. They are a record of what the tooling cost before someone decided the cost was the problem. The next time a CloudFormation template takes an afternoon to debug, the alternative was On Error Resume Next.