近來在3D建模的領域中,挑戰著各式迷宮以及幾何數學,看著腦中想法化為實體世界一部份的過程,著實令人沉迷,某日我從3D建模的小世界中探出頭來,看著程式社群與網站上那些想搶佔目光的各式標題與討論,這些資訊突然給我一種如此遙遠而不具體的陌生感,腦中也萌生了一個想法,在程式設計入門之時,程式人真的還需要從一門通用目的語言(General-purpose language)或環境作為開始嗎?

Polyglot Programming的反思

其實這種感覺也不算是第一次了,程式設計演變至今,已經是個非常大的領域,沒有人能掌握所有的一切,也沒有人能跟上所有的新知,相信認真在程式設計這條路上耕耘的人們,多半也會有類似的感概,這條路上必須知道的越來越多,因而當我看到《程式設計人應該知道的97件事》時,嘴角立即失守大笑,甚至一度懷疑,O'Reilly出這本書,根本就是在故意嘲諷這個現象。

對於一個要在這條路上前進的程式人來說,該如何面對這個日益膨脹的領域?有人主張,程式設計中看似在變,然而有些本質上不變的部份,因此該針對這些本質上不變的部份奠定好基礎,這個說法基本上沒錯,不過實際上,單只是這個本質的部份,也是多得不得了,為了未來不知道可能會面對的種種問題,程式人得於提前拼命地學習解決問題的基礎知識。

另一個現象就是,由於程式人終究還是得以某個語言來實現解法的方式,為了應付各種未來可能出弄的問題,該選擇哪門語言成了難題,也經常成為論戰的主題,是的,選擇一門盡可能涵蓋各領域各問題的通用目的語言,可以只學一次就應付各種狀況,會是最佳的投資;然而,許多程式人其實用不上通用目的語言的所有特性,卻往往得在一開始全面地瞭解,更糟的是,這些語言為了照顧更多的需求,隨著時間演進的同時,會納入更多的元素,變得日益龐大而笨重。

事實上,這幾年來斷斷續續地,一直有著Polyglot Programming這類概念的文件或者實作出現,使用單一語言對付應用程式各式需求的年代正在逐漸遠去,使用某個語言在某個範疇做它擅長的事,再適當地連接或膠合起來已經不算鮮見,若真是如此,那麼程式人在開始程式設計這條路時,真的還需要奠定各種基礎,或者從一門通用目的語言或環境作為開始嗎?

具體結合既有的知識

來思考一個老戰題「寫程式要不要用到數學」,這問題的答案往往視不同程式人的工作經驗而有所不同,贊同者與反對者在此話題上,也經常不會有交集,戰文的內容經常都是就結果在戰,也就是會不會在工作上用到數學在戰,卻很少看到在思考為何這個問題為何會發生!

實際上這個問題還有一個意義,許多時候,我們經常是以彼此分離而互不相關的方式,在學習新知識。在學習數學時,就真的只是在學習數學,在學習程式設計時,就真的只是在學程式設計,很少去思考如何用程式解決數學問題,或者是用數學解決程式問題,甚至是結合數學與程式,來解決另一個領域的問題。現在經常在談跨領域的重要性,然而,我們在一開始學習時,卻很少思考具體結合既有知識的重要性。

為何不能在學習程式設計的同時,就試著結合既有的知識呢?單就「寫程式要不要用到數學」這個問題來說,何不在一開始學習程式時,就試著找一門可結合數學來具體解決的語言或環境呢?目的不是擺在學會該語言或環境的全部元素,而是擺在學習擷取適當的程式及數學元素,來解決一個具體的需求,也就是說,要學習的其實是如何解決問題,程式與數學只是問題解決過程中,順道習得與應用的技能。

〈【洪士灝v.s蘇文鈺】真正的資訊教育不在學寫程式,關鍵在學用電腦解決問題〉這篇虛擬對話中,有一句很重要的話寫著‥「學生學會如何解答問題,但不知道要解決什麼問題」,這其實除了可用在程式設計上之外,也可以用在任何學科,就數學來說,也可以寫成是‥「真正的數學教育不在學解數學,關鍵在學用數學解決問題」。

結合數學的程式設計

當然,領域很多,知識也很多,為了能具體比喻,還是來談談結合數學的程式設計是怎樣的一回事。實際上,在我先前專欄〈程式、數學與Maker〉中已經談過一些例子了,像是級數、機械手臂轉動角度的運算等,程式人不必學會一門語言或數學的所有元素與細節,也能做這類任務的解決。

實際上,有一些語言或環境,本身就是著重在特定領域,像是Processing這門語言,就著重在繪圖,程式人不用先搞懂一堆艱澀的語法或邏輯,只需要使用簡單的圖形函式繪圖作為開始,當試著結合迴圈而創造出美麗的圖案時,就會有想要試著挑戰更複雜圖案的欲望,而這會是結合數學的開端。就實用性而言,在Maker領域中,有許多應用是結合感測器擷取而來的數據,並以圖案表現出數據本身代表的意義。

最近我沉迷其中的程式3D建模,當然也是個具體的例子,基本上我是以一邊試著解決建模問題,一邊學習OpenSCAD語言的方式進行,從一開始,因為得同時思考程式邏輯與幾何數學的不熟悉,而舉步維艱,到後來因為逐步在結合OpenSCAD及幾何數學上取得成就感,而不斷地挑戰各種形狀的迷宮、字元之塔等建模問題,我可以清楚地感受到,無論是OpenSCAD、幾何數學或者是程式設計技巧,都因為彼此之間的交互應用,而獲得了提昇。

許多人學習事物,總喜歡問:學這些東西,能做什麼?就OpenSCAD,或者其他程式建模的方案來說,除了能同時訓練程式設計與數學邏輯之外,還能將成果透過3D列印,在實體世界中佔有實際的空間,而不再只是虛擬於電腦之中,這會是個更具體的回饋,當然,列印出來的成品,也能是解決日常生活中具體的需求,或者是某些機器的替代零件,甚至是過去因不符合經濟成本,而無法或難以取得的組件等。

與既有知識迭代增長

當然,各種知識的基礎都很重要,將來也許都會應用得上,然而,累積某個知識基礎的方式,不見得一定得是將該知識抽象化到與其他領域無關的程度,學習時,1+1=2的抽象觀念或許很棒,然而,有時「1個蘋果加1個蘋果等於多少?」的這種學習概念,不但具體,而且更能將知識用於解決身邊的問題之上。

回顧一下程式設計這領域的基礎好了,資料結構、演算法、物件導向、函數式、設計模式等,這些都很好,然而,還記得剛開始接觸物件導向封裝、繼承、多型時,那種過於抽象而無法理解其概念的年代嗎?有時沒實際面對問題,便無法理解某個方法或知識的重要性,從而缺少了學習的欲望與動機,許多人就是因此而在學習的過程中,迷失了方向;反過來說,也有人因為遇上了實際問題而理解了某個方法的重要性,再回頭重拾相關知識時興緻盎然。

另一種程式設計選擇值得思考,也許不再是從一門通用目的語言作為開始,而是從某個特定領域的語言或設計環境著手,也許不再只是解決那些資料結構、演算法上著名的題目,而是嘗試結合數學、物理這類既有的知識,讓程式設計與知識之間彼此結合應用,激發獲取更深度技巧的需求,在這個彼此迭代的過程中,或許更能夠奠定更扎實而具體的基礎。

作者簡介


Advertisement

更多 iThome相關內容