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