為什麼 VB 裡面是 Dim?從 BASIC 行號到 Excel VBA 的歷史演進

| Visual Basic | 1 Reads

在很多人眼裡,VB(Visual Basic / VB.NET)看起來「老派」、「不主流」。但如果我們回頭去看它的歷史,你會發現這些奇怪的關鍵字、設計方式,背後其實都有時代的印記。
本文將從 Dim 的由來講起,一路談到 BASIC 的行號、子程序、VB.NET 的地位,以及為什麼 Excel 至今還沒有淘汰 VBA。


1. Dim 是什麼?為什麼不是 Declare

在 VB 裡,我們用 Dim 來宣告變數,例如:

Dim x As Integer
Dim name As String
Dim arr(10) As Double

這個關鍵字其實來自 Dimension(維度) 的縮寫。在 1960s 的早期 BASIC 裡,變數本來不需要宣告,直接用就行。但陣列需要指定大小,於是才有了 DIM 命令:

10 DIM A(10)   ' 宣告一個 10 元素的陣列
20 DIM M(5,5)  ' 宣告一個 5x5 矩陣

隨著 Visual Basic 的出現,微軟決定「繼承」這個語法,把 Dim 泛化為所有變數的宣告方式。

而另一個關鍵字 Declare,則被專門用來聲明「外部函數」(DLL 函數),比如:

Declare Function GetTickCount Lib "kernel32" () As Long

這樣一來,DimDeclare 的語義被區分開來:

  • Dim = 我要一塊記憶體空間(內部變數)

  • Declare = 我要告訴編譯器外部有一個函數

  • Const = 我要一個常數

  • Static = 我要一個靜態變數

這樣的關鍵字設計,其實是 內存 vs 外部接口 vs 常數 的清楚分工。


2. 為什麼 BASIC 要行號?為什麼從 10 開始?

在早期 BASIC 程式裡,你會看到這樣的代碼:

10 PRINT "HELLO"
20 GOTO 10

這裡的 1020 並不是變數,而是 行號 (Line Number)

作用

  1. 指定程式執行順序(按行號大小執行)。

  2. 作為 GOTOGOSUB 的跳轉目標。

  3. 幫助「編輯」程式 —— 在沒有現代 IDE 的年代,你只能一行一行輸入和修改。

為什麼從 10 開始、每隔 10?

雖然可以從 1、2、3 寫,但大家更習慣用 10,20,30…。理由是:

  • 方便插入新行。比如要在 10 和 20 之間加一句,就可以用 15

  • 如果行號用滿了,可以用 RENUM 命令重排。

這不是語法強制,而是 程式員的共識
你甚至可以用行號 0(0 PRINT "HELLO"),但幾乎沒人這樣幹,因為容易混淆。


3. BASIC 沒有函數?那怎麼辦?

早期 BASIC 的確沒有「自定義函數」的概念。
只能用 GOSUB ... RETURN 來模擬子程序:

10 INPUT "Your name"; N$
20 GOSUB 100
30 END

100 PRINT "Hello "; N$
110 RETURN

這樣的「子程序」:

  • 不能帶參數

  • 沒有回傳值

  • 全靠全域變數傳資料

所以說,早期 BASIC 更像是 面向過程的初級形態

到了 QuickBASIC (1985),才正式加入 SUBFUNCTION,能定義參數與回傳值。再到 Visual Basic (1991),才徹底進入「結構化程序設計」。VB.NET 則進一步支援完整的 OOP(物件導向)

👉 BASIC 的演進路線可以概括為:
指令流 (Line Number + GOTO) → 面向過程 (GOSUB) → 結構化 (SUB/FUNCTION) → 物件導向 (Class in VB.NET)


4. 那 VB.NET 還「爛」嗎?

很多人覺得 VB.NET 過時,其實這要分兩方面看:

技術層面

VB.NET 本質上與 C# 一樣強大,因為它們都跑在 .NET CLR 上。

  • 有 OOP、LINQ、Lambda、Async/Await。

  • 能做 WinForms、WPF、ASP.NET、Entity Framework。

  • 編譯出來的 IL 幾乎與 C# 無差。

👉 VB.NET ≠ 技術爛

生態層面

  • 微軟從 .NET Core 開始,重心轉到 C#。

  • 新特性、範例、教學幾乎只有 C#。

  • 社群規模懸殊,VB.NET 幾乎只剩「維護老系統」。

👉 VB.NET = 被邊緣化


5. 為什麼 Excel 只能寫 VBA,而不是 C#?

Excel 的巨集(Macro)一直用 VBA (Visual Basic for Applications)
很多人納悶:為什麼不用 C#?

原因

  1. 歷史包袱:1993 年 Excel 5.0 就內建 VBA,至今數億份文件依賴它。

  2. 使用者族群:會計師、分析員不是程式設計師,VBA 更容易學。

  3. 內建引擎:VBA 是解譯器,程式碼可以直接存進 .xlsm 文件,C# 需要外部 CLR,太重。

  4. 安全與部署:VBA 宏能夠被 Excel 管控(雖然仍有安全風險),而 C# 如果內建,宏病毒會更危險。

微軟的替代方案

  • VSTO (C#/VB.NET Add-in) → 部署麻煩,沒普及。

  • Office.js (JavaScript API) → 用於 Web Add-in,不是宏。

  • Office Scripts (TypeScript) → Excel Online 的新方向,但還不成熟。

為什麼沒淘汰 VBA?

不是因為性能,而是因為:

  • 巨大的歷史相容性成本。

  • 使用者群體對 VBA 依賴太深。

  • 微軟還沒找到能完全取代的解決方案。


6. 總結:從 Dim 到 VBA,背後的邏輯

  • Dim:原本只為陣列(Dimension),後來泛化為所有變數的宣告。

  • 行號:為了在沒有 IDE 的年代方便插行,於是大家用 10,20,30

  • 子程序:早期 BASIC 沒有函數,只能用 GOSUB,算是面向過程的起點。

  • VB.NET:技術上很強,但社群與戰略上被邊緣化。

  • Excel VBA:不是性能最佳,而是「相容性 + 使用者群體」決定了它至今不死。

👉 這些設計看似「奇怪」甚至「落後」,其實都是當年 時代背景 + 實用妥協 的結果


✍️ 如果你今天在用 VB.NET 或 VBA,別急著笑它「爛」——它們其實是歷史演進的活化石,也是微軟工程哲學裡「兼顧相容性與現實需求」的最好見證。

This article was last edited at