Jeffrey Snover and the Making of PowerShell

Original Article ↗ Hacker News Discussion ↗

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.