http://lukhnos.org/blog/zh "Entia non sunt multiplicanda praeter necessitatem" Thu, 03 Jul 2008 20:22:13 +0000 http://backend.userland.com/rss092 en ... 所以困難的事情才正要開始。 這大概是在邁入多核 64-bit 又要考慮 multithreading 又要考慮跨平台的年代裡開發 framework 的某種感想吧。 http://lukhnos.org/blog/zh/archives/603 我第一次幫人家撰寫命名跟縮排法則是在很早、很早之前的事了。訂立這些規則是一件很有樂趣的事。或許這是某種奇怪的愛好。後來在棄絕的那些漫長的日子中，曾經一度把某一版 MLA Style Guide 給整本 k 完，而且竟然對於「到底句點要放在括號前還是括號後」或是「在又有引號又有括號的句子裡，句點要放引號裡、引號外、還是括號外？」這種事情覺得津津有味。這一定是某種不正常的表現。 重新寫起程式之後，倒是花了相當、相當、相當長的時間，才又像某種緩慢的吸體一樣，把對命名和縮排規則的看重，變為自己的一部分。然後看著自己從前寫的 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 ... http://lukhnos.org/blog/zh/archives/602 長年以來我一直在尋找這一句諺語的源頭：optimum inimicum bono。字面上的意思是 "perfect is the enemy of the good"。原本一直以為會是哪個羅馬詩人的句子，最近發現似乎更像是伏爾泰（Voltaire）說的：le mieux est l'ennemi du bien。也有義大利文版本謂：il meglio è l'inimico del bene。但照這樣講起來拉丁文版本的存在應非不可能，卻始終尋找未果。 每次打開編譯器的最佳化選項時，都會想到這句話。嗯，雖然其實原意並非如此啦。 http://lukhnos.org/blog/zh/archives/601 一點近況，或者，毋寧說是一點思考。前陣子寫完那篇抱怨捷運的文章後，開始在思考什麼是「不滿」，以及改善的可能性。就好比說捷運這一件事好了，一個可能很容易有說服力的論點是，「你看人家國外的地鐵上都沒有/不需要這樣那樣的標示」。但是拿別人當參考點，很可能一開始就輸了，變成了一種自我擊敗（self-defeating）的起點。佐證這種事情可以比上不足比下有餘。最末改善還是要從自身的不滿/不滿足出發的。然而接下來的問題就變成了，你的不滿未必是我的不滿。要怎麼溝通、傳達、「使跨越」、「把點開回家」我的不滿呢？聽起來好像是要把我的牢騷餵食給你。並不是，也不該是這樣。在我的設想當中，不滿應該是從價值出發的。好比說我的價值是訊息應該足夠就好、反對畫蛇添足的美學價值（是的，我後來覺得畫蛇添足不是一種「問題」，而實實在在是一種價值體系）跟教條主義（一種認為事情只要由上到下「宣達」了──一種人類最古老的語言表演──就會完成的信仰）、善用歐康的剃刀法則（Occam's Razor）跟常識。不滿不一定必然或非得是情緒上的，不滿也可能來自於空缺──這是不滿最本初的字義──一種等待被填入新事物的狀態。 雖然最初的出發點還是捷運，但是之後想的其實是，我們要怎麼樣才能從自己所感受/感知的不滿中尋找改善的可能。而不是永遠從參考點來告訴自己其實很suck，或是其實還不錯。這樣的事情。生活如此，制度如此，軟體也是這樣。 驚覺很久沒有更新 blog。顯然我對這件事情還沒有太多發自於內心的不滿。 http://lukhnos.org/blog/zh/archives/600 不少使用者曾經回報：「我的 OpenVanilla 不能用了，備份碟上的也不能用了，裝回 0.7.2 也不能用了......」 我們曾經為了這個問題困擾很久。現在犯人抓到了：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）。 太不專業了吧。 http://lukhnos.org/blog/zh/archives/599 iVanilla 的想法是由 ycchang 於 2007 年十月的時候提出的。最早的想法是希望在 iPhone/iPod Touch 上利用當時的 "Toolchain" 製作出一個簡單的、作為概念實證 (proof of concept) 的 OpenVanilla 實作。所使用的方法也是當時各家 iPhone/iPod Touch 輸入法外掛所使用的 dynamic library insertion （透過 DYLD_INSERT_LIBRARIES 環境變數指定）。 對我們來說，iVanilla 的 code 主要還是在驗證 OpenVanilla 框架的可移植性。用 C++ 簡單撰寫的 "MinimalLoader" 實作了所有 OV 模組所需要的基本功能：對於組字區與選字列的操作。 這個實驗是在 2007 年 10 月至 11 月間進行的。ycchang 並於去年的 COSCUP 2007 中簡單討論過 iPhone/iPod Touch open ... http://lukhnos.org/blog/zh/archives/598 住台北縣的人可能聽過這一句： 永和有永和路，中和也有永和路， 中和有中和路，永和也有中和路； 中和的中和路有接永和的中和路， 永和的永和路沒接中和的永和路； 永和的中和路有接永和的永和路， 中和的永和路沒接中和的中和路。 最近發現，世界上存在不少類似結構的東西，例如： 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 的 ... http://lukhnos.org/blog/zh/archives/597 Lipogram 在歐語中是一種具有難度的文字遊戲。簡言之就是刻意限制不使用某幾個字母來寫東西。例如，刻意不用字母 e 來寫詩，或是重寫莎士比亞作品（真的有人這麼做過）。 那麼作為漢語書寫用的中文，有沒有這樣的東西呢？ 今天想到一種：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... http://lukhnos.org/blog/zh/archives/596 Update: 的確，還有一種場合會把 closing credit 放完，那就是有 closing credit 裡面有安排花絮的那一種。 在朋友 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，不過這有待來日說明吧）。 但是，實用的價值之外，或許更重要的還是那些一點都不實用、一點都對電影「播放」本身都沒有影響的、形而上的東西吧？保有作品的完整性，難道不是一種對作品的尊重嗎？就好比說，書本不可能截去封面封底來販賣一樣。聽音樂會，大家也不會在樂團謝幕之前就開燈走人。那麼為什麼電影不可以呢。 更何況，大家恐怕無法想像，影展片如果遭受這種對待，會是什麼德性吧。那為什麼一般的電影就不行呢。 其實會坐在觀眾席上把片尾看完的人還真不少（看影展就知道了）。有些人說，「片尾哪有什麼人看」。這其實是倒果為因。正是因為台灣太多不播片尾的電影院，大家也只能燈亮走人啊。 http://lukhnos.org/blog/zh/archives/595 投影片在這裡。 應 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──等等可以被當做型別來操作）等等挑戰。 總之還有很多很多要努力的地方啊。 http://lukhnos.org/blog/zh/archives/594