在csdn上見到一篇文章，說的是電腦自動編程，原文連結為：
http://www.csdn.net/develop/Read_Article.asp?Id=27403覺得有些意思，也來說說電腦自動編程。 首先，把程式員解脫出來，讓電腦實現自動編程的想法，是很有意義的，也不完全是天方夜談。據我所知，可操作的“自動編程”的概念，作為遺傳程式設計GP的目標，已經在演化計算（智能計算的一種）中提出了；而且，在一些相對簡單而卻實用的領域，已經可以有很好的實踐。如我們系的老師康立山教授所舉的例子，他取三峽大壩岩石的資料，曾演化設計出一段程式，對其問題獲得很好的模型。 如文中所言，或許未來真可以使程式員的身份轉變，他們不再是“程式員”，而不得不成為“輔助程式員”；電腦可以自動編程，所以對於一般問題，只需購買一些自動編程組件（原文如此稱呼之），讓輔助程式員操作一定的介面就可以由電腦完成編程工作，而且比人做的更好。 然而，科學的“自動編程”概念，還處於剛剛提出的階段，事實上目前所做的工作，還是在相對簡單的問題領域上進行的。所依據的原理，所達到的成果，和我們的目標還有很大差距。如原文所言的大規模工程上的使用，還差之千裡萬裡。 為什麼如此呢？原文中並沒有深入的談。而說到如何?“自動編程”，原文只是說需要人工智慧的發展，並利用海量網路資訊。但是，其中頗為艱辛呢。 我就從進階語言C++的編程談起。 最簡單的問題領域，我們取整數的加法、減法運算。比如下面的問題： 問題. 使用C++語言，編寫程式模組完成對兩個整數a與b求和。 程式員對其編程，就會完成如下的一個程式： //compute the sum of a and b int Sum(const int a,const int b) { return a+b; } 程式員完成這個編程工作，一般思考步驟為： 1，對於該問題，所用到的資料結構是整型數，C++語言提供資料類型int。兩個整數為a和b。 2，對於該問題，所用到的演算法為整數相加求和，C++語言提供‘+’運算操作符。 3，對於該問題，程式員對模組進行設計，模組名為Sum，輸入參數為const int a和const int b，傳回型別為整型數。 顯然，其中1與2是程式的核心，是傳統意義上的程式定義。3是程式的結構，我覺得程式的結構也是非常重要的，尤其對於近年來，電腦軟體的複雜度越來越高，注意設計良好的程式結構，是必然的要求。如對於本問題，使用“函數”設計模組當然是可以的，然而使用C++類來封裝也未嘗不可。 所以，對於電腦程式，目前我理解的概念是：
電腦程式 = 資料結構 + 演算法 + 程式結構。 這個簡單的問題，由電腦自動編程來實現是否能完成？ 事實上，目前演化計算的“自動編程”，是啟發於“
電腦程式 = 資料結構 + 演算法”的思想的。我們來看一看它對上述問題的解決。 對於該問題，建立電腦自動編程的基礎——兩個集合： data = { a,b },op = { + }. 電腦自動編程所得到的程式，為data與op的一種關係，我們用字串表示。如 s1 = aa+ ;// 即 s1 = a + a ；現在對於一個字串s，電腦便可以進行自動設計： s = a ; // 尚未成功 s = aa; // 尚未成功 s = aa+; // 不合要求的程式，捨棄 s = a; // 尚未成功 s = a+; // 不合法的程式，捨棄 s = a; // 尚未成功 s = ab; // 尚未成功 s = ab+; // 程式成功，退出 換言之，電腦自動編程的程式，這裡定義為
電腦程式 = data * op .當然，獲得一個合要求的電腦程式，不是一個枚舉的過程。演化計算的方案是使用隨機策略、通過演化獲得好的程式。 data和op兩集合，是自動編程的基礎，可相對於問題的領域與複雜度而設計（好比程式員所需要的電腦語言複雜程度也不同一般）。比如，上述的data再加入兩個整型變數x，y，就完全可以設計出和Sum模組功能相等的程式。如果data和op擴充如下： data = { a0,a1,a2,...an,n,x },op = { +,-,* }.其中x是實型變數，那麼就可以由電腦自動編程來設計多項式逼近的程式。 而且，邏輯操作如if，else，還有迴圈操作，都可以加入到op集合中。那麼，自動編程可解決的問題領域會更大。 然而，自動編程仍只是剛剛開始。說它要代替程式員的工作，還為時尚早。 首先，電腦自動編程是基於集合data和op的，這兩個集合可比於電腦自動編程的語言，但這個語言還非常的不完善。對於個別的問題可以設計一個可行的語言，但大部分問題還沒有辦法找到合適的語言，更不用說設計出一個較為普遍的語言。而程式員所使用的電腦語言，則已到了相當完善的程度。而OO語言出現後，程式員可以設計自己的資料類型，電腦的自動編程目前是無法做到這一點的。 比如對於上面的問題，程式員可以設計一個資料類型對整數進行封裝（我們不談它對本問題的實際意義，很顯然我們重視它的抽象意義）： //define new type :Integer class Integer { //... public: //... }; 由此，程式員對於現實世界進行建模的時候，表達工具（電腦語言）是相當得力的。然而電腦自動編程的data與op，對工程計算與簡單邏輯判斷，可以很好的建立模型，但在深度與廣度上卻遠遠落後於程式員。 其次，我覺得電腦程式的概念，必須要加入“程式結構”的因素；程式結構的因素，對於大規模工程應用具有重要的意義，而且是程式員智慧體現的精彩處。一個複雜問題的程式，糟糕的結構，往往是致命的。比如一個全域的指標對象，就會有太多的陷阱，能讓設計不好的系統徹底癱瘓。然而好的結構則不然。另外，程式員充分利用“程式結構”上的經驗，總結出好的設計模式，開發出效能良好的類庫、程式架構，使得程式設計的繼續得以良性迴圈。 但目前自動編程尚沒有規劃這方面的問題。一開始的定義，就是基於data與op的，而data*op的過程，目前由演化計算來做，就如處於組合語言程式設計時期的程式員，可考慮的程式結構是很少的，只能拚命般的用聰明的腦袋對付問題的複雜度。 最後，當然是目前電腦的制約。就目前自動編程的主要問題，還是難以處理的複雜度。電腦本身效能的進一步提高，好的演算法進一步開發，會使得自動編程進一步發展。但問題並非孤立的，解決問題的複雜度，當然也得考慮自動編程自身理論的發展，如突破上述的界限等。 原文中還提到利用網路資訊資源，與電腦的學習能力，當然，這些步驟都是必然的。自動編程肯定要面臨這些學科資源。但這涉及的問題更多。集中的說，網路和分布式系統，與人工智慧，都要解決大量的問題，才可在工程上更充分進入自動編程的範圍。目前來看，還是智能計算與自動編程關係最為緊密，也是主要的推動學科。 這裡所說的，都是從軟體的角度。原文另外提到跨系統（比如windows與UNIX）的自動編程，我想這個問題程式員更為頭痛些。不妨更寬泛的說，由於偶然或必然的原因，電腦體繫結構目前是多種多樣的，自然程式員的編程都是基於某種體繫結構的電腦。一個CISC機器的程式，在RISC機器上運行肯定有問題；那麼在前者上編程（無論是程式員還是自動編程），如何無縫移植到後者上去，我想這就不僅是程式設計的問題了。 原文中提出“輔助程式員”的說法，我覺得很有意思。既然編程的工作，下放給電腦，那麼輔助程式員就是要管理那些進行“自動編程”的電腦了，這有些專案經理的味道了。 很顯然程式員在程式設計的時候，受軟體工程上的一些規律制約。而這個過程的管理，是十分複雜的；大部分專案經理都有經驗的。那麼，如果多個電腦在“協同自動編程”的時候，又會是個什麼樣子？其中有那些規律可探討？我想雖然電腦可以自動編程了，程式員從編程的工作中解脫了；但行業對人的要求並沒有降低是嗎？ 或許應該說，時代在發展，行業對於人的要求，永遠都是在提高的。 除非，人工智慧徹底的成熟，機器和人具有一樣的行為方式了。人或許可以休閑了。 那麼，“輔助程式員”們，你們怕不怕？這個問題就不僅僅是行業內部問題了，電腦也要薪水的話，整個社會就會關注它了。
