Jeffrey Snover and the Making of PowerShell
PowerShell’s origin story as Jeffrey Snover’s embattled project inside Microsoft prompts renewed debate over whether it ultimately delivered on its promise as a modern, object-oriented shell. Commenters highlight its strengths—deep Windows and Azure integration, rich pipelines, self-describing cmdlets, and access to .NET—while criticizing its quirks, performance issues, breaking changes, and awkward fit as both shell and scripting language. Many contrast it with Bash and Python, noting that PowerShell remains powerful but under-invested, with its broader potential constrained by Microsoft’s internal politics and the dominance of Unix-style tooling.
Origins and design goals
- PowerShell was created to make Windows server administration automatable in an environment where configuration is API‑driven, not file‑based.
- It drew inspiration from Korn shell, Perl, VMS DCL, and C#, with a focus on structured data, not text.
- Internally it faced strong resistance, demotions, and politics between Windows, .NET, and DevDiv teams.
Current state and Microsoft investment
- Several commenters feel PowerShell is no longer a priority at Microsoft, citing stalled features, deprecated modules (Azure/O365), and incomplete Graph API replacements.
- There are regressions and incompatibilities between Windows PowerShell 5.1 and modern PowerShell (7+). Some features vanished due to internal API/metadata fights.
- WinGet’s PowerShell integration exists but is considered awkward and poorly designed by some.
Strengths frequently praised
- Pipelines of typed objects instead of text; easy property access and conversion (CSV/JSON/XML).
- Rich, self‑describing cmdlets with consistent parameter parsing, auto‑completion, and “WhatIf/Confirm” simulation modes.
- Tight integration with Windows/.NET/COM and especially Azure; many Azure resources have strong PowerShell support.
- Good cross‑platform story (Windows, macOS, Linux) for some admins; useful REPL with introspection and aliases familiar to Unix users.
Pain points and design criticisms
- Verb‑Noun naming and verbose syntax; awkward interactive use compared to terse Unix shells.
- Surprising behaviors: automatic array flattening, difficulty piping raw bytes, quoting/escaping issues, single‑element arrays becoming scalars.
- Backward incompatibilities, execution policies, and constrained language mode cause deployment headaches.
- Interop with legacy Windows tools (batch files) and external commands can be brittle.
- Some modules (networking, Graph/Azure coverage, Winget) are incomplete or poorly aligned with PowerShell idioms.
Comparisons and alternatives
- Many prefer Bash or other *sh for quick, text‑glue tasks and ubiquity, despite its own pitfalls; others find Bash unmaintainable beyond small scripts.
- Several have moved to Python for cloud/APIs and data work, treating PowerShell mainly as Windows glue.
- Some use PowerShell happily as primary shell on non‑Windows; others find it powerful but too complex to “stick.”
- Nushell is mentioned as an object‑pipeline shell influenced by PowerShell but less powerful; C# scripting and other REPLs appeal to some instead.
Other themes
- Desire for first‑party GUI, charting, and data‑science‑friendly cmdlets to make PowerShell a better tool for business analysts.
- Mixed experiences with Azure CLI vs Az PowerShell; REST APIs exist but are seen as under‑documented.
- Multiple comments praise the interview itself but find the auto‑generated transcript hard to read.