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

這個小組會議的主題是職業路徑，是程式語言設計和實現（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
作者：Jean Yang
來源：InfoQ 架構頭條
譯者 | 王強，策劃 | 曉旭

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.別在再滿屏的 if/ else 了，試試策略模式，真香！！

3.臥槽！Java 中的 xx ≠ null 是什麼新語法？

4.Spring Boot 2.5 重磅釋出，黑暗模式太炸了！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！