這大概是在邁入多核 64-bit 又要考慮 multithreading 又要考慮跨平台的年代裡開發 framework 的某種感想吧。

重新寫起程式之後，倒是花了相當、相當、相當長的時間，才又像某種緩慢的吸體一樣，把對命名和縮排規則的看重，變為自己的一部分。然後看著自己從前寫的 code ，就會不可思議起來：天啊，我真的當時允許自己寫出這樣的東西來？！

但即使到了現在，我們仍然不時會為命名規則所苦。這裡講的是廣義的命名規則，還包括了標點符號、斷字、大小寫。我們會為了，好比說，Objective-C 的 instance variable 到底要用底線開頭（Apple/WebKit 風格）還是 m_ 開頭（業界普遍流傳、或者說某種被 MS 污染〔誤〕的 C++ 風格），就讓我們頭痛不已。那麼 Interface Builder 相關的成員呢？

命名麻煩的地方在於，它會隨著時間和潮流的改變而跟著變化。甚至，其實命名或許是第一個反應變化的事物，因為世界本來就是在命名之後才生的（這一點可以扯上更多思考與說法，在此不表）。當我們發現 Apple 竟然自己有 sample code 開始使用 mSomeVariable 的時候，著實訝異，卻還猜不透：這種命名改變背後究竟是被什麼考量所驅使的呢？

然後是看到大公司發表的 C++ 寫作風格。閱讀該文件，有如某種經文研究，裡面竟然每一條規則都以某種詰問或者至少是 pros and cons 體裁撰寫。

風格沒有一定，貴在一致和便利。但是大公司的寫作風格跟我認知或習慣所用的很不相同。有的甚至完全逆著我的考量而行之，有的則是在、例如說、前十條規則如此成立之後，就不得不然。

另一方面，這種由諸多規則堆積起來的風格，必有相當多的例外、互相衝突之處（於是又回到了以前學外語時，課堂的鐵律：規則是為了例外而存在的……），以及某種因為要想辦法推廣至每個環節，而某種制度必然帶來的不快（照說風格跟規則不至於帶來情緒……），但是這個世界往往以我們難以理解的方式彰顯自身。我們以為掌握風格，結果是風格在撰寫我們。

不過，再怎麼說，我應該再也不會、也不敢、也不願，寫出像 fooidx (fooIndex), barcnt (barCount), lahlahrfcnt (lahlah… WhatThe????) 這樣的東西了吧。我也會記得變數跟 operator 之間一定要有空白、大括號要打在正確位置、還有絕對不斷行（這一點是從 Delicious Monster 作者 Wil Shipley 學來的，他曾經說過類似人類發明寬螢幕就是給你寫程式不斷行用的、類似這樣的話）。

就好像我會記得大標題裡面 a 不能大寫但 The 首字要大寫那樣……

每次打開編譯器的最佳化選項時，都會想到這句話。嗯，雖然其實原意並非如此啦。

雖然最初的出發點還是捷運，但是之後想的其實是，我們要怎麼樣才能從自己所感受/感知的不滿中尋找改善的可能。而不是永遠從參考點來告訴自己其實很suck，或是其實還不錯。這樣的事情。生活如此，制度如此，軟體也是這樣。

驚覺很久沒有更新 blog。顯然我對這件事情還沒有太多發自於內心的不滿。

我們曾經為了這個問題困擾很久。現在犯人抓到了：Logitech Control Center。

跟一位 Growl 開發者通過信後，發現受害者名單還包括有 Growl (另有FAQ ), TextMate, AquaTerm, CrossOver games 等等。

技術上的原因是 Logitech Control Center 搶走了 Cocoa 應用程式的 [NSConnection defaultConnection]，以致於任何以這種方式取得連接的軟體，都有可能 break。這樣說好了：你好歹也是個泛應用程式層級的 plug-in，怎麼可以寫出會把應用程式搞爛的 code 呢？

雖然說 Growl 已經提出了自己的繞行方案 (workaround)，但是問題根本還是出在 Logitech 使用了非常、非常、非常、非常、非常糟糕的程式寫法。

上述 TextMate 的連結中有針對「到底是誰的錯？」做討論──許多使用者一開始會怪罪 TextMate。比較有建設性的作法，說真的，還是應該請 Logitech 用家們寫信給 Logitech 工程師。

其實感覺很不爽。Logitech 這種搞法，用一句話來說，叫：乞丐趕廟公（khit-tsia̍h kúaⁿ biō-kong）。

太不專業了吧。

永和有永和路，中和也有永和路， 中和有中和路，永和也有中和路； 中和的中和路有接永和的中和路， 永和的永和路沒接中和的永和路； 永和的中和路有接永和的永和路， 中和的永和路沒接中和的中和路。

最近發現，世界上存在不少類似結構的東西，例如：

Vista 64 有 System32 ，也有 SysWow64，System32 裡面裝的是 64-bit 的 binaries，SysWow64 裡面裝的是 32-bit 的 binaries。Vista 64 的 64-bit binaries 不能放進 Vista 64 的 SysWow64 裡，Vista 64 的 32-bit binaries 不能放進 Vista 64 的 System32 裡。

又或者：

Cocoa 有 NSString，Carbon 有 CFString，Cocoa 的 NSString 可以接 Carbon 的 CFString，Carbon 的 CFString 可以接 Cocoa 的 NSString。Carbon 的 CFString 沒有 garbage collection，Cocoa 的 NSString 有也可以沒有 garbage collection。Carbon 的 CFString 可以接到 Cocoa 沒有 garbage collection 的 NSString 裡，Cocoa 有 garbage collection 的 NSString 不能直接接到 Carbon 的 CFString 裡。

對，總歸一句話就是，不鬼打牆時候就不會覺得這樣的設計會鬼打牆，鬼打牆的時候就真的覺得這樣的設計真是鬼打牆……

那麼作為漢語書寫用的中文，有沒有這樣的東西呢？

今天想到一種：sinojapanocoreanogram (”CJKgram”)，意思是僅能使用中日韓共通的漢字來書寫。規則很簡單，不能使用另一種書寫系統不存在的字符。例如「書寫」就不能用，因為並非（嚴格定義上的）簡體字字符。

於是，以下這句話：

「僅能使用中日韓共通的漢字來書寫，繁體字才有的，或是簡體字才有的，就不允許使用。」

就可能得書寫成：

「只能使用中日以及其中那地方等三地的方型字做文，很久以前就在用的字才有的，或是容易一些的字才有的，就不能使用。」

（很不幸的，韩国的相关称呼或历史称呼，高丽、朝鲜、新罗、百濟似乎都没有好的通用字。「汉字」很不幸地本身就是非通用字。）

相對之下，antebellumkanjigram（我自造的詞，意思是使用「二次大戰前日本還沒將和製簡化漢字標準化後的漢字來書寫」）就容易多了。上述句子只要改掉「書寫」一詞就可以了，因為日文漢字似乎做「冩」（無上頭的一點）。

當然，對本身就使用繁體字的我們來說，magnacinquogram macropentagram (”Big5gram”)，或是對本身就使用簡體字來書寫的人來說，extendronatiogram (”GBgram”) 就是沒有意義的了。

一但開始練習 sinojapanocoreanogram ，就會發現有太多繁體字的常用字，在簡體字中都被簡化過（主要是偏旁部首造成的）。因此如果僅限制使用通用字，書寫的難度，看來是要比 Simple English 要難得多，如上例所示。

當然，如果按照趨勢，未來可預見，台灣各地將越來越多簡體字標示或說明，那麼除了簡繁轉換filter外，或許針對兩種文字的書寫慣例（句法風格或文法差異）的探討，也會增添更多實用價值。

註：其實， -gram 用拉丁前綴是不對的。But (1) they are all Greek to me, (2) 計算語言學家自己就用 bigram 了（照理說應該是 “digram”）, so…

在朋友 MSN 上看到這樣的串連活動：要求電影院把電影的完整片尾給放完。

我從來不參加串連，所以就不列出網址了（搜尋一下很容易找到）。我看了一下原發起人的文章和相關回應，很有趣。

我所記憶以來，台灣只有兩個場合會把片尾，所謂 closing credit，給完整放完。一個是影展。一個是外商影城。後者就我最近經驗，也每下愈況。

生活中保有一些「對完整的堅持」有這麼困難嗎。更何況，我們講的是「作品完整性」這一件事情呢。

就實用的價值來看，片尾有好幾種功用。會放 NG 或搞笑片段的電影排除的話，closing credit 一定會提供的資訊有：演員名單、工作人員名單、音軌清單、拍攝地點。

我其實並沒有對 closing credit 做過什麼有系統的研究。不過很可能這是小時候養成的癖好（我曾經被家人問過：為什麼就是非得把片尾看完？），再加上對名字（事實上是任何的名詞）有狂熱，我的粗淺觀察是，從小到大看的科幻片中，”visual effect” 或 “computer graphics” 一項，80 年代出現過不少日本人，90 年代華人的名字比較多，到了近十年，則幾乎非歐美人士的名字裡，都是韓國人的名字。所以，或許 closing credit 也可以視為某種產業指標？

這種都是實用主義傾向的辯護就是了──就如同我看書本的 colophon 或 copyright page 是為了想知道書本是用哪一套字體編排，或是買成藥看 fine print 是想要知道不能喝完酒後服用一樣。（事實上我有個理論是，廣告、保單、軟體授權，這些裡面的 fine print 其實我等現代人的 daily ritual，不過這有待來日說明吧）。

但是，實用的價值之外，或許更重要的還是那些一點都不實用、一點都對電影「播放」本身都沒有影響的、形而上的東西吧？保有作品的完整性，難道不是一種對作品的尊重嗎？就好比說，書本不可能截去封面封底來販賣一樣。聽音樂會，大家也不會在樂團謝幕之前就開燈走人。那麼為什麼電影不可以呢。

更何況，大家恐怕無法想像，影展片如果遭受這種對待，會是什麼德性吧。那為什麼一般的電影就不行呢。

其實會坐在觀眾席上把片尾看完的人還真不少（看影展就知道了）。有些人說，「片尾哪有什麼人看」。這其實是倒果為因。正是因為台灣太多不播片尾的電影院，大家也只能燈亮走人啊。

應 OSDC.tw 的邀請，上週六下午給了一個題目為「開放原始碼、開放資料與日常生活的語言應用」（Open Source, Open Data in Everyday Handling of Natural Languages）的分享。題目有點長，內容也有點雜。主要的企圖還是在區分日常生活語言問題的種類，以及圍繞在中文的核心問題──斷字──上面。

「問題意識」（problems）上，日常生活的語言問題，主要還是在怎麼將之編目索引檢索。除非你的應用程式本身就是語言應用（language-specific applications）。這個部分有一些地方跟 l10n/m17n/i18n 有重疊處，但這並不是同樣的兩件事。另外一個我試圖（但沒有很成功）想要講述的方向是，我們這些講中文的人應該試圖去處理中文以外的語言，切莫認為我們只需要處理中文就好（而且事實上中文也並非是如我們被教育成的，是一種均質的語言，「中文」本身諸元的差異或許就和中文與其他語言的差異一樣地多）。

在「方法論」（methods）的段落，我簡短介紹了兩種「正規」的方法，基於觀察中文構詞型態的MMSEG以及基於language model的方法。事實上相關的研究很多，implement說來比較偏工程問題。（中文自動選字）輸入法的問題其實只是其中的一種變體，把輸出改成音素，輸出改成可能的最佳句子就是了（用最化約的方法來說）。

在「工具」一段，所介紹的大多數工具仍是以 Perl 為主。Perl 在語言處理上仍然是最強大的語言之一，也是大多數相關工作的首選。我不熟 Python ，所以用 Python 寫的 NLTK 等工具，就無法多說什麼。Ruby 在這方面很弱。當我說「如果你用 C++ ，那沒有人救得了你」時，沒想到大家竟然反應熱烈地笑了。這句話，出自一個還是必須用 C++ 來解決問題的人嘴裡，其實是很辛酸的呀。

「資料」的問題，還是跟 Hans Rosling 在講公共衛生議題的相關 TED talks 的那句話一樣：資料就都在那邊，可是卻沒有辦法開放出來。

準備這次主題的一個額外的收獲是，我深深感受到日文相關軟體計畫，無論在規劃，募集資料、或者看問題的方法、甚或是 C library header file 的組織上，都有很多可以借鏡的地方。另一方面同樣看到的問題是，編碼的需要現代化（例如 anthy 仍是 Shift JIS-based）、程式語言的需要現代化（需要引進 C++ 來使得語言物件──音節、音素、unigram──等等可以被當做型別來操作）等等挑戰。

總之還有很多很多要努力的地方啊。