00:50:15
在近期的一次访谈中,Stripe 联合创始人 Patrick Collison 分享了他在编程语言选择、人工智能发展以及 Stripe 工程决策方面的见解。从早期创业到如今领导一家大型科技公司,他的经验揭示了技术演进中的关键思考。
Patrick Collison 的第一个创业项目使用了 Smalltalk 语言,这源于他对 Lisp 方言和 continuation-based web 框架的偏好。他认为 Smalltalk 提供了高度交互式的开发环境,允许实时调试和代码修改,这在当时主流语言如 Ruby 中缺乏。尽管 Smalltalk 非主流,但团队快速学习并应用它,不过项目最终因创意问题而非技术选择失败。
更早时期,Patrick 还开发过一个基于 Lisp 的 AI 聊天机器人,用于 MSN Messenger。它使用贝叶斯模型进行单词预测,并通过遗传算法优化键盘布局(如 Workman 布局),但未深入神经网络领域,部分原因是计算资源限制。
Patrick 预测主流语言(如 JavaScript 和 Python)会持续吸收 Lisp 和 Smalltalk 的理念,尤其是集成开发环境(IDE)的交互性。他推崇 Mathematica 式的环境,其中代码编辑、运行和调试无缝结合,而非当前分离的模式。理想情况下,IDE 应实时显示性能分析、日志和变量值,提升开发效率。
他赞赏 Brett Victor 的“发明原理”和动态可视化概念,但认为其更适用于特定领域(如动态系统),而非通用软件工程。对于 Stripe 这类复杂系统,符号化推理比空间可视化更实用。
Patrick 讨论了 AI 如何改变编程范式。他设想 AI 可能从“人类助手”演变为“高级编译器”,使编程语言更高级、更专注于意图而非实现细节。这可能减少形式化,但保留命名和逻辑重用的优点。
他强调 AI 工具需支持快速迭代和控制,例如允许 AI 在后台运行代码并反馈结果。同时,AI 可辅助代码重构和美化,降低现有代码库的维护负担,这与 Jerry Sussman 的“易修改系统”理念一致。
Stripe 早期选择 Ruby 和 MongoDB,源于 Patrick 对 SQL 的“原则性反对”——他认为对象数据存储更贴合应用域模型。尽管这不是主流选择,但团队通过自建基础设施确保了高可用性(如 99.99986% 的 API 可用性)。Ruby 在性能瓶颈处用 Java 重写服务,以平衡开发效率与运行时需求。
这些决策具有长期影响,体现了早期技术选择对组织结构和业务策略的塑造力(Conway 定律)。例如,iOS 生态的成功部分归因于其优于 Android 的框架设计。
2022 年,Stripe 开始设计 V2 APIs,以修正核心抽象中的问题。新 API 统一了客户、子账户和支付接收者等实体,支持更灵活的 n-to-m 关系。设计过程强调客户反馈和实际集成测试,避免过度工程。
迁移类似指令集变更,需处理共存和升级路径。Patrick 认为统一性和灵活性是关键教训,且设计应由单一主导者负责以确保一致性。
Patrick 主要用 AI 聊天工具(如 Grok 语音模式)回答事实性问题,或在阅读时实时查询。但他对 AI 生成文本不满意,认为其风格过于通用,无法匹配个人写作风格。在编码中,他通过 Cursor 使用 AI,强调控制力和迭代速度。
Patrick 关注 AI 对生产力的影响。近期研究未显示 LLM 带来显著生产率提升,且全球经济增长仍未见指数级加速。他引用 Anthropic 联合创始人 Jack Clark 的预测——AI 可能年增 GDP 0.5%,但扩散需时间。
他认为 GDP 仍能捕捉经济增强,但未来更不确定,技术轨迹将决定受益者(如实物资产或 positional goods)。Progress studies(进步研究)的需求增加,以应对技术、地缘政治等多变因素。
Patrick 参与创办的 ARC 生物医学研究组织正开发生物学基础模型和虚拟细胞。他指出,人类从未治愈复杂疾病(如心血管病或癌症),因缺乏足够实验技术。新进展如单细胞测序、CRISPR 和 AI 提供了“读-想-写”循环,可能破解疾病动态。
Patrick 肯定 Cursor 对 Stripe 生产力的提升,并建议三个改进方向:
他认为降低代码库变更成本和提高架构质量将增强灵活性。