【譯】哪個程式語言可以統治其他所有的程式語言？
原文連結：http://betterprogramming.pub/the-one-programming-language-to-rule-them-all-620366df2805
在我撰寫本文的時候，Google搜尋【我應該學習哪種程式語言】有5.17億個搜尋結果。每個頁面都在討論一種程式語言相對於其他語言的優勢，其中90%的頁面最終會推薦 Python 或 JavaScript。
我不是針對誰，我只想說我反對這5.17億個文章的觀點。並且我建議您應該學習的第一種程式語言是邏輯【logic】。
知道如何編寫程式碼已經不再有競爭力了。市場上到處都是培訓班出來的畢業生，【初級軟體開發者】這個名號已經沒有什麼價值了。如果你想在今天成功，你不僅需要知道如何編寫程式碼，還需要有一個邏輯思維的模型。
我的第一堂電腦科學課
我第一次接觸電腦科學是在10年級的一次選修課上。第一天上課的時候，我驚喜的發現教室裡擺滿了冰淇淋和各種聖代。
在我們就座後，我們的老師宣佈：
“今天我們要製作聖代。有一個條件: 你必須寫一份關於如何製作聖代的具體指令，然後我會照著這些指令做。”
沒問題！我認為這將是一件輕而易舉的事。
於是在不到一分鐘的時間裡，我快速地寫下了一套我認為完美的聖代製作指令: ``` 將三勺黑莓冰淇淋舀入碗中
將兩湯匙熱軟糖倒入碗中
將生奶油放入碗中
在聖代上撒上糖屑和櫻桃 ```
然後我的老師開始精確的執行了我的指令：她開始惡毒地捅著冰淇淋盒，即使盒蓋是完好無損的。
“好吧。老師您應該先把冰淇淋盒子的蓋子開啟”，我不得不補充道。
“但是你的指令中並沒有告訴我應該開啟蓋子，所以很不幸，我無法為你製作聖代。擡走，下一位！”
第二次嘗試
後來我有了第二次嘗試的機會，然後我就編寫了這些指令：
取下蓋子開啟黑覆盆子冰淇淋
將三勺黑莓冰淇淋舀入碗中
開啟熱軟糖，將兩湯匙倒入碗中
開啟鮮奶油，在碗中加入一些
在聖代上撒上糖屑和櫻桃
這一次我確信我寫了正確的指令。甚至為了保險起見，我提前打開了每一件物品，以確保不會出現上次那樣的諷刺畫面。
然後我的老師開始執行我的指令。
她開啟蓋子，舀了三勺，放進碗裡。然後她開啟熱巧克力軟糖，在我的碗裡放了兩湯匙。
注意，執行到這個步驟的時候，老師在我碗裡放置的是兩個真正的勺子，而不是兩大湯匙的熱軟糖。
完了，這一次我又說得不夠準確。最終我拿到的是一碗裝著兩個金屬勺子的冰淇淋，而不是我想要的聖代。
到這裡我終於想明白一個道理了：計算機是一個純粹的邏輯實體。它沒有上下文，也沒有假設。它只能對一組具體的指令做出反應，然後按照指令來執行。
最後，我重新了一個非常冗長的製作聖代的步驟。看起來很繁瑣，但是很有必要：
``` 如果尚未開啟，請開啟以下各項：黑莓冰淇淋、熱軟糖、灑布和生奶油
從堆疊中取出一個碗並將其放在您面前
拿起冰淇淋勺，一次一個，舀三勺黑覆盆子冰淇淋到碗裡。 完成後將勺子放下
如果您還沒有熱軟糖勺，請獲取熱軟糖勺，然後取兩湯匙熱軟糖並將它們放入碗中，一次一個，完成後放下熱軟糖
將攪打好的奶油倒置，將手指按在碗上方的噴嘴上 3 秒鐘，然後將瓶子放回靜止位置
在碗上撒上大約 40 次灑水，完成後將振動篩恢復到直立位置
從櫻桃罐中取出一顆櫻桃，小心地放在聖代上
用勺子把聖代遞給學生 ```
最後一步非常重要。如果沒有這個指令，老師會直接吃了這份聖代而不是給我。😁
這就是計算機程式設計的現實。我們需要為計算機提供大量詳細的指令集。本質上，所有的程式語言編寫的程式碼都會被轉化為指令集。
軟體開發的職業道路
【軟體開發】現在的問題是：作為一個單一的行業來討論它過於寬泛，就像【軟體開發人員】是一個過於寬泛的職位頭銜一樣。兩個技術棧不同的開發人員可能有同樣的市場需求。這意味著開發者的職業生涯中不能只有編碼的能力，有一個技能是所有開發者通用的，那就是：邏輯（logic）。
最好的開發人員是批判性思維方面的專家。這是必不可少的，因為大多數軟體專案都是沒有文件的、混亂的屎山。他們需要一個批判性的思考者把資訊拼湊起來，並在需要的時候填補空白。而比較差的開發人員就做不到這一點。
基於這一切，我們可以大膽地得出一個結論：電腦科學的基礎是，並將永遠是，編碼的能力（coding ability）。（而不是某個的程式語言）
流行語言隨著潮流來來去去，舊的框架會被拋棄，新的框架會得到人們的讚揚。而軟體公司也會隨著需求來改變自己的技術棧。但是那些最基礎的東西是不會變的。
如何提高自己的邏輯思維【logical Thinking】
對於那些不擅長深度思考的程式設計師來說，可以通過下面的方式提到自己的批判性思維。
瞭解程式的時間複雜度
也稱為 Big-O，程式的執行時複雜度可以表示為任何例項上採取的步驟數與輸入大小的關係(n)。程式設計的第一步是永遠關注程式的執行時間。
瞭解程式的資料結構
資料結構是每個複雜程式的核心。知道在什麼情況下使用什麼結構是一門獨立的藝術。資料結構直接與時間複雜性聯絡在一起，選擇錯誤的資料結構可能會使程式陷入停頓。
在陣列中搜索一個值是的時間複雜度是o (n) ，這意味著隨著陣列的大小的增加，搜尋陣列中的元素的開銷會增加。而在雜湊表中查詢一個元素的時間複雜度是 O(1) ，因此不管所說的雜湊表中鍵的數目如何多，查詢一個元素需要花費的時間將是常量。
閱讀/觀看/聽
像 Udemy、 Pluralsight 和 codeacademy 這樣的網站是學習新程式語言的絕佳資源。對於基礎知識，請閱讀有關一般工程概念、最佳實踐和編碼風格的書籍。對於工程師來說，最受推薦的書籍是《設計模式》、《重構》、《乾淨的程式碼》等等。最後，為了安全起見，每個工程師都應該在自己的辦公桌上放一本《演算法導論》。
練習
如果你不過分地拉小提琴，你就不可能成為一個優秀的小提琴家。像 hackerank、 CodeWars、 CoderByte、 TopCoder 和 LeetCode 這樣的網站有成千上萬的挑戰性問題，旨在測試你對資料結構和演算法的瞭解。我發現使用這些網站的最好方法就是自己嘗試解決這個問題，把你的解決方案放在 Github 上，然後看看這個問題的最佳解決方案，看看其他人是怎麼解決的。這就引出了我的最後一點:
檢視別人的程式碼
您在軟體開發過程中可能犯的最大錯誤就是單幹。軟體開發在很大程度上是一種眾包式的努力。我們一起建立標準，一起犯錯誤，並且隨著時間的推移學習什麼是有效的(通過多次失敗)。花時間閱讀熟練開發人員的程式碼總是會有回報的。只要確保程式碼是好的就行了。
總結
我能給你的最好的建議就是永遠不要為你不知道的事情感到羞愧。正如我所提到的，這個行業規模龐大，語言數量極多，內容密集。建立理解需要花費大量的時間和精力，獲得熟練程度需要更多的時間和精力，獲得掌握程度需要更多的時間和精力。我到了會告訴你的。