FrankHB

@dcsuibian @idealhs 想简单了，powershell 和 pwsh 微妙不兼容，测试版本都烦。而且在 Windows 上 COMSPEC 默认仍然是 cmd ，用 native 语言互操作几乎不可能可靠测试（就算无视 cmd 这玩意儿 UCRT fallback 都是写死的问题）。虽然其它 shell 也有版本和兼容性问题，但测试起来明显简单。
这还不说得多学不同的东西。虽然学语言不难，但受限还是个性价比问题：没能明显更好地满足需求为什么非得学不同的？凭空多出兼容性包袱。
更糟糕的问题我上面早就提过：跨平台项目同时用多种 shell ，凭空多出来 powershell 特供的 bug ，还得用户倒霉。
@iorilu 相信我，至少目前 bash 跨平台总体成本比 powershell 低得多，无非 Windows/macOS 用户得多安装个运行时而已，这是只有一次性的部署代价。而且你 powershell 想要用不过时的特性就是 Windows 都一样得另外装 pwsh ，明显比 bash 吃亏。虽然传统 shell 写起来确实更恶心但就算 pwsh 也不是都省事，要干活比 powershell 熟练工好找多了，怕翻车至少也有 ShellCheck 。

@PTLin 多几种其实不是直接问题。上古的 cons pair 限制个别元素就能造出 list monad ，用比较现代一点的说法，决定限制的 unit predicate 是 null?；中古一点的 string 同样也是个 monad ，unit pred 是 string-null? 。其实吧，传统数学上 list 和 string 可以就是一回事。那为什么不嫌弃 string 和 list 共存冗余呢？因为 string 好歹有复杂度 hint 表明适合不同场景（激进一点的还有 encoding 甚至 SSO 之类的假设，但把本属于 text 的东西混同 string 有过度设计的问题，这又是另一回事了）。这个意义上 string 是具有更多实现假设的 list 又确实不都能替代 string ，这种不同层次上的冗余适应新的需求，其实不难接受。
问题是引入的目的和过程。新增的抽象如果没有提供更详细的假设提升到接口的含义，而仅仅是为了给不完善的旧有抽象擦屁股，但被擦屁股的东西又因为兼容性之类的原因没法被彻底替代而只能共存，这样缝合的下场自然不会让用户舒服了。
为什么说 null 是多余的呢？因为 nullable type 历史上本来就是实现偷懒（ null pointer ）的结果上反向臆造的抽象。要从需求侧讲，没什么和 Maybe 区分的必要，反倒是传统实现习惯（比如死板的错误处理）导致使用者体验很尴尬。相比之下，C++一样也有 optional<T&>不能随便和 T*等价的历史包袱，这里思想包袱就体现得更明显，因为 nullptr 并没有 Java 一样被迫弄得到处都是的存在感，兼容性问题本该不是借口。

@lisongeee null 就是个阉割版的 Optional ，而且明显更祖宗。
Optional 本身本来也不是太大的问题（起码回避起来比起无处不在的 null 来说容易多了），问题是 null 这祖宗干不掉，又另外加上 Optional ，本该是同一种目的凭空多出来不同的不兼容的表达方式乃至于扭曲目的本身（不顾历史，强行为现状洗地而寻找不同的用例场合），混起来效果就很感人了。

没有明显低估或者高估，市场反应大抵是合理的。
学习性价比偏低。对已经会用传统 shell 的正经用户可能还会多赠烦恼。
https://www.v2ex.com/t/838173#r_11433315

既然把能被 AI 替代的程序员单独拎出来说，那是挺丢人的。
能被所有人容忍的 bug 通常来自需求分析不充分和设计缺陷，让只能负责个别阶段的工程师严格避免这类 bug （比如通过形式化方法）的确可能是比较困难的。
而单纯转化设计到实现阶段的体力活冒失引起的 bug 就不配相提并论。单纯程序员身份引起的 bug 都属于此类。
虽然原文坐着好像也没这个自觉——程序员当然不可能是被 AI 最后代替的。
奇怪的是，有很多人明明干着比程序员高级复杂的工作，偏偏自贬身份，何苦呢？被 AI 还是 leader pua 惯了？

看你对成功的定义。
你似乎只在乎商业市场？
然而产品是否成功，并不一定看“市场”的反馈，因为产品服务的用户不来自市场。
一般地，能解决真实需求的实际问题的产品就是好产品。我写的代码有不少用于我日常工作效率提升，就算产品规格稀烂，那也不是失败的。而且因为没有产品和销售职能的额外成本，成功得比商业产品更加纯粹。
如果你非得认为你只能作为产品的生产者而不能同时是享受产品好处的消费者，那你可能不得不失败。