Simple things should be simple, complex things should be possible

Simple things should be simple, complex things should be possible.

这句话是 PowerShell 创始人 Jeffrey Snover 在《Monad Manifesto》（2002年）中提出的核心设计原则，也是理解整个 PowerShell 语言哲学的钥匙。

📖 字面含义

简单的事情应该简单做，复杂的事情应该有可能做到。

它反对两种极端：

• ❌ 过度简化：为了"易用"而阉割能力，导致复杂任务无法完成（如传统 CMD/Batch）
• ❌ 过度工程：为了"强大"而让简单操作也变得繁琐（如直接写 C# 代码来管理服务器）

🔍 在 PowerShell 中的具体体现

层级	"Simple things should be simple"	"Complex things should be possible"
文件操作	Get-ChildItem *.log	[System.IO.File]::ReadAllLines() + LINQ 过滤
进程管理	Stop-Process notepad	[System.Diagnostics.Process]::GetCurrentProcess().Modules
网络请求	Invoke-RestMethod https://api.example.com	[System.Net.WebRequest]::DefaultWebProxy = ... （你原始代码的场景）
类型系统	$x = 42 （自动推断为 int）	[int[]]$arr = [System.Linq.Enumerable]::Range(1,100)
学习曲线	不需要懂 .NET 就能用	需要时可以无缝下沉到完整 .NET API

💡 与你之前问题的关联

回到方括号 [...] 的设计：

• "Simple things should be simple" → 日常使用中，用户完全不需要写方括号。Get-Process | Where CPU -gt 100 没有任何类型语法，简洁如传统 Shell。
• "Complex things should be possible" → 当环境变量不够用、需要设置 .NET 运行时级代理时，[System.Net.WebRequest]::DefaultWebProxy = ... 这扇门始终敞开，且语法明确、无歧义。

方括号的"奇怪感"恰恰是这个原则的视觉化身：它在说"你现在离开了简单区域，进入了复杂能力的领域"。如果设计者把类型语法做得和命令调用一样"自然"，反而会模糊这条边界，让简单事情变复杂（因为解析器要不断猜测意图），也让复杂事情变困难（因为歧义导致不可靠）。

🌍 更广的背景

这句话其实是对计算机科学史上反复出现的 "简易性 vs 完备性"张力 的回应：

• Unix 哲学偏向"simple"：每个工具只做一件事，但组合复杂任务时需要大量胶水代码
• Java/.NET 企业开发偏向"possible"：什么都能做，但删除一个文件可能要写十几行代码
• PowerShell 的定位：作为管理自动化 Shell，必须同时服务两类人——偶尔敲命令的运维新手 + 编写千行自动化脚本的 SRE 工程师

Snover 的原话还有后半句常被忽略：

"Simple things should be simple, complex things should be possible, and impossible things should take a little longer."

最后这句幽默地承认了语言的边界：PowerShell 不是万能的，但它确保你在触及边界之前，不会被人为的设计缺陷提前挡住。

📌 一句话总结

这不是空洞的口号，而是一个可验证的工程约束：PowerShell 的每一处语法设计都可以用这个原则来检验——如果某个简单操作需要写三行代码，或者某个必要的高级功能找不到入口，那就是设计失败。方括号语法通过了这个检验，所以存活了 20 年。