为什么Windows不内置Perl，Python等编程语言环境？
程序员文章站
2022-04-12 08:17:53
...
OS X和绝大部分Linux发行版都内置Python，Perl，Ruby等编程语言环境，无论是对开发者还是普通用户都是好事，开发者在写程序的时候会有很多选择，不用担心目标机器上没有这一种语言环境而寻找替代，用户也可以拿过去直接运行；运维人员在大规模部署一些脚本的时候也可以省心很多。
为什么微软却不这样做呢？是怕威胁到自家推的产品吗？
PS：微软自家的Script Center里也有Perl和Python的分类。
Powershell, VB Script, SQL and JavaScript
而 Mac OS X 和 Linux 默认安装这些语言肯定是有原因的。有的可能是其他软件的依赖，比如 GNOME 桌面就非常依赖 python。一些服务软件依赖 perl，而 FreeBSD 一个流行的包管理系统就依赖 ruby 等。
反观 windows，这个系统根本没有这些需求。不安装也在情理之中。（FreeBSD 这一点倒是和 windows 类似） 要是Windows内置了Python，你现在写程序的时候，照顾Vista你只用兼容到Python 2.5，还要还考虑XP，你连Python 2.1甚至Python 1.6都要兼容。 Windows 也内置了很多编程环境啊
VBScript
PowerShell
这些都是啊，只不过都是微软自家出品 Ubuntu虽然自带了python，却连C/C++的基本编译环境都没有，码农安装之后第一件事儿就是安装build-essential。
这说明了，Ubuntu自带python，不是让用户写脚本用的，而是因为系统里很多模块是需要运行在python环境里。
（Ubuntu软件中心就依赖于python，就因为它依赖2.7，导致我想系统默认使用2.6都难，可我偏偏有一些2.6的pyc程序需要运行，你知道有多别扭么？）
显然，Windows就不用。
=========
Linux发行版、Mac OS，讲究的是包管理，模块分离，版本依赖。当你需要安装某个软件，相关依赖的底层模块会被自动安装。
Windows讲究的是一个完整的安装包，除了微软自己的.Net Framework、Direct X等通用底层平台外，绝大部分软件都是将自己需要的模块打包在一起安装。
以上这两种模式，都不需要预先安装一堆各种编程语言底层平台（目标机器上有没有啊，大规模部署怎么办啊）。这可以说是从不同方向探索出来的两套可行方案。
=========
Linux发行版、Mac OS，其平台上的软件很多来自于社区贡献，所以难免基于多种语言。
Windows都是微软自己开发的，底层平台统一，这是它的优势。 Windows跟Linux是两个不同风格的体系。
Win：简单易用，但是开发上略显粗犷。重视简单操作。
Linux：开源化、多元化。CGI还是很常用的，不可避免地需要各种功能强大的脚本类或者shell类脚本。
相比之下，我觉得Windows提供的更多的是“整机”。而Linux提供的更多的是“零部件”。而出于这个原因，Linux下面也就需要各种“加工厂”（也就是Perl啊Python啊之类的了）。当然，各有各的好处。整机对使用者的要求更多的是如何去操作，而加工厂则要求使用者学会一定的设计才能够得心应手。后者的起点会高一些，但是达到一定层级之后，Linux下一个使用者则会明显感觉到自己的*度会很高。
说道为什么不内置，那其实原因也很简单了。日常中需要完成的大部分操作应该已经有存在的软件了，小部分的循环性操作，批处理也差不多搞定了。偶尔遇到一个开发，一般的IDE也可以搞定了，makefile什么的也就不一样了。
从微软的利益角度考虑来看的，那就不只是这些了。如果内置了这么多东西，让大家都去使用这些工具，接受Unix思想的洗礼，那么微软的生态环境以及产品还如何更好推广呢？
差不多了，我觉得我考虑的就是这些。 主要是因为内置了也没人用……而且自己去下载一个安装包安装也不是什么难事…… Windows 带了 ScriptHost 呀，直接上 VBS 或者 JS 就是了。呀，您就喜欢 perl/python ？M$ 不喜欢行不行？ 其实我也不确定，猜的。
1. 系统面向群体，windows本来就是面向普罗大众，Perl和Python这些语言，除了增加系统体积，完全没用。如果是工程师，安装起来也很简单吧。
2. 系统内核，Win 系统一向只附带自己的产品，从内核到外部所有的东西都是Microsoft自家的，加上这些开源的语言，同时是个闭源的系统，实在别扭。Linux等等本身就偏Geek，同时这些语言也是优先在这个平台上产生，也是开源软件，基因相同。
以上，可能都是错的。 因为Windows是GUI系统。而GUI应用基本都是用C API（Windows API）和.NET API开发的 @李遥 提到了 GUI，挺对。
但我以为，问题的实(cao)质(dian)还能进一步——
因为 Windows 的 GUI 做不到家，于是想方设法要和「命令行」划清界线。
PS：微软自家的Script Center里也有Perl和Python的分类。
Powershell, VB Script, SQL and JavaScript
回复内容：
其中一个原因是需求吧。比如说 FreeBSD 系统曾经把 perl 默认安装，作为系统级别的组件。后来因为种种原因又把 perl 剔出系统，用 awk 做了个替代。因此，现在默认安装最新版的 FreeBSD 里面没有 python，也没有 perl 更别提 ruby 了。而 Mac OS X 和 Linux 默认安装这些语言肯定是有原因的。有的可能是其他软件的依赖，比如 GNOME 桌面就非常依赖 python。一些服务软件依赖 perl，而 FreeBSD 一个流行的包管理系统就依赖 ruby 等。
反观 windows，这个系统根本没有这些需求。不安装也在情理之中。（FreeBSD 这一点倒是和 windows 类似） 要是Windows内置了Python，你现在写程序的时候，照顾Vista你只用兼容到Python 2.5，还要还考虑XP，你连Python 2.1甚至Python 1.6都要兼容。 Windows 也内置了很多编程环境啊
VBScript
PowerShell
这些都是啊，只不过都是微软自家出品 Ubuntu虽然自带了python，却连C/C++的基本编译环境都没有，码农安装之后第一件事儿就是安装build-essential。
这说明了，Ubuntu自带python，不是让用户写脚本用的，而是因为系统里很多模块是需要运行在python环境里。
（Ubuntu软件中心就依赖于python，就因为它依赖2.7，导致我想系统默认使用2.6都难，可我偏偏有一些2.6的pyc程序需要运行，你知道有多别扭么？）
显然，Windows就不用。
=========
Linux发行版、Mac OS，讲究的是包管理，模块分离，版本依赖。当你需要安装某个软件，相关依赖的底层模块会被自动安装。
Windows讲究的是一个完整的安装包，除了微软自己的.Net Framework、Direct X等通用底层平台外，绝大部分软件都是将自己需要的模块打包在一起安装。
以上这两种模式，都不需要预先安装一堆各种编程语言底层平台（目标机器上有没有啊，大规模部署怎么办啊）。这可以说是从不同方向探索出来的两套可行方案。
=========
Linux发行版、Mac OS，其平台上的软件很多来自于社区贡献，所以难免基于多种语言。
Windows都是微软自己开发的，底层平台统一，这是它的优势。 Windows跟Linux是两个不同风格的体系。
Win：简单易用，但是开发上略显粗犷。重视简单操作。
Linux：开源化、多元化。CGI还是很常用的，不可避免地需要各种功能强大的脚本类或者shell类脚本。
相比之下，我觉得Windows提供的更多的是“整机”。而Linux提供的更多的是“零部件”。而出于这个原因，Linux下面也就需要各种“加工厂”（也就是Perl啊Python啊之类的了）。当然，各有各的好处。整机对使用者的要求更多的是如何去操作，而加工厂则要求使用者学会一定的设计才能够得心应手。后者的起点会高一些，但是达到一定层级之后，Linux下一个使用者则会明显感觉到自己的*度会很高。
说道为什么不内置，那其实原因也很简单了。日常中需要完成的大部分操作应该已经有存在的软件了，小部分的循环性操作，批处理也差不多搞定了。偶尔遇到一个开发，一般的IDE也可以搞定了，makefile什么的也就不一样了。
从微软的利益角度考虑来看的，那就不只是这些了。如果内置了这么多东西，让大家都去使用这些工具，接受Unix思想的洗礼，那么微软的生态环境以及产品还如何更好推广呢？
差不多了，我觉得我考虑的就是这些。 主要是因为内置了也没人用……而且自己去下载一个安装包安装也不是什么难事…… Windows 带了 ScriptHost 呀，直接上 VBS 或者 JS 就是了。呀，您就喜欢 perl/python ？M$ 不喜欢行不行？ 其实我也不确定，猜的。
1. 系统面向群体，windows本来就是面向普罗大众，Perl和Python这些语言，除了增加系统体积，完全没用。如果是工程师，安装起来也很简单吧。
2. 系统内核，Win 系统一向只附带自己的产品，从内核到外部所有的东西都是Microsoft自家的，加上这些开源的语言，同时是个闭源的系统，实在别扭。Linux等等本身就偏Geek，同时这些语言也是优先在这个平台上产生，也是开源软件，基因相同。
以上，可能都是错的。 因为Windows是GUI系统。而GUI应用基本都是用C API（Windows API）和.NET API开发的 @李遥 提到了 GUI，挺对。
但我以为，问题的实(cao)质(dian)还能进一步——
因为 Windows 的 GUI 做不到家，于是想方设法要和「命令行」划清界线。