小米降噪藍牙耳機Necklace分享：聽一首歌 讀懂一個故事
在今天下午的小米Civi 2新品發布會上，小米還帶來了一款新的降噪藍牙耳機Necklace，我們也在發布結束的第一時間給大家帶來這款耳機的簡單分享。現在大家能見到最多的藍牙耳機
作者 | JOS VISSER
編譯 | 王瑞平
最近，大家總在吐槽Python：“雖然它是一種不錯的語言，但不適用于專業領域。”
圖片
數據顯示：Python依然排名第一，占比13.33%；C語言緊隨其后，排行第二，占比11.41%；C++位列第三，占比10.63%，與C語言差距為0.78%。
圖片
此外，Java和C#分別排在第四和第五位，占比分別為10.33%和7.04%。JavaScript在本月依然保持榜單第六位，占比為3.29%。
雖然Python如此受歡迎，但它能否持續流行依舊是一個重大問題，很多用戶普遍認為，如果持續使用將會使行業倒退好幾年。
Python對于開發大型應用程序不太友好，在工程化實踐中需要特殊的技術支持。
“我曾用Python編寫過大型應用程序很多年。由于Python入門非常簡單，在編寫大型應用程序時就像用樂高積木構建核反應堆一樣。”原作者在文章中形象地比喻道。
“但是，現在‘反應堆’已經運行很久，輻射泄漏到處都有，我們需要到處‘貼新磚’讓‘反應堆’持續運轉。”
實際上，目前唯一能做的就是將“反應堆”封裝在混凝土中讓它冷卻下來，然后再用合適的建筑材料構建出一個新的。
認為“Python無法開發大型應用程序”的網友認為它“不太友好”，在工程化實踐中需要特殊技術支持。
圖片
也有反對者認為：在大型項目中，與影響更大的其它因素相比，編程語言的語法、語義、范式等幾乎無關緊要。團隊經驗和熟悉度、開發管理、流程、實踐、支持工具、文檔、語言生態系統、語言成熟度、管理支持等都會對項目結果產生更大的影響。
另外，從技術層面來講，質疑Python無法開發大型編程語言只能反映提問者對相關開發缺乏了解。這些質疑一是源于Python的動態類型特性，使類型推斷變得困難，對代碼的靜態檢查和重構十分不利；二是由于Python代碼沒有編譯過程，因此缺少編譯時檢查錯誤機制。
關于動態類型特性質疑，Python從3.3版本起就引入類型聲明，因此，只要遵循規范編寫代碼，類型推斷和代碼重構就不是問題。
不久前，ChatGPT的問世也證明了Python可以寫出高性能、可擴展性強的大型分布式計算平臺—Ray。目前，這個平臺已匯聚超過1億的月活躍用戶。
“糟糕的應用程序架構是絕大多數應用產生性能瓶頸的原因，而不應該由開發語言來背黑鍋。”有些評論者這樣認為。
誠然，Python與其它開發語言相比，在運行速度方面確實落后不少。究其根源，還是由于Python之父認為不需要過多關注Python的速度問題，認為它已經足夠快了。
確實，對于99%以上的任務來說，Python的速度夠快，快到足以支撐早期Google和Dropbox。
自那時起，Python的速度又有了顯著提升，但開發者仍要求Python運行得更快。因為，無論人們已經使用Python構建出算力多么驚人的計算平臺，它的計算能力在很多場景下依然更慢。
當然，Python是一種靈活的和duck類型的語言：我們鍵入代碼、保存它，然后僅在運行時才能根據輸入的數據確定語句始終有效、有時有效還是根本不可能實現。
此外，你在用Python編寫程序時，只能部分控制進入該函數的數據，需要嚴格檢查所有輸入的數據。
更糟糕的是，Python的duck式輸入方式可能會引入“可怕”代碼，這會帶來麻煩。
我在用Python編寫大型應用程序的這些年里，經歷過一些可怕的事情；如果這些應用程序是用理性的、安全的語言編寫的，這些事就不會發生。
*在幾年前的一個例子中，我設法說服組織用Rust重寫系統，效果非常不錯！
實際上，我曾多次在社區中發布用Python編寫的大型應用程序新版本，結果卻立即被錯誤“吞噬”；這些錯誤都是由Python代碼異常導致的。
*Python的捍衛者會說，這不是語言的缺陷，而是代碼審查和測試方法的缺陷。
*他們錯了！理論上，測試方法主要是查看每一行代碼并檢查每個輸入和場景，但實際上這并不可能！
好的編程語言的特點之一是：你不必檢查和測試內存中每個相關位置的排列；如果必須詳盡地檢查和測試每個“a=b+c”，程序將可能永遠無法應用于實踐。
我會經常查看Python函數，并想了解是否有人實際調用了它們以及攜帶了哪些參數。
我也經常不得不“求助”代碼庫的全文搜索功能尋找調用位置；不幸的是，即便沒有輸出任何結果，當我刪除相應函數時，程序依然會崩潰；就算程序沒有立即崩潰，也無法判斷程序是否會在某種情況下崩潰。
用Python的另一個問題是內存。我的筆記本電腦有10個CPU內核，其中，Python應用程序大約占用1.2個。
這該怎么辦呢？幸運的是，我可以在Python中使用分叉工作進程的功能處理請求，確保所有核心都能正常使用。
不幸的是，分叉進程的操作很快就耗盡了內存，所以我決定在處理完一定數量的請求后自行終止分叉，然后由Linux進行內存管理。雖然這并不是Python本身的問題，但Python使內存管理變得更加糟糕。
分叉工作進程還有另一個影響：Python使用引用計數法擊敗了寫時復制。為控制引用計數，保存只讀變量的內存塊也被寫入，從而耗費了一定的內存。
解決這個問題的有效方法是：讓編譯器對所有由主進程創建和由worker進程繼承的變量使用參考數值，而不必觸及到具有該參考數值的引用計數。
這是超級聰明的解決方案，但我認為應該沒這個必要。如果你需要破解編譯器才能讓Python為你所用，那這種語言又有什么用呢?
總之，Python使編寫可靠、易于維護和快速的代碼變得非常困難。
當我對Python忍無可忍之時就會轉向Go，它使用起來幾乎與Python同樣容易、安全，還能快速構建系統并生成高度優化的二進制本機代碼文件。
雖然Go也并不是完美的，但是，如果你想可靠和快速地編寫代碼，并在代碼失控時可以調試和重構，Go比Python好很多！
https://www.zhihu.com/question/321166662/answer/2937406779?utm_id=0
https://www.zhihu.com/question/321166662/answer/2937406779
本文鏈接：http://www.tebozhan.com/showinfo-26-5699-0.html到底該不該使用Python?
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： CSS 如何改變網格布局偶數行的排序？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號