語(yǔ)言、平臺(tái)、鏈接庫(kù)，這三者之間有很密切的關(guān)系。本文嘗試著以鏈接庫(kù)為中心，探討它們之間的現(xiàn)況。
語(yǔ)言與鏈接庫(kù)
語(yǔ)言通常會(huì)伴隨著鏈接庫(kù)，沒(méi)有鏈接庫(kù)的語(yǔ)言，差不多什么程序都寫(xiě)不出來(lái)。比方說(shuō)，用 C 語(yǔ)言寫(xiě)出一個(gè)印出 Hello 的小程序，你需要用到 stdio 的鏈接庫(kù)。用 Python 寫(xiě) GUI 程序，你需要 Tkinter 鏈接庫(kù)。
平臺(tái)與鏈接庫(kù)
平臺(tái)通常也會(huì)伴隨著鏈接庫(kù)，沒(méi)有鏈接庫(kù)的平臺(tái)，等于是擺明了不希望別人開(kāi)發(fā)此平臺(tái)的程序。比方說(shuō)，你想用 Visual C++ 6 開(kāi)發(fā) Windows 程序，你需要用到 GDI32 以及 USER32 或 MFC 等鏈接庫(kù)。寫(xiě) Mac OS 9 的程序，需要 Carbon 鏈接庫(kù)。
平臺(tái)的鏈接庫(kù) vs 語(yǔ)言的鏈接庫(kù)
在 A 平臺(tái)上用 B 語(yǔ)言開(kāi)發(fā)軟件，你會(huì)同時(shí)面對(duì) A 平臺(tái)的鏈接庫(kù)和 B 語(yǔ)言的鏈接庫(kù)，此二鏈接庫(kù)因?yàn)槭遣煌瑥S商所提供的，所以可能無(wú)法百分之百契合，特別是牽涉到內(nèi)存管理、資源管理、執(zhí)行緒等和操作系統(tǒng)有密切關(guān)系的主題時(shí)。如果你想進(jìn)行的某功能在 A 平臺(tái)的鏈接庫(kù)和 B 語(yǔ)言的鏈接庫(kù)都有提供，那么你應(yīng)該使用 A 平臺(tái)鏈接庫(kù)的版本，通常比較安全些。比方說(shuō)，用 C 語(yǔ)言開(kāi)發(fā) Windows 平臺(tái)的程序，如果你想配置內(nèi)存，那么你應(yīng)該呼叫 Win32 API 的版本（比方說(shuō) GlobalAlloc()），而非 C 語(yǔ)言的版本（比方說(shuō) malloc()）。
跨平臺(tái)的鏈接庫(kù)
你為某平臺(tái)所開(kāi)發(fā)的程序，為什么不能在別的平臺(tái)上重新編譯之后就能執(zhí)行？問(wèn)題就出在平臺(tái)的鏈接庫(kù)上。比方說(shuō)，你用 C 語(yǔ)言搭配 C 的標(biāo)準(zhǔn)鏈接庫(kù)和 Win32 鏈接庫(kù)，在 Windows 平臺(tái)上開(kāi)發(fā)出一個(gè)演示文稿軟件 WeakPoint 2000；你將 WeakPoint 2000 的原始程序拿到 Linux 上編譯，卻無(wú)法編譯成功，問(wèn)題就出在 Linux 沒(méi)有 Win32 的鏈接庫(kù)。
那么，如果有一個(gè)鏈接庫(kù)將各個(gè)主要平臺(tái)的鏈接庫(kù)萃取（abstract）出一個(gè)共通的鏈接庫(kù)，不就可以解決這個(gè)問(wèn)題了。例如 Qt 正是這么做，你的 C++ 程序如果只使用標(biāo)準(zhǔn)的 C++ 鏈接庫(kù)和 Qt 鏈接庫(kù)，你就可以把程序重新編譯之后在不同的平臺(tái)（Linux，Unix，Windows）上執(zhí)行。
語(yǔ)言 + 平臺(tái) + 鏈接庫(kù)
Java 就更了不起了，不但將鏈接庫(kù)統(tǒng)一起來(lái)，更將平臺(tái)統(tǒng)一起來(lái)，也就是說(shuō)程序不用重新編譯，就可以直接執(zhí)行。但是也因此，多了一層 JVM，犧牲了一部分的效率。
跨語(yǔ)言的鏈接庫(kù)
Borland 的 VCL 鏈接庫(kù)是在 Windows 平臺(tái)上相當(dāng)受好評(píng)的一套鏈接庫(kù)，可以被 C++ 和 Object Pascal（Delphi）使用。其實(shí)「跨語(yǔ)言的鏈接庫(kù)」不是一種很好的說(shuō)法，畢竟許多語(yǔ)言都可以連結(jié)外部原生鏈接庫(kù)，兩者不需要是同一種語(yǔ)言。但是這樣的連結(jié)是否需要大費(fèi)周章，則有相當(dāng)大的差異。而 Delphi 和 C++ Builder 使用 VCL 則是相當(dāng)方便的。
即將在本月底問(wèn)世的 Mac OS X，提供了 Cocoa 鏈接庫(kù)。Cocoa 鏈接庫(kù)可以被 Objective-C 和 Java 語(yǔ)言使用。Objective-C 和 Java 語(yǔ)言版的 Cocoa 鏈接庫(kù)相似性在九成以上。Java 在 Mac OS X 的原生程序設(shè)計(jì)上被簡(jiǎn)化成一個(gè)純語(yǔ)言，完全不使用 Java 的 API，只使用 Cocoa 鏈接庫(kù)，這倒是挺特別的。（當(dāng)然 Mac OS X 也另外會(huì)有 JVM 來(lái)支持一般的 J2SE）
語(yǔ)言規(guī)格 + 平臺(tái) + 鏈接庫(kù) = 包山包海 ?
.NET 比 Java 的眼光更高，甚至準(zhǔn)備將語(yǔ)言規(guī)格也統(tǒng)一起來(lái)。.NET 有一個(gè) CLS（common language specification），任何語(yǔ)言只要符合 CLS 這個(gè)標(biāo)準(zhǔn)，就可以輕易地整合進(jìn) .NET 平臺(tái)，享用 .NET 平臺(tái)的資源。這一點(diǎn)就是 Java 比不上的。雖然別的語(yǔ)言一樣可以設(shè)計(jì)出編譯器來(lái)將程序編譯成 Java bytecode，在 JVM 上執(zhí)行，但 Java 并沒(méi)有提供直接的支持，所以要移植一個(gè)語(yǔ)言到 Java，比移植一個(gè)語(yǔ)言到 .NET 來(lái)得困難。
.NET 雖然允許各種語(yǔ)言，但是為了因應(yīng) CLS，所以各個(gè)語(yǔ)言常常需要做出妥協(xié)更改語(yǔ)言本身，比方說(shuō) Visual Basic 的更改幅度就很大（Visual Basic 7 差不多是一個(gè)新的語(yǔ)言了），而 JScript 和 Visual C++ 的語(yǔ)言也都有改變。這種方式的語(yǔ)言中立性，無(wú)疑是削足適履。有了 CLS 的規(guī)范，這些語(yǔ)言會(huì)趨于一致，思維模式如出一轍，只有一些微不足道的小差異。歷史會(huì)證明，C# 會(huì)是 .NET 平臺(tái)上獨(dú)大的語(yǔ)言，.NET 上的其它語(yǔ)言都將淪為點(diǎn)綴，這么一來(lái)，跨語(yǔ)言的宣示，竟成了一個(gè)幌子。雖然我對(duì) .NET 的語(yǔ)言中立性這點(diǎn)頗有疑異，但我倒是挺喜歡 .NET framework 的，我忍不住豎起大拇指稱(chēng)贊 .NET framework 是「歹竹出好筍」。
.NET 的語(yǔ)言規(guī)格和鏈接庫(kù)都是統(tǒng)一的。命運(yùn)多舛的 Eiffel 將 .NET 視為救命的浮木，準(zhǔn)備將 Eiffel 移植到 .NET，但這么一來(lái)，Eiffel 勢(shì)必得放棄自行開(kāi)發(fā)的 Windows 專(zhuān)用鏈接庫(kù) WEL（Windows Eiffel Library）與跨平臺(tái)的鏈接庫(kù)（比方說(shuō) EiffelVision 等）。難道 Eiffel 沒(méi)有發(fā)現(xiàn)它所以為的浮木，其實(shí)是鱷魚(yú)偽裝的？
同樣的問(wèn)題也會(huì)發(fā)生在 Delphi 上，如果 Delphi 準(zhǔn)備移植到 .NET，也必須更改一部分的語(yǔ)言特性，并可能要放棄在 .NET 上使用 VCL（CLX）。Delphi 這么做一點(diǎn)好處都沒(méi)有。
最亂的時(shí)代，最好的選擇
看完這篇文章，你可能已經(jīng)頭昏腦脹了。沒(méi)關(guān)系，你只要記得下面這句話就好了：最亂的時(shí)代，最好的選擇 ...Java。