有些文章读起来像宣言：约翰·巴克斯（John Backus）1977年的《编程能否摆脱冯·诺依曼风格？》激发了一种新范式，催生了函数式语言如Haskell。另一些则是警示：肯·汤普森（Ken Thompson）在1984年的《信任信任的反思》中展示了后门编译器的危险，可能避免了大量安全漏洞。埃兹格·迪克斯特拉（Edsger Dijkstra）在1972年的《谦逊的程序员》中提醒同行们警惕过度聪明，承认“人类思维的内在局限性”。
就本文而言，值得关注的是肯尼斯·艾弗森（Kenneth Iverson）1979年的演讲《符号作为思维工具》。他展示了数学符号不仅是方便的简写——比如CO2代表二氧化碳，3888代表罗马数字MMMDCCCLXXXVIII——更能帮助发现新的洞见。正如数学家阿尔弗雷德·诺斯·怀特黑德所言：“通过减轻大脑不必要的工作，好的符号让它得以专注于更高级的问题。”
艾弗森因APL语言获得了图灵奖。APL是一种看起来诡异的编程语言，最初作为连接不同语言的符号系统诞生。在科学计算早期，程序员需要用一种语言思考（数学符号），却用另一种语言编程（如Fortran）。APL设计让复杂操作能像数学方程一样简洁表达——代码行压缩成几个符号如+或×。虽然APL影响深远，但并未广泛采用；无论如何，它证明了两种语言可以合二为一。
这就是所谓的双语言难题：研究人员用慢速且友好的Python进行原型设计，但性能关键部分则用更快但不那么友好的语言如C++或Rust重写。这个限制无法靠大量AI编码代理解决，因为无论如何优化慢语言，快语言总会胜出。
类似的二元权衡在其他领域也存在。比如建筑领域有两种材料问题。木材适合原型搭建——即使是业余者也能锯木钉钉搭建功能性建筑，但它不适合建造摩天大楼。于是问题来了：有没有一种既像木材那样易于操作，又像钢铁那样坚固的材料？有没有一种语言既像Python那样人性化，又像C那样快速？
我们是Matlab的资深用户，有些是Lisp高手，有些是Python爱好者，还有Ruby和Perl的忠实粉丝……我们生成的R图表多得令人发指。C是我们荒岛求生的编程语言。
但正如他们所说，“每种语言在某些工作方面完美无缺，在其他方面却糟糕透顶。”他们渴望“一种开源、宽松许可的语言……既极其简单易学，又能满足最严肃黑客的需求。”Julia就是那个能统一所有语言的存在。
我第一次偶然接触Julia是在2017年——它的语法还未稳定——当时我听神经科学家塞巴斯蒂安·松（Sebastian Seung）的讲座，他用Julia绘制大脑神经连接组的完整图谱。我的第一印象是它那悦耳且迷人的名字，打破了该领域笨拙的命名惯例：不优雅的PL/I、丑陋的Erlang、排版难看的C++，以及字面上“病态”的MUMPS（你能相信吗？它支撑着美国医疗系统）。
我还能感受到Julia设计背后的深思熟虑。创始团队研究了其他语言的诸多陷阱，融合了不同语言的巧妙理念——这证明了细致观察是创造新语言前的必经之路。
但你不会在Stack Overflow年度最受欢迎语言调查中看到Julia。它并未取代Python，甚至差距甚远。为什么？哪里出了问题？
首先，正如人类语言依赖于其文本语料库，编程语言的价值也取决于其生态系统和工具链。Python的生态极其强大，难以撼动。其次，Julia未被大型科技公司采纳。过去，一些小众语言崛起往往得益于企业支持：苹果推动Objective-C用于iOS开发，谷歌推动Kotlin用于Android开发。
第三，也是我的观点：没有什么出错。Julia是小众语言，但在其领域内非常成功。很可能Julia会一直存在，虽小众但备受喜爱。它被ASML、CERN、NASA等机构用于艰巨任务，也被用于药物发现和先进机器学习等严肃项目。
即使未来Julia取代Python，我也不认为它能解决双语言难题——或者说任何语言都难以解决。虽然该问题在科学计算中常被提及，但它存在于所有软件领域。游戏开发中，游戏引擎用C++编写，脚本用Lua。服务器后端有多种易用语言——Python、Ruby、JavaScript，但真正需要性能时，工作交给Go或Rust。反之，尝试用Go或Rust做前端开发则彻底失败。
但我又怎敢断言我们会永远停留在这里？也许有一天，像艾弗森那样洞察深刻的人会找到桥接差距的办法。那时，别忘了收听他们的图灵奖演讲。
