为什么 Java 之父 James Gosling 认为工程师是艺术家

Java 的普及是自下而上的胜利

Gosling 回忆了 Java 早期在伦敦某大银行的传播故事，这是全篇最有操作价值的一段：

• 该银行交易结算系统里有个 C 写的最终确认程序，因内存泄漏每 8~10 小时就得重启一次，团队花了大力气也没找到泄漏点
• 几名工程师用 Java 重写了一个版本——"两名开发人员一周就能搞定"的复杂度，跑通了银行全套详尽的验收测试
• 经理的态度是："好，等它崩溃了，我们就换回原来那个。"——结果它再没崩过
• 从此案例越积越多，Java 在该银行内部慢慢传开

Gosling 总结："我一直相信自下而上的营销。从某种意义上说，这就是开源的本质。"与之相对，他对自上而下强推技术的态度是"真的很糟糕"——CEO/CIO 被大供应商施压后把工具强加给工程师，工程师的第一反应是"搞什么鬼？"。他还见过银行买了 Oracle 全包许可证，结果大多数项目实际用的是 MySQL，"因为后者用起来容易很多。他们只是在自欺欺人。"

AI 炒作与即将到来的调整

• Gosling 认为过去几年 AI 的发展方式恰好证明了自上而下的命令效果有多差："你们必须在所有事情上都使用 AI"这种命令根本说不通——AI 仍相当新，大量科学实验尚未完成，资深人士却把炒作当真（"解雇所有客服人员，因为我们可以用 AI 替代"）
• 他预判一场巨大的调整即将到来，但影响不会像互联网泡沫那么广泛
• 点名 OpenAI 和 Anthropic："他们的做法从数学上来说行不通，把巨额资金挥霍视为成功的衡量标准……我很确定，他们两家会失败。"小型 AI 公司（AI 的使用者而非生产者）失败率会比风投领域 95% 的基线更高
• 他眼中稳固的是微软、谷歌、亚马逊；Oracle "似乎真的过度杠杆化了"；X 和 Facebook 是"史诗级的垃圾场"，Substack"很出色"

Sun 的工程文化：对"打擦边球"的宽容

纪录片里提到 Java 爆发增长期团队接入未备案商用 T3 线路的往事。Gosling 的回应揭示了 Sun 文化的核心：管理者的优点之一是知道自己实际上并不了解正在发生的事情——如果工程师开始做一些出格的事情，他们会顺其自然。"大家只想着先把正确的事落地。"

伦理：第零条规则是"不要伤害你的客户"

• 安全是 Sun 从创立第一天起的最高优先级（1985 年愚人节 Gosling 自己写了个蠕虫入侵 Sun 内网，"过了好几年才承认是自己干的"）
• 当产品用于工业和银行系统，一分钟故障可能造成数百万美元损失时，可靠性的意义完全不同
• 管理者讨厌安全：做好安全成本高昂，又不会在产品功能列表上产生引人注目的效果。他的比喻很妙——烤面包机的宣传是"能烤百吉饼、能做燕麦粥"，然后最底下一行小字："顺便说一下，它不会要你的命。"没人会写"我们承诺不会伤害你"，但消费电子设备的第零号需求永远是"不要伤害你的客户"
• 另一句金句：工程师的绝对目标之一，就是不让自己的项目出现在新闻中——工程师大部分时间的追求是"让自己隐形"，确保事情顺利进行、不出差错

工程师都是艺术家

被问编程更像水管工还是木匠，Gosling 的回答是两者皆是："我认识一些水管工，我会称他们为艺术家。当一个水管工的工作做得非常出色时，那是美的……它可能被墙遮住，但依然是美的。"

代码之美在于：有多清晰？有多容易理解？这往往关系到可靠性和可维护性。像伦敦地铁控制系统这种要运行数十年的系统，一批批工程师来来去去，代码优美意味着下一批接手的人能轻松上手。"我认为所有工程师都是艺术家，只是方式略有不同。"

Gosling 怎么看 LLM 辅助编程

• 他一直在用，但从未对生成的代码满意过，基本上全部重写，"因为那看起来太糟糕了"
• 真正的价值在另一处：当你试图在一个从未涉足的领域编写软件时，编程助手能提供编程环境和 API 的地图。"有一种误解是编程语言很难学，事实并非如此，编程语言很容易，难学的是所有的接口：如何建立网络连接？如何操作数据库？"
• 朋友的评价更毒辣："编程助手挺好用的，只要你不去看代码。因为看了你会尖叫。"
• 对维护性问题他很清醒：联邦快递这样的公司可能有五十亿行代码，丢给 LLM 助手它肯定崩溃。简单场景效果不错，"但这仍然是个科学实验"
• 欣慰的一点：软件开发工具长期不受重视，如今终于成了热门赛道

Zero 的看法

这篇访谈对一线工程师最实用的不是"工程师是艺术家"这种情怀，而是 Gosling 复盘 Java 传播路径时给出的自下而上改进的完整剧本：找一个小而痛的点（内存泄漏的结算程序）→ 用极低成本做出替代品（两人一周）→ 跑通对方自己的验收测试 → 让管理者零风险兜底（"崩了就换回来"）→ 靠实际运行效果自然扩散。这套打法对任何想在团队里推工具/流程改进的 IC 都成立——关键不是说服，而是制造一个"试一下也没成本"的既成事实。另外两点值得记住：一是他对 LLM 的定位——"API 地图"而非代码生产者，这个判断来自一个写了 40 年代码且天天在用的人，比各类布道者的说法可信；二是"工程师的目标是让自己隐形、让项目不上新闻"——基建、稳定性、可维护性这类工作的价值天然不可见，这既是现实也是这类工作容易被低估的原因，做的人要有意识地显性化成果。

原文为 InfoQ 翻译 THE STACK 的英文专访，source 已填原文链接。