現今有許多方便的技術,入門學習起來不費功夫,甚至用來作為解決方案,乍看也蠻像一回事,因而產生了許多目標導向的作法。

例如,過去熱門的課題,是以打造一個部落格為目標,而現在可能是行動裝置App。從中遇到什麼問題,就克服什麼問題,某些方面這是不錯的作法,然而,某些方面,這也會引發一些問題!

來個輪胎設計營如何?

這些日子以來,因為熱衷於使用OpenSCAD進行程式建模,分享了不少作品,也發表了一些文件記錄我的設計思路與零星想法。

由於在(臺灣)3D列印這領域,使用程式建模的人極少,自然地,我的作品與文件容易突出而引人注意,因此,除了演講與邀稿之外,也開始有人想要合作協商課程,而其中一個特別的課程是輪胎設計營的構想,對方希望可以教導學生使用OpenSCAD,來進行輪胎建模,而且,為了讓輪胎有彈性及抓地力等因素,列印時會採用軟料,同時,對方可以提供我軟料測試。

我對後者回應是:「軟料不用給我」、「列印與測試軟料離我的專業太遠了」而對前者的回應是:「我擔任的角色,應該是在教會你們運用OpenSCAD,而不是教會你們設計輪胎……我對輪胎沒有概念」。

輪胎設計營是其中一個例子,另一個課程也很有趣。對方提出的問題是:「有無可能設計課程來教導列印一些古老部落重複型圖示?例如台灣原住民的衣服?」而我的回應是:「只要有重複的模式,基本上就可以設計,但是你們要告訴我那個模式是什麼,因為那些未必是我研究過的東西」。

如果你從未接觸過自造者(Maker)領域,這兩個題材看來似乎很新鮮,實際上,回到軟體設計領域,這種情況也很常見,只不過主題換成了某種類型的Web應用程式,或者是行動裝置App,而且大多會是希望從語言開始,最後產出一個應用程式作為結果。

當程式設計遇上……

至今為止,我沒有寫過任何一個行動裝置App(我常戲稱對它沒有愛),因此,我推辭任何有關行動裝置App的課程設計。

實際上,行動裝置App的書籍相關資料非常地多,我大可以臨時趕鴨子上架地惡補幾本,不足的部份,以一些通用的程式設計概念彌補,然後再加上點個人名聲,也許就能讓學員信服。硬是要承接課程的話,某些程度上,還是能蒙混過關的。

輪胎設計營?我對輪胎根本一無所知,重點是我去哪找輪胎的資料啊?對方丟給我Thingiverse上的一些輪胎模型,作為參考,我隨便擺弄了幾個,用OpenSCAD畫了個看似輪胎的東西,事實上,我知道這根本就不是輪胎,天曉得它的曲線是不是對的,上面的輪紋是純粹的裝飾,還是有實際的作用?裝到遙控車上時,輪框帶得動這輪胎嗎?或者只是輪框搞笑地自轉而已?

至於古老部落重複型的圖示,我也沒研究,因此我第一個想法是:「你們要告訴我重複的模式是什麼,而不是丟一個東西,請我自己探索重複的模式是什麼,因為每個人研究的東西不同」。

重複,看起來沒什麼難的,對嗎?其實,如果實際研究過禪繞或是碎形,就會知道沒那麼簡單。

因為,重複有很多種——水平或垂直位移、旋轉,或者各式的組合。古老部落重複型的圖示?嗯!光是搜集資料,或辨識重複樣式,就會耗費我很大的時間。

好吧!當程式設計遇上Web應用程式,可以寫些無關痛癢的應用程式,像是討論區之類的;當程式設計遇上行動裝置App,也可以寫個無關痛癢的BMI計算之類的。那麼,當程式設計遇上輪胎設計,我也可以設計個像是輪胎的東西;當程式設計遇上古老部落重複的圖示,我也可以隨便教教海龜繪圖、遞迴,畫畫科赫曲線、蕨葉曲線之類的。不過,這真的是課程提案者,或者是學員想要的東西嗎?

課程提出者其實都很有誠意溝通,純粹只是誤以為我,也研究過這類型題材,不過,其實我也因此想到了一些值得思考的問題。

對本質性困難的誤解

如果對軟體設計有一定時間的浸淫,也許就會看過《人月神話》作者Frederick P. Brooks,在1986年發表的論文《沒有銀彈:軟體工程的本質性與附屬性》,而我曾經在先前專欄〈框架的本質與附屬〉中,對於本質性與附屬性作過介紹。

簡而言之,在軟體設計界中,越來越便利的語言、程式庫、框架與工具等,讓程式設計者越來越能免於附屬性困難,以便集中心力在解決問題的本質性困難。

自造者運動再興以來,也已經若干年了,而這些年來,我發現,越來越多便利、門檻低的自造工具,不斷地被創造出來,像是控制板、感應器、可程式機器人、3D列印機等,這些工具讓想要自造某物的過程中,附屬性的困難降低,也成為用來吸引更多人加入自造的號召口號之一。

然而,你就會發現,不只是軟體界會有百花齊放的情況,自造界也是如此。三不五時地,就會看到,又有人熱切地討論哪個新控制板、感應器出現了……嗯……感覺就像是不斷地在重複「下一臺XXX會更好」這樣的話……

其實,無論工具再怎麼方便,問題的本質性困難仍是不變的。

回到程式建模,也是一樣,對於有重複規則的模型,是可以使用程式建模來更方便的解決;不過,它也有其本質性的困難——如果要描述一個曲面,得找出它的數學函式;如果要建立重複的圖樣,得辨識出它的重複模式;而像OpenSCAD選擇了函數式風格,於是,這也成了它在描述模型時的本質性困難之一。

在過去,無論是軟體界或是自造界,由於問題的本質性與附屬性困難程度,相當地交錯在一起,很難辨識出兩者。而現在,新工具的推出,降低了附屬性困難,卻往往給了我們本質性困難也一同降低了的感覺。

我觀察到,許多推廣者或課程設計者本身,常有這樣的誤解。為了吸引更多人加入,雖無可厚非,然而,對於本質性困難,特意避而不談,或甚至無法察覺,也並不是個正確的做法。

跨領域學習時的誤區

對我來說,輪胎或古老部落重複型圖示很陌生,因而本質性困難是顯而易見的。至今我也未正式承諾設計這類課程,同時,我也跟對方表達這類觀點,因為,這是跨領域學習時的誤區。

程式設計本身,也有其學習上的本質性困難,需要克服;輪胎,或古老部落重複型圖示也是。在此同時,我也請對方想清楚,想要學員習得的是哪個部份?

當然,很多人兩者皆想要,可惜這很難達到。就這方才兩類型的需求來說,必須找到另一個人能教授輪胎,或古老部落重複型圖示的知識,而如何能克服OpenSCAD在程式建模上的本質性困難,由我教授;除此之外,還需要考量課程時間長短,以及學員程度是否能吸收等要素。

也就是說,如果工具真的太方便了,學習就更應重視而非輕視本質性困難……

以我最近的例子來說,我對資料科學產生了些興趣,使用的工具是Python,結果怎麼了?至今為止,我花費最大量的時間,是在向量、機率、統計等學習上。

為什麼如此?因為,Python我算是很熟悉了,相關資料科學工具,看來也非常豐富與方便,真是太好了。這表示,我可以專心地學習資料科學處理需要的一些數學,並且,進一步看清,哪些才是解決本質性困難時有所助益的相關知識。

作者簡介


Advertisement

更多 iThome相關內容