还原论为何那么有吸引力？因为还原论符合人类自然科学直觉。任何形式的系统论都带有人为的、有意的一种建构，这种建构完全无法解释任何时间任何范围的一切事物。本质上来说系统论是一种模拟，是对物质世界的粗糙的仿制，人类从未能够完美无缺的复现真实世界。More is different，系统论最终都不可能真正的再现。
还原论却是对物质世界最直接的抽离，它不接受任何特殊性，也不应该有任何特殊性，因为那意味着物理法则在时空的不均匀，意味着真理并不存在，系统论的建构更是笑话。还原论如同真实世界那样无视人类的一切，它是非符号学的、非政治的，仅仅只是存在着，这也符合人类经历科学革命的集体心智。
在这无火的时代，堕落于大啖黑暗而腐败了身体，真是愚蠢的事
祛魅已久，该返魅了
「人生苦短，远离 windows 脚本」
windows 的命令行让我饱受折磨。
自身的 cmd/bat 核心功能很残废，难以进行复杂的编程，没有数组，没有字典，没有类，没有模块。我见过的绝大多数脚本（包括各种著名开源项目），最常用的是简单使用 if 语句，就连函数都很少用，无论脚本有多长。至于说自己实现这些功能，比如数组，看上去简单，你可以试一试，相信我，你最后会放弃的。
powershell 看上去不错，核心功能勉强合格了，面向对象是有了，但基础功能弱，加上缺少第三方模块、文档（无论中英文，人们更多用简陋的 cmd/bat），导致虽然理论上可能实现功能，但实际写起来效率奇慢，写几行就得 Google 一下文档。显然这不现实，有这功夫，我干嘛不用 python 或 shell，还能跨平台。
于是我尝试用 python 代替 bat/cmd/ps1 脚本。得益于 python 良好的生态与跨平台性，以及方便的交互式设计，脚本写起来很轻松，绝大多数功能调包完事……如果不调用外部命令或进程的话。无论使用 subprocess 模块还是 os 模块，结果取决于 windows 底层设计，往往是预料之外的，比如 args 你在 shell 上测试没问题，可通过脚本传递时却抛出从没见过的 error；比如传递的参数带有特殊字符，CLI 中用引号就能解决的事在脚本中变得难以发觉及处理；再比如返回的标准输出格式千奇百怪，有用 bytes 的、有用 unicode 的、有用 utf-8 的、有用 gbk 的，总之需要手动、显式处理编码问题……以上种种导致调试效率低下，虽然没有 bat 折磨，但还是痛苦。
最后 shell……在 windows 上实属玄学，尤其是在脚本中调用 shell。直接调用 .sh 脚本会报错，因为 windows 不内置 shell 解释器，你得手动指定，比如你可以通过 git 自带的 sh.exe 或 bash.exe 打开。然后你会见到全新的报错，因为 sh.exe 始终只是模拟，底层还是 windows 内核，运气好可以正常运行，运气差就可以见到各种玄学报错。
你是否可以想象， subprocess.run(args=['sh.exe', '-c', xxxxxxx]) 与 subprocess.run(args=['bash.exe', '-c', xxxxxxx]) 是完全不同的效果？有时 sh.exe 无法执行，有时 bash.exe 执行了却是不同效果？
你是否能想象，subprocess 调用 bash.exe 与直接在 bash.exe -l 命令行中手动执行命令，二者是完全不同的效果？
你是否能想象，直接运行 .sh 文件又是全新的 效果 报错？
哦对了，sh.exe bash.exe start 返回的输出可能是不同编码哟~
……
一句话，
只要足够中二，三次元就追不上我
还原论为何那么有吸引力？因为还原论符合人类自然科学直觉。任何形式的系统论都带有人为的、有意的一种建构，这种建构完全无法解释任何时间任何范围的一切事物。本质上来说系统论是一种模拟，是对物质世界的粗糙的仿制，人类从未能够完美无缺的复现真实世界。More is different，系统论最终都不可能真正的再现。
还原论却是对物质世界最直接的抽离，它不接受任何特殊性，也不应该有任何特殊性，因为那意味着物理法则在时空的不均匀，意味着真理并不存在，系统论的建构更是笑话。还原论如同真实世界那样无视人类的一切，它是非符号学的、非政治的，仅仅只是存在着，这也符合人类经历科学革命的集体心智。
世界 #贝萨因都在这无火的时代，堕落于大啖黑暗而腐败了身体，真是愚蠢的事
祛魅已久，该返魅了
「人生苦短，远离 windows 脚本」
电脑windows 的命令行让我饱受折磨。
自身的 cmd/bat 核心功能很残废，难以进行复杂的编程，没有数组，没有字典，没有类，没有模块。我见过的绝大多数脚本（包括各种著名开源项目），最常用的是简单使用 if 语句，就连函数都很少用，无论脚本有多长。至于说自己实现这些功能，比如数组，看上去简单，你可以试一试，相信我，你最后会放弃的。
powershell 看上去不错，核心功能勉强合格了，面向对象是有了，但基础功能弱，加上缺少第三方模块、文档（无论中英文，人们更多用简陋的 cmd/bat），导致虽然理论上可能实现功能，但实际写起来效率奇慢，写几行就得 Google 一下文档。显然这不现实，有这功夫，我干嘛不用 python 或 shell，还能跨平台。
于是我尝试用 python 代替 bat/cmd/ps1 脚本。得益于 python 良好的生态与跨平台性，以及方便的交互式设计，脚本写起来很轻松，绝大多数功能调包完事……如果不调用外部命令或进程的话。无论使用 subprocess 模块还是 os 模块，结果取决于 windows 底层设计，往往是预料之外的，比如 args 你在 shell 上测试没问题，可通过脚本传递时却抛出从没见过的 error；比如传递的参数带有特殊字符，CLI 中用引号就能解决的事在脚本中变得难以发觉及处理；再比如返回的标准输出格式千奇百怪，有用 bytes 的、有用 unicode 的、有用 utf-8 的、有用 gbk 的，总之需要手动、显式处理编码问题……以上种种导致调试效率低下，虽然没有 bat 折磨，但还是痛苦。
最后 shell……在 windows 上实属玄学，尤其是在脚本中调用 shell。直接调用 .sh 脚本会报错，因为 windows 不内置 shell 解释器，你得手动指定，比如你可以通过 git 自带的 sh.exe 或 bash.exe 打开。然后你会见到全新的报错，因为 sh.exe 始终只是模拟，底层还是 windows 内核，运气好可以正常运行，运气差就可以见到各种玄学报错。
你是否可以想象， subprocess.run(args=['sh.exe', '-c', xxxxxxx]) 与 subprocess.run(args=['bash.exe', '-c', xxxxxxx]) 是完全不同的效果？有时 sh.exe 无法执行，有时 bash.exe 执行了却是不同效果？
你是否能想象，subprocess 调用 bash.exe 与直接在 bash.exe -l 命令行中手动执行命令，二者是完全不同的效果？
你是否能想象，直接运行 .sh 文件又是全新的 效果 报错？
哦对了，sh.exe bash.exe start 返回的输出可能是不同编码哟~
……
一句话，
「人生苦短，远离 windows 脚本」
只要足够中二，三次元就追不上我