語言的數據親和力
目前，程序設計語言似乎進入了一個蓬勃發展的時期，Javascript、Perl、Python、Ruby、Groovy等一批較新的語言正越來越多地被熟悉和使用，而C++、C#、Java等主流語言也在不斷地融入函數式和動態性特征。程序員的百寶箱中可供選擇的寶貝是越來多了，而社區中關于語言間的比較和爭論也更為熱烈，我們常常見到關于“面向過程和面向對象的比較”、“動態語言和靜態語言的比較”、“命令式和函數式范式的比較”等比較。我注意到這類討論的關注點多集中于設計相關話題，如“動態語言的Duck typing多態和靜態語言的繼承多態的比較”，“Prototype based和Class based的比較”等。但我認為還有一個十分重要的方面值得關注，這就是數據處理。
數據處理之所以重要是因為不論是本地信息存儲還是系統間信息交換都需要建立在一定的數據格式基礎上。另外，不管語言屬于那種范式，設計上采用什么模式，在微觀層次上程序很大一部分工作都是在做數據處理。所以，從數據處理角度比較和理解語言間的差異有重要的現實意義。雖然數據通常是平臺和語言無關的，但不同的語言在處理某種格式的數據時會表現出不同的難度，甚至某些數據格式只能采用特定的語言才能實現，這就是數據親和力的不同。
語言的數據親和力(Data Affinity)指的是語言與某種數據格式之間的相容程度，它主要取決于語言的數據模型，類型系統，以及庫的支持等。語言對某種數據格式親和力越強，則操作某類數據越容易。
二進制字節塊格式
在偏底層的操作系統、嵌入式和通信系統中，二進制的字節塊是最常見的一種數據格式。二進制數據布局緊湊和接近機器的特點使得它常常作為系統間通信或系統文件的數據格式。但一般高級語言不方便直接和0101打交道，而是基于記錄、結構體和類等結構化表示操作數據，這就存在著在底層的二進制字節塊和高層的結構化數據之間的轉換問題。
C語言作為最主要的系統語言具有很高的字節塊數據親和力。這不僅因為C語言具有指針可以直接訪問內存以外，還因為C的結構體(struct)可以和字節塊建立起直接的映射關系。例如，在基于Socket連接的分布式系統中服務器端和客戶端通過二進制的字節數據進行通信，通信雙方只要事先定義共用的結構體，發送方先創建相應的結構體變量并填充字段，然后把變量對應的內存塊copy到Socket，接收方從Socket讀取字節塊，然后把字節塊強制類型轉換為相應的結構體指針即可讀取個字段信息。整個過程中通信的雙方都沒有復雜的信息編碼和解碼的過程。示例代碼如下：
int version;
char type[10];
float value;
};
//發送方
struct t_data data;
data.version = 1;
strcpy(data.type, “degree”);
data.value = 189.0;
send(socket, (char*)&data, sizeof(data));
//接收方
struct t_data data;
read(socket, (char*)&data, sizeof(data));
printf(“%d, %s, %f”, data.version, data.type, data.value);
上面的方法在實際應用中還需要注意內存對齊問題和大小端問題。內存對齊問題可以通過編譯器預處理命令來進行控制，保證內存中struct結構與傳輸的字節塊具有相同的對齊方式；大小端問題需要通信的雙方采用同樣的大小端方式，否則就需要進行轉換。
C++可以完全兼容C的結構體，但C++的類(包括class和struct)中如果定義了虛函數，則會喪失結構的字節塊數據親和力，這是C++編程時需要權衡的一個因素。而除了C/C++，其他語言中則難以見到字節塊數據親和力，其原因在于C/C++允許控制結構體/對象的內存布局，并允許對指針進行非類型安全的強制類型轉換，這都是在Java，C#等語言中不允許的。所以，在Java、C#中進行字節塊的編碼解碼就只能按照協議一個字段一個字段地按偏移量和長度進行解析。C/C++的指針以及結構體和內存的直接映射帶來了對字節塊數據的親和力，但同時也留下了內存訪問和類型安全的隱患；而Java、C#在擁有引用安全和類型安全的同時也失去了對字節塊數據的親和力。
文本格式
文本格式是另一種十分常見的數據格式。《Unix編程藝術》是這樣評價文本格式的："Text streams are a valuable universal format because they're easy for human beings to read, write, and edit without specialized tools ”。基于文本流的管道處理是一種備受贊譽的Unix風格。Shell可以通過管道把各種功能單一的命令串聯起來，讓文本流在管道上流動，因而Shell語言具有很好的文本數據親和力。許多文本數據處理任務Bash都可以一行搞定，這就是Hacker們酷愛的One Liner風格。
下面我們來看兩個用Bash進行文本處理的例子：
1. 統計當前目錄下的gz文件數目：
ls –l *.gz | wc –l
2. 在Web服務器日志service.log中統計2011年6月26和27兩天中每天各頁面的PV
service.log:
2011-06-2513:00:55 /music/c.htm Safari
…
2011-06-2608:01:23 /main.htm IE
2011-06-2608:03:01 /sports/b.htm Chrome
…
2011-06-2711:41:06 /main.htm IE
2011-06-2711:52:41 /news/a.htm Firefox
輸出:
2312011-06-26 /news/a.htm
1552011-06-26 /sports/b.htm
2882011-06-27 /main.htm
2922011-06-27 /news/a.htm
1612011-06-27 /sports/b.htm
上面的兩個簡單文本數據處理任務如果是在C或C++下實現則要麻煩得多，代碼量至少是十幾行或者數十行，加上編譯調試，整個開發效率可能比Shell低一個數量級。除了Shell外，Perl也是以強大的文本數據處理而聞名的。我們來看一個Perl正則表達式的例子：
if (/hello\s(\w+)/i) {
print “say hello to $1“
}
elseif (/goodbye\s(\w+)/i) {
print “say goodbye to $1”
}
}
輸入：
Goodbye bug
輸出：
say goodbye to bug
上面的例子中我們看到Perl直接進行字符串匹配并進行數據提取的強大威力。Perl基于正則表達式的字符串處理不僅比C/C++等系統語言更強大，甚至比Python這樣的動態語言也更強大和更方便，這是因為正則表達式是Perl語言的“一等公民”，這就使得Perl比其他以庫的方式支持正則表達式功能的語言具有更好的文本數據親和力。后來的Ruby也學習Perl直接在語言上支持正則表達式。
結構化文本格式
XML是最近十幾年來流行起來的一種通用（半）結構化的文本數據交換格式。XML除具有一般文本格式的優點外，還具有能層次結構表達力和可擴展性的優勢，所以它至誕生以來就被大量用于配置文件和各種Web Service中。現代程序設計基本都少不了和XML打交道，不過在C++、Java和C#幾種靜態類型語言中處理XML卻并不是一件十分輕松的事情。我們先來看一個Java解析和構建下面這個XML的例子：
<language>Java</language>
<language>Groovy</language>
<language>JavaScript</language>
</langs>
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse("src/languages.xml");
Element langs = doc.getDocumentElement();
System.out.println("type = "+ langs.getAttribute("type"));
NodeList list = langs.getElementsByTagName("language");
for(int i =0 ; i < list.getLength();i++) {
Element language = (Element) list.item(i);
System.out.println(language.getTextContent());
}
}catch(Exception e) {
e.printStackTrace();
}
//Java創建XML
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.newDocument();
Element langs = doc.createElement("langs");
langs.setAttribute("type", "current");
doc.appendChild(langs);
Element language1 = doc.createElement("language");
Text text1 = doc.createTextNode("Java");
language1.appendChild(text1);
langs.appendChild(language1);
Element language2 = doc.createElement("language");
Text text2 = doc.createTextNode("Groovy");
language2.appendChild(text2);
langs.appendChild(language2);
Element language3 = doc.createElement("language");
Text text3 = doc.createTextNode("JavaScript");
language3.appendChild(text3);
langs.appendChild(language3);
} catch (Exception e) {
e.printStackTrace();
}
為了解析和創建小小的一段XML代碼需要編寫如此冗長的Java代碼，而實現同樣的功能動態語言Groovy則十分簡潔：
def langs =new XmlParser().parse("languages.xml")
println "type = ${langs.attribute("type")}"
langs.language.each{
println it.text()
}
//Groovy創建XML
def xml =new groovy.xml.MarkupBuilder()
xml.langs(type:"current"){
language("Java")
language("Groovy")
language("JavaScript")
}
上面Groovy操作XML的代碼簡潔而富有表達力，代碼與XML幾乎是一一對應的，如同直接在XML上進行操作的DSL一樣，而相應的Java代碼則看不到XML的影子。這說明Groovy具有很高的XML數據的親和力。為什么Java和Groovy在XML親和力方面有這樣的差異呢？原因在于Java要求所有的方法和屬性都必須先定義再調用，嚴格的靜態類型檢查使得Java只能把XML元素作為“二等公民”來表達；而Groovy則沒有靜態類型檢查的限制，可以自由地使用方法和屬性來表達XML結構。上面用Groovy創建XML的例子中，groovy.xml.MarkupBuilder類中實際上并沒有langs, language這些方法，但會在調用的時候自動創建相應的XML結構。
除了XML外，JSON是另一種通用的半結構化的純文本數據交換格式，它常被視為輕量級的XML。JSON的本意是Javascript的對象表示(Javascript Object Notation)，它屬于Javascript的語法子集，Javascript對JSON有原生的支持。下面就是一個在Javascript中創建JSON對象的例子：
"type” : "current”,
"language” : ["Java”, "Groovy”, "Javascript”]
}
}
許多Javascript程序都會通過AJAX都從服務器獲取JSON字符串，然后把字符串解析為JSON對象。由于Javascript對JSON的原生支持，所以，在Javascript中解析JSON字符串可以采用通用的eval方式，如：
alert(json.langs.type);
甚至可以：
alert(json.langs.type);
不過eval的通用性帶來了一定的安全隱患，所以一般只建議對受信任的數據源采用eval方式解析JSON，對于不受信任的數據源可以采用專門的JSON解析庫。無論如何Javascript對JSON的原生支持都使得Javascript具有很高的JSON數據親和力。另外，Groovy 1.8也加入了對JSON的原生支持，操作JSON與Javascript一樣方便。
總結
到這里為止本文篇幅已經很長了，只能列舉二進制字節塊格式、文本格式和結構化文本格式3種典型的數據格式。實際上，數據親和力的話題還有很多值得探討的，比如C#的Linq。本文的探討算是拋磚引玉，目的在于引起大家注意在比較語言的時候不要忽略了數據親和力這樣一個重要方面。本文的錯誤或不足，敬請指正，謝謝！
留言列表
