为什么没有更多的编程语言初创公司？

几周前，我主持了一个小组讨论，有人问：“为什么编程语言社区没有更多的初创公司？”这是在与编程语言设计和实现 (PLDI) 会议相关的职业道路小组会议上。这个人问的是为什么我们没有看到更多尖端的编程语言和软件分析技术商业化。显然有很多程序员的痛苦。但是为什么我们没有看到这些“深层”技术从研究到工业的更多技术转移是我从大学开始就一直在思考的问题，当时我决定用我的一生来改善程序员的生活。许多其他领域，从机器人技术到数据库，都有更清晰的商业化路径。但是当涉及到新的编程语言或软件分析时，技术转移的路径通常要长达几十年，如果存在的话。我是一个编程语言博士生，然后是教授，现在是 Akita 的创始人，这是一家以 API 为中心的可观察性公司，基于将软件分析技术应用于 API 流量。但是，唉，我只是主持人，所以我必须专注于实际上是为小组成员准备的问题。上周，我做了一个 Twitter 线程来回答这个问题。这篇文章是对该线程的详细说明。我将讨论如何，即使对开发人员工具的投资和购买正在增加，“深度技术”工具并没有看到它们的增长份额。我们可以做很多事情来解决它——我很乐意一起做。在这篇文章中，我将重点讨论为什么我们没有看到更多高增长的初创公司专注于来自 PLDI 社区（编程工具的“深度技术”方面）的各种语言和工具。还有许多其他类型的开发人员工具作为高增长初创公司表现出色。还有其他成功的技术转让途径（大公司；开源项目），我不会在这里介绍。有一种流行的说法是公司不为开发人员工具付费（例如参见此处），但这种说法越来越不真实。甚至在几年前，人们还在撰写有关风险投资支持的开发工具公司面临的挑战以及围绕开发人员工具建立大型企业的难度。到 2021 年，人们普遍认为开发者工具有钱了。在过去的几年里，我们看到 Salesforce 以 2.12 亿美元收购 Heroku，微软以 75 亿美元收购 GitHub。如今，私营公司 Postman 的估值为 20 亿美元，HashiCorp 的估值为 51 亿美元。开发者优先的公司也上市了，表现也不错：New Relic 的市值超过 40 亿美元； Datadog 的市值超过 320 亿美元。

但是人们并没有为之花大钱的是任何基于新编程语言和技术的东西，尤其是专注于帮助人们编写更有保证的代码的技术。 2020 年整个静态分析市场规模在 2020 年估计为 7.481 亿美元，预计到 2027 年仅达到 20.02 亿美元。编程语言的开发主要由大公司支持，例如 Go 和 Python，或由企业语言支持寻找其他方式来支持自己的开发人员，因为他们聚集了他们的开源社区，例如 Ruby、Elm 和 Julia。显然有程序员的痛苦——这些新语言和工具中的一些可以解决这些痛苦。是什么赋予了？难道工程领导者正在违背开发人员的意愿选择工具？这是许多人所说的（例如，请参阅此处）。但数据并不支持这一点。根据 2017 年开发者国家状况（通过 SlashData），77% 的开发者现在在工具选择方面有发言权。他们选择将这些工具预算花在让他们的工作生活更轻松的产品上，而不是让他们的代码质量更高的工具上。不管是好是坏，这两个问题并不相同。值得一提的是程序员的愿望和程序员的需求之间的区别。我希望在我的后院有一个鸟舍，在那里我可以饲养宠物猫头鹰。 🦉但我现在需要做的就是写一些电子邮件和吃午饭。类似地，程序员希望按时交付无错误的代码，这些代码的运行速度始终与测试时一样快。但他们需要的是解决他们的火灾事故，然后在路线图上弥补时间，以便他们可以尽快将预定的功能推出。提到一种可以神奇地将错误减少到零的工具，软件开发人员的眼睛可能会睁大，但扎根于现实的软件开发人员知道事实是他们的用户似乎对某些错误有很高的容忍度。软件开发人员可能会在周末使用这种漂亮的闪亮的研究语言来发泄，但他们内心深处知道，在他们凌乱的工作代码库中采用它并不是促进职业发展的最佳方式。有人会说，我们看到采用更高级、更深层次的技术只是时间问题。我的两分钱：编程语言社区目前持有一些与程序员需求不一致的假设。以下是一些不符合 PL 世界观的程序员需求：

零错误：通常不是首要任务。语言设计和软件分析的一个共同目标是“健全性”：如果有错误，工具会发现它。如果你正在建造一艘宇宙飞船，其中一个虫子就意味着你会失去生命和数百万美元，那么用细齿梳来检查可能的虫子是有意义的。然而，对于一般的 Web 应用程序，修复错误和交付功能之间存在很大的权衡。 Web 应用程序开发人员通常需要一些东西来帮助他们快速构建软件，同时又不牺牲太多的正确性——而不是相反。人们不想知道他们所有的问题。我经常看到“花哨的”技术假设开发人员想知道系统的所有错误。你的朋友总是告诉你所有可能出错的事情是你最受欢迎的朋友吗？人们不想知道他们所有的问题，尤其是当并非所有问题都重要时。如果您想让开发人员高兴，请给他们一个优先级列表，列出下一步要做什么，而不是让他们忽略通知的大量潜在问题列表。技术栈是有机进化的生态系统，而不是集中规划的实体。现在的问题是为什么没有单一的编程语言或框架会接管。正如在任何其他领域梦想银弹解决方案都很有吸引力一样，梦想一种真正的语言也很有趣。但是大多数具有一定成熟度的系统都会选择第二种语言，然后是第三种语言。技术堆栈的不同层采用自己的语言和技术。这不是因为组织混乱，或者没有考虑周全。语言在发展，系统的需求在发展，下一代程序员也在发展。从工作开发人员的角度来看，零错误的想法、让您解决所有错误的时间表以及对技术堆栈的完全控制似乎是不可能的奢侈品。编程语言社区一直在开发的技术没有被破坏，但它们需要适应工作开发人员的需求！在下一节中，我将讨论如何操作。 （如果您对了解这一点如何使我们转向 Akita 所做的事情感到好奇，我们将在这篇博文中更多地讨论它。）为了适应开发人员的生活，编程工具创建者需要从预期的方向倒退开发者体验，而不是我们想要构建的技术。为了做到这一点，我们需要参与一个经常被技术人员视为肮脏词的学科：设计。我经常看到人们忽视设计的编程工具，但我相信这是因为对设计是什么的误解。特别是在编程工具中，设计意味着减少摩擦以帮助开发人员到达他们需要去的地方，而不是增加美观或拨打良好用户体验的装饰，例如可爱的错误消息或暗模式。

以下是我从用户研究和与设计师合作中学到的一些经验教训，它们可以帮助以直接对开发人员的工作有帮助的方式打包现有技术： 工具解决的问题比其他任何事情都重要。在技​​术编程语言社区中，我经常看到人们更多地强调人们正在构建的东西而不是他们正在解决的问题——而且通常可以接受用户的模糊、假设图片。例如，我经常看到函数式编程爱好者出于与软件团队正在经历的高优先级问题无关的技术原因（更多保证；优雅）而争论他们的语言如何更适合开发人员。如果人们不采用这些技术，可能不是他们没有“了解”该技术有多酷，而是它如何帮助他们解决最重要的问题。适应工作流程比技术“哇”更重要。特别是对于“深度技术”工具，通常会关注他们正在做的新的或酷的事情。在对开发人员进行了几十次用户研究采访后，我开始了解每个工具在生态系统中的作用。当我问开发人员为什么采用工具 X 或 Y 时，答案通常是它适用于他们的编程语言或基础架构，或者它有他们想要的 Slack/GitHub/Jira 集成。我看到的许多“深度技术”工具都假设开发人员将切换到全新的工具链以获得相对较少的好处。对于大多数软件团队来说，这是不可能的。包装通常比技术解决方案更重要。如果您是一名开发人员，为了表明某事是可能的而多次运行某事，那么输出很笨重也没关系，并且您必须对其进行查询或手动美化它才能理解它.如果这是一个您将日复一日地使用并与您的团队共享结果的工具，那么拥有一个花时间抚平粗糙边缘的工具，让您很容易看到您需要看到的输出，并让您轻松地对结果做您想做的事情，这会产生很大的不同。正如我在秋田所经历的那样，在构建深度技术的同时采取面向设计的观点是相当困难的——我主要看到它在隶属于大公司的研究实验室中做得很好，那里有几乎无限的资源。但我确实相信在初创公司中是有可能做到的，尤其是我们现在看到早期开发工具公司获得的那种资本化，我很想看到更多。 （如果你想更多地了解我对开发人员体验如何与“深度技术”编程工具相关联的看法，我在这里有另一篇博文。）我们正在进入开发人员工具的黄金时代——我很想看到“深度技术”开发工具分得一杯羹。我离开了学术界，因为我觉得我可以利用我在编程语言和软件分析方面的专业知识为开发人员解决主要问题。我写这篇文章的很大一部分动机是因为工作对于一个团队来说太大了！我深信，通过将正确的技术与正确的问题相结合，我们可以使软件开发过程比现在更加顺畅，甚至令人愉悦。从编程工具方面来看，以下是获得更广泛采用所需的工具：

如果您是一名编程工具消费者，希望有更好的工具，那么您也可以扮演一个角色！以下是我认为生态系统需要发生的事情才能让“深度技术”编程工具更加受欢迎：更多地接受边缘有点粗糙的工具——很难为不存在的东西创造良好的开发体验前！更多关于您想使用某些工具/工具类解决的问题的反馈 对导致开发人员生产力降低的流程缺乏耐心，尤其是在影响业务的方式（因此更容易修复） 显然，这一切都说起来容易比做！我已经在秋田进行了多年的旅行——我们仍在弄清楚很多事情。但是我们越是谈论这个，我们就越希望开发者工具爱好者能够团结起来，利用最前沿的可能性让开发者的生活更美好！如果您觉得开发这样的工具很有趣，我们正在招聘——而且我们现在特别努力寻找我们的第一位专门的前端工程师。如果您使用大量 API 并希望帮助我们更快地实现一键可观察性的目标，我们很乐意让您加入我们的内测。