作者 | Jean Yang
译者者 | 王磊策画 | 星毛责任编辑起初发布于 akitasoftware.com 中文网站，经原作许可由 InfoQ 英文站译者并撷取。
数周前我策划了两个小组深入探讨，会后有人问道：“为何C词汇街道社区没所以多孵化器子公司呢？”
那个联席会议的主轴是业余方向，是C词汇设计和同时实现（PLDI）会议的两个各个环节。这人问的是为何他们没看见很多世界级的C词汇和应用软件预测控制技术迈向商品化。
开发人员待化解的伤痛显然有很多。但为何他们没看见更多“微细”控制技术从生物医学迈向行业，从而同时实现控制技术迁移，是我从大学开始就一直在思索的事——当时我决定用我的毕生来让开发人员的生活变得更快。从机器控制技术到资料库，其它很多应用领域都有更加明晰的商品化方向。但对于目蛙的C词汇或应用软件预测控制技术来说，即使控制技术同时实现了迁移，迁移方向也往往长达数十年。我是一位C词汇研究生的时候就在思索那个难题，然后当了教授，现在又成为了 Akita 的创办人——这是一家以 API 为中心的可观察性子公司，意在将应用软件预测控制技术应用于 API 网络流量——我的思索仍未停下过。
难题。上周，我开了两个 Twitter 热门话题 征询那个难题的标准答案。这首诗是对那个深入探讨串的详尽说明。尽管开发辅助工具得到的投资和销售量已经开始快速增长，但“广度控制技术”辅助工具并没斩获自己的快速增长交易额，我要深入探讨的就是这种现象背后的其原因。他们可以做很多事来化解那个难题——我很乐于与大家一起实现目标。
在这首诗中，我将重点深入探讨为何他们没看见更多高成长的孵化器子公司著眼于来自 PLDI 街道社区（程式设计辅助工具的“广度控制技术”侧）的各种词汇和辅助工具。在其它应用领域除了很多类型的开发辅助工具催生了很多高成长的孵化器子公司。成功的控制技术迁移有效途径也除了不少（大子公司、开放源码项目），这里我就不提了。
1应用软件项目组已经开始购买辅助工具有一种盛行的讲法是子公司并不会为开发工具付费，但这种观点越来越站不住脚了。甚至在几年前，人们还在谈论风险投资支持的开发辅助工具子公司所面临的挑战，以及 围绕开发辅助工具建立大型企业的难度有多高。
关于开发辅助工具销售情况的两个盛行观点
到了 2021 年，估值达到了 20 亿美元，HashiCorp 的估值有 51 亿美元。一些开发者优先的子公司也上市了，表现不错：New Relic 的市值超过 40 亿美元；Datadog 的市值超过 320 亿美元。
但是人们并没为基于目蛙C词汇和控制技术的东西慷慨解囊，尤其是那些意在帮助人们编写有更多保证的代码的控制技术。2020 年，整个静态预测市场规模估计为 7.481 亿美元，预计到 2027 年也才达到 20.02 亿美元。C词汇的开发主要由大子公司支持，例如 Go 和 Python 的例子；或者是一群动力十足的开发人员寻找其它方式来支持自己，汇聚成两个个开放源码街道社区，例如 Ruby、Elm 和 Julia。
开发人员的伤痛显然是存在的——其中一些目蛙词汇和辅助工具恰恰可以化解这些伤痛。所以到底出了什么难题呢？
2开发人员已经开始用他们的预算投票难道工程领导人所选择的辅助工具在违背开发人员的意愿吗？很多人持这种观点。
关于开发辅助工具销售量的两个常见难题
但数据并不支持这一点。根据 2017 年的开发世界状态调查（来自 SlashData），77% 的开发者现在在辅助工具选择方面有发言权。他们选择将这些辅助工具预算花在让他们的工作更轻松的
值得一提的是开发人员的愿望和开发人员的需求是不一样的。我希望在我家后院装两个鸟舍，在那里我可以饲养宠物猫头鹰。但是我现在需要做的就是写一些电子邮件和吃午饭。类似地，开发人员希望按时交付无错误的代码，希望这些代码的运行速度能一直与和测试时一样快。但他们需要的是化解眼前火烧眉毛的事件，然后在路线图上找地方把进度赶回来，这样才能尽快将规划的特性发布出去。如果有人提到一种可以神奇地将错误减少到零的辅助工具，应用软件开发人员可能会很感兴趣，但脚踏实地的应用软件开发人员知道其实他们的用户似乎对某些错误有很高的容忍度。应用软件开发人员可能会在周末用这种闪闪发亮的研究型词汇来发泄一番，但他们内心深处知道，在他们凌乱的工作代码库中采用它并不是推进业余生涯的最佳方向。
所以为何开发人员会选择花钱购买某些辅助工具呢？这些辅助工具相比其它辅助工具来说有什么好处？
3干活儿的开发人员不会购买“奢侈品”有些人会说，更高级、更微细次的控制技术得到广泛采用只是时间难题。个人拙见：C词汇街道社区目前持有的一些假设是与开发人员的需求不一致的。
以下是一些不符合 PL 世界观的开发人员需求例子：
零错误：往往不是首要任务。词汇设计和应用软件预测的两个共同目标是“健全性”：如果出现了两个错误，辅助工具会发现它。如果你已经开始建造一艘宇宙飞船，其中两个错误就意味着几条人命和数百万美元的代价，所以用细齿梳来检查可能存在的错误的确是有意义的。然而，对于常见的 web 应用来说，修复错误和交付特性之间存在很大的权衡空间。Web 应用开发人员通常需要一些东西来帮助他们快速构建应用软件，同时又不牺牲太多的正确性——而不是相反。
人们不想搞清楚他们所有的难题。我经常看见“花哨的”控制技术假设开发人员想知道系统中存在的所有错误。你最受人欢迎的朋友会总是告诉你所有可能出错的地方吗？人们不想搞清楚他们所有的难题，尤其是考虑到并非所有难题都所以重要的时候。如果你想让开发人员高兴起来，请给他们两个优先级列表，列出下一步要做什么，而不是给他们两个充斥着潜在难题的列表，让他们把你的消息直接静音掉。
控制技术栈是有机进化的生态系统，而不是集中规划的实体。现在的难题是为何没哪种C词汇或框架会统治世界。在所有应用领域，理想中的银弹化解方案都很有吸引力，做梦想象一种真正完美的词汇也挺有趣。但大多数具有一定成熟度的系统都会再去选择第二种词汇，然后是第三种词汇。控制技术栈的不同层次会采用各自的词汇和控制技术。这并不是因为组织出现了混乱，或者没考虑周全。词汇在发展，系统的需求在发展，下一代开发人员也在进步。
从在职开发人员的角度来看，零错误的理念、足够让你化解所有错误的时间表以及对控制技术栈的完全控制看来都是不可能拥有的奢侈品。
C词汇街道社区一直在开发的控制技术并没坏掉，但它们需要适应在职开发人员的需求！在下一节中，我将深入探讨如何做到这一点。
4辅助工具需要适应开发人员的日常生活为了适应开发人员的生活，程式设计辅助工具创建者需要根据预期的开发体验来倒推具体的方案，而不是从他们想要构建的控制技术去正推结果。为了做到这一点，他们需要接触两个控制技术人员经常视为肮脏词汇的学科：设计。
我经常看见忽视设计的程式设计辅助工具，但我相信这是因为人们误解了设计的含义。特别是在程式设计辅助工具中，设计意味着减少摩擦以帮助开发人员到达他们需要去的地方，而不是装饰外观或装点用户体验的小玩意儿，例如可爱的错误消息或黑暗模式。
以下是我从用户研究和与设计师合作的过程中学到的一些经验教训，它们可以帮助他们打包现有控制技术，让它们直接助力开发人员的工作：
辅助工具化解的难题比什么都重要。在控制技术C词汇街道社区中，我经常看见人们更多地强调他们已经开始构建的是什么东西而不是他们已经开始化解哪些难题——而且给用户两个模糊的、假设性的图景往往也不被认为是什么大事。例如，我经常看见函数式程式设计爱好者出于与应用软件项目组当下面对的高优先级难题无关的控制技术原因（更多保证；优雅）而发起争论，争辩说他们的词汇更适合开发人员。如果人们不采用这些控制技术，可能并不是因为他们没“明白”这项控制技术有多酷，而是因为他们不知道它是怎样帮助他们化解最重要的难题的。
适应工作流程比控制技术“惊叹”更重要。特别是对于“广度控制技术”辅助工具来说，这些辅助工具的开发者往往在乎的是自己做的事是不是够新够酷。在对开发人员进行了几十次用户研究调查后，我开始了解各款辅助工具在生态系统中的作用。当我问开发人员为何采用辅助工具 X 或 Y 时，标准答案通常是它适合他们的C词汇或基础架构，或者它有他们想要的 Slack/GitHub/Jira 集成。我看见的很多“广度控制技术”辅助工具都假设开发人员会切换到全新的辅助工具链，只是为了获得相对较少的好处。对于大多数应用软件项目组来说，这是不可能的。
包装往往比控制技术化解方案更重要。如果你是一位开发人员，只是为了证明某件事物是可行的而去跑上它几次，所以它的输出不所以好看也没关系，并且你也不在乎去查查资料或者手工美化它一下以加深理解。如果你要日复一日地使用某款辅助工具并与你的项目组共享结果，所以如果它能花时间抚平粗糙边缘，让你很容易看见你需要看见的输出，并让你轻松地对结果做你想做的事，就会是很不一样的体验。
正如我在 Akita 所经历的那样，在构建广度控制技术的同时采取面向设计的视角是相当困难的——我看见大子公司附属的研究生物医学在这方面做的不错，毕竟那里有几乎无限的资源。但我确实相信这在孵化器子公司中是有可能做到的，尤其是他们现在看见开发辅助工具子公司在早期就能获得相当大的资本支持，我很想看见更多孵化器子公司采用这种理念。
5前进的道路他们已经开始迈入开发辅助工具的黄金时代——我很乐于看见“广度控制技术”开发辅助工具能分得一杯羹。我离开了学术界，因为我觉得自己可以利用C词汇和应用软件预测方面的专业知识为开发人员化解很多核心难题。另外我写这首诗的很大一部分动机是因为那个任务对于两个项目组来说负担太大了！我深信，只要他们将正确的控制技术与正确的难题相结合，就可以让应用软件开发过程比现在更加顺畅，甚至更令人愉悦。
从程式设计辅助工具一侧来看，为了获得更广泛的采用率，辅助工具需要做到以下目标：
更多地满足开发人员的需求、适应辅助工具所在的工作流程
与现有开发辅助工具的互操作性更强
更多适用于现有内容的增量改进
更多符合开发者优先级顺序的设计
如果你是程式设计辅助工具的消费者，希望获得更快的工具，你也可以做些力所能及的事！为了让“广度控制技术”程式设计辅助工具在生态系统中更受欢迎，我认为开发人员需要做到以下几点：
接受更多边缘有点粗糙的辅助工具——人们很难为完全目蛙的事物创造良好的开发体验！
接受更多 、复杂性探索辅助工具
提供更多关于你想使用某些辅助工具 / 辅助工具类来化解难题的反馈
不要所以期待“银弹”
不要梦想“有一种词汇来化解一切”
对拖累开发人员生产力的流程少些耐心，尤其是在影响业务（更容易修复）的层面
显然，这说起来容易做起来难！我已经在 Akita 走过了多年的旅程——并且还在很多事上寻找标准答案。但他们谈论那个热门话题越多，开发者辅助工具爱好者能够团结起来的希望就越大，他们就更可能利用最前沿的控制技术让开发者的生活更加美好！
原文链接：
https://www.akitasoftware.com/blog-posts/why-arent-there-more-programming-languages-startups
今日好文推荐XML之父：不对代码做测试就像“上完厕所不洗手”为何应用软件工程师出身的CEO越来越“香”？70万行代码、历时20年，一位开发人员写出的史诗般的计算机程序被疫情加速的通信云企业，“慢”下来后该迈向何方？进群资料门极客时间课程，免费滴！大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的控制技术礼包等你领取，除了超值活动等你参加，快来加入他们吧！
点个在看少个 bug 👇
