为什么有人觉得Windows比macOS更适合编程？

macOS

隔壁的 macOS 系统内置了不少编程语言环境，说实话，这对我来说还挺麻烦的，甚至觉得还不如 Windows 什么都不内置来得干净利落。例如，macOS 自带了 Python 和 Ruby，我这台 MBP M2 上的 Python 是 3.9 版本，Ruby 是 2.6 版本。由于 macOS 的许多内置组件依赖于这些语言环境，因此我们基本上无法替换掉这些内置的版本。即使通过 Homebrew 安装最新版的 Python 和 Ruby，也不会自动覆盖系统自带的版本。所以，对于 Python 和 Ruby，我分别使用 pyenv 和 rbenv 来管理它们的版本——尽管实际上我根本没有在系统上管理多个 Python 版本的需求。不过，把 pyenv 的配置写入 ~/.zshrc 文件有时也不靠谱。有些软件完全不理会你在 ~/.zshrc 中的设置，总是以某种奇妙的方式莫名其妙地调用到系统自带的那个 Python 环境中去。我真的希望在这种情况下，如果找不到指定的 Python 环境就直接报错，而不是回退到系统自带的版本上去。而 Windows 方面就没有这样的问题，因为 Windows 系统本身并没有预置 Python。此外，macOS 还有一套独特的 Java 支持机制。虽然系统并不自带 Java，但也不能通过 Homebrew 一键安装。目前，我也只能像处理 Python 和 Ruby 那样，借助 jenv 来管理系统中安装的 Java 环境。而且，由于 macOS 自身的这套 Java 支持机制更为复杂，管理起来也更加曲折。Clang 的情况同样如此。系统自带的是 Clang 15，但对于 C++ 20 标准库的支持还不够全面，导致一些代码无法成功编译。每次编译时，我都不得不明确指定通过 Homebrew 安装的那个较新的 LLVM 路径。相比之下，macOS 的情况还算好些，毕竟现在还有一些 linux 发行版仍然内置着 Python 2.7，那才是真正让人头疼的问题。而且，在各种 linux 系统上的软件开发过程中，还需要考虑系统内置的 GCC 和 CMake 到底是什么版本。而在 Windows 上，事情就简单多了——开发者可以直接告诉你最低支持的 GCC 和 CMake 版本是多少，反正这些都是用户自己安装的，责任自然也在用户身上。再来说说 Windows 内置 Visual Studio 的情况。刚开始的第一年，你可能会觉得系统自带的编译工具实在太方便了；但到了第二年，你就会开始嫌弃系统自带的版本太旧了，甚至觉得不如没有，然后上网搜索如何替换掉 Windows 自带的 Visual Studio？最后跑到 Stack Overflow 上寻找高赞答案并尝试解决问题。