In Haskell you can write two kinds of pattern match for the + operator.

(^+) :: Int -> Int -> Int

0 ^+ m = m

(n+1) ^+ m = (n ^+ m) + 1

(+^) :: Int -> Int -> Int

m +^ 0 = m

m +^ (n+1) = (m +^ n) + 1

When the above two operators apply on any pair of natural numbers, their answers are equal. However, I wrote the second rule of (+^) function mistakenly,

m +^ (n+1) = (m +^ m) + 1

and then (2 +^ 3) cannot stop to give an answer. What done by (^+) and (+^) must be proved the same, though both are type-checked.

I tag my articles with {lab : Agda} to note that all what I write are practices, which may have somethings wrong.

When learning to model natural numbers in Agda, I found that it's not easy to present the predecessor of a number. Consider the following example:

data Nat : Set where
    zero : Nat
    succ : Nat -> Nat
    pred : (n : Nat) -> (n > zero) -> Nat

_>_ : Nat -> Nat -> Bool
zero > m = false
succ n > zero = true
succ n > succ m = n > m

The (n > zero) segment in the term pred is not in scope. A datatype must known a function before using one. To provide the proof of pred, a greater operator on discrete numbers, including negative numbers, must be modelled firstly.

Paul Graham的"駭客與畫家"有個很有趣的說法，說，做學術的總愛把不是數學的科技論文弄成很數學的樣子；要看起來漂亮一點，請多用一些希臘變量。

真的是這樣子嗎？覺得我所見的，有些層面似乎是這樣...

我想這次一次讓我減低「認為研究有趣」的事情. 我看到了一篇文章, 2000年的, 恰好與我的研究有相同的方法.

看過之後卻覺得非常不認同他的觀點. 他的方法是著重在一個 Non-Passing Property, 並且很肯定地解釋其意思是如果有二台車在二個不同時點從同一地點出發, 最後到達另一地點, 則二台車都必須按照先後順序到達目的地. 他也提出證明. 整篇文章也以有沒有NPP而判斷各種方法的好壞.

雖然這篇文章在演算法的分析寫得很精采, 但我很不懂, 為什麼可以將NPP掛上一個theorem標籤? NPP是交通系統中的一種現象, 它的存在並沒有推翻其他non-NPP的可能性. 但看到這一篇方法倒果為因, 認為NPP是內嵌在交通模式中的通用性質, 並且大幅加以申論. 這有什麼意思? 我想只要窮舉法舉出一個反例, 就可以踢掉這個稱為theorem的性質了吧!

不過文章中有些討論技巧令人佩服, 在研究的各面, 這一面解釋一番, 那一面解釋一番. 哪個地方該講什麼話就寫出來. 簡單說就是八股文. 在這方面我覺得研究真沒意思.

另一方面, 看到 Nachum Dershowitz 的老文章 A Taste of Rewrite Systems, 感覺是, 同樣是研究, 有人就是能用有趣愉快的方式說明該有的東西. 我想, 對學者來說, 若能用更有趣的方式交待有趣的事物, 會讓學術工作變成藝術.

這幾天我陷入一種喪失真實感的情結, 可能與我所遭遇的事有關吧! 簡單說, 是對於什麼是真的, 什麼是假的都沒有判斷力了. 因為這樣的想法, 當某天下午我在寫著過去曾熟練的ASP程式時, 心裏帶著一點害怕的感覺. 就好像龍與地下城中很容易被下一種簡單但有效的法術: 恐懼. 不曉得這種擔憂擴大了是否即憂鬱症, 不過, 目前我非常確定自己很有自制力, 自我抵抗憂鬱發作的能力.

我想我害怕的是人性. 我們習慣照著規矩行事, 卻沒想到其他人不見得照著規矩來. 在研究所中, 即使我不願意參與某研究領域, 卻仍然會被騙進一個計劃, 而被支使要去做那個領域的事情. 別人可能會定義我 "搞不清楚狀況", 其實是對方搞不清楚彼此認知的差異.

指導老師胡說八道, 我抗議了, 卻因為他面子掛不著生氣了, 而叫出: "我不想指導你了! 真的!" 事實是我一點都不想接受凡meeting就是胡說八道一番的 "指導", 最後卻變成聲音大的看起來比較有理. 雖然換指導老師之後, 研究真的做得比較輕鬆愉快, 但在切換老師那一陣子, 我沒有犯錯卻要因為老師情緒上受不了, 反而讓我被羞辱一番. 感想是: 似乎老師的心情比知識的正確程度更重要, 是這樣嗎??? 我迷惑了.

我想可能是因為我們的研究所還算年輕吧, 過去長久擔任大學教師的, 短期還不能確實勝任研究所教師的角色. 也因為學術專業程度似乎真的有差別, 竟聽說研究上較有能耐的老師自居為博士生的推手, 而且是全系所惟一的把關者.

我也算是前述高程度教師的受害者. 雖然我一直知道自己的方向, 也有自己的研究題目, 卻因為某位老師不確實明白我的情況, 以及他的自我中心想法, 他以為只要指派了我幫他寫程式, 我就必須拋棄我的研究方向而取他的研究方向. 他不是我的指導老師, 卻平白無故要我參與他的研究. 他以將一個計劃掛我的名字為名目, 實質上要我做他領域的事情, 而且範圍是所謂 "越多越好". 我沒有答應他所認知的那一套, 只打算幫他寫程式而已. 但明白了他的想法, 我開始覺得憤怒, 失望, 與焦燥不安. 為什麼一個光明正大的計劃, 他不想對我好好講, 卻只先徵求我同意A事項, 然後自行將我對於A的允諾擴充為對B的允諾? 於是, 剛開始問我有沒有時間, 想將我名字掛在一個計劃下. 答應了之後, 想問明細節, 他卻不正面回答我. 之前說只要我幫忙寫程式, 之後卻要我花時間去坐他研究室. 但是, 畢竟我不是他的指導學生.

其實他也說謊. 原本每位教師各有一間研究室, 他刻意向另一位兼行政職的老師調借研究室, 使它為提供學生使用的研究室, 就對我們說: 全校只有他能夠有多的研究室提供給學生使用. 我覺得很疑惑, 老師如此地假意自我膨脹, 究竟為何目的?

現在, 我的處境非常複雜: 一方面我每個月都收到計劃薪資, 我都存起來不動用, 打算全數歸還給他; 另一方面我履次受到他要求我白天要多去他的研究室, 我一概拒絕 (我從來沒答應要參與他的實驗室); 再一方面, 我一直很想狠狠質問或指責他, 為什麼他自己手下好幾個學生都做他領域的事情, 他不妥善利用, 卻要找我這個外行人去做他的事情? 為什麼他一味以為有程式能力的人都必須做他領域的研究? 為什麼他一味以為只有透過他, 學生才能夠有所成就? 為什麼他以為略施小利就能任意始喚人? 為什麼明知道我碩三一定沒時間, 卻仍要跟我搶時間? 總之, 我覺得他的處事方式非常不切實際. 感想是: 難道老師的計劃有沒有人做, 比學生的學業能不能完成更重要, 也是這樣嗎??? 我很疑惑.

其實我不必太主動反應, 因為那一切都不是我本來該做的事情, 我只要把份外之事拒絕之後, 不再想它們就好. 但若不吭聲氣我又耐不住. 當初那老師主動來找我幫他做事, 我該解釋的實情若沒解釋, 或者是被他搪塞帶過, 他就視我默認了他的決定. 他如此自我中心, 我很擔心他再搞出什麼名堂.

另一個讓我覺得不真實的地方, 那老師教我大學的 "專案管理" 課程, 說專案的三要素是範圍, 資源, 人力, 但是在這計劃中卻完全不顧這些因素. 人力只找了我一人, 範圍無限, 資源幾乎沒有, 卻面對了相當大的題目. 三年期的計劃, 我看不到前二年所該做的前置研究; 前二年他曾經把他不滿意的學生趕走, 或許是沒有前置研究的原因吧. 而我的確沒有能力執行此計劃, 如果早先明白核對過計劃內容, 我會先提出拒絕. 不過, 其實這計劃內容並不重要, 因為他用意是找我來幫他做很多事情而已. 但或許他真沒料想到我如此了解自己無法配合的程度, 也如此了解周遭的狀況.

我慶幸自己並不受利欲薰心, 對於他提出的許多利益, 包括上博士班的機會, 許多的研究成果表現, 高級工作機會等等, 我都沒有動心. (也恰好對他所提的事情完全沒感興趣.) 我卻發現, 人受利欲影響的價值取向可能扭曲得多可怕啊!

於是, 這幾天我覺得精神跳躍到另一個界限, 差一點失控了. 我感覺, 例如, 當對痛覺不在乎的時候, 人在自焚前就比較不會猶豫了. 我的心裏跳出一個又一個瘋狂的想法, 包括犯罪, 傷害等許多惡行, 不包括自殺, 都帶著同樣的精神: 只要臨界的條件變得模糊, 做出這些所想到的事情也沒關係. 這就是人性啊! 於是, 後來看到任何事都覺得很糟, 我持續懷疑著為什麼路上其他人要以這個角度擦過來, 那個角度晃過去, 或是走到一半突然停下來擋路; 我疑惑著為什麼區區一個捷運座位空出來, 這邊有人要過來搶位子, 那邊也有人要過來搶位子; 又納悶為什麼路好好的並不太窄, 人走過去就是一定要撞到或擦到背包. 我的可怕經驗是, 看到任何事物與現象, 我都直接考慮並定義它們的負面理由.

看過 "People Ware" 這本書的一篇文章, 提到科技狂熱者可能以為科技決定一切, 其實若真實的非決定系統變成科技的決定系統, 那些重要的非決定的特質就遺失了. 我想, 在我生長過程中, 受到許多對 "正規" 的指導太多了, 判斷規則太多, 對於不規則的事情無法忍受.

把Mano的書翻出來複習, 簡單的邏輯gate都很好做.

不過在想SR Flip-flop的時候發現真難做. 好像要用Y combinator了.

type Wire = [Bool]

type S = Wire

type R = Wire

type Q = Wire

srff :: S -> R -> Q

srff ss rs = norgate (norgate (delay (delay ss)) (???)) (delay rs)

SR Flip-flop是二個norgate交織而成. 訊號的前後順序算一下, S訊號延遲了二單位, R訊號延遲了一單位, 才符合時序. 但有個難題是, 其中一個norgate要等待整個Flip-flop產生一個答案做它的輸入, 而這個norgate也要提供答案給整個Flip-flop做它的輸入. 目前不曉得思考中缺少哪一塊東西.

以前都覺得寫ASP做網頁上傳檔案很不簡單, 因為要選適合的上傳元件, 而且要想辦法取得元件的授權. 此外, 管公家電腦的必須願意安裝上傳元件.

目前又需要上傳功能了, 但不方便安裝上傳元件, 就看別人怎麼做所謂 "無組件上傳", 驚然發現ADO Stream元件就是提供檔案上傳的物件. 一般只知道Stream大概是做物件串流的東西, 只看使用手冊卻看不懂是用來做什麼的. 後來, 看到一些做法, 才知道原來Stream的LoadFromFile就是從用戶端抓檔案過來的方法. 使用上比以前用的更簡單, 以前網頁表單還要設定為編碼傳輸(encrypt="form-data"), 讀取表單很麻煩. 若使用Stream, 表單連編碼傳輸都不必.

看過Jerry前輩的用中文寫程式一文, 雖是老調重彈, 但考慮另一種程式風格呢? 將命令語言弄成中文讀起來很怪, 但函數語言弄成中文又如何呢?

flatten :: Tree a -> [a]
flatten (Tip x) = [x]
flatten (Bin x y) = (flatten x) ++ (flatten y)

平 定為 某樹 至 某列
平 一葉 為 一列
平 一二枝 為 平 一 連 平 二

只要parsing合理, 中間有沒有空格不重要. 而中文程式可以寫得比較像句子.

不過上面這幾句寫得很久. 而且慘了慘了, 再怎麼想都是flatten, 都想不出新例子. 函數語言的功力還不夠, 只能胡扯一番.

今天收到一些簡訊, 一下子是這邊拜票, 一下子是那邊拜票. 收煩了, 我就覺得: 看最後哪邊寄來的簡訊比較少, 就投票給那一邊吧!

你們競選, 卻要放簡訊騷擾我們小老百姓! 有沒有一點德性?

最近寫一篇文章喜歡用這個詞: 比類合誼. 這是中國字源六書之一, 會意, 的解釋. 原意為將一些象形字湊在一起, 可以得到一個綜合的意思, 這就是會意字. 不過, 我借來表達的意思是: 胡拼亂湊的疊床架屋結構. :p 不知道會不會因為用詞太雅反而被刪減.

有些講做菜(料理)的漫畫主角總是聲明: 做菜是讓人得到幸福的方法.

有沒有人以開發使人幸福的軟體為志呢?

Web 2.0強調以使用者提供內容為許多網站的主要內容. 這種網路驅勢有點像學界所稱的解構主義. 初版Web是建構的, Web 2.0則是解構的. 所謂解構, 是以支解成零碎物, 開啟重構或亂構的可能.

當前的blog都看得到一種現象, 所謂blog-deco(部落格裝飾物)越來越多, 佔用越來越多blog版面.

加上再看到許多主題式分享網站: 影音分享提供一個Flash螢幕播放影片, 簡報分享提供一個Flash螢幕播放投影片, 文件分享提供網頁頁面顯示符合格式的文件或程式碼. 現在你必須跑去那個網站才能夠使用那個功能, 我猜想將來當此種application service provider (ASP)成為基本必要的網際網路構件時, 許多公用或私有的網站將劃分為一個又一個區塊, 每一區塊到處載入ASP提供的資料做為網站的重要內容.

前天的超簡單網頁圖片驗證機制實作, 似乎是對的. 但在網頁圖片驗證上線使用之後, 發現在暫存檔的威力之下, 難以掌握伺服器端與客戶端的一致性. 於是, 將正確的圖片對應碼輸入誤判, 讓正常的留言板使用者非常不高興. 與我之前提到的網頁狀態毛病丟到使用者頭上的事情雷同, 我也將圖片對應出毛病的問題拋給使用者.

或許應該將超簡單網頁圖片驗證機制收回, 因為對多人使用的網頁, 驗證圖片應該記錄在session中, 隨著使用者而有區別, 而不是讓大家都把圖片複製到同一個複本檔案.

今天seminar中, 感覺到在場存在著一種上下層級的差異. 差異並不在位階, 成就或成績, 而是在於對學問的熟識程度吧!

目前在學習邏輯與型態系統的知識, 覺得自己還學不會如何講出某件事物, 難以參與討論. 最多只能做盡力吸收與領悟. 把事情講出來甚至講清楚, 難的是能講出某件事物是什麼, 而且所講出那是什麼能得到其他人的同意.

我想, 大家熟與不熟的程度差距要少於一個距離, 才會有足夠的討論.

以前讀過函數語言的優點, 有一項優點是無狀態. 因為無狀態, 函數語言的驗證只要檢查term有沒有符合的資料型態. 因為有狀態, 命令語言由許多assert做驗證.

回想起有狀態與無狀態的特性, 是因為使用學校資訊系統時又遇到了問題. 當前一次系統在我的電腦中留下cookie, 且我用完之後登出了系統, 下一次就再也無法登入系統了. 下一次登入時, 常常彈現一個對話方塊說session expired, 但身為使用者, 我為什麼要知道session expired? 此外, 如果解決辦法是自己清理瀏覽器的cookie或暫存檔, 或者是切換proxy, 我認為這種對待網站使用者的方式非常不合理. 上網本來是無狀態的簡單事情, 但沒有經驗的網站程式撰寫者讓它變成複雜的難事, 網站不但有狀態, 並且 "邀請" 網站使用者一同檢查網站的狀態.

不過, 登入後與登入前, 的確是有狀態的. 網頁程式做狀態的控制, 似乎是合理的事情. 即使網站本身的特性是無狀態, 網頁程式也必須處理狀態.

狀態隨著命令語言的執行而存在. 特性為無狀態的函數語言, 在需要的時候, 藉由將狀態鑲嵌在term中讓程式變得有狀態. 這感覺與OSI架構很符合: TCP提供傳輸序列的保證; UDP雖然沒有同樣的能力, 卻可讓上層的實作幫忙做傳輸序列保證. 對使用者來說, 需要通透性: 不管是TCP或UDP, 只要能合理傳輸資料就好; 不管是命令語言或函數語言, 程式只要做對就好.

好的網站設計, 應該讓使用者覺得是無狀態的. (如此說法還不夠精準; 使用者起碼要認得什麼是登入後, 什麼是登入前.) 讓使用者端保持無狀態, 並讓網站端好好控制狀態.

或許有另一種方式可以讓網站算是無狀態. 將登入動作比擬為打開一個盒子, 登入前就像是盒子沒打開, 登入後就像是盒子已經打開且盒子的內容可以取出. 權限控制只是讓使用者在盒子沒打開時無法取出盒子內容而已. 寫成函數程式大概是:

take :: Box a -> [b] -> [a]
take box [] = []
take box account = flatten box

函數語言處理權限的方式是, 如果所給的參數是可用的帳號, 就可以提供內容. 如果是[], 就不提供內容. 對應的網頁程式, 相當於每當要取出內容時, 把帳號附加在take命令的query string傳送出去. 一般網頁設計是先從使用者讀取帳號訊息, 之後要提取任何內容, 網頁程式就擔任掮客角色, 借使用者帳號 "蓋印章" 之後提取內容. 如果網站都是函數語言程式, 在session存在期間, 都存在一個term代表帳號資訊, 就是 "印章" , 也就是狀態.

材料: 圖片數張, 存放圖片目錄一個, 擁有web guest寫入權限的目錄一個, 固定的公開顯示圖檔名一個.

1. 資料庫設定: 建立圖片對應碼資料表, 含欄位: id, url, value, copy. 將數張圖片儲存位置填入url欄位, 並將對應碼填入value欄位.

2. 圖片產生: 顯示圖片的網頁程式必須做下列動作:

2.1. 隨機讀出圖片對應碼資料表中的一筆記錄.

2.2. 將選出的圖片複製到網頁程式(web guest)擁有寫入權限的目錄, 檔名定為固定的公開顯示圖檔名.

2.3. 將圖片對應碼資料表所有的copy欄位清空.

2.4. 在選出的那一筆記錄的copy欄位, 把固定的公開顯示圖檔名寫入.

2.5. 讀取固定的公開顯示圖檔名, 顯示在網頁上.

3. 圖片對應碼驗證: 驗證的網頁程式必須做下列動作:

3.1. 知道固定的公開顯示圖檔名, 並讀取使用者所輸入的圖片對應碼.

3.2. 查詢圖片對應碼資料表中, copy欄位是固定的公開顯示圖檔名的那一筆記錄.

3.3. 由選出的圖片對應資料記錄的value欄位取出對應碼.

3.4. 將正確的圖片對應碼與使用者輸入的對應碼對照, 如果相同就通過驗證.

在此機制中, 網頁程式釋出非常少的資訊, 含固定的公開顯示圖檔名與圖片內容. 剩下的重要工作就在於圖片與對應碼的妥善設計.

因為太簡單, 破解率的控制就靠資料量來撐. 10張圖片代表每一次嘗試破解有10%成功率, 20張圖片代表每一次嘗試破解有5%成功率.

久沒操作的程序真的會生疏. 隔了半年才繼續處理一點網頁設計的工作, 發現過去很熟的一點JavaScript都遇到不可解釋的問題. 過去, 我確定每個網頁都可以讀到document物件, 而且若存在一張form, 就一定能從document.form[1]讀到form物件. 此外, 我還確定form的每一個元件, 例如按鈕, 都可以從中取得this.form, 而且可以呼叫form.submit()方法.

但是, 我剛使用FireFox 3與IE 8, 發現都沒辦法正確使用上述項目. FireFox的error console老是說form沒有submit()方法, 難道新版的HTML或JavaScript改了嗎? 或是JavaScript解譯器改版了嗎? 總之, 在FireFox 3與IE 8構成的狹小視野中, 我發現自己沒辦法順利複習睽違短短半年的網頁程式語言. 所謂一文錢逼死英雄好漢, 在資訊領域大概就是這一類情形吧!

我們寫SQL那麼久了, 不曉得為什麼從來沒聽過, 或者恰巧沒遇見過, 有人把資料庫語言規劃成符號程式語言的模樣. 舉個例子, 普通來說, 要把二個資料表合併為一個資料表, 寫出SQL語法是:

    INSERT INTO table 3 (SELECT * FROM table1 UNION SELECT * FROM table2)

好像夠簡單了. 但寫成下列這樣可以更簡單:

    table2 = table1 //把資料表table1複製到table2

    table3 = table1 + table2 //把資料表table1與table2合併, 放在table3

    table3 = table1 (+) table2 //exclusive addition: 把資料表table1與table2不重複的記錄放在一起, 放在table3

回想起來, 物件導向資料庫就在做這個事情. 而被影響的部份不是以語言為主, 而是影響了架構.

我開始想, 並且質疑, 資深學者真的可以不再親身實作, 只靠著雇用或者指導的研究生來產生所有的東西了?

這個問題來自於所見到的情況. 對此問題我沒有答案, 也沒有預設立場.

我所見到的有二種情況, 第一種是真的不再唸書的, 沒有唸書是從普通的學術討論就可以聽出來, 因為沒有唸書又自信滿滿的人會開始胡說八道; 第二種情況是研究做得很多, 但背後實際情況是有努力的研究生撐著, 或許做出來了可供資深學者提供校訂意見, 但若是做不出來, 則是不聞不問直到哪一天有成果出來為止. 後者的後者是我所經歷的情況.

不知道是缺乏溝通, 或是上頭拒絕接受負面消息, 我看到上頭的老師表現著不合理的處置態度, 並且似乎真的等著我把他要的東西生出來. 但可惜的是, 我知道工作內容的實情之後, 只能夠回報我缺乏能力, 生不出來.

我知道直接講生不出來可能會遭受許多相關的指責, 例如現在學生怎麼都這樣, 或者是都不努力. 但就我的情況來說, 我並不覺得可恥. 因為如果都是我會做的東西, 卻不努力, 我被罵會覺得羞愧. 不過, 如果針對我本來就不會的東西指責我的不是, 我認為這不是我的問題. 龍華科技大學電玩系培養繪圖程式人員, 要花多少的工夫? 我遭遇到的事, 卻是在一年內要我從無開始培養出這方面的實作能力, 並做出一個東西. 我只能老實說, 我做不到.

這東西如果做得出來, 老師就會高興好一陣子. 但是, 我沒辦法只為了讓老師一個人高興, 就勉強自己做到那麼誇張的程度.

反過來說, 既然我們資管系的人一般都不會有這方面的能力, 為什麼老師要提出這樣的計劃案, 並且為了這個計劃以及他個人的選才偏好, 只在熟悉的人中間尋找計劃執行者? 另外, 這樣的計劃題目, 他自己能夠親自實作嗎? 就目前進展來看, 我認為老師應該沒有多媒體方面的實作能力. 沒有這方面專才的執行者, 為什麼敢提這樣的計劃案? 又提了這樣的計劃案之後, 為什麼又不戰戰兢兢地選擇真正適合的執行者? (我並不適合做這個計劃; 卻被塘塞並矇混而接下了這個計劃案.)

不過, 抽離現實的層次, 我感到一種矛盾的疑惑: 因為人年歲的限制, 可想而知, 有些人老了之後會失去精確的實作能力, 也許只能夠掌握概念層面的方向. 因此, 資深學者的確可能沒辦法參與實作. 但是, 不參與實作必須有個限度, 超過了限度而成為完全不關心實作細節, 也沒辦法做相關討論的時候, 似乎就可以用 "不適任" 來標明其立場. 到了後者的程度, 資深學者若仍然將研究產出掛在自己名下, 有沒有意義?

對學軟體設計的人來說, 沒有實際在Source-Forge開一個專案並徹底完成的經驗, 也許是直接的反證, 證明自己實際上還不是軟體設計者. 這是我個人想法, 不曉得學資訊科學的你同意不同意?

最近認真思考, 對某個國科會計劃案的了解已經很深入了. 那個計畫是要做氣象模擬的虛擬實境呈現, 計算平台是電腦網格. 將系統分解, 看到需要Grid, 氣象, 與虛擬實境三方面的專業知識與技術. 對我來說, 這三方面都不是我的底子, 而且我不很感興趣. 估計整體該有的工作時間與人力, 與目前所有的不符.

目前, 人力是我ㄧ個人, 完全沒有相關專業知識, 資源是學校的高效能電腦中的一個普通使用者帳號及可用的硬碟空間, 工作內容是要將氣象系統改寫或修改為此電腦所需的架構 --- 若Grid監控架構也要改寫到符合另一種架構, 則可能需要擁有學校高效能電腦的特殊權力帳號. 工作完成時間, 估計為一年以上. 所需要的酬勞, 絕對不只是每個月只拿六千塊.

如此一想, 我認為我的實力不足. 我不應該繼續死撐著要做這件事情.

有人可能質疑: 為什麼我有問題不早講? 我可以給個答案, 實際上我沒有辦法早講. 這件事到現在才明朗化並且能夠提出來, 已經算很早了.

二年半之前, 我早已耳聞這個計畫, 稱為三年期計畫, 當時卻找不到執行者. 因為那老師的學生得力助手已經去別的學校, 而其他學生並沒有繼承相關能力與對該計畫的認知. 當時ㄧ開始問我有沒有興趣, 我直接回答沒有興趣, 因為我真的對Grid不感興趣. 去年老師突然開始主動聯絡我, 並問我對高效能電腦上寫程式有沒有興趣, 我基於願意幫助老師寫程式的想法而答應. 當時只知道要試著在高效能電腦上寫另一種網格監控架構而已, 但花了許多日子卻發現難以完成. 半年前, 突然說要把這個程式工作報成國科會計畫, 當時我沒有想到這計畫就是過去耳聞的三年期計劃, 主題就是氣象模擬的虛擬實境呈現. 我以為是在高效能電腦上寫寫程式的工作而已. 答應這個計畫時, 我想問這個計畫內容是什麼, 且範圍到哪裏, 老師卻不講清楚, 只說 "越多越好". 實際上, 我沒有越來越多的時間.

不僅是在談論計畫範圍時, 老師的搪塞態度讓我感到非常奇怪, 後來我還發現老師的態度前後不ㄧ. 本來我只答應幫忙寫程式, 自從答應加入計畫之後, 不僅我平常要花時間尋找並閱讀相關資料, 老師還試著叫我花時間來研究室駐守, 且完全不管我自己對於碩士班三年級的時間有什麼安排. 基本上碩ㄧ碩二都沒什麼利害關係的學生, 碩三突然接下這個重要的案子, 在外人眼中看起來是很奇怪的事情. 此外, 我納悶為什麼我碩士班三年級本來就該好好唸書做好自己的研究, 卻要被拉去花很多時間做別人的事情? 就好像是, 老師只覺得我的所有時間都該貢獻出來做他的事情. 最後是, 這個稱為三年期計畫的事情, 在前二年都沒有相關的前期研究, 使第三年的工作難以進行.

現在我有幾點結論:

1. 我應該辭退這個計畫, 因為能力不足, 且實在沒有時間.

2. 我沒有理由繼續接任執行這個計畫, 因為在加入這個計畫的當時, 我對於這個計畫的內容與應做的事情並不了解.

3. 這個計畫是個爛攤子. 這個計畫需要足夠的專業人力, 有效的資源, 以及整合性的跨學門合作, 卻在人力, 資源, 與時間都樣樣缺乏, 也沒有做必要的前期研究. 實際上是無法完成的工作.

我想我應該辭退這個計畫, 把之前領下的人事費用都退還.