另一種程式設計選擇

近來在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個蘋果等於多少？」的這種學習概念，不但具體，而且更能將知識用於解決身邊的問題之上。

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

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