愛恨交織！我們經常抱怨卻離不開的7種語言

【編者按】本文作者 Peter Wayner 是 InforWorld 特約編輯，也是超過16本書的作者，其著作涉及開源軟體、全自動汽車、保密加強型計算、數字交易等廣泛題材。其最新著作為《未來的駕座(Future Ride)》第二版，主要描繪全自動汽車在未來將如何改變世界。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現，以下為正文。

但凡是以程式設計為生的人，肯定不會給出不要心懷怨懟的好意規勸。只要經歷過複雜到萬劫不復的邏輯，你就會了解那些最糟糕的程式錯誤有多恐怖。

當然，每個人都會愛上他們最早相遇的計算機語言。為什麼不呢？最簡單的“hello world”示例，短短三行程式碼就能表現出這門語言的神通廣大。雖然程式語言應該具備隱含邏輯，但這並不意味著他們的邏輯應該隨處可見。一個討人喜歡的酒保能使整個酒吧的氣氛更加歡樂。一個勇敢的消防員會輻射出鼓舞人心的膽量。但是，程式語言的邏輯機制卻往往孕育出不合邏輯、混亂甚至疑惑。

不過，聲稱程式語言沒有邏輯顯然是不合常理的。但我們還是經常這麼說，因為我們知道邏輯也有其限制。從 Gödel 到 Turing，我們逐漸意識到邏輯機制在其邊緣地帶也會催生出可怕的場景。當然，這可能是我們人類的責任，因為我們的誤用或程式設計不當所致。但是，如果程式語言促使我們選擇了危險的道路，語言本身也是難辭其咎的。

而且，我們往往對此無能為力。已經安裝好的基礎環境或許太大，因此我們無法放棄讓自己惱怒的語言。老闆可能特別鍾愛某個技術棧，以致於無法容忍來自辦公桌的怨言。更為殘忍的現實是：你沒有更好的選擇。我們已經在使用人類所能打造的最佳工具了。

以下是7種我們常常抱怨但卻離不開的程式語言。

1、C

有關該語言的問題如此之多，以致於它更應被稱為“可移植彙編器”，而不是完整的計算機語言。有人喜歡編寫分開的標頭檔案麼？有人在用前處理器處理複雜的內容時不會感到煩躁麼？

理論上，我們應該可以運用指標運算巧妙地實現豐功偉績，但是大家除了用其分配資料結構，還做了什麼呢？巧妙地利用指標是否真的值得鼓勵？這正是程式碼開始崩壞的地方。如果你能巧妙地使用指標，往往還需要編寫非常長的註釋以實現完善的文件，而這常常會消耗很長的時間，甚至抵消了巧妙程式碼所節省的時間。有人能記住為了避免所有可能的安全漏洞（比如快取溢位）所需牢記的所有 C 語言編寫規則麼？

但是，我們別無選擇。Unix 是用 C 語言寫的，而前者執行著大多數手機與大多數雲。並非每個為這些平臺編寫程式碼的程式設計師都需要使用 C 語言，但是總得有人熟悉星號與花括號，否則一切都可能崩塌。此外，還有許多裝置驅動程式與其他嵌入式程式。總得有人承擔維護 Linux/Unix 程式碼庫並不斷開拓進取的重擔。

2、JavaScript

JavaScript 的創造者試圖打造更為先進的語言。可惜的是，他們的聰明智慧導致我們要不停地計算花括號，方括號以及圓括號的數量——同時還要保證它們的巢狀合理。此外，在匿名函式、閉包以及 JSON 資料結構之間的往來調停，導致我們總是在鍵盤上忙個不停。

此外，還有許多奇奇怪怪的細節。假設 x 是包含著字元 1 的一個字串，則 x+1 會得到字串 11，而 x-1 會得到數字零。有人記得 false,null, NaN 以及 undefined 之間的區別麼？他們看起來很相似，但是 JavaScript 為什麼要設定它們四個呢？而且，它們為什麼表現不一致呢？

不過，我們抱怨再多也沒有用。網路、全球資訊網以及不計其數的瀏覽器並不會因此改變。並且，機靈的 Node.js 團體來了，迫使我們在伺服器端編寫 JavaScript 程式碼。堅持不用 JavaScript 的想法估計只能持續幾秒鐘，一旦開始檢查郵箱，或者網路購物，就只好屈服了。筆者相信，JavaScript 會相伴我們很久很久。

3、PHP

PHP 其實不算真正的計算機語言。它更像是為靜態 HTML 新增智慧的工具。你可以在資料庫中儲存資訊，並使用靜態標籤連結這些資訊。可能還存在一些別的特性，但對筆者而已，PHP 的主要功能是連結從資料庫中抓取來的字串。

不過，爭論無足輕重的程式碼或幼稚的語法顯然沒有必要。現而今，大多數網站都是用 PHP 搭建的。WordPress, Joomla 以及 Drupal，大多數網站內容都是通過 PHP 程式碼呈現的。此外，還有用 PHP 搭建的 Facebook，越來越多地佔用了人們花在網路上的時間。我們應該感到高興，Facebook 開發了 HipHop 虛擬機器，啟發 Zend 打造了 PHP 7.0。這些全新的 PHP 引擎往往能帶來兩倍的速度提升，節省數百萬元的電力，這幾乎是令人無法抗拒的誘惑。在未來，PHP 仍將繼續保持活力。

4、Cobol

Cobol 早在1959年就出現了。按理說，它應該是充滿百來個限制詞，語法複雜的老古董才對。但是，Cobol 的擁躉仍在不斷更新其版本，從其他語言中借鑑新思想，再融入年近六旬的框架中。你知道 Cobol 2014 麼？它包含了動態表格——人們早在2002年就想將其納入該語言。Cobol 其實沒有那麼老。你以為它在70年代就無人問津了？其實你大錯特錯了。

我們可能擁有更好的用來編寫業務邏輯以操控資料庫的工具，但是沒人在意這些工具。原因是，我們只需購買一個更大的計算機，就能讓 Cobol 程式碼繼續執行。在筆者寫這篇文章時，Dice.com 網站上有543個涉及“Cobol”的任務。在保險公司與國防承包商的系統中，充滿了 Cobol 任務。最早採用大型主機的企業們還在使用 Cobol，並且能夠順利完成工作。電腦科學家可能會有些退縮，但是隻要客戶還在穩定增長，老闆會說：“既然還沒壞，就不用修了。再買一臺大型機吧。”

5、XSLT

所有人一開始都會愛上 XSLT，一種轉換 XML 的函式式語言。當你需要抽取 XML 文件的零碎片段時，XSLT 是能夠順利執行的智慧方案。但是，一旦老闆要求一些比簡單的搜尋、替換更為複雜的資料，開發就會陷入困境。XSLT 是顯式的函式式語言，我們很快就會發現，當文件中出現“變數(variable)”時，其使用方法更像是代數老師，而非程式設計師的做法。仔細想想 XSLT 專家 Bob DuCharme 充滿禪意的這句話吧：”XSLT 變數實際上與許多程式語言中的常量有很多相似點，並且使用目的也很相似。“如果你想把 XSLT 中的變數用得像其他計算機語言中的變數一樣——也即，其值可變——你要非常聰明才行。

XML 或許正失勢於 JSON 之類更加高效的資料格式，但它仍是許多大資料處理器的強有力基礎。你可以不使用 XSLT，轉而編寫能解析文字自身的基礎程式碼。然而，編寫這些程式碼以解析 XML 往往比掌握 XSLT 結構更加費時費力。

6、Java

Java 虛擬機器與函式庫可能來自90年代，但是其語法卻來自 C 語言誕生的70年代。自動記憶體管理似乎是很大的進步，但是當垃圾回收程式佔據主動時，應用程式碼就得歇一歇了。Android 開發者常常交換意見，討論何時適當地提早請求垃圾回收，從而確保在重要事件，諸如急救電話中途避免垃圾回收。

Java 開發者已經就諸多問題抱怨了很長時間，其中一些問題可能已經得到 Oracle 的解決，或至少引起了一定的重視。但是，這引來了一個新問題。一些新的程式碼與庫沒法與舊版本的 VMs 相容。筆者曾經花了一天的時間探索 java.lang.UnsupportedClassVersionError，但未能找到永久的解決方案。似乎，自 1.4 之後的每個 Java 版本，都是一種新語言。

不過，以上問題都不重要。Java 是 Web 與移動手機的基礎。它是許多高中開授的第一種計算機語言。其函式庫的集合比幾乎任何一種語言都更為豐富，也更具價值。為何還要使用其他語言呢？

7、Python

Python 是年輕程式設計師熱衷使用的摩登語言。其標點符號很少，所以程式碼看起來更加簡潔。那有什麼缺點呢？Python 2.7 與 3.0 版本間的代溝頗為明顯。這是使 Python 更上一層樓的唯一選擇，但是這一飛躍的幅度太大，以致於使用者必須時刻了解自己當前使用的語法版本。也就是說，我們永遠都要記得檢查所安裝的 Python 版本。

此外，有多少人喜歡計算用來縮排程式碼塊而新增的空格數？計算花括號的數量已經夠磨人了，計算空格符的數量則需要等寬字距(monospace)編輯器。

但是，這些問題並不重要。因為人文科學家們已經帶著熱情而又模糊的情感傾倒在 Python 的腳下。生物學家與經濟學家們認為 Python 是唯一選擇。一些人甚至建議在股票與債券的售股章程中納入對 Python 編碼的需求，好像投資銀行家可以通過 Python，而不是精心編造的銀行學說辭忽悠我們。

不過，好訊息是，Python 語言比銀行家的”語言“更好懂。這真是一大進步——即便這意味著我們要計算空格的數量。新的潮流已經到來，而且它收穫了許多人文科學家的支援。

本文系 OneAPM 工程師整理呈現。OneAPM 能為您提供端到端的應用效能解決方案，我們支援所有常見的框架及應用伺服器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，效能監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術部落格。

本文轉自 OneAPM 官方部落格

原文地址：http://www.javaworld.com/article/3074858/java-language/7-programming-languages-we-love-to-hate-but-cant-live-without.html