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