也談程式設計改革

英文原文：Yep, Programming Is Borked，翻譯：外刊IT評論

導讀：如果我告訴大家，這篇文章出自一個只有20歲的小夥，我想很多人都會感到吃驚。至少我是吃了一驚，因為這篇文章涉及到主題聽起來是 很有深度的，我本人在20歲時幾乎想都不會想這些事情，更別說研究了。但又過了這麼多年，不知國內的青年們有沒有追趕上西方的步伐，也能出現幾個這樣看起來很有程式設計天分的人？

我最近看到了《程式設計改革 》這篇文章，裡面的內容討論到了我們的程式設計中存在的一個最根本的問題。我同意作者的觀點，但我感覺很多的評論並沒有理解他說的問題，所以，我打算用另外一種方式來說明一下。

我從事程式設計已經很久，主要是因為我痴迷於解決難題。我非常喜歡研究程式語言，一部分原因是作為一個程式設計師，我本身是被它們包圍，同時也是因為語言是讓我們成為人類的一個重要因素。

我享受程式設計這種職業，我喜歡這種能夠從無到有創造出神奇東西的能力，但同時也對我們每天需要處理的這些事情感到失望。下面就是原因：

程式導向 vs 面向結果的程式設計

鏈式(Concatenative)，函式式，物件導向的，邏輯式——不管你選擇何種程式設計模式，他們全都有相同的問題：它們要求你去描述如何做，而不是做什麼。在你能叫得出名字的任何一種語言裡，程式是一個對能計算出你想要的東西的處理過程的描述，而不是一個對你想要的東西的描述。誠然，一些語言會比另外一些語言更具有陳述性，但這跟“陳述式 vs 命令式”的問題並不相關——能夠陳述式的表達一個過程的語言仍然是程式導向的，而不是面向結果的。

這才是癥結所在。作為程式設計師，我們用程式碼解決問題。我們應該能夠用程式碼來表達我們想要的結果，而不是想要達到這種結果需要的過程。

作者提出的是一種“約束滿足(constraint satisfaction)”式的程式設計方式。給出一系列的約束條件，你就能夠從中推匯出一種能夠滿足它們的演算法。當然，我們必然的會擔心編譯器推匯出的這種演算法的正確性和各種效能指標；是否本來可以做到Θ(n log n)級別的，它編譯器卻給出了Θ(n!)？這是一個很合理的擔心，但它只是跟你的描述是否嚴謹有關。

你也知道，對於一個特定的演算法，我們可以通過很多種不同的但卻等效的約束集合來定義。從中進行優選，我們有信心相信，編譯器能夠推匯出我們想要的結果。我們的工作應該變成把需求用有效的約束正確的表達出來，讓編譯器去滿足這些約束。

我知道這聽起來很枯燥，我最初也是這種神奇的程式設計方式的懷疑者。但想一想：任何值得一提的程式其實都是這樣實現的，只是它們是以一種效率低的容易出錯的手工方式。一個程式設計師拿到一些需求，先整理它們，然後辛苦的把它們轉換成一種合適的處理過程。我們可以省掉這其中的一個步驟。

一個現實的例子

假設你在編寫一個遊戲。在你的待完成任務清單上的第一個要實現的事情是：通過方向鍵，讓一個遊戲角色可以在螢幕上四處移動。在任何一種語言裡，你不得不構造出一大堆不相干的基礎構件來實現這個操作：

●把一個連續的物理動作轉變成一系列相互分離的影象

●處理幀頻，幀渲染，幀衝突等問題

●管理各種活物體和死物體的狀態和資源使用問題

所有的這些折騰實際上跟我們想要的東西是沒有關係的。

很多時候，這些工作已經由某個程式庫提供完成了，但這表明一個事實：需要有人去做這些麻煩事。相比較，功能應對式程式設計很適合做這種事情。你可以準確的表達出你的意思：

● 這個遊戲角色的特徵包括：

▲某位置的加速度( a_x , a_y )

▲某位置的速度( v_x , v_y )

▲位置( x, y )

▲物體的大小( w, h )

● 當方向鍵按下時，加速度改變：

▲左：( ‒1, 0 )

▲右：( +1, 0 )

▲上：( 0, ‒1 )

▲下：( 0, +1 )

● 隨著時間的相互作用：

▲加速後的速度

▲運動後的位置

● 在( p_x , p_y )處畫素點的顏色是：

▲如果( p_x , p_y )在物體的( x, y, x + w, y + h )範圍內：

▲顯示物體( p_x ‒ x, p_y ‒ y )處的顏色

▲否則：

▲顯示背景色

這是一個完備的，完全陳述式的，完全面向結果的對一個程式的描述。這些描述都是跟你目前要實現的目標任務是直接相關的，每個描述都是一種約束，在一個RRP(這是一個簡單的約束求解程式，根據實時狀態推導解決方案)系統裡，你可以按意願新增或去除這種約束。

何去何從？

Prolog語言就是一個以約束為基礎的程式設計方式的樣本，而Haskell語言裡的FRP庫表現的更好，但這些跟我們能夠做到的比起來更像玩具。

沒有任何理由去說我們不能實現一種更好、更面向結果的語言，或者把目前存在的程式導向的語言變得更像面向結果，為這種程式設計模式賦予更大的能力。參考一下Swym這篇文章，裡面提到的關鍵字etc就能讓你實現類似的事情：

當你提供給它一些不同的引數，它能做出更智慧的事情：

這真是讓人興奮，但事情並非到此為止，我們可以把它做的更好。我們實現更多的類似etc 和 each 這樣的”魔法“操作符，可以讓一種命令式的語言看起來更像面向結果的語言。

有一段時間，我使用一個叫做Prog的語言工作。你可以把它按照普通的命令式的語言進行程式設計。但它附帶有一些特殊的語言特徵。這些神奇的語言特徵是 通過“radioactive types”實現的，它們是一種中間態的語言行為特徵，只能在直譯器分析期執行，過了此階段，它們就蛻化成普通的語法。舉個例子，對一個列舉資料結構進行 各種操作，可以這樣寫：

在讀了那篇文章和 之後的評論後，我激起了再次使用Prog語言的想法——如果有時間的話。我希望能看到更多的關於這方面的文章出現。目前開發的一個具有相似理念的專案消耗 了我大量的精力，那是一個能讓非程式設計師使用者製作出專業質量的互動式媒體的工具。如果你不知道如何程式設計，你在建立遊戲或其他媒體應用時會受到阻礙。所有的這 些幫助創造性的軟體基本上可以歸為兩類：

●功能可憐的有限

●複雜的沒法用

所以，利用研究人們能如何更好的解決問題，我開發了這樣一個工具，能讓那些心裡有想法、但沒能力把它變成現實的人解決他們的問題。目前為止，我們還有繼續努力。如果你是一個程式設計師，受到這篇的啟發，想參與做一些事情，請聯絡我evincarofautumn@gmail.com，我會告訴你如何參與進來。