几周前，我主持了一个小组讨论会，有人问，“为什么编程语言社区中没有那么多初创公司？”会议的一部分。那人在问为什么我们还没有看到很多一流的编程语言和软件分析技术走向商业化。显然有很多程序员的痛苦需要解决。但为什么我们还没有看到更多“深度”技术从实验室走向工业，从而实现技术转移，这是我从大学开始就一直在思考的问题——当时我决定用我的一生让程序员的生活更美好。更好的。许多其他领域，从机器人技术到数据库，都有更清晰的商业化路径。但对于新生的编程语言或软件分析技术，即使实现了技术转移，转移路径往往长达数十年。作为一名编程语言博士生，然后是一名教授，现在是Akita的创始人——一家旨在将软件分析技术应用于API流量的以API为中心的可观察性公司——我一直在思考这个问题——我一直在思考这个问题。但在小组讨论中，我只是主持人，所以我必须专注于真正针对小组成员的问题。上周，我启动了一个Twitter线程，要求回答这个问题。这篇文章是对该线程的详细描述。虽然开发人员工具的投资和销售都在增长，但我将探讨为什么“深度技术”工具没有获得增长的份额。我们可以做很多事情来解决这个问题——我很乐意与你们所有人一起努力，做出改变。在这篇文章中，我将重点讨论为什么我们没有看到更多的高增长初创公司专注于PLDI社区（编程工具的“深度技术”方面）的各种语言和工具。其他领域有许多类型的开发工具，催生了许多高增长的初创公司。成功的技术转移渠道（大公司、开源项目）还有很多，这里就不多说了。1.软件团队正在购买工具有一种流行的说法是公司不为开发工具付费，但这种观点越来越站不住脚。甚至几年前，人们还在谈论风险投资支持的开发工具公司面临的挑战，以及围绕开发工具建立大型企业的难度。开发者工具销售的流行观点到2021年，人们普遍认为开发者工具将会赚钱。在过去的几年里，我们看到Salesforce以2.12亿美元收购了Heroku，微软以75亿美元收购了GitHub。如今，私人持有的Postman估值为20亿美元，HashiCorp估值为51亿美元。一些开发者至上的公司也已经上市并表现出色：NewRelic的市值超过40亿美元；Datadog的市值超过320亿美元。但是人们对基于新兴编程语言和技术的东西并不慷慨，尤其是那些旨在帮助人们编写具有更多保证的代码的东西。2020年整体静态分析市场规模预计为7.481亿美元，预计到2027年将达到20.02亿美元。编程语言的开发主要由大公司支持，如Go和Python；或由一群积极的开发人员找到其他方式来支持自己，汇聚到开源社区，如Ruby、Elm和Julia。程序员的痛苦显然存在——其中一些新兴语言和工具正是解决了这种痛苦。那么出了什么问题呢？2.程序员用他们的预算投票工程领导者是否会违背开发人员的意愿选择工具？许多人持这种观点。关于开发者工具销售的常见问题，但数据不支持。根据2017年世界发展状况调查（来自SlashData），77%的开发人员现在在工具选择方面有发言权。他们选择将这些工具预算花在使他们的工作更轻松的产品上，而不是花在使他们的代码质量更高的工具上。无论如何，这两个问题不是一回事。值得一提的是，程序员的愿望与程序员的需求是不一样的。我希望在我的后院有一个鸟舍，我可以在那里饲养宠物猫头鹰。但我现在需要做的就是写一些电子邮件和吃午饭。同样，程序员希望按时交付没有错误的代码，并且该代码的运行速度始终与测试时一样快。但他们需要的是解决迫在眉睫的事件，然后在路线图上找个地方来赶进度，让计划中的功能尽快发布。如果有人提到一种工具可以神奇地将错误减少到零，软件开发人员可能会感兴趣，但脚踏实地的软件开发人员知道他们的用户似乎对某些错误有很高的容忍度。软件开发人员可能会在周末用这种闪亮的研究语言发泄一下，但在内心深处，他们知道在他们混乱的工作代码库中采用它并不是提升他们职业生涯的最佳途径。那么为什么开发者会选择花钱购买某些工具呢？与其他工具相比，这些工具有哪些优势？3.在职开发人员不购买“奢侈品”。有些人会争辩说，更先进、更深入的技术被广泛采用只是时间问题。个人拙见：目前编程语言社区持有的一些假设与程序员的需求不一致。以下是一些不符合PL世界观的程序员需求示例：零错误：通常不是最优先考虑的事情。语言设计和软件分析的共同目标是“健全性”：如果出现错误，该工具将捕获它。如果您正在建造一个错误可能意味着几条生命和数百万美元的航天器，那么使用细齿梳检查可能的错误确实有意义。然而，对于常见的Web应用程序，在修复错误和交付功能之间存在很大的权衡空间。Web应用程序开发人员通常需要一些东西来帮助他们在不牺牲太多正确性的情况下快速构建软件——而不是相反。人们不想弄清楚他们所有的问题。我经常看到假设开发人员想知道系统中存在的所有错误的“花哨”技术。你最受欢迎的朋友是否总是告诉你所有可能出错的地方？人们不想弄清楚他们所有的问题，尤其是当你认为并非所有问题都那么重要时。如果你想让开发人员开心，给他们一个下一步要做什么的优先级列表，而不是一个充满潜在问题的列表，然后让他们只是让你的消息静音。技术堆栈是有机进化的生态系统，而不是中央计划的实体。现在的问题是，为什么没有单一的编程语言或框架会统治世界。理想的灵丹妙药解决方案在所有领域都很诱人，梦想像真正完美的语言这样的东西是很有趣的。但是大多数达到一定成熟度的系统都会选择第二种语言，然后是第三种语言。技术栈的不同层次使用自己的语言和技术。这不是因为组织混乱或缺乏深思熟虑。语言在进化，系统需求在进化，下一代程序员也在进化。从工作开发人员的角度来看，零错误的理念、允许您修复所有错误的时间表以及对技术堆栈的完全控制似乎是不可能的奢侈品。编程语言社区一直在开发的技术并没有被破坏，但它们需要适应工作开发人员的需求！在下一节中，我将讨论如何做到这一点。4.工具需要适应开发者的日常生活。为了适应开发者的生活，编程工具的创造者需要根据预期的开发经验推断出具体的解决方案，而不是从我们想要构建的技术中推导出结果。为了做到这一点，我们需要接触一门被技术专家视为肮脏词汇而不屑一顾的学科：设计。我经常看到忽略设计的编程工具，但我相信这是因为人们误解了设计的含义。特别是在编程工具中，设计意味着减少摩擦以帮助开发人员到达他们需要去的地方，而不是像可爱的错误消息或黑暗模式这样的装饰性或UX摆设。以下是我从用户研究和与设计师合作中学到的一些经验教训，它们可以帮助我们打包现有技术，以便他们可以直接为开发人员的工作做出贡献：最重要的是，工具可以解决问题。在技??术编程语言社区中，我经常看到人们更强调他们正在构建什么，而不是他们正在解决什么问题——并且给用户一个模糊的、假设性的图片通常不被认为是什么事件。例如，我经常看到函数式编程爱好者争辩说，出于与软件团队目前面临的高优先级问题无关的技术原因（更多保证；优雅），他们的语言更适合开发人员。如果人们不采用这些技术，可能不是因为他们不“了解”该技术有多酷，而是因为他们不了解它如何帮助他们解决最重要的问题。适应工作流程比技术“哇”更重要。尤其是对于“深科技”工具，这些工具的开发者往往关心自己做的东西是否够新、够酷。在与开发人员进行了数十次用户研究调查后，我开始了解每个工具在生态系统中的作用。当我问开发人员他们为什么采用工具X或Y时，答案通常是它适合他们的编程语言或基础设施，或者它具有他们想要的Slack/GitHub/Jira集成。我看到的许多“深度技术”工具都假设开发人员会切换到一个全新的工具链，只是为了获得相对较少的好处。对于大多数软件团队来说，这是不可能的。包装往往比技术解决方案更重要。如果您是一名开发人员并且您运行了几次只是为了证明它有效，那么如果输出不是那么漂亮也没关系，您不关心查找它或手动美化它以增加深度。理解。如果你要日复一日地使用一个工具并与你的团队分享结果，如果需要时间来平滑粗糙的边缘，那么让你很容易看到你需要看到的输出，并使它事实证明，做自己想做的事，会是一种截然不同的体验。正如我在Akita的经历，在构建深度技术时很难采用面向设计的视角——我看到大公司附属的研究实验室在这方面做得很好，毕竟那里几乎有无限的资源。但我确实相信这在初创公司是可能的，尤其是我们现在看到开发工具公司在早期就获得了相当大的资金支持，我希望看到更多的初创公司采用这种理念。5.前进的道路我们正在进入开发者工具的黄金时代——我很乐意看到“深度技术”开发者工具参与其中。我离开学术界是因为我觉得我可以利用我在编程语言和软件分析方面的专长为开发人员解决很多核心问题。另外，我写这篇文章的很大一部分动机是因为这项任务对团队来说负担太大了！我坚信，如果我们将正确的技术与正确的问题相结合，我们可以使软件开发过程比今天更顺畅，甚至更愉快。从编程工具端来看，为了实现更广泛的采用，工具需要满足以下目标：更多地满足开发人员的需求，适应工具所在的工作流程，与现有开发工具的互操作性更好。适用于现有内容的更多增量改进更多符合开发人员优先级的设计?更少关注100%保证?更少关注构建“新世界”好工具，你也可以做一些力所能及的事情！为了让“深度技术”编程工具在生态系统中变得更加流行，我认为开发人员需要做以下事情：接受更多边缘有点粗糙的工具——人们很难为某些东西创造良好的开发体验完全新生！拥抱更多，复杂性探索工具更多反馈你想使用某些工具/工具类来解决问题不要期待那么多“银弹”不要梦想“一种语言解决一切”的过程这会降低开发人员的工作效率少一点耐心，尤其是在业务影响层面（更容易修复）显然，说起来容易做起来难！多年来我一直在与Akita一起旅行-并且仍在寻找很多事情的答案。但越是讨论这个话题，越是希望开发者工具爱好者能够团结起来，越是可以用前沿的技术让开发者的生活更美好！
