為什么編程語言社區(qū)沒那么多初創(chuàng)公司呢？
點(diǎn)擊關(guān)注公眾號，Java干貨及時(shí)送達(dá)
幾周前我主持了一個(gè)小組討論，會上有人問道：“為什么編程語言社區(qū)沒那么多初創(chuàng)公司呢？”
這個(gè)小組會議的主題是職業(yè)路徑，是編程語言設(shè)計(jì)和實(shí)現(xiàn)（PLDI）會議的一個(gè)環(huán)節(jié)。那人問的是為什么我們沒有看到很多一流的編程語言和軟件分析技術(shù)走向商業(yè)化。
程序員待解決的痛苦顯然有很多。但為什么我們沒有看到更多“深層”技術(shù)從實(shí)驗(yàn)室走向行業(yè)，從而實(shí)現(xiàn)技術(shù)轉(zhuǎn)移，是我從大學(xué)開始就一直在思考的事情——當(dāng)時(shí)我決定用我的一生來讓程序員的生活變得更好。從機(jī)器人技術(shù)到數(shù)據(jù)庫，其他許多領(lǐng)域都有更加清晰的商業(yè)化路徑。
但對于新生的編程語言或軟件分析技術(shù)來說，就算技術(shù)實(shí)現(xiàn)了轉(zhuǎn)移，轉(zhuǎn)移路徑也往往長達(dá)幾十年。我是一名編程語言博士生的時(shí)候就在思考這個(gè)問題，然后當(dāng)了教授，現(xiàn)在又成為了 Akita 的創(chuàng)始人——這是一家以 API 為中心的可觀察性公司，旨在將軟件分析技術(shù)應(yīng)用于 API 流量——我的思考并未停下來過。
但在小組討論會上我只是主持人，所以我必須關(guān)注那些實(shí)際上是為小組成員準(zhǔn)備的問題。上周，我開了一個(gè) Twitter 話題 征求這個(gè)問題的答案。這篇文章是對這個(gè)討論串的詳細(xì)說明。盡管開發(fā)工具得到的投資和銷量正在增長，但“深度技術(shù)”工具并沒有收獲自己的增長份額，我要探討的就是這種現(xiàn)象背后的成因。我們可以做很多事情來解決這個(gè)問題——我很樂意與大家一起改變現(xiàn)狀。
在這篇文章中，我將重點(diǎn)討論為什么我們沒有看到更多高成長的初創(chuàng)公司專注于來自 PLDI 社區(qū)（編程工具的“深度技術(shù)”側(cè)）的各種語言和工具。在其他領(lǐng)域還有很多類型的開發(fā)工具造就了許多高成長的初創(chuàng)公司。成功的技術(shù)轉(zhuǎn)移途徑也還有不少（大公司、開源項(xiàng)目），這里我就不提了。Intellij IDEA 順利激活。爽推薦看下。
1、軟件團(tuán)隊(duì)正在購買工具
有一種流行的說法是公司并不會為開發(fā)工具付費(fèi)，但這種觀點(diǎn)越來越站不住腳了。甚至在幾年前，人們還在談?wù)擄L(fēng)險(xiǎn)投資支持的開發(fā)工具公司所面臨的挑戰(zhàn)，以及 圍繞開發(fā)工具建立大型企業(yè)的難度有多高。
關(guān)于開發(fā)工具銷售情況的一個(gè)流行觀點(diǎn)
到了 2021 年，人們普遍認(rèn)為開發(fā)工具有錢途可言了。在過去的幾年里，我們看到 Salesforce 以 2.12 億美元收購了 Heroku，微軟以 75 億美元收購了 GitHub。如今，私營公司 Postman 的估值達(dá)到了 20 億美元，HashiCorp 的估值有 51 億美元。一些開發(fā)者優(yōu)先的公司也上市了，表現(xiàn)不錯(cuò)：New Relic 的市值超過 40 億美元；Datadog 的市值超過 320 億美元。
但是人們并沒有為基于新生編程語言和技術(shù)的東西慷慨解囊，尤其是那些旨在幫助人們編寫有更多保證的代碼的技術(shù)。2020 年，整個(gè)靜態(tài)分析市場規(guī)模估計(jì)為 7.481 億美元，預(yù)計(jì)到 2027 年也才達(dá)到 20.02 億美元。編程語言的開發(fā)主要由大公司支持，例如 Go 和 Python 的例子；或者是一群動力十足的開發(fā)人員尋找其他方式來支持自己，匯聚成一個(gè)個(gè)開源社區(qū)，例如 Ruby、Elm 和 Julia。
程序員的痛苦顯然是存在的——其中一些新生語言和工具恰恰可以解決這些痛苦。那么到底出了什么問題呢？Intellij IDEA 順利激活。爽推薦看下。
2、程序員正在用他們的預(yù)算投票
難道工程領(lǐng)導(dǎo)人所選擇的工具在違背開發(fā)人員的意愿嗎？很多人持這種觀點(diǎn)。
關(guān)于開發(fā)工具銷量的一個(gè)常見問題
推薦一個(gè) Spring Boot 基礎(chǔ)教程及實(shí)戰(zhàn)示例：https://github.com/javastacks/spring-boot-best-practice
但數(shù)據(jù)并不支持這一點(diǎn)。根據(jù) 2017 年的開發(fā)世界狀態(tài)調(diào)查（來自 SlashData），77% 的開發(fā)者現(xiàn)在在工具選擇方面有發(fā)言權(quán)。他們選擇將這些工具預(yù)算花在讓他們的工作更輕松的產(chǎn)品上，而不是花在讓他們的代碼質(zhì)量更高的工具上。不管怎樣，這兩個(gè)關(guān)注點(diǎn)并不是一回事兒。
值得一提的是程序員的愿望和程序員的需求是不一樣的。我希望在我家后院裝一個(gè)鳥舍，在那里我可以飼養(yǎng)寵物貓頭鷹。但是我現(xiàn)在需要做的就是寫一些電子郵件和吃午飯。類似地，程序員希望按時(shí)交付無錯(cuò)誤的代碼，希望這些代碼的運(yùn)行速度能一直與和測試時(shí)一樣快。但他們需要的是解決眼前火燒眉毛的事件，然后在路線圖上找地方把進(jìn)度趕回來，這樣才能盡快將規(guī)劃的特性發(fā)布出去。
如果有人提到一種可以神奇地將錯(cuò)誤減少到零的工具，軟件開發(fā)人員可能會很感興趣，但腳踏實(shí)地的軟件開發(fā)人員知道其實(shí)他們的用戶似乎對某些錯(cuò)誤有很高的容忍度。軟件開發(fā)人員可能會在周末用這種閃閃發(fā)亮的研究型語言來發(fā)泄一番，但他們內(nèi)心深處知道，在他們凌亂的工作代碼庫中采用它并不是推進(jìn)職業(yè)生涯的最佳路徑。
那么為什么開發(fā)人員會選擇花錢購買某些工具呢？這些工具相比其他工具來說有什么好處？
點(diǎn)擊關(guān)注公眾號，Java干貨及時(shí)送達(dá)
3、干活兒的開發(fā)人員不會購買“奢侈品”
有些人會說，更高級、更深層次的技術(shù)得到廣泛采用只是時(shí)間問題。個(gè)人拙見：編程語言社區(qū)目前持有的一些假設(shè)是與程序員的需求不一致的。
零錯(cuò)誤：往往不是首要任務(wù)。語言設(shè)計(jì)和軟件分析的一個(gè)共同目標(biāo)是“健全性”：如果出現(xiàn)了一個(gè)錯(cuò)誤，工具會發(fā)現(xiàn)它。如果你正在建造一艘宇宙飛船，其中一個(gè)錯(cuò)誤就意味著幾條人命和數(shù)百萬美元的代價(jià)，那么用細(xì)齒梳來檢查可能存在的錯(cuò)誤的確是有意義的。然而，對于常見的 web 應(yīng)用來說，修復(fù)錯(cuò)誤和交付特性之間存在很大的權(quán)衡空間。Web 應(yīng)用開發(fā)人員通常需要一些東西來幫助他們快速構(gòu)建軟件，同時(shí)又不犧牲太多的正確性——而不是相反。 人們不想搞清楚他們所有的問題。我經(jīng)?？吹健盎ㄉ诘摹奔夹g(shù)假設(shè)開發(fā)人員想知道系統(tǒng)中存在的所有錯(cuò)誤。你最受人歡迎的朋友會總是告訴你所有可能出錯(cuò)的地方嗎？人們不想搞清楚他們所有的問題，尤其是考慮到并非所有問題都那么重要的時(shí)候。如果你想讓開發(fā)人員高興起來，請給他們一個(gè)優(yōu)先級列表，列出下一步要做什么，而不是給他們一個(gè)充斥著潛在問題的列表，讓他們把你的消息直接靜音掉。 技術(shù)棧是有機(jī)進(jìn)化的生態(tài)系統(tǒng)，而不是集中規(guī)劃的實(shí)體?，F(xiàn)在的問題是為什么沒有哪種編程語言或框架會統(tǒng)治世界。在所有領(lǐng)域，理想中的銀彈解決方案都很有吸引力，做夢想象一種真正完美的語言也挺有趣。但大多數(shù)具有一定成熟度的系統(tǒng)都會再去選擇第二種語言，然后是第三種語言。技術(shù)棧的不同層次會采用各自的語言和技術(shù)。這并不是因?yàn)榻M織出現(xiàn)了混亂，或者沒有考慮周全。語言在發(fā)展，系統(tǒng)的需求在發(fā)展，下一代程序員也在進(jìn)步。
從在職開發(fā)人員的角度來看，零錯(cuò)誤的理念、足夠讓你解決所有錯(cuò)誤的時(shí)間表以及對技術(shù)棧的完全控制看來都是不可能擁有的奢侈品。
編程語言社區(qū)一直在開發(fā)的技術(shù)并沒有壞掉，但它們需要適應(yīng)在職開發(fā)人員的需求！在下一節(jié)中，我將討論如何做到這一點(diǎn)。
4、工具需要適應(yīng)開發(fā)人員的日常生活
工具解決的問題比什么都重要。在技術(shù)編程語言社區(qū)中，我經(jīng)常看到人們更多地強(qiáng)調(diào)他們正在構(gòu)建的是什么東西而不是他們正在解決哪些問題——而且給用戶一個(gè)模糊的、假設(shè)性的圖景往往也不被認(rèn)為是什么大事。例如，我經(jīng)?？吹胶瘮?shù)式編程愛好者出于與軟件團(tuán)隊(duì)當(dāng)下面對的高優(yōu)先級問題無關(guān)的技術(shù)原因（更多保證；優(yōu)雅）而發(fā)起爭論，爭辯說他們的語言更適合開發(fā)人員。如果人們不采用這些技術(shù)，可能并不是因?yàn)樗麄儧]有“明白”這項(xiàng)技術(shù)有多酷，而是因?yàn)樗麄儾恢浪窃鯓訋椭麄兘鉀Q最重要的問題的。 適應(yīng)工作流程比技術(shù)“驚嘆”更重要。特別是對于“深度技術(shù)”工具來說，這些工具的開發(fā)者往往在乎的是自己做的事情是不是夠新夠酷。在對開發(fā)人員進(jìn)行了幾十次用戶研究調(diào)查后，我開始了解各款工具在生態(tài)系統(tǒng)中的作用。當(dāng)我問開發(fā)人員為什么采用工具 X 或 Y 時(shí)，答案通常是它適合他們的編程語言或基礎(chǔ)架構(gòu)，或者它有他們想要的 Slack/GitHub/Jira 集成。我看到的許多“深度技術(shù)”工具都假設(shè)開發(fā)人員會切換到全新的工具鏈，只是為了獲得相對較少的好處。對于大多數(shù)軟件團(tuán)隊(duì)來說，這是不可能的。 包裝往往比技術(shù)解決方案更重要。如果你是一名開發(fā)人員，只是為了證明某件事物是可行的而去跑上它幾次，那么它的輸出不那么好看也沒關(guān)系，并且你也不在乎去查查資料或者手工美化它一下以加深理解。如果你要日復(fù)一日地使用某款工具并與你的團(tuán)隊(duì)共享結(jié)果，那么如果它能花時(shí)間撫平粗糙邊緣，讓你很容易看到你需要看到的輸出，并讓你輕松地對結(jié)果做你想做的事情，就會是很不一樣的體驗(yàn)。
5、前進(jìn)的道路
我們正在邁入開發(fā)工具的黃金時(shí)代——我很樂意看到“深度技術(shù)”開發(fā)工具能分得一杯羹。我離開了學(xué)術(shù)界，因?yàn)槲矣X得自己可以利用編程語言和軟件分析方面的專業(yè)知識為開發(fā)人員解決很多核心問題。另外我寫這篇文章的很大一部分動機(jī)是因?yàn)檫@個(gè)任務(wù)對于一個(gè)團(tuán)隊(duì)來說負(fù)擔(dān)太大了！我深信，只要我們將正確的技術(shù)與正確的問題相結(jié)合，就可以讓軟件開發(fā)過程比現(xiàn)在更加順暢，甚至更令人愉悅。
從編程工具一側(cè)來看，為了獲得更廣泛的采用率，工具需要做到以下目標(biāo)：
更多地滿足開發(fā)人員的需求、適應(yīng)工具所在的工作流程 與現(xiàn)有開發(fā)工具的互操作性更強(qiáng) 更多適用于現(xiàn)有內(nèi)容的增量改進(jìn) 更多符合開發(fā)者優(yōu)先級順序的設(shè)計(jì)? 減少對 100% 保證的關(guān)注? 減少對構(gòu)建“新世界”的關(guān)注
如果你是編程工具的消費(fèi)者，希望獲得更好的工具，你也可以做些力所能及的事情！為了讓“深度技術(shù)”編程工具在生態(tài)系統(tǒng)中更受歡迎，我認(rèn)為開發(fā)人員需要做到以下幾點(diǎn)：
接受更多邊緣有點(diǎn)粗糙的工具——人們很難為完全新生的事物創(chuàng)造良好的開發(fā)體驗(yàn)！ 接受更多 、復(fù)雜性探索工具 提供更多關(guān)于你想使用某些工具 / 工具類來解決問題的反饋 不要那么期待“銀彈” 不要夢想“有一種語言來解決一切” 對拖累開發(fā)人員生產(chǎn)力的流程少些耐心，尤其是在影響業(yè)務(wù)（更容易修復(fù)）的層面
顯然，這說起來容易做起來難！我已經(jīng)在 Akita 走過了多年的旅程——并且還在很多事情上尋找答案。但我們談?wù)撨@個(gè)話題越多，開發(fā)者工具愛好者能夠團(tuán)結(jié)起來的希望就越大，我們就更可能利用最前沿的技術(shù)讓開發(fā)者的生活更加美好！
原文：https://www.akitasoftware.com/blog-posts/why-arent-there-more-programming-languages-startups
作者：Jean Yang
來源：InfoQ 架構(gòu)頭條
譯者 | 王強(qiáng)，策劃 | 曉旭
關(guān)注Java技術(shù)棧看更多干貨
