讨论：为什么Python能胜出？
某些语言明明远胜Python，却因其外观略胜Perl而永远无法获得Python曾拥有的机遇
我最近重温了2021年的一期播客，其中讨论了Python不可思议的崛起。
我记得早期围绕Python的积极评价，与其说是Python本身的优势，不如说是Perl语言的强大之处——但Perl终究是Perl。Python作为Perl的优雅精简版，既继承了Perl的所有赞誉，又享有“没有Perl缺陷”的美誉。如今回想起来，Python本应立足自身价值，而非仅仅作为“更优秀的Perl”存在，然而现实就是如此。我认为事后看来，我们本该更深入地审视Python的缺陷。Lisp开发者们早已洞悉这些问题，可惜无人倾听。如今Python已成为全球最主流的编程语言，而Perl几乎被世人遗忘。
若观察当下语言生态，某些语言明明远胜Python，却因其外观略胜Perl而永远无法获得Python曾拥有的机遇——这在我看来荒谬至极。
1. Python的设计过程是通过让新手用户测试语法来验证其易用性[1]。当前超过90%的Python用户在语言诞生时尚未出生。他们都经历过学习过程，而Python之所以成为最易学的语言，是因为Guido及其团队与某些“语言设计之神”不同，他们以实验科学家的态度而非艺术家的姿态解决问题。
2. Python 概念精炼，核心是基于字符串键的哈希表。生态系统早期领头羊 Perl 则概念臃肿，难以推演。
3. Python 还借鉴了 Unix shell 的设计，这种成熟环境既能包容新手也能满足专家需求。
4. Python 从早期就建立了规范的 C 模块集成流程。
5. Python管理层采用优雅的剪切层结构，使创意能从任何渠道渗透进来。
6. $NEXT_GENERAL_PURPOSE_LANG(Ruby、Go)并未足够优秀到取代Python。二者虽深受Python语法影响，却忽视了孕育该语法的社区导向设计流程，转而奉行“我们最懂”的自负态度。
7. 谈及开源创业精神，JavaScript因Web(及Node)崛起成为真正劲敌，却受制于相反的失败模式：Go由少数谷歌人主导，而JavaScript在关键十年间标准库层面实质无人管理，如今已难挽颓势。(我猜想，要在混乱的Web客户端与Unix世界中同时构建高效模块系统，本身就是个令人望而生畏的设计难题。)
8. Python因数据科学的兴起而幸运地获得发展机遇。
[1] https://ospo.gwu.edu/python-wasnt-built-day-origin-story-wor…
我漏了两个，呃，三个：
9. Python 走运的是，其必然的失误(Python3)并未彻底扼杀它。
10. Swift 和 Kotlin 都将编程定义为服务于编译器(具体指 LLVM)，而非服务于开发者的问题。(此前未讨论Rust是因为它不试图与Python的98%用例竞争，但若仔细观察，可发现它比Swift和Kotlin更进一步——实质上迫使程序员成为某种人类编译器，以类型和内存管理思维进行思考。顺便说一句，这并非对Rust的批评。)
0. 这一切背后支撑着摩尔定律与程序员人口的爆炸式增长。Python本质上是种隐性赌注——若能体贴地服务用户，与当代硅基硬件需求的权衡便不再那么重要。
我对此念念不忘。以Perl为例，两位竞争者都采用了Unix shell模式的做法令人着迷。Python至今仍因无法自动抓取环境变量等特性而受限。但Perl则极力拥抱TECO式的乱码风格和正则表达式这种元语法，让初学者直面任意复杂性。沃尔似乎拥抱了编程中系统管理员的维度——那个需要极强能力追踪边界案例、管理阻抗失配的维度。沃尔的语言学训练或许并非偶然，毕竟在该领域大陆事实至关重要。而圭多则是成就斐然的数学家。(这正是《密码学典》中矮人与精灵的差异。)
Guido van Rossum并非杰出数学家。他拥有数学与计算机科学双硕士学位，并在国际数学奥林匹克竞赛中获得铜牌，但前者源于当时计算机科学在数学系授课，后者则因其高中时期便展现出非凡才智。
正如他所描述：
"但大学第一年后，我发现真正的数学并非我的强项。虽然那所大学有杰出的教师和超酷的教学内容，但我跟不上进度。记得有次涉及某种群论形式的课程，当时我和其他几位同学都意识到——‘哦，你们该转学图论或群论了’。而我只能看着课程飞速推进，突然意识到自己缺乏掌握这些知识的技能。但与此同时，从进入数学系的第一个月起，我就开始学习编程——因为他们开设的本科一年级课程中，有一门是Pascal编程课。"
引自《Guido van Rossum口述历史》https://www.computerhistory.org/collections/catalog/10273871…
感谢指正。我本应使用“受过训练”的表述。
我认为“训练有素”的表述同样不够准确。
他在阿姆斯特丹大学攻读计算机科学学位时，该校的计算机科学专业还隶属于数学系。他还曾在自由大学修读计算机课程，当时两校有协议允许学生在任意一所学校选课。
他既没学过群论或图论，对数学也毫无兴趣。相反，他选修的是计算机课程：
数学系不得不“根据他的情况对学位进行些许调整”。
没有任何迹象表明他接受过数学家训练——既非接受过数学研究训练，也未受过将数学应用于其他问题的训练。
我拥有数学学士学位，修读过纯数学和应用数学方向的课程，但即便刚毕业时，我也不敢说自己受过数学家训练。
Kotlin设计之初完全没有考虑LLVM，该特性是后期才添加的。Kotlin的主要目标始终是JVM。Kotlin从诞生之初就以易用性为核心设计理念，这正是其存在的价值所在。说Kotlin将编程定义为服务于编译器未免奇怪——恰恰相反，编译器会竭尽全力服务用户。
感谢指正
Rust与其说是与Python“竞争”，不如说是“互补”。这恰如Python早期被定位为“C语言的脚本语言”的初衷。
Python程序中低效部分可重写为Rust或C实现，选择权在您手中。这种设计理念令人耳目一新。
于我而言，这正是早期Python最强大的特质：谦逊。
它不妄图满足所有人群(新手、中级、专家、学者)的所有需求(高性能、编译时静态类型)。
而是通过与现有优秀解决方案协同工作，轻松解决关键需求(如最高性能的热代码)。
能否详细说明 Ruby 如何刻意回避以社区为中心的设计流程？
Ruby的语法兼具易用性与强大功能，而Matz明确将开发者幸福感作为设计目标。
我认为若今天重新设计#1，绝无可能采用空格作为代码块标记。
当我解答新手代码失效问题时，这绝对是最常见的自掘坟墓式错误。
我的专业背景是语言哲学，研究生阶段研习过形式逻辑与数学逻辑。虽然计算机科学课程教授的语言对我这种背景的人来说也晦涩难懂——其语法过度依赖数学术语和面向对象等技术概念(当时很可能是Java)——但我始终为自己不会编程而感到羞愧。
2010年左右，我向朋友倾诉这般挫败感，他建议：“试试Python吧，听说它很受非数学背景的人欢迎。”我买来书本，翻开瞬间便能流畅阅读。虽然花了几天才理解面向对象概念，但在函数式编程方面，我翻开书半小时就能写出“fizz buzz”程序。
人类大脑天生具备逻辑思维能力，只是我们用自然语言作为语法载体。Python巧妙地尽可能采用自然语言语法，为非数学专业人士消除了学习障碍。空格机制正是自然语言语法特性的完美体现。
空格机制实则是Python的主要缺陷之一。该特性赋予了非打印字符语法意义。从人类角度看，沉默往往蕴含深意；但从工程学角度审视，这种设计理念堪称疯狂。沟通必须明确且刻意为之。
还记得苹果SSL漏洞“goto fail”吗？那正是空格漏洞的典型——尽管C语言的空格特性早于Python存在，但当Python普及后，人们的审视目光早已习惯性地忽略这种粗鄙的捷径。
>沟通必须积极且刻意。
我不明白这句话的含义。
空格问题实际上是Python的主要缺陷之一。该特性赋予了非打印字符语法意义。从人类角度看，沉默往往蕴含某种深意。但从工程角度看，这种设计方法简直荒谬至极。
这并非非打印字符的问题，而是对齐方式的差异。句点在编程中相当于分号，用于标记单元终结；而Python中的空白符则类似于项目符号或诗歌诗节，二者都以原子语句的形式与Python形成对应关系。
多数人关注的是悬挂缩进。我认为我们能有效证明：悬挂缩进比花括号更贴近自然语言。只需搜索“手写食谱”，你就会发现——在自然语言的组合练习中(这本质上是编程的现实对应)——人类在归类子项时会自然采用悬挂缩进。
https://duckduckgo.com/?q=handwritten+recipes&iar=images
这是否类似于数学书中晦涩的数学术语？并非如此。但这种表达方式源于现实世界中人类的自然思维，且在语法上并无形式错误。因此我们很可能发现，外行人能直观理解悬挂缩进，而大括号作为语法则属于专业术语范畴，需要刻意学习。
空格作为不可打印字符的功能差异微乎其微，除非存在文本编辑器在使用空格时无法呈现偏移空白的情况。
空格与制表符之争，这确实值得讨论。
但主张“{文本编辑器中可见的符号}与其他字符本质不同”似乎缺乏合理性。
Python又不是在使用ASCII铃声字符之类的东西。
我认为这与Python无关。在接触Python之前，我曾在C++中因第二行缩进却未加花括号而遭遇大量’if’语句错误。调试过程总是痛苦不堪。最终我养成了_永远_为’if’代码块添加花括号的习惯——无论单行或多行——从此再未重蹈覆辙。问题根源在于C语言允许单行省略花括号；这种设计本应强制要求每次都添加花括号。
Python的执行逻辑与语法读取方式一致，我认为这是个积极特性。它彻底杜绝了C语言那种跨行if语句块的错误。
> 当我解答新手关于代码失效的问题时，这绝对是最常见的自掘坟墓式错误。
根据我的经验，在Python 3严格规范缩进格式之前确实如此； 在
SyntaxError报错机制改进之前(例如对无except的try块的处理)；在VSCode普及之前(那时新手们用着天知道什么乱七八糟的编辑器，每次都要费劲揣摩他们如何生成缩进，甚至不确定是否能转换制表符)。更奇怪的是，在大型语言模型出现之前。倒不是因为它们能解释得特别透彻，而是因为那些懒惰又不懂技术的家伙现在能直接生成正确缩进的代码，不必再从Stack Overflow复制粘贴后，还搞不懂如何让代码对齐。
但如今我更常看到的是这样的人：他们连REPL和命令行都分不清(“为什么
pip install ...会报语法错误？”)，或是苦苦挣扎于Python团队最新推出的Windows安装管理方案，甚至完全无法理解Python必须知道代码在磁盘上的具体位置。会报语法错误？”)，或是苦苦挣扎于Python团队最新推出的Windows安装管理方案，又或是完全无法理解Python需要知道磁盘上安装库的位置(以及为何不能直接把所有东西扔进系统环境变量)。至于语言本身，最大的绊脚石莫过于命令查询分离(“为什么不能写成foo.append(bar).append(baz)？”)以及正确使用函数(通常归结为“为什么return foo会导致调用函数中无法引用foo`？” 但实际表述往往截然不同)。空格规范只是问题的一部分。更严重的是代码块结尾不可见的问题，这导致以下后果：
1. 难以向初学者口头描述代码块的结束位置，只能通过指点来确认。
2. 那些容易在闭合代码块时误用“}”或“end”标记数量的学生，反而会错误地缩进或缩进不足。这种错误无法像括号错配那样被有效预防。
3. 关闭代码块时，你试图与之前代码块对齐的内容可能已不在屏幕上。原因不明，但我发现嵌套代码块关闭后出现的间距偏差错误远超预期。
话虽如此，我毫不怀疑Python选择空格分块是基于实践经验得出的。但我强烈怀疑，80年代末至90年代初学习编程的大多数用户都熟悉等宽字体——这种字体当时在绝大多数办公软件中无处不在，因此更便于他们理解逻辑。
需要明确的是，我其实并不特别在意Python的空格块机制。虽然我不喜欢这种设计，但到了我这个年纪，纠结语法细节已显得小题大做——况且Python始终是我快速完成任务的首选“瑞士军刀”语言。我的核心观点是：空格块是开发时代的产物，其初学者友好性远不及宣传所言。
编辑：稍作沉淀后，我意识到在理想状态下，初学者语言更应接近Lua而非Python。但随即想起Roblox的火爆程度，以及此前Garry’s Mod的盛况。这些平台的成功或许印证了某种设计理念。
#1 使Python成为最易读的语言，这可能比格式化带来的些许麻烦更重要。
此前讨论：
– Perl的衰落源于文化因素 – https://news.ycombinator.com/item?id=46175112 – 2025年12月 (460条评论)
– (!) 问HN：Python为何胜出？ – https://news.ycombinator.com/item?id=37308747 – 2023年8月 (839条评论)
– 问HN：为什么Python在机器学习/数据科学领域如此受欢迎？ – https://news.ycombinator.com/item?id=16207834 – 2018年1月 (19条评论)
– Ask HN：Python是否正在衰落？ – https://news.ycombinator.com/item?id=11100251 – 2016年2月(352条评论)
– Python已成为美国顶尖大学最受欢迎的入门语言 – https://news.ycombinator.com/item?id=8001337 – 2014年7月(362条评论)
– Ask HN：为何选择Python而非Ruby？ – https://news.ycombinator.com/item?id=682101 – 2009年7月(196条评论)
– Ask HN：Ruby有哪些Python不具备的优势？ – https://news.ycombinator.com/item?id=283639 – 2008年8月(223条评论)
这根本不算“难以解释”……尤其当你把它和Perl这种以难以阅读著称的语言相比时。
* Python拥有简洁易读的语法，完全的新手也能理解——它非常接近教学中使用的伪代码。
* Python拥有优秀的标准库，因此在需要安装更多库之前就能完成大量工作(且抛开可重复性问题不谈，一旦需要安装，
pip install确实非常简单)* 正因其易学易教的特性，Python在学术统计/数据分析等领域占据了特定市场——这些领域从业者并非专业程序员，只需能快速拼凑出解决方案的工具。自NumPy问世后，人们几乎没有理由再另寻他法。
(此处应插入玛吉·辛普森“我就是觉得它很酷”的动图。)
> 一种以难以阅读著称的语言。
这还算客气的说法。Perl在这方面被调侃过无数次，但
却是能有效检索文件名行段的Perl程序。有人戏称这是种“只写不读”的语言——这玩笑还算半真半假。几个月后面对毫无注释的魔法变量堆，天啊。反观Python，若采用描述性函数变量命名，短脚本甚至几乎无需注释。
Perl的败笔在于：当你三年后重返那团Perl泥浆修复漏洞时——由于缺乏类系统且Perl 6永远延期——等待你的绝非愉悦体验。Python虽不完美(正因如此才发展出类型系统)，但Perl某些时刻确实堪称“只写不读”的典范。
每位合格的程序员都必须掌握高效工具的使用，并突破初级至中级水平的局限——这已成为我们行业永恒的生存法则。
绝不该耗费整天用Python编写可通过vim宏五分钟完成的工作，更不该用Python耗时一年实现Perl一周就能完成的任务。
>> $=$/;for(@ARGV){open F,$_;while(<F>){print if/$_/}}
掌握Perl单行模式后，你将省下数十人小时的Python/Java编码工作量。
记得在Perl时代跟经理说过：一个有十年Java经验的人看起来很厉害，但其实相当于有半年经验的初级Perl开发者。
浪费精力更重要的是浪费时间，没什么值得得意的。
我断断续续用Perl单行命令已有20年，正因为不用每天用，每次都要查资料。
不确定你的省时方案是否真正有效，尤其当99%的问题都无法用Perl单行命令解决时。
>>不确定你的省时方案是否真正有效，尤其当99%的问题都无法用Perl单行命令解决时。
这恰恰说明：若缺乏思维范式，就难以找到真正适用的工具。
我见过太多Java程序员目瞪口呆的场景——他们耗费40多小时完成的“每周项目”，本质上不过是个vim宏，用vim三五分钟就能搞定。
这正是我所强调的核心观点：当Java开发者自诩拥有十年经验时，其实力仅相当于初级Perl开发者。
我猜大多数Python/Java程序员根本无法胜任不涉及数据库、XML或JSON的项目。这些语言的设计初衷，就是局限于处理特定数据格式和计算范式。
这可能是我在HN上读过最愚蠢的评论。根本不存在使用Perl是正确选择的场景。正如他人戏称的那样，它是个“只写不读”的语言。你用Perl写的垃圾代码对其他人来说完全不可读，而当你转战新项目后，18个月后再回来调试旧代码时，连自己都看不懂。你以为用Perl写单行命令和微型脚本很聪明，其实是在破坏团队。我真心认为，明知如此还坚持用Perl的人该被开除——他们提交代码到组织仓库的瞬间，就成了累赘的技术债务，主动损害团队和组织利益。
真正的项目要用真正的语言，这样才能让除你之外的人参与协作和维护。
>>正如他人戏称，这根本是种“只写不读”的语言。
你为替代那行Perl代码而写的个人项目，同样注定成为“写完就弃”的产物。区别仅在于：你耗费数年光阴完成的事，我们几分钟就能搞定。
做些本可省略的无谓之事，浪费生命毫无值得炫耀之处。
浪费精力更重要的是浪费时间，这没什么值得自豪的。
正因如此，你提到的任务正被交由大型语言模型处理——它们根本不在乎目标语言是什么。
> 纵观当今语言生态，某种语言可能远胜Python，却因恰好比Perl稍显美观就永远错失Python曾有的机遇。这在我看来荒谬至极。
你难以理解Python的成功，是因为你认定它成功的主因是比Perl更漂亮，无法理解这点就足够了。但这远远不够。Python的成功源于多重因素。
我直觉认为它成功在于逃避了严格审查。虽然我听过CL圈对这门语言的诸多批评，但外界更乐于接受这种改良版Perl——它能将C代码粘合为实用应用和脚本。
恕我直言，Lisp开发者恐怕不是探讨如何打造主流语言的最佳人选。
无论如何，你完全复述了我的观点。你的直觉认为Python只是比Perl稍优的替代品——这至多是单维度认知。若无法拓宽视野，那么本帖中关于Python流行原因的诸多实例与论据都将与你失之交臂。
既然如此确信自己的判断，何必还来提问？
> 我的直觉是它成功是因为逃避了审查。
基本上所有语言在成功前都逃避着审查——除了极少数利基领域(通常是那些对其他语言深信不疑、根本不考虑替代方案，却批评所有非首选语言的人)。因为语言数量庞大，在达到临界点前，没人愿意花时间去审查它们。
但Python战胜其他语言并非如此。
> 逃避审查。
还有什么比人们长期用它编写大型项目更能体现审查力度的呢？
没错，人们需要的是无需耗费大量时间学习的粘合语言。Python完美契合这点。
> 我的直觉是它正因逃避了审视才得以成功。
你总这么说，但2000到2010年间，它究竟逃过了哪些审查？
你是说当大学用Python取代Java/C++作为入门课程时，他们只是掷骰子选的语言？
你是说那些不断宣称“Python永远无法拥有CPAN的强大功能”的Perl程序员根本不存在？
难道埃里克·雷蒙德从未撰文赞颂Python的优点？
我大约在2000年学习Python时年仅17岁。
它读写起来相当轻松，意外情况极少，能轻松编写简单程序。“电池已装好”的设计理念令人赞叹。
它仿佛由精明实干者为实用编程设计，而非执着于纯粹优雅的学术天才所创。它容忍些许瑕疵，却将它们安置在符合人体工学的角落。
它由懂得权衡取舍的设计者打造——将map、filter、reduce从内置函数移至库文件。尽管我个人偏爱map(并非极端反对函数式编程)，但更欣赏设计者追求更长但更明确的代码风格。
尽管我对这个具体决策颇有微词，但毫无疑问它确实能降低处理简单/常见任务时的认知负担。
若将这两行代码展示给学习过几个月Java但未接触过Python的CS101学生，我敢肯定他们会更快理解第一行。如此高度一致的设计决策造就了符合人体工学的实用语言。他们赢了。
它更契合人类思维模式。参见PyTorch与TensorFlow的对比。
因为鲜少有人像GvR那样重视语法设计。即便如今有人发布新编程语言，多数人仍会追问其功能特性、运行速度、包管理器效率等——这些都是简单的是非题。而语法设计选择则不然。
即便有人提及语法设计，常被轻描淡写地否定：“语法不重要”。Python却反其道而行，将语法置于首位。这种理念俘获了初学者，造就了今日局面。
当然人工智能让Python更受欢迎，但早在ChatGPT问世前它已占据主导地位。
我认为Python胜出的关键在于其易学易读的特性，以及“电池已装好”的设计理念。相较之下，Perl让用户陷入语法斗争而非解决实际问题。
网络效应同样至关重要——使用者越多，吸引新用户的门槛就越低。
Python的“电池已装好”理念体现在标准库中——在那个时代，将这类功能纳入标准库确实合理。
如今却有大量功能被视为禁忌而不敢移除，若非既成事实，开发者根本不敢考虑添加。(不信的话，去discuss.python.org看看新增功能的提案就知道了。人们总以为Python是不断新增改动、导致兼容性问题的语言，但相较于提案数量，其实它相当保守。)
>>我认为Python胜出的关键在于易学易读且自带电池。
这也正是AI辅助编程将全面取代Python程序员的重要原因。
若你专为终生停留在初级水平的人群优化，却取代了那些用专业工具解决复杂难题的人，那么如今被自动化取代也就不足为奇了。
Perl本就具备“电池包含”特性，还有CPAN库。Python借鉴了Perl的精华，却因声誉掩盖了诸多缺陷。若它曾像Perl那样被严格审视，我们早该发现它同样糟糕，只是问题表现形式不同。
这毫无道理…Python在问世时就曾遭受严苛审视——“Perl vs Python”的比较曾风靡一时，胜负判定全凭作者立场。
若真存在多年来被忽视的Perl压倒Python的致命优势，何不直接提出论据？更理想的是撰写博客详述Perl优于Python之处，这样我们就能围绕具体论点展开讨论，而非空泛地谈论“不同方式”。
Perl曾有其魅力，黑客们敬重它能为“懂它的人”带来乐趣。它至今仍是门优美的语言，我因自以为品味高雅而错过学习机会深感遗憾。Python则毫无这种魅力。至今仍不解它如何胜出——窃取了语言的光环却毫无真才实学。依我之见，你们唯一能辩护的理由不过是“无趣即优越”。
曾尝试转投Ruby却最终选择Python的Perl黑客在此：
当然无趣才是上策。怎么可能不是呢？当你试图解决问题时，最不想考虑的就是语言本身。
你用来编写解决方案的语言应当迫使你清晰思考，但仅此而已。可执行的伪代码，才是高级语言能达到的理想状态。
与此同时，Perl却充斥着多种实现方式——这种荒谬的特性竟被奉为美德——沉溺于副作用，并在变量与流程中暗藏诸多隐含操作，导致代码常令他人难以理解，甚至连三个月后的你自己都难以解读。
“Python实现了其他脚本语言的所有功能，却以更简洁易懂的方式呈现”这句话道出了Python胜出的关键，而致命一击来自Perl社区对复杂性的迷恋——这最终催生了灾难性的Raku语言。
进入新世纪之际，Python 3显然比Perl 6更具未来前景。
基本正确，但
> 进入新世纪之际，Python 3 已被公认为比 Perl 6 更具前瞻性的规划。
Python 3 开发计划直至 2006 年才正式公布，而 Perl 6 早在 2000 年就已启动。
> 它因能给“懂它的人”带来乐趣而受到黑客推崇
这不正是问题的核心吗？对“懂它”的黑客而言Perl固然出色，但对其余95%的人群来说Python更实用。
Lisp/Scheme对’懂它的人’同样美妙。
> 我至今不解它如何胜出——窃取语言的光环却毫无真才实学。
许多人已给出答案。95%的程序员编程只为完成任务。二十年前我认识的语言学研究生用Python写代码，只因它简单(他毫无编程背景)。若没有Python，他只会改写论文主题，绝不会去学Perl。
Perl属于极客，Python属于大众。
> 这不正是问题的核心吗？对领悟其精髓的极客而言，Perl堪称完美；而对其余95%的人群来说，Python更实用。
但这并非核心问题。“比Perl更适合普通开发者”的门槛其实不高。多数语言都能轻松跨越，无论它们是否成功。Python的成功绝非仅因如此。
顺带一提，根据我的经验，Perl 擅长处理单行代码和小规模粘合项目。即便在广泛使用 Perl 的公司(雅虎)工作时，我也从未见过用 Perl 构建出真正重要且有价值的代码。我确信 Perl 的魅力更多在于其巧妙的设计，而非在大项目中的实用性。
> “对普通开发者而言优于Perl”并非高标准。多数语言都能轻松达到这个门槛，无论它们是否成功。
若将时钟拨回2002年，此论断便不成立。Perl的流行并非源于其优雅，而是因其作为高效粘合剂的特性——它能用极少代码完成大量工作。
当时唯一的主流替代方案是Python。
明白了。这里存在两个独立但相关的问题：
1. 为何Python取代了Perl？
2. 为何Python能如此风靡？
第一个问题的答案在于：对众多工程师而言，它在多数场景下确实优于Perl。第二个问题的答案则更为复杂。
你开这个帖子，莫非就是为了找人附和你的偏见？
如果是这样，没错。Perl很美。Python很烂，它之所以成功，只是因为蠢开发者看不懂Perl的美。除了抢走潜在的Perl开发者，Python在任何任务上都表现拙劣。
现在心情好些了吗？
没有。
可读性、明确性、单一实现方式都是优秀设计理念的体现。Perl恰恰与这些背道而驰。
我不认同“语法胜出”的说法。Python同样丑陋，强制缩进的设计就像yaml。
我更看重生态系统——尤其是计算机视觉和机器学习领域广泛采用Python作为前端语言(重型计算仍用C++完成)。numpy库的普及同样为该语言带来了海量应用场景。
缩进本就是编程规范，如今更被格式检查工具强制执行——这类工具在多数生态中已是开箱即用的标配(如gofmt)。
既然99%的场景都存在缩进，何不赋予其语法意义？
初时确实感觉怪异，但坦白说习惯后便不会多想。
> 别相信“语法优势”的说法。Python同样丑陋——强制缩进的设计，就像yaml一样。
这纯属个人观点。Python的设计初衷就是易于学习，大量借鉴了ABC原则——该原则曾通过实验不同语法来验证可行方案。缩进机制显然对此大有裨益，在引入缩进代码块之前，冒号分隔符也起到了类似作用。
这种看似“丑陋”的强制缩进和空格规则，反而让Python更易于阅读——尤其对新手和休闲程序员而言。标准化的视觉结构与接近可执行伪代码的语法，大幅降低了入门门槛，使Python显得“平易近人”。这种易用性认知进一步强化了前人提及的网络效应。
关键不在于美丑，而在于简洁。
Python 简单易读易写，更便于理解推理，尤其适合需要编程语言解决问题却非软件工程师的人群。
它之所以胜出——特别是在数据分析领域——是因为多数数据分析师并非软件工程师，Python 对他们而言更符合直觉。
使用优质文本编辑器时，缩进并非大问题
> Python同样丑陋，因其强制缩进，如同yaml.
YAML在配置文件领域同样胜出的事实，难道不值得你深思？
> Python同样丑陋，源于强制缩进
难道不是因为强制缩进？毕竟所有写过代码的人都习惯性地缩进啊？
> 更看重生态系统，特别是计算机视觉和机器学习领域对Python的广泛采用
先有鸡还是先有蛋？
接触Python 2之前我几乎没碰过代码，始终觉得缩进和换行既美观又实用。其实YAML也是如此。我认为对缩进等偏好纯属后天习得。
即便对使用过多种语言的人来说，Python也完全没问题。比起学术圈偏爱的Lisp类语言，它美观得多。
“丑陋”这个评价太主观了。我个人觉得完全没问题，Python强制缩进的特性恰好符合我的编程习惯。这对我而言和项目通过gofmt之类工具检查缩进没什么区别。
强制缩进极大简化了普通用户在其他语言中遇到的可读性问题。
过去想用简单接口完成任务的人根本无从下手。
我认为围绕Python缩进的争议反而助推了它的成功。无论你如何看待这个选择，它都为无谓争论提供了绝佳机会，并持续激发了大量关于该语言的讨论。
人们提出了各种各样的论点，但坦率地说，我无法理解为何有人觉得基于缩进的代码块语法“丑陋”，而替代方案却不觉得丑陋。我不禁怀疑这种审美是否会延伸到不缩进大括号语言的代码。
Python在代码可读性方面完胜。
Perl实现相同功能的方式五花八门，不同代码库几乎判若两语——简直像在写不同语言。当年编写Perl时，我曾翻阅几年前写的脚本，因其中处处错误而恼火——短短数年间我的Perl风格已发生巨变。而他人脚本更是不堪入目！
更何况Python拥有诸多提升日常脚本编写效率的实用特性。例如真正的函数参数、异常处理(再也不用在每次文件打开后写“or die”)、庞大的标准库(我绝对不怀念在每台新机器上配置“cpan”的日子)、内置的repr()函数等等。
诚然，Python确实有些幸运——当时市场需要“比Perl更易读、对新手更友好的语言”，而Python恰好填补了这个空白。如今这个需求窗口已然关闭，新语言更难填补这个空白。但这正是语言生态的常态——Rust填补了“无C++开销却内存安全”的空白，Go填补了“带GC的编译型系统语言”的空白等等。一旦语言流行起来，网络效应就会发挥作用。
> 事后看来，Python本应立足自身价值，而非仅仅作为更优秀的Perl存在，但现实就是如此。
它确实做到了。只是最初的立足点并非如此。Python历经多次关键突破才达到今日地位。“早期阶段”绝非启动不可逆转的引擎。数据科学、机器学习等领域的后续推动才真正奠定基础——即便Perl 6发展得再好，这些领域也极可能永远不会触及Perl。
> 事后看来，我们本应更深入地审视Python的缺陷。
问题很多。我个人觉得许多常见的争议点其实并不重要，而大家却忽视了更严重的问题。但事情就是这样。所有流行语言都存在类似情况。“虽然实用性胜过纯粹性。”
> 我知道Lisp程序员注意到了这些问题，但没人听他们的。
说真的，Lisp对其他语言的编程方式产生了巨大的隐性影响。《计算机程序的构造与解释》是部革命性著作。只是当你不需要元编程时——这种情况占绝大多数——同构性其实用处不大；而且当代码结构没有用各种标点符号(而非仅括号)明确标记时，人类反而更难理解。
> 纵观当今语言生态，某些语言明明比Python优秀得多，却因外观略胜Perl而永远无法获得Python那样的机遇。这在我看来荒谬至极。
这属于人生不公的范畴。若你心中有打造Python杀手级替代品的构想，我仍鼓励你全力以赴。
完全正确。
但同时：
> 事实证明，在绝大多数不需要元编程的场景中，同构性并无太大价值。
元编程如同其他技术，存在多个层次。对于浅层需求，Python的反射机制、魔法方法和元类已足够应对，无需过度纠结。
老实说我觉得元类都用得过头了，很多时候类装饰器就足够了。
这话有道理，但存在几个原因：
– 承认吧，装饰器语法确实有点丑
– 历史因素。装饰器语法是新事物
– 对于需要反复派生子类的场景，元类能自动跟上
但维护者查看装饰类时，几乎肯定更容易理解其工作原理。
多年前我曾撰写过相关文章：https://www.notonlycode.org/why-python-has-won/
简而言之(以下均为个人观点)：它在学术界广受欢迎并获得部分企业采用，因此当机器学习爆发式流行时，它自然成为机器学习工具的脚本语言首选。此外它易于上手且是通用语言——诸如pandas等大量科学工具、Web框架等皆以它为基础。
Perl因过于古怪难以广泛普及且停止开发(Raku/Perl 6耗时过长)，PHP专注于Web领域，JS亦然。Ruby本有机会胜出——我个人更偏爱它——但除日本外它主要与Web开发关联(因Rails框架)，且缺乏Python已有的丰富库资源。
> Ruby本可胜出，
似乎不太可能。它本身就继承了不少Perl式的怪癖。
它是由品味出众的个人设计而非委员会制定的。仅此而已，优秀设计语言脱颖而出绝非偶然或难以解释。
过多提及Perl很奇怪——它和PHP才是糟糕品味的典型代表。这些语言之所以流行，纯粹因为当时恰好可用，而非自身优秀。
公平地说，据我所知PHP在“零成本快速部署处理Web请求的简易语言”领域仍占主导地位。
当前风靡的“无服务器”架构(这个命名实属谬误)或许会改变现状，但我对Web技术了解有限，无法判断其发展态势。
Python的胜出源于2000年代初谷歌选择它而非Perl，宣称其更统一——提供单一推荐实现方式，而非像Perl那样允许程序员用无数种方法完成任务。
Perl之父Larry Wall曾提出“让简单的事更简单，让困难的事成为可能”的理念。但Perl简化的功能并非总是市场所需。Perl对企业规范持高度怀疑态度，其“让千花齐放”的文化理念(即“实现方式不止一种”/TMTOWTDI)对维护大型代码库/系统的组织而言并无实际价值——尤其当团队由技能水平参差的成员组成时。
Python则更有效地穿过了这根针——它成功集中了正确做事的方式(不仅限于空格规范)。
我还在所属组织中观察到Scala同样受困于失效的“TMTOWTDI”动态：不同成员解决基础问题时风格迥异，这使得代码难以维护，尤其在人员流动频繁、新成员不断加入的小型组织中更是如此。
此外，数据科学应用场景在某种程度上延长了Python在网络/脚本领域的生命周期，这与AI/CUDA技术延长NVIDIA以3D图形为核心的根基颇为相似。(尽管如今Python数据科学生态确实存在某些“通往目标的路径不止一条”的缺陷，这让我想起2000年代中期Perl/CPAN在网络开发框架选择上的困境！)
不能仅从软件工程师视角审视问题。相较于众多其他语言，普通人学习Python的门槛低得多——入门极其简单，几乎无需繁文缛节。它对用户错误高度包容，同时允许使用者随语言成长(没人会在入门首日就写出ABC程序)。
Python确实存在问题，但这些问题对不同人群和场景的影响程度各异。低门槛特性结合梅特卡夫定律，在我看来能解释很多现象。
我热爱Scheme语言，但并非人人如此，我也能理解这种差异。
> 不能仅从软件工程师的视角看待问题。
此言极是。
另一方面，某些人表现出的“真正的苏格兰人”心态——声称真正的程序员绝不会刻意使用Python——往往暴露了这种态度持有者的真实面目。
非软件工程师出身的传统工程师在此
Python易学且拥有庞大的库资源，线上支持也极其丰富。正因如此，过去工作中需要编写基础程序时我总选择它。
随着大型语言模型的兴起，Python更具吸引力——这些模型在编写Python代码方面表现尤为出色。
Python最终胜出源于其社区力量。
Python领导团队对初学者和非传统背景人士态度友好，并积极招募他们参与社区建设。这是我所知最不恶毒的开发者社区之一。
在数据科学或网络安全这类领域尤为重要——这些领域存在大量缺乏传统软件工程师背景的人才。
该语言使用体验舒适且代码可读性强，内置大量特性(Perl则缺乏这些)，但我认为这些都远不如以下网络效应关键：(1) 营造欢迎新人的友好社区氛围，(2) 积极招募跨领域人才。
我最近全面转向Python。此前仅在需要Pandas或numpy的项目中使用Python，Web应用则采用React/TypeScript/Node。但如今我已迁移至Django/HTMX。
主要原因在于规避npm，同时希望获得更多内置默认功能(我的Web应用需求简单)。这与语言本身无关——对我而言更关乎生态系统。
我曾考虑过Ruby/Rails，但它们似乎并未比Python更胜一筹，且无法替代我所需的Pandas功能。
就个人而言，我认为ALGOL家族中没有哪种语言的语法能超越Python。它几乎消除了所有冗余：繁文缛节、模板代码、大括号等等。程序员常将想法写成伪代码…而这些伪代码往往恰巧能直接转化为有效的Python代码！我认为这正是Python成功的关键原因——它兼具简单与强大。
编程语言存在网络效应。一旦语言流行起来，就会有更多人编写库和指南，进而推动其进一步普及。
假设你是宇宙沙皇能从零开始设计，是否能创造出更优的脚本语言？当然可以。但现实并非如此，况且Python在现有领域表现尚可，无需推倒重来。
仅供参考，纯属个人回忆。在编程的石器时代，有两种语言占据主流地位：Perl和Python。当然还有其他语言也曾风光一时(如REXX、Rebol等)。我认为Python之所以脱颖而出并形成发展势头，关键在于它能在Windows平台运行并与之深度集成——而许多当今资深开发者正是通过Windows平台初涉编程领域。尤其值得一提的是马克·哈蒙德的贡献。突然间，你拥有了一种既易于上手又与底层操作系统深度融合的语言。Perl在Unix系统上也有类似优势，但当时大多数急于求成的开发者并不使用Unix——毕竟那时的Linux远非今日之盛况。Perl在传统文件操作(及类文件任务)领域表现卓越，早期通过CGI技术在网页开发中占据独特优势。但在我看来，Python不仅整体门槛更低，实用性也超越Perl——且无需依赖C、C++等编译型语言。
三点说明：
1. 崛起期：2005 – 2010谷歌于2005年聘请了Guido van Rossum(任职七年)，公司高层的支持使团队顺利从Perl迁移至Python。当时Python被视为科学家和精英人士的语言，因此许多使用Fortran、MATLAB、Perl等各类语言的开发者纷纷转向Python。为解决速度问题，谷歌官方提出“能用Python就用Python，必须用C才用C”的口号。彼得·诺维格等人工智能领域重量级人物(他曾担任首席人工智能科学家，并合著了著名的《人工智能》一书)将Python推广为可接受的Lisp替代方案。
2. 濒死时刻：2010-2015年间，Python因从2版向3版迁移的自我伤害险些消亡，很可能像许多前辈语言那样销声匿迹。Guido也离开了谷歌，而谷歌似乎将重心转向了Golang(除标准的C++和Java外)。顺带一提，Python的统治地位并未获得谷歌内部认可，因此他们停止了积极推广。例如埃里克·施密特泄露的发言记录中提到：
https://gist.github.com/sleaze/bf74291b4072abadb0b4109da3da2…
3. 复兴：2015年至今数据科学与机器学习蓬勃发展，Python凭借谷歌的早期支持以及熟悉该语言的科学家工程师生态圈(包括双语言模式工作者)稳居前列。此时已无其他语言能与之抗衡。
语法设计、性能考量等因素实属次要，毕竟多数脚本语言只是调用C/C++/Fortran编写的强大库或封装Shell的工具。这些特性未必能解释Python为何能占据如此主导地位。
我对Python并无偏见，但仍坚持使用Perl 5——它能完美满足我的需求。
Perl 6重构计划早在2000年就宣布启动，却耗时二十年？Python固然优秀，但Perl 6的漫长开发周期让许多人望而却步。记得2019年它还更名为Raku。
因为使用体验实在令人愉悦。若你的项目允许使用Python——即能承受性能损失——几乎找不到不喜欢它的理由。Common Lisp功能完备，但人们总因括号结构望而却步。而Python确实能带给使用者纯粹的愉悦感。
其语法堪称最低公约数，让各行各业的人都能轻松上手。它几乎能胜任所有任务的“足够好”。
但本质上是谷歌、Dropbox等巨头造就的局面。这与Java走红的逻辑相同——即便语言本身不够完美，顶级企业的背书也难以撼动。
谷歌与Python确实经历过蜜月期。他们曾聘请Guido开发内部应用(据我所记得是Mondrian？) 。在“云计算”成为流行词之前，他们推出的初代App Engine平台仅支持Python。但后来谷歌默认的易学语言变成了Go——这种静态类型语言能杜绝大量编译时错误。甚至出现过宣言，宣称Python等动态类型语言不适合大规模软件工程。如今Python仅用于小规模代码开发。
支持预编译原生二进制包。以manylinux项目为例：https://github.com/pypa/manylinux，该项目历时十年确保glibc变更不会破坏python wheels。其他语言均需完整构建管道才能安装二进制扩展：例如node-gyp。即便在支持扩展的场景(如PECL)，语言与系统的兼容性也总是被视为次要考虑且规范不足。最终结果是：大多数语言“安全”安装二进制扩展的唯一途径是通过发行版或第三方仓库，而非包注册表。
一件略带趣味的往事：1990年代某年，我在研究生院实验室从事电磁仿真工作。显然代码必须高效运行，但实验室里有人想为实用主义的C语言仿真代码寻找一种粘合语言。
有人开始尝试Perl，后来他中途退学转行做了系统管理员。
有人开始尝试Tcl/Tk，后来他转专业投身用户界面/用户体验测试领域。
我则开始接触Python——当时版本大概是0.9.2之类的。历经波折后，我最终投身机器学习领域。
这其中有什么启示吗？大概没有，但我总觉得这段经历颇具趣味。
赢什么？
反对Perl？那已是十多年前的事了。十年前，唯一需要Perl的地方要么是硬核工程领域(即非程序员的电子工程师)，要么是那些拥有遗留代码库的项目。
比其他语言都强？当然不是。你不会用Python做系统级工作。
Python的问题微不足道(除了打包)，不足以让你为此改用其他语言。若真需要静态类型优势，已有成熟语言胜任此职(C++、Rust等)。
对多数人而言(包括部分Perl拥趸)，转向Python是显著的体验提升。如今若有人推荐比Python更优的语言，其优势也仅是渐进式改进。诚然我偏好F#这类函数式语言，但绝大多数人并非如此。
> 它看起来比Perl稍微美观些。这在我看来荒谬至极。
这并非荒谬，而是值得探讨的观点。我认为可读性对任何语言都是可取的品质，尤其关乎普及度。某些语言在这方面确实更胜一筹。
Python胜出关键在于强制空格规范。它解决了其他语言推给代码检查工具的社会问题，将可读性直接写入规范。
Python被视为Perl的替代品，主要因为它们常用于同类脚本场景。当时最大的差异(暂且不论实现方式的多样性)在于：新手看到20-50行的Python脚本时，无需查阅语言手册就能(感觉自己)理解其内容。对尚未系统学习该语言的人而言，这种一目了然的可读性意义重大。“可执行的伪代码”正是其精髓所在。
另有一点未见他处提及：对众多Python用户而言，阅读和编写代码是他们与该语言唯一的接触点。
从那些因未从虚拟环境起步而陷入全局Python包命名空间噩梦的开发者视角看，Python常遭诟病。这些批评有理有据，但对非开发者用户而言，这些问题属于他人范畴。考虑到本站读者群体…这些问题虽可能与我们相关，但我们并非Python的核心用户群体。我们只是为这些用户提供支持。
Python之所以成功，在于其受众并非代码专家，而是偶尔需要编程的其他领域专家。他们的工作往往具有我们工作中罕见的即时重要性。它的价值不在于技术人员是否喜欢，而在于科学家、分析师、学生以及{非计算机工程类}工程师是否认可。
> [虚拟环境中的冲突]很可能是我们面临的问题，但我们并非Python的直接用户群体。我们只是为这些用户提供支持。
或许？我的意思是，如果用户未察觉这些问题而你却发现了，他们如何依赖你的支持？
> 它之所以胜出，是因为其受众并非代码专家，而是偶尔需要编程的其他领域专家。他们的工作往往具有即时重要性，而我们的工作通常没有。它的价值不在于技术人员是否喜欢，而在于科学家、分析师、学生以及{非计算机工程}工程师是否认可。
界限并不清晰。我作为代码专家，将Python作为构建其他代码的工具。我从不遇到虚拟环境问题，因为我的Git仓库已包含所有必需组件。
具体来说，多位教授发现我在解决软件包相关问题上颇有建树，因此会主动联系我寻求帮助。他们认为若在工业界工作，遇到这类问题时只需提交工单，就会有人帮忙理清混乱局面。
此外，在之前的工作中，我也处理过这类工单(例如“为何安装此版本的foo会导致bar完全无法运行？”)。
其他人以不同方式提供支持。某数据中心负责堆叠GPU的员工，至少部分是在为那些用Python处理数据的专家提供支持。
当然，许多专家能独立完成工作，但更多人并非如此，他们依赖机构或其他形式的支持来处理这类事务。
这说得有道理，不过你描述的分工模式中，那些依赖你修复环境的人，若没有你，很可能自己就能解决问题。
我想我们都认同这些并非典型终端用户。
> 其他人以不同方式提供支持。某数据中心里负责堆叠GPU的员工，至少部分是在为那些操纵Python传输数据的专家提供支持。
这就像农民也在养活我。你打算如何划分界限？
从那些因未从一开始就使用虚拟环境而陷入困境的人们视角来看，Python常遭人诟病——如今他们的全局Python包命名空间已成噩梦。
在了解venvs之前，我从未经历过“噩梦”阶段。
但有时仍很享受拥有一个即用型环境：它装满热门且互不冲突的组件，供你在REPL中随心探索。
我一直好奇为何激活虚拟环境最终实现为通过source脚本(更新当前进程的环境变量)和deactivate脚本(恢复变量)的方式，而非创建子shell(检测当前shell并重新调用带新变量的shell)。
子shell能实现环境嵌套：先创建“正常默认环境”，再通过另一个“疯狂实验环境”深入探索，退出子shell即可回归正常状态。但实际情况是，停用操作会将环境直接还原至系统包命名空间(或许能实现嵌套，但不确定——恢复中间环境的责任在于虚拟环境实现而非操作系统)。
> 始终不解为何激活虚拟环境要通过源文件脚本实现(更新当前进程环境变量)，而停用时却要恢复原始变量，而非直接进入子shell(检测当前shell并重新调用带新变量的实例)。
虚拟环境本质上只是文件夹和Python脚本。
激活脚本的概念很可能只是Ian Bicking最先想到的方案。但或许在Windows上子shell的用户体验并不理想？
当然也有其他实现基于子shell的虚拟环境管理方案。
> 当前机制下，停用操作会将你完全带回系统包命名空间(或许可嵌套环境，但不确定——恢复中间环境的责任在于venv实现而非操作系统)。
效果无法嵌套，至少使用*sh激活脚本时如此。你需要实现环境变量设置的堆栈机制。
不过我认为你描述的使用场景确实难以引起多数人共鸣。
> 但我认为你描述的使用场景确实难以引起多数人共鸣。
嗯，我想“扁平优于嵌套”的理念确实深植于核心哲学。
我大概是个怪人吧。想到退出到根目录时，除了能进入某个或多个特殊临时环境外别无他物——这种感觉对我而言如此…纯粹。
另外，若不至少设置$PS1，就很难记住当前所在层级。
你可以配置direnv根据目录进入/退出启用/禁用环境，只要你的shell提示符显示当前工作目录，就能知道所在环境。将两种状态绑定后反而更省心。
Python胜出的部分原因在于其社区驱动特性。许多与之竞争的高级语言都出自某家科技巨头之手，但人们对这类语言的信任度较低——毕竟曾有先例表明它们会遭遇许可证变更等变故。
Python易读易写，网络效应成就了其余一切。
Perl6比Python3混乱得多。
我更惊讶于Ruby未能取得更好成绩。
> 我更惊讶于Ruby未能取得更好成绩。
正如你所言，
> 网络效应成就了其余一切。
在平行宇宙中，Ruby 占据着 Python 如今的位置，而你正疑惑 Python 为何未能腾飞。(但我猜想 Ruby 在那些情境下的演变路径截然不同。)两者皆受欢迎的宇宙实属罕见。
我认为难以归因于单一特性，语言成功的关键往往在于时代背景与定位(JavaScript便是绝佳例证)。
Python确实具备若干核心优势：
高度动态特性——无需精通所有细节即可上手(无编译步骤、无静态类型等)。
它未必在所有领域都最出色，但对多数场景都是不错的选择，因此成为理想的通用编程入门语言。
它与底层语言的良好互操作性——这对数据科学至关重要，因为非技术背景(从计算机科学角度看)的用户仍需C/Fortran/Rust等语言的性能支持。Python采用“作为其他语言库的高级API”模式(如numpy、pandas、polars、pytorch等库)，
这点近期尤为重要——Python正因此成为数据科学领域的事实标准语言。
大约30年前，编译器的零售价格从初学者的常规选择，变成了超出大多数初学者预算的昂贵商品。专业软件工程领域同样变得极其昂贵。这些变化中的第一点，使得Python对过去30年间尚未成为程序员的初学者群体产生了相对吸引力。第二个变化则让Python对所有领域专家产生了吸引力——这些专家所在的组织无论规模大小，其办公桌上都配备着计算机，但他们无法获得组织资助来开发理想中或想象中那种超级简单、易用且高价值的应用程序。这是必然趋势。
Perl是我90年代接触网页编程的起点，后来我转向了Python和PHP。
Perl 诡异的语法和众多相互冲突的“最佳实践”吓退了新手，也让代码审查变得困难。
由于迁移到 Perl 6 的努力，Perl 还停滞了相当长一段时间，尽管 Python 后来也陷入停滞，但那时它已经获得了更好的发展势头。
不过我认为 Perl 输给 PHP 的程度至少不亚于输给 Python。PHP当时以极简直观的特性彻底革新了简单网页编程领域——这恰是Perl的核心应用场景之一。
到2010年代初，几乎所有场景都已没有选择Perl的合理理由：系统管理脚本在Python和Go语言中更易审查维护，网页应用转向PHP及各类无Perl缺陷的语言框架。
我认为Python部分受益于数据科学计算领域的增长。大量博客和开源项目降低了学习门槛，Pandas与Numpy库让数据分析入门变得轻而易举。PyTorch和TensorFlow同样为此提供了便利，让用户既能享受优化C代码的性能优势，又无需学习C语言。后来FastAPI的出现，为那些希望将数据转化为产品的开发者提供了绝佳选择——其出色的文档和指南，帮助这些来自数据/科学计算背景的开发者构建出可运行的软件。我想我描述的正是网络效应的一部分。
我常思索人类究竟耗费了多少生命年华，仅仅用于应对和缓解那些看似琐碎的问题——比如Python版本管理、依赖处理或换行编码冲突。
历经多年发展，这些耗费恐怕已达数十万乃至数百万年？
正是这些思考时刻让我明白，人类在应对自身脆弱与死亡问题上做得并不好。若我们做得更好，本该选出一个不让我们永无止境地沉溺于编程中最空洞、最西西弗斯式的环节的赢家。Python是应对存在焦虑的典范，我如今认为这正是它诞生之初的初衷。
2008年Python迎来重大飞跃，成为谷歌应用引擎首个支持的语言，并跻身谷歌内部三大核心语言之列。这或许是连锁反应中的第一块关键骨牌。
我个人期待Julia能填补这一空白。
Python在数据科学爆发之际实现了C语言互操作优化(NumPy)。当Perl称霸文本处理领域时，Python却成为C库的通用接口。正是这种生态锁定——而非语法优势——成就了它的胜利。它恰逢其时地扮演了粘合剂的角色。
Python胜出源于其简洁性可扩展。如同英语——26个字母，极简语法——它成为默认选择。Python复制了这条发展轨迹。
它易学得不可思议，灵活得荒谬，生态系统影响力无与伦比。没有更简单的语言能达到同等覆盖度。
Python或许不适合系统级、实时或性能关键型工作——这些领域属于Rust、C和C++。
但每位严肃的工程师都必须掌握Python，正如必须掌握shell/bash脚本一样。这是不可妥协的底线。
我认为Python成功中被低估的一点在于：它更易于非软件工程师理解和使用。Python在软件开发者中广受欢迎，但在科学家群体中更是压倒性的流行。
> Python是全球最具统治力的语言
根据GitHub贡献者统计，2025年8月TypeScript首次成为GitHub使用最广泛的语言，贡献者数量领先Python约4.2万
https://github.blog/news-insights/octoverse/octoverse-a-new-…
https://dreamsongs.com/RiseOfWorseIsBetter.html
我这个完全外行的看法：
Python就是C/C++，但省去了语法装饰和指针问题，况且CPU周期如此廉价，谁还在乎速度？
Python是shell，但只需改个shebang就能构建大型项目
Python是Java，却更简洁且没有公司背景
若只能学好一种语言(多数人如此)，那非Python莫属。
唯一的缺点是浏览器中没有 Python 解释器(不像 JS 和 PHP)。不过 Python 可能因此遭遇了反竞争措施 🙂
> Python 是地球上最主流的语言
JavaScript 想说两句！
英语嘲笑它们所谓的统治地位。
数学透过显微镜凝视着，对所有地球语言微笑。真可爱。
数学当然不是语言。我们常说的“标准记法”是语言，但它和所有其他语言一样接地气。
> 当然
持异议无可厚非，但别假装存在更优解。
将物理定律视为程序、数学作为其语言的框架，与其他视角同样合理。而推论出多个文明会发现这种语言，不过是逻辑上的自然延伸。
Python之所以成功，在于LLM时代之前人们必须掌握语言才能使用它，而Python既适合初学者入门，也让疲于应对复杂语言的资深开发者轻松上手。
对我而言，正是Django框架让Python成为开发首选语言。更重要的是，它省去了C++中繁琐的指针操作，大幅简化了使用体验。
我的数据分析之旅始于Perl，后转投Python。Perl同样拥有丰富的库资源、O’Reilly在线课程、网络示例及CGI支持。后来因安装依赖变得麻烦，加上Perl不同版本间存在兼容性问题(具体细节已记不清)，我转投Python阵营，自2.7版本起便广泛使用至今。
当足够多的人使用某种工具时，简单永远是胜出的关键。
这解释了为何Windows击败DOS(NT击败Warp)，以及后来苹果战胜微软。
简单永远制胜。
一流的包管理器、顶尖的科学计算数值运算(numpy)、垃圾回收机制、统一的人类可读语法。它似乎从Perl身上汲取了诸多经验——无论优劣——并率先将其应用于科学计算领域。学生在校园接触后便乐此不疲。
当主流媒体机器正吹捧其形象时，谷歌在关键时刻采用并力荐Python。程序员也爱效仿名人，于是Python成了精通内行的雅致黑客首选。纯属运气加愚蠢的社会因素使然。
本人曾任IDE及编程语言产品经理。语言的胜出，如同万物成败，取决于其赋予的价值。以Ruby on Rails为例：它推动了Ruby的发展，其价值在于恰逢其时地实现了全栈Web应用的便捷构建。再看VB：它能构建UI应用。语言的胜出从来不在于语言本身，而在于它能让你达成什么。通常这体现在库的形式上：即使用该语言能实现的功能。关键不在语言本身，而在于使用它能抵达的境地。
Python是种好语言，但其他语言亦然。我认为Python经历了三个主要库——三个主要“高效完成任务”——时代，正是这些推动了Python的发展。
1. Beautiful Soup。2000年代初至中期，网页抓取与网站/XML/HTML数据处理成为热点；该库的出现让操作变得简单。此前我在Slashdot等平台听说过Python，它很酷但Perl更受关注。而根据我的亲身经历，突然间我读到的不再是Perl或Python，而是Beautiful Soup。
2. NumPy / SciPy。Python显然是为数值计算而生，而现今形态的NumPy稍晚于Beautiful Soup问世。2000年代初，统计与数据可视化领域普遍使用R语言。到了2010年代，我开始听到越来越多不使用R，而选择NumPy和SciPy的人。
3. 人工智能。直到几年前，AI领域还以SciPy为主导，而当下时代，人人都在用Python——用于AI。
这些都并非语言本身的特性。人们并非“使用Python”，而是(例如)使用SciPy。
我认为Python的巨大优势在于它不像VB那样只有单一的“我能实现功能”价值主张，而是连续拥有了三个核心价值。
这些技术在广为人知之前都已深耕多年。从爱好者发端，到初始设计，再到经年累月的实践应用，最终“突然”间普及开来。其共同根源或许在于Python的设计理念与社区生态；Python成功的深层动因，并非它赋予用户的成就能力，而是最初促使人们为这些库采用Python的价值驱动因素。对此我无从评述——90年代和2000年代我并未活跃于Python社区。
[*] 并非总是如此：Rust的价值在于其内存系统和安全性。这并非库功能而是内置特性，但它依然是可实现的目标、价值，是通过语言本身达成的成果，因此人们会选择该语言来实现目标。若失去这些特性，Rust就需要其他理由来支撑其使用价值。
> 这些本质上都不属于语言本身。人们并非在“使用Python”，而是在使用(比如)SciPy库。
没错，但语言特性本身对库开发者选择目标语言有着重大影响。
我完全同意。多数语言使用者并非库开发者，而是库消费者。因此库生态的存在才是推动语言流行的关键——正如你所言，这种流行需要语言本身能吸引库开发者参与其中。
层次分明！
你遗漏了Django/Flask，它们拥有极高的采用率。
说得对。我确实没听过它们像其他框架那样广为人知，但这可能源于我的认知局限。不过我知道它们确实非常流行。
开发效率压倒了运行时效能的需求。这催生了大量技术上尚未达到生产级标准但“足够用”的代码，而很少有人愿意承认自己做错了选择。
解释型语言如JavaScript、Perl、PHP和Python的异常流行毫不意外，这与纯粹的语言特性无关。真正的杀手锏在于其反馈循环机制。
若与Go语言程序员交流，你会发现他们同样重视快速反馈循环。这并非解释型语言的专属优势。
Python的制胜之道在于完善两点：(1) 语法结构兼具简洁与强大，(2) 完善的对象/函数标准库与模块系统。
其优雅的语法接近自然语言表达，这正是Python的独特之处。
(不过近十年间添加的类型提示等冗余特性，确实让它没那么优雅了。)
类型提示完全是可选的。
坦白说，当你开始使用它——哪怕只是用于函数签名这类简单场景——配合合适的IDE，它确实能帮你捕捉错误。
它赢了吗？是战胜Perl，还是所有其他语言？
我认为关键在于它摒弃了大括号、分号等冗余语法，并采用了合理的缩进机制。:)
比Perl容易上手太多。对资深程序员如此，更不用说新手了。还有丰富的标准库。
pytorch、langchain、streamlit、fastapi等等不胜枚举…
我认为原因显而易见。
参考https://www.tiobe.com/tiobe-index/，Python的增长势头其实始于2018年——这比langchain、streamlit和fastapi的出现还要早。
或许Python 2向Python 3的迁移曾制约其发展，但值得注意的是，即便在过渡期内，其增长态势依然积极或相对稳定。https://www.tiobe.com/tiobe-index/python/
科学
一句话概括：更差即更好
但愿内存价格持续上涨，迫使我们重新发掘软件效率与优化的失传技艺。
对我们而言这已是失传技艺。大型语言模型或许会为其统治者重拾此道(不过没必要——他们早已坐拥海量内存和GPU)。