點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

幾周前我主持了一個小組討論，會上有人問道：“為什么編程語言社區沒那么多初創公司呢？”

這個小組會議的主題是職業路徑，是編程語言設計和實現（PLDI）會議的一個環節。那人問的是為什么我們沒有看到很多一流的編程語言和軟件分析技術走向商業化。

程序員待解決的痛苦顯然有很多。但為什么我們沒有看到更多“深層”技術從實驗室走向行業，從而實現技術轉移，是我從大學開始就一直在思考的事情——當時我決定用我的一生來讓程序員的生活變得更好。從機器人技術到數據庫，其他許多領域都有更加清晰的商業化路徑。但對于新生的編程語言或軟件分析技術來說，就算技術實現了轉移，轉移路徑也往往長達幾十年。我是一名編程語言博士生的時候就在思考這個問題，然后當了教授，現在又成為了 Akita 的創始人——這是一家以 API 為中心的可觀察性公司，旨在將軟件分析技術應用于 API 流量——我的思考并未停下來過。

但在小組討論會上我只是主持人，所以我必須關注那些實際上是為小組成員準備的問題。上周，我開了一個 Twitter 話題 征求這個問題的答案。這篇文章是對這個討論串的詳細說明。盡管開發工具得到的投資和銷量正在增長，但“深度技術”工具并沒有收獲自己的增長份額，我要探討的就是這種現象背后的成因。我們可以做很多事情來解決這個問題——我很樂意與大家一起改變現狀。

在這篇文章中，我將重點討論為什么我們沒有看到更多高成長的初創公司專注于來自 PLDI 社區（編程工具的“深度技術”側）的各種語言和工具。在其他領域還有很多類型的開發工具造就了許多高成長的初創公司。成功的技術轉移途徑也還有不少（大公司、開源項目），這里我就不提了。

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。

程序員的痛苦顯然是存在的——其中一些新生語言和工具恰恰可以解決這些痛苦。那么到底出了什么問題呢？

2程序員正在用他們的預算投票

難道工程領導人所選擇的工具在違背開發人員的意愿嗎？很多人持這種觀點。

關于開發工具銷量的一個常見問題

但數據并不支持這一點。根據 2017 年的開發世界狀態調查（來自 SlashData），77% 的開發者現在在工具選擇方面有發言權。他們選擇將這些工具預算花在讓他們的工作更輕松的產品上，而不是花在讓他們的代碼質量更高的工具上。不管怎樣，這兩個關注點并不是一回事兒。

值得一提的是程序員的愿望和程序員的需求是不一樣的。我希望在我家后院裝一個鳥舍，在那里我可以飼養寵物貓頭鷹。但是我現在需要做的就是寫一些電子郵件和吃午飯。類似地，程序員希望按時交付無錯誤的代碼，希望這些代碼的運行速度能一直與和測試時一樣快。但他們需要的是解決眼前火燒眉毛的事件，然后在路線圖上找地方把進度趕回來，這樣才能盡快將規劃的特性發布出去。如果有人提到一種可以神奇地將錯誤減少到零的工具，軟件開發人員可能會很感興趣，但腳踏實地的軟件開發人員知道其實他們的用戶似乎對某些錯誤有很高的容忍度。軟件開發人員可能會在周末用這種閃閃發亮的研究型語言來發泄一番，但他們內心深處知道，在他們凌亂的工作代碼庫中采用它并不是推進職業生涯的最佳路徑。

那么為什么開發人員會選擇花錢購買某些工具呢？這些工具相比其他工具來說有什么好處？

3干活兒的開發人員不會購買“奢侈品”

有些人會說，更高級、更深層次的技術得到廣泛采用只是時間問題。個人拙見：編程語言社區目前持有的一些假設是與程序員的需求不一致的。

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

• 零錯誤：往往不是首要任務。語言設計和軟件分析的一個共同目標是“健全性”：如果出現了一個錯誤，工具會發現它。如果你正在建造一艘宇宙飛船，其中一個錯誤就意味著幾條人命和數百萬美元的代價，那么用細齒梳來檢查可能存在的錯誤的確是有意義的。然而，對于常見的 web 應用來說，修復錯誤和交付特性之間存在很大的權衡空間。Web 應用開發人員通常需要一些東西來幫助他們快速構建軟件，同時又不犧牲太多的正確性——而不是相反。

• 人們不想搞清楚他們所有的問題。我經常看到“花哨的”技術假設開發人員想知道系統中存在的所有錯誤。你最受人歡迎的朋友會總是告訴你所有可能出錯的地方嗎？人們不想搞清楚他們所有的問題，尤其是考慮到并非所有問題都那么重要的時候。如果你想讓開發人員高興起來，請給他們一個優先級列表，列出下一步要做什么，而不是給他們一個充斥著潛在問題的列表，讓他們把你的消息直接靜音掉。

• 技術棧是有機進化的生態系統，而不是集中規劃的實體。現在的問題是為什么沒有哪種編程語言或框架會統治世界。在所有領域，理想中的銀彈解決方案都很有吸引力，做夢想象一種真正完美的語言也挺有趣。但大多數具有一定成熟度的系統都會再去選擇第二種語言，然后是第三種語言。技術棧的不同層次會采用各自的語言和技術。這并不是因為組織出現了混亂，或者沒有考慮周全。語言在發展，系統的需求在發展，下一代程序員也在進步。

從在職開發人員的角度來看，零錯誤的理念、足夠讓你解決所有錯誤的時間表以及對技術棧的完全控制看來都是不可能擁有的奢侈品。

編程語言社區一直在開發的技術并沒有壞掉，但它們需要適應在職開發人員的需求！在下一節中，我將討論如何做到這一點。

4工具需要適應開發人員的日常生活

為了適應開發人員的生活，編程工具創建者需要根據預期的開發體驗來倒推具體的方案，而不是從我們想要構建的技術去正推結果。為了做到這一點，我們需要接觸一個技術人員經常視為骯臟詞匯的學科：設計。

我經常看到忽視設計的編程工具，但我相信這是因為人們誤解了設計的含義。特別是在編程工具中，設計意味著減少摩擦以幫助開發人員到達他們需要去的地方，而不是裝飾外觀或裝點用戶體驗的小玩意兒，例如可愛的錯誤消息或黑暗模式。

以下是我從用戶研究和與設計師合作的過程中學到的一些經驗教訓，它們可以幫助我們打包現有技術，讓它們直接助力開發人員的工作：

• 工具解決的問題比什么都重要。在技術編程語言社區中，我經常看到人們更多地強調他們正在構建的是什么東西而不是他們正在解決哪些問題——而且給用戶一個模糊的、假設性的圖景往往也不被認為是什么大事。例如，我經常看到函數式編程愛好者出于與軟件團隊當下面對的高優先級問題無關的技術原因（更多保證；優雅）而發起爭論，爭辯說他們的語言更適合開發人員。如果人們不采用這些技術，可能并不是因為他們沒有“明白”這項技術有多酷，而是因為他們不知道它是怎樣幫助他們解決最重要的問題的。

• 適應工作流程比技術“驚嘆”更重要。特別是對于“深度技術”工具來說，這些工具的開發者往往在乎的是自己做的事情是不是夠新夠酷。在對開發人員進行了幾十次用戶研究調查后，我開始了解各款工具在生態系統中的作用。當我問開發人員為什么采用工具 X 或 Y 時，答案通常是它適合他們的編程語言或基礎架構，或者它有他們想要的 Slack/GitHub/Jira 集成。我看到的許多“深度技術”工具都假設開發人員會切換到全新的工具鏈，只是為了獲得相對較少的好處。對于大多數軟件團隊來說，這是不可能的。

• 包裝往往比技術解決方案更重要。如果你是一名開發人員，只是為了證明某件事物是可行的而去跑上它幾次，那么它的輸出不那么好看也沒關系，并且你也不在乎去查查資料或者手工美化它一下以加深理解。如果你要日復一日地使用某款工具并與你的團隊共享結果，那么如果它能花時間撫平粗糙邊緣，讓你很容易看到你需要看到的輸出，并讓你輕松地對結果做你想做的事情，就會是很不一樣的體驗。

正如我在 Akita 所經歷的那樣，在構建深度技術的同時采取面向設計的視角是相當困難的——我看到大公司附屬的研究實驗室在這方面做的不錯，畢竟那里有幾乎無限的資源。但我確實相信這在初創公司中是有可能做到的，尤其是我們現在看到開發工具公司在早期就能獲得相當大的資本支持，我很想看到更多初創公司采用這種理念。

5前進的道路

我們正在邁入開發工具的黃金時代——我很樂意看到“深度技術”開發工具能分得一杯羹。我離開了學術界，因為我覺得自己可以利用編程語言和軟件分析方面的專業知識為開發人員解決很多核心問題。另外我寫這篇文章的很大一部分動機是因為這個任務對于一個團隊來說負擔太大了！我深信，只要我們將正確的技術與正確的問題相結合，就可以讓軟件開發過程比現在更加順暢，甚至更令人愉悅。

從編程工具一側來看，為了獲得更廣泛的采用率，工具需要做到以下目標：

• 更多地滿足開發人員的需求、適應工具所在的工作流程

• 與現有開發工具的互操作性更強

• 更多適用于現有內容的增量改進

• 更多符合開發者優先級順序的設計?

• 減少對 100% 保證的關注?

• 減少對構建“新世界”的關注

如果你是編程工具的消費者，希望獲得更好的工具，你也可以做些力所能及的事情！為了讓“深度技術”編程工具在生態系統中更受歡迎，我認為開發人員需要做到以下幾點：

• 接受更多邊緣有點粗糙的工具——人們很難為完全新生的事物創造良好的開發體驗！

• 接受更多 、復雜性探索工具

• 提供更多關于你想使用某些工具 / 工具類來解決問題的反饋

• 不要那么期待“銀彈”

• 不要夢想“有一種語言來解決一切”

• 對拖累開發人員生產力的流程少些耐心，尤其是在影響業務（更容易修復）的層面

顯然，這說起來容易做起來難！我已經在 Akita 走過了多年的旅程——并且還在很多事情上尋找答案。但我們談論這個話題越多，開發者工具愛好者能夠團結起來的希望就越大，我們就更可能利用最前沿的技術讓開發者的生活更加美好！

原文鏈接：

https://www.akitasoftware.com/blog-posts/why-arent-there-more-programming-languages-startups

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

總結

以上是生活随笔為你收集整理的为什么编程语言初创公司那么少？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。