第1071章倉頡的路線之爭
第1071章倉頡的路線之爭(第1/3頁)
第1071章倉頡的路線之爭
而此刻會議室的另一邊，終端bg總裁姚塵風看著臺上正在詳細講解技術細節的餘新峰，腦海中也不由浮現出“倉頡”項目啟動初期，團隊內部關於技術路線的那場激烈爭論。
這支由餘新峰組建起來的編程語言團隊，雖然彙聚了一批國內優秀的青年才俊，但他們中的大多數人，此前並冇有從頭開始設計和開發大型通用編程語言的完整經驗。
大家都清楚，通用語言的技術難度和複雜性，遠高於為特定領域設計的專用語言。
在“倉頡”語言的起步路線上，團隊內部出現了明顯的分歧。
有一部分專家提出，應該基於javascript語言進行改進和增強。
他們的理由很充分：
javascript在web前端領域占據著絕對的統治地位，生態極其繁榮，像微信小程序等國民級應用，其技術底座就與javascript密切相關。
javascript的優勢在於開發便捷、敏捷性強、動態類型靈活、無需編譯即可運行，學習和上手成本相對較低。
但是，這個提議幾乎被華興高層和餘新峰團隊核心毫不猶豫地否決了。
為什麼？因為安全性！
javascript作為動態類型語言，其在類型安全方麵的天然劣勢，是其無法逾越的鴻溝。
而對於華興立誌要打造麵向萬物互聯時代的鴻蒙操作係統而言，安全性是底線，是生命線！
開放的鴻蒙生態需要應對來自全球各種複雜場景和潛在威脅，任何可能引入安全漏洞的技術選擇都是不可接受的。
缺乏嚴格類型檢查的動態語言，在大型複雜項目開發中，更容易出現難以在編譯期發現的潛在錯誤，這對係統安全是致命的。
此外，在性能方麵，動態類型語言在運行時需要進行類型判斷和轉換，其執行效率、內存占用和功耗控製，往往難以滿足鴻蒙係統對多種終端設備（尤其是資源受限的iot設備）的苛刻要求。
選擇javascript路線，無異於從一開始就背上了沉重的“曆史技術債務”，未來將步履維艱。
經過審慎的評估與激烈的討論，華興最終拍板：
“倉頡”必須定位為一款自研的、靜態類型的編程語言。
它的對標對象，是蘋果的swift、安卓早期依賴的java和現在主推的kotlin這些成功應用於大型移動生態的語言，無一例外都是靜態類型。
靜態類型語言在編譯階段就能發現大量類型錯誤，極大地提升了代碼的健壯性和安全性。
同時，由於其類型信息在編譯期確定，編譯器可以進行更深層次的優化，通常能帶來更好的運行時性能。
當然，華興
（本章未完，請點擊下一頁繼續閱讀）