为什么编程语言社区没那么多初创公司呢？-轻识

点击关注公众号，Java干货及时送达

几周前我主持了一个小组讨论，会上有人问道：“为什么编程语言社区没那么多初创公司呢？”

这个小组会议的主题是职业路径，是编程语言设计和实现（PLDI）会议的一个环节。那人问的是为什么我们没有看到很多一流的编程语言和软件分析技术走向商业化。

程序员待解决的痛苦显然有很多。但为什么我们没有看到更多“深层”技术从实验室走向行业，从而实现技术转移，是我从大学开始就一直在思考的事情——当时我决定用我的一生来让程序员的生活变得更好。从机器人技术到数据库，其他许多领域都有更加清晰的商业化路径。

但对于新生的编程语言或软件分析技术来说，就算技术实现了转移，转移路径也往往长达几十年。我是一名编程语言博士生的时候就在思考这个问题，然后当了教授，现在又成为了 Akita 的创始人——这是一家以 API 为中心的可观察性公司，旨在将软件分析技术应用于 API 流量——我的思考并未停下来过。

但在小组讨论会上我只是主持人，所以我必须关注那些实际上是为小组成员准备的问题。上周，我开了一个 Twitter 话题征求这个问题的答案。这篇文章是对这个讨论串的详细说明。尽管开发工具得到的投资和销量正在增长，但“深度技术”工具并没有收获自己的增长份额，我要探讨的就是这种现象背后的成因。我们可以做很多事情来解决这个问题——我很乐意与大家一起改变现状。

在这篇文章中，我将重点讨论为什么我们没有看到更多高成长的初创公司专注于来自 PLDI 社区（编程工具的“深度技术”侧）的各种语言和工具。在其他领域还有很多类型的开发工具造就了许多高成长的初创公司。成功的技术转移途径也还有不少（大公司、开源项目），这里我就不提了。Intellij IDEA 顺利激活。爽推荐看下。

1、软件团队正在购买工具

有一种流行的说法是公司并不会为开发工具付费，但这种观点越来越站不住脚了。甚至在几年前，人们还在谈论风险投资支持的开发工具公司所面临的挑战，以及围绕开发工具建立大型企业的难度有多高。

关于开发工具销售情况的一个流行观点

到了 2021 年，人们普遍认为开发工具有钱途可言了。在过去的几年里，我们看到 Salesforce 以 2.12 亿美元收购了 Heroku，微软以 75 亿美元收购了 GitHub。如今，私营公司 Postman 的估值达到了 20 亿美元，HashiCorp 的估值有 51 亿美元。一些开发者优先的公司也上市了，表现不错：New Relic 的市值超过 40 亿美元；Datadog 的市值超过 320 亿美元。

但是人们并没有为基于新生编程语言和技术的东西慷慨解囊，尤其是那些旨在帮助人们编写有更多保证的代码的技术。2020 年，整个静态分析市场规模估计为 7.481 亿美元，预计到 2027 年也才达到 20.02 亿美元。编程语言的开发主要由大公司支持，例如 Go 和 Python 的例子；或者是一群动力十足的开发人员寻找其他方式来支持自己，汇聚成一个个开源社区，例如 Ruby、Elm 和 Julia。

程序员的痛苦显然是存在的——其中一些新生语言和工具恰恰可以解决这些痛苦。那么到底出了什么问题呢？Intellij IDEA 顺利激活。爽推荐看下。

2、程序员正在用他们的预算投票

难道工程领导人所选择的工具在违背开发人员的意愿吗？很多人持这种观点。

关于开发工具销量的一个常见问题

推荐一个 Spring Boot 基础教程及实战示例：https://github.com/javastacks/spring-boot-best-practice

但数据并不支持这一点。根据 2017 年的开发世界状态调查（来自 SlashData），77% 的开发者现在在工具选择方面有发言权。他们选择将这些工具预算花在让他们的工作更轻松的产品上，而不是花在让他们的代码质量更高的工具上。不管怎样，这两个关注点并不是一回事儿。

值得一提的是程序员的愿望和程序员的需求是不一样的。我希望在我家后院装一个鸟舍，在那里我可以饲养宠物猫头鹰。但是我现在需要做的就是写一些电子邮件和吃午饭。类似地，程序员希望按时交付无错误的代码，希望这些代码的运行速度能一直与和测试时一样快。但他们需要的是解决眼前火烧眉毛的事件，然后在路线图上找地方把进度赶回来，这样才能尽快将规划的特性发布出去。

如果有人提到一种可以神奇地将错误减少到零的工具，软件开发人员可能会很感兴趣，但脚踏实地的软件开发人员知道其实他们的用户似乎对某些错误有很高的容忍度。软件开发人员可能会在周末用这种闪闪发亮的研究型语言来发泄一番，但他们内心深处知道，在他们凌乱的工作代码库中采用它并不是推进职业生涯的最佳路径。

那么为什么开发人员会选择花钱购买某些工具呢？这些工具相比其他工具来说有什么好处？

点击关注公众号，Java干货及时送达

3、干活儿的开发人员不会购买“奢侈品”

有些人会说，更高级、更深层次的技术得到广泛采用只是时间问题。个人拙见：编程语言社区目前持有的一些假设是与程序员的需求不一致的。

以下是一些不符合 PL 世界观的程序员需求例子：

零错误：往往不是首要任务。语言设计和软件分析的一个共同目标是“健全性”：如果出现了一个错误，工具会发现它。如果你正在建造一艘宇宙飞船，其中一个错误就意味着几条人命和数百万美元的代价，那么用细齿梳来检查可能存在的错误的确是有意义的。然而，对于常见的 web 应用来说，修复错误和交付特性之间存在很大的权衡空间。Web 应用开发人员通常需要一些东西来帮助他们快速构建软件，同时又不牺牲太多的正确性——而不是相反。
人们不想搞清楚他们所有的问题。我经常看到“花哨的”技术假设开发人员想知道系统中存在的所有错误。你最受人欢迎的朋友会总是告诉你所有可能出错的地方吗？人们不想搞清楚他们所有的问题，尤其是考虑到并非所有问题都那么重要的时候。如果你想让开发人员高兴起来，请给他们一个优先级列表，列出下一步要做什么，而不是给他们一个充斥着潜在问题的列表，让他们把你的消息直接静音掉。
技术栈是有机进化的生态系统，而不是集中规划的实体。现在的问题是为什么没有哪种编程语言或框架会统治世界。在所有领域，理想中的银弹解决方案都很有吸引力，做梦想象一种真正完美的语言也挺有趣。但大多数具有一定成熟度的系统都会再去选择第二种语言，然后是第三种语言。技术栈的不同层次会采用各自的语言和技术。这并不是因为组织出现了混乱，或者没有考虑周全。语言在发展，系统的需求在发展，下一代程序员也在进步。

从在职开发人员的角度来看，零错误的理念、足够让你解决所有错误的时间表以及对技术栈的完全控制看来都是不可能拥有的奢侈品。

编程语言社区一直在开发的技术并没有坏掉，但它们需要适应在职开发人员的需求！在下一节中，我将讨论如何做到这一点。

4、工具需要适应开发人员的日常生活

为了适应开发人员的生活，编程工具创建者需要根据预期的开发体验来倒推具体的方案，而不是从我们想要构建的技术去正推结果。为了做到这一点，我们需要接触一个技术人员经常视为肮脏词汇的学科：设计。

我经常看到忽视设计的编程工具，但我相信这是因为人们误解了设计的含义。特别是在编程工具中，设计意味着减少摩擦以帮助开发人员到达他们需要去的地方，而不是装饰外观或装点用户体验的小玩意儿，例如可爱的错误消息或黑暗模式。

以下是我从用户研究和与设计师合作的过程中学到的一些经验教训，它们可以帮助我们打包现有技术，让它们直接助力开发人员的工作：

工具解决的问题比什么都重要。在技术编程语言社区中，我经常看到人们更多地强调他们正在构建的是什么东西而不是他们正在解决哪些问题——而且给用户一个模糊的、假设性的图景往往也不被认为是什么大事。例如，我经常看到函数式编程爱好者出于与软件团队当下面对的高优先级问题无关的技术原因（更多保证；优雅）而发起争论，争辩说他们的语言更适合开发人员。如果人们不采用这些技术，可能并不是因为他们没有“明白”这项技术有多酷，而是因为他们不知道它是怎样帮助他们解决最重要的问题的。
适应工作流程比技术“惊叹”更重要。特别是对于“深度技术”工具来说，这些工具的开发者往往在乎的是自己做的事情是不是够新够酷。在对开发人员进行了几十次用户研究调查后，我开始了解各款工具在生态系统中的作用。当我问开发人员为什么采用工具 X 或 Y 时，答案通常是它适合他们的编程语言或基础架构，或者它有他们想要的 Slack/GitHub/Jira 集成。我看到的许多“深度技术”工具都假设开发人员会切换到全新的工具链，只是为了获得相对较少的好处。对于大多数软件团队来说，这是不可能的。
包装往往比技术解决方案更重要。如果你是一名开发人员，只是为了证明某件事物是可行的而去跑上它几次，那么它的输出不那么好看也没关系，并且你也不在乎去查查资料或者手工美化它一下以加深理解。如果你要日复一日地使用某款工具并与你的团队共享结果，那么如果它能花时间抚平粗糙边缘，让你很容易看到你需要看到的输出，并让你轻松地对结果做你想做的事情，就会是很不一样的体验。

正如我在 Akita 所经历的那样，在构建深度技术的同时采取面向设计的视角是相当困难的——我看到大公司附属的研究实验室在这方面做的不错，毕竟那里有几乎无限的资源。但我确实相信这在初创公司中是有可能做到的，尤其是我们现在看到开发工具公司在早期就能获得相当大的资本支持，我很想看到更多初创公司采用这种理念。

5、前进的道路

我们正在迈入开发工具的黄金时代——我很乐意看到“深度技术”开发工具能分得一杯羹。我离开了学术界，因为我觉得自己可以利用编程语言和软件分析方面的专业知识为开发人员解决很多核心问题。另外我写这篇文章的很大一部分动机是因为这个任务对于一个团队来说负担太大了！我深信，只要我们将正确的技术与正确的问题相结合，就可以让软件开发过程比现在更加顺畅，甚至更令人愉悦。

从编程工具一侧来看，为了获得更广泛的采用率，工具需要做到以下目标：