當前程式語言正處於蓬勃發展期：JavaScript、Python、Ruby、Groovy 等新興語言廣泛普及，而 C++、C#、Java 等主流語言也持續融入函數式與動態特性。開發者的選擇愈發豐富，社群關於「面向過程 vs 面向對象」、「動態 vs 靜態」、「命令式 vs 函數式」的辯論從未停歇。然而，這些討論多聚焦於設計層面——如 Duck Typing 與繼承多態、Prototype-based 與 Class-based 的對比——卻常忽略一個極具實務價值的維度：資料處理能力。
無論是本地儲存還是系統間交換，資料皆建立在特定格式之上；而在微觀層次，程式碼的絕大部分工作皆在進行資料搬運與轉換。雖然資料格式本身與平台、語言無關，但不同語言處理同一格式時的難易度截然不同，甚至某些格式只能靠特定語言高效實現。這種「語言資料模型與資料格式的匹配程度」，即為資料親和力。親和力越強，操作該類資料越輕鬆。
在作業系統、嵌入式、通訊系統等底層領域，二進位位元組塊是最常見的資料格式。其記憶體佈局緊湊、貼近機器，常作為系統通訊或檔案格式。但高階語言通常基於結構化表示（記錄、結構體、類）操作資料，因而面臨「底層位元組塊 ⇄ 高層結構化資料」的轉換問題。
C 語言憑藉指標與結構體記憶體佈局的精確控制，擁有最高的位元組塊親和力。在基於 Socket 的分散式系統中，雙方預先定義共用結構體，發送端填充欄位後直接將記憶體塊寫入 Socket，接收端讀取後強制轉型為結構體指標即可存取欄位——全程無編碼/解碼開銷。
struct t_data { int version; char type[10]; float value; };
// 發送端
struct t_data data;
data.version = 1;
strcpy(data.type, "degree");
data.value = 189.0;
send(socket, &data, sizeof(data));
// 接收端
struct t_data data;
read(socket, &data, sizeof(data));
printf("%d, %s, %f", data.version, data.type, data.value);實務中需注意記憶體對齊（透過編譯器指令控制）與大小端序（雙方約定一致或轉換）。
C++ 完全相容 C 結構體，但若類別定義了虛函數，將引入虛函數表指標，破壞記憶體佈局的連續性，喪失位元組塊親和力——這是系統級 C++ 開發時的關鍵取捨。
Java、C# 為了引用安全與型別安全，禁止指標運算與非型別安全的強制轉換，也就失去了對位元組塊的直接映射能力。處理二進位協議時，只能逐欄位按偏移量與長度解析，代碼冗長且易錯。
《Unix 編程藝術》讚譽文本流：「易於人類閱讀、撰寫、編輯，無需專用工具」。基於管道的文本處理是 Unix 風格精髓，Shell 語言因此擁有極佳的文本親和力，許多任務僅需「One Liner」即可完成。
# 統計 .gz 檔案數
ls -l *.gz | wc -l
# 統計特定日期的頁面 PV
cat service.log | grep '^2011-06-2[6-7]' | cut -d ' ' -f 1,3 | sort | uniq -c若用 C/C++ 實現，代碼量至少數十行，開發效率相差數量級。
Perl 將正則表達式內建於語言核心，而非以庫形式提供，賦予了其無可匹敵的文本處理表達力：
while (<STDIN>) {
if (/hello\s(\w+)/i) { print "say hello to $1\n"; }
elsif (/goodbye\s(\w+)/i) { print "say goodbye to $1\n"; }
}輸入 HeLLo world、Goodbye bug，輸出對應問候。Ruby 後來也借鑑了這一設計。
XML 能表達複雜層次，廣泛用於配置檔與 Web Service。但在 C++、Java、C# 等靜態類型語言中處理 XML 卻異常繁瑣。以 Java 解析/構建簡單 XML 為例，代碼動輒數十行，充斥著工廠、建構器、節點操作等樣板代碼，與資料本身的簡單結構形成鮮明對比。
資料親和力是評估語言適用場景的關鍵指標，卻常被設計層面的討論掩蓋。C/C++ 稱霸二進位，Shell/Perl 擅長文本，動態語言在結構化文本上常更靈活。理解這一維度，能幫助我們在具體任務中做出更務實的語言選擇，而非盲目跟隨範式之爭。
