對于新項目，嵌入式開發人員應該使用哪種編程語言? 這篇文章將探討一些為嵌入式開發人員選擇正確編程語言的建議。

建議 #1 – 避免死亡或正在死亡的語言

隨著時間的推移，編程語言不再流行，這是不可避免的。發明了新的做事方法，發明了新的語言來解決當今的編程問題。 曾經常用的語言逐漸消失，取而代之的是新的語言。

請注意，匯編語言是全球第 8 大最受歡迎的編程語言! 但是，你知道有多少人積極地用匯編語言編寫應用程序? 在大多數情況下，匯編語言已經死了。 當然，我們偶爾會編寫匯編來優化某些功能，但我們并不是每天都在編寫匯編語言。 因此，請確保你選擇的語言尚未死亡或尚未正在逐漸消失。

建議 #2 – 選擇面向對象的語言

今天幾乎每個系統都可以用數據驅動、面向對象的體系結構來描述。 我相信許多嵌入式系統自然而然地落入了這種設計范式，沒有必要折磨我們的設計來獲得它們。 但是，選擇支持面向對象編程概念的編程語言對于構建可擴展和可重用的軟件系統至關重要。

當我們查看嵌入式系統的編程語言列表時，我們會注意到前五種語言存在一個小問題; C 和匯編不是面向對象的語言! 它們不提供嵌入式開發人員實施現代軟件架構所需的現代工具集。 此外，這些語言需要大量額外的工作才能獲得自然內置到其他語言中的功能。

建議 #3 – 僅使用標準化語言

構建必須經過多年維護和更新的商業產品的人不應該用非標準化的語言，除非他們能夠承擔與不斷升級軟件相關的技術債務。在像 Rust 一樣標準化語言之前，該語言的規范是不斷變化的。隨著語言的發展和確定做事的最佳方式，它在不斷變化。這意味著你可能使用一個編譯器得到結果 A，然后使用另一個編譯器得到結果 B。同樣的語言，不同的結果，都是因為語言不標準化!

盡管新語言令人興奮，但對于大多數企業來說使用標準化語言是有意義的。我認為使用具有標準的語言并積極更新這些標準以發展語言及其功能是有意義的。像 C++ 這樣的語言是一個不錯的選擇。 C++有一個定義明確的標準，標準每三年更新一次。 結果，為開發人員提供了新技術和新功能來改進他們的軟件，使語言活起來。 它還提供了一個一致的標準，這樣團隊就不必承擔變更的技術債務，如果他們不想這樣做。 相反，他們繼續使用他們采用的標準版本。

建議 #4 – 平衡語言運行時權重

嵌入式開發團隊的一個關鍵考慮因素是他們語言的運行時權重。

如果你檢查 C/C++，你會發現運行 C 應用程序所需的代碼大小遠低于 1 KB。運行代碼的開銷也可以忽略不計甚至不存在， C/C++ 具有輕量級的運行時權重。如果你檢查 Python 或 MicroPython，你會發現情況并非如此。 MicroPython 解釋器通常構建到 300 – 400 KB 之間!運行解釋器的開銷相對較小，但解釋器的權重相當高。

如果內存成本被認為便宜或不重要，那么重量級運行時可能沒什么大不了的。在這種情況下，使用像 MicroPython 這樣的語言可以帶來很多好處。例如，幾乎每個人都知道 Python 或者可以很快學會它。此外，它的適應性強，編碼標準比人們想象的要多。升級應用程序代碼也可以像更新一些腳本模塊一樣快。

在任何一種情況下，嵌入式開發團隊都應該仔細考慮與他們選擇的語言相關的開銷。 例如，python、Java、Labview 等可能比其他語言具有更高的運行時成本。

建議 #5 – 使用適合你的語言

歸根結底，你(團隊)需要決定哪些功能和語言最適合你的需求。例如，如果整個行業都在轉向 Python，但匯編語言更有意義，因為你提供了手動優化的庫，那么選擇匯編語言。另一方面，如果你有一堆用 C 編寫的遺留代碼，并希望繼續利用現有資產，那么請使用 C。(或者包裝你的 C 代碼并使用 C++!)。

不要讓我們這個時代的語言時尚說服你改變。相反，使用有意義的方法并考慮我們在本文中討論的建議。

嵌入式開發人員和團隊確實可以選擇豐富的編程語言來開發他們的嵌入式軟件。他們選擇的語言將取決于他們編寫的軟件類型、公司的需求以及他們在維護代碼時產生的技術債務。在選擇要使用的語言時，本文中的建議應提供一些額外的考慮。當有疑問時，C/C++，尤其是 C++，可能是一個很好的默認值。