真的需要一個人人都會程式設計的未來麼?

kimylrong發表於2013-11-09

近幾年來,科技行業有強烈的願景去教會所有人程式設計。

“所有學校的每一個學生都應該有機會學習電腦科學”——CODE.ORG

每個人都應該有學習電腦科學的機會。對計算的理解,可以改變你的思考方式,並且它直接給你驚人力量去實現自己的創意。理解一些概念比如抽象、耦合、普適、複雜度以及伸縮,能夠改變你思考以及定位問題的方式。運用通用性的程式設計工具改變你解決問題的方式。

自農業之後,現在軟體比任何其它技術都更劇烈,更快地改變著世界。不管是在科技行業還是其他行業,現在它都是業務增長和創新的核心,並且快速改變著人們的生活方式。軟體已經主導了我們獲取知識,儲存及處理資訊,釋出及接收多媒體,處理商業事務,和朋友、同事、社群溝通的方式。世界上最大的圖書銷售商和最大的視訊服務商都是軟體公司;主要的幾家音樂公司也是軟體公司;增長最快的娛樂公司和電信公司還是軟體公司。那些非軟體公司正越來越多的依賴軟體來優化物流、供應鏈、生產流程,和廣告,亦或提供工具給員工去創造更多的價值。軟體來到了這樣的一個臨界點,改變我們教授和學習知識,借款和貸款,瞭解和關心健康,搜尋和消費各種服務的方式。

儘管軟體給我們的生活帶來了空前的變革,但總有一天,程式設計將會變少。對程式設計的狂熱以及程式設計的增長都是暫時的,程式設計是眾多工具的產物。現在程式設計是實現計算最好的技術,但是程式設計自身並不是電腦科學的必要部分。計算就是處理資料並通過一些演算法來解決問題。當前程式設計是我們不二的選擇,但是我們必須創造更好的工具。將來一天,不需要寫一行程式碼就可以處理資料以及驅動演算法將變得習以為常。我已經迫不及待了。

程式設計是一項非常專業化的技能。處理複雜問題自然地是困難的,作為一個程式設計師,我經常寫程式解決各種複雜度的問題。我對那些非程式設計師用來處理簡單自動化任務的技術懷有敬畏之心。我有幸接觸過一個邏輯及語言工具,在我腦中模擬一臺電腦並通過有著怪異規則的不常見的語言和它溝通(我不太善於模擬人)。很多人並不適合程式設計,但大多數人還是需要解決複雜問題所帶來的好處。程式設計相關的工具及方法使得通過程式設計解決問題複雜化,會把我們大多數人擋在通過計算解決問題的大門之外。程式設計並不容易學習,並且和人們所希望解決的問題也無多大關係。人們不應該非得通過程式設計才能運用軟體來解決問題。有那麼幾個工具,我認為能夠給非程式設計師帶來像程式設計一樣解決問題的能力。

計算器

自上世紀70年代推出行動式計算器以來,計算器已經發展了很多。可程式設計的計算器讓科學家和工程師能夠解決一些比普通算術更復雜的問題(儘管他們可能使用了一些程式碼)。圖形化的計算器幫助他們直觀的理解計算結果。自從個人電腦和膝上型電腦流行以來,軟體化的計算器介面已經朝著展示使用者所處理問題的方向發展著,而不是不合潮流的累加風格實現方式(一次性從左到右敲一整行的表示式,而不是每次一個資料專案,一個操作符,來來回回多次)。創新的設計(如SoulverCalca)把計算器內嵌其中,並在介面顯示工作狀態,提供改變輸入引數及實時檢視結果的能力。

電子表格

電子表格有30來年的歷史了,但是依然像受書啟發而發明的老祖先一樣基礎和重要。它依然最重要的輕量級記賬工具,並且證明是一個通用的計算和建模工具,同樣也善於展示表格式的資料。表格格式如今依然足夠通用,並可分飾多角,實時重算功能有助於問題的拆分處理。許多和資料打交道的人有高超的電子表格技術,他們能夠做一些非常非常瘋狂的作品。更復雜的,電子表格可以用來儲存和研究資料(特別是資料透視表出現之後),幫助人們開發和計算複雜的多變數的表示式,探索模擬和假設的場景,並實時呈現結果。電子表格是一個通用的工具,能做遠超當初電子表格作者能夠想象的事情。從某種程度上來說,它非常接近於人們使用的程式設計工具。

不過電子表格也有不足之處,特別是以今天對使用者介面以及處理能力的標準來看。它在處理多維資料的時候就會顯得力有不及,你得提前決定維度,否則需要從頭開始。可以通過使用多個連續的單元格以及重複交叉計算,來粗略模擬向量和平行計算,但是它們並不能理解你的資料模型,也就沒有能力提供更多的幫助。電子表格把扁平化二維表格資料檢視介面與資料本身和計算資料的公式合在一起。字母數字單元格的地址是不透明且易變動的,移動資料或者改變佈局都有可能破壞其他的單元格或者影響計算結果。公式是隱藏起來的且難以驗證其正確性,如果你不是原作者,甚至理解其功能也很困難。

80年代中期有幾個電子表格專案嘗試解決其中的一些缺點,特別是把資料與表格化顯示剝離開來。比如 JavelinTrapeze 以及Lotus Improv,不過它們已經消失在我們的視線中很久了,遺憾的是在軟體市場上並沒有再看到類似的軟體。

個人資料庫

當你在處理複雜或者多維的資料時,有時候電子表格解決不了問題。對於大部分人們想解決的問題,對資料的操作、查詢和統計都是必要的。但是不像電子表格,令我印象深刻的是過去幾十年間個人資料庫的受歡迎程度大大降低。個人資料庫不再流行了嗎?還是說現在的我和大家不在同一個圈子裡面?可能是由於程式設計師不鼓勵大家使用個人資料庫吧,依”專家”的意見。還記得大學時候討厭MS Access,實在是不屑於滑鼠點點就能構建查詢那些小技能,我是幼稚的,痴迷於SQL的強大能力。我們應該把個人資料庫的功能都教給大家,而不是教大家程式設計,至少也應該排到程式設計之前。

我最近發現MS Access可以很好的用來開發增刪改查的應用,Filemaker也類似。等下次我想構建一個大資料量的應用的時候我倒是非常有興趣試試Zoho Creator。儘管這些軟體都發展了很多,但是如要構建真正的應用它們還是顯得不夠靈活,僅僅能處理一些簡單的表單和檢視。

還有好幾個特定的領域,非程式設計師也有工具來處理類似程式設計能夠處理的事情,但只需很少的程式碼。遊戲開發就是一個很好的例子,遊戲是提供特殊互動的計算機程式。遊戲通常是複雜的程式,由使用者介面主導,但是遊戲開發專案組卻由美工和設計師主導,而不是程式設計師(視遊戲需求而定)。美工和設計師使用程式設計師開發出來的工具實現很大部分遊戲包含的內容,如美術,結構,地圖,模型,動畫,情節,關卡設計,迷宮,對話,故事。假設這樣的一個流程,關卡設計師提供圖紙和寫好的規則讓程式設計師用程式碼來實現,一遍遍的重複相同的流程直到關卡設計師滿意為止,看起來很冗繁(當前大部分的應用使用者介面都是這樣實現的)。遊戲領域不是這樣的,程式設計師先開發遊戲引擎和關卡設計工具,然後設計師就可以在一個非常接近真實遊戲的環境裡面設計,並能夠實時地把設計裝載到遊戲引擎中執行起來。

遺憾的是現在的介面設計工具不適合非程式設計人員使用,甚至是很多程式設計師。自滑鼠發明以來,滑鼠點來點去這樣的小伎倆是被“真正的”程式設計師輕視的,就像彙編程式設計師看不起早期的Fortran擁護者,C程式設計師看不起Java程式設計師,Vi/Emacs使用者看不起依賴IDE開發的程式設計師一樣。那些已經掌握高難度工具或者流程的人總是很難接受新的更強大的事物。

長時間以來,GUI的構建工具就是一坨屎,現在依然是。它們通常只是簡單的顯示將要實現的介面效果,一方面不足夠強大使得程式設計師可以用它實現他們所想要實現的功能,另外一方面又複雜且充斥著各種程式設計概念,使得非程式設計師難以使用。程式設計師自然而然地迴歸到編寫程式碼實現介面的方式,因為他們需要做一些工具做不到的事情。這樣做是錯誤的,雖然可以理解。程式碼帶來一個視覺概念與思維方式的不一致的嚴重問題,特別是程式碼是過程式的,如果是申明式的還好些,你構建你正設計的介面。重新編譯、釋出並檢查介面變動實在是一個漫長的開發過程。我完全理解這種做法,但是設計師在Photoshop設計好作品,然後讓程式設計師用程式碼再次從頭開始實現作品實在是一個人力的極大浪費。我們的GUI工具必須得提高,使得設計師設計GUI介面,隨後程式設計師來接管介面與後臺的互動(Spark InspectorReveal預示未來)。

其它一些提供給非程式設計師類程式設計能力的有批處理器(如Photoshop),多節點且分層的合成工具(如ShakeBlender),蘋果公司多節點圖片處理以及顯示工具Quartz Composer,為Mac OS錄製指令碼的Automator,用於科學和工程設計分析的MathematicaMatlab、和LabVIEW,收集聚合網際網路內容及API資料的Yahoo! PipesIFTTT,內容管理和展示工具wikis。特別值得一提的是HyperCard(1987-2000),迄今為止最有影響力的應用設計環境。我依然清晰的記得遠在掌握程式設計的基礎概念之前就能夠構建棧及寫HyperTalk程式碼。我做了一些自己覺得驕傲的事情,看到我們和父輩(在計算機出現之前接受的教育)做相同的事情。如果你錯過了,請讀一讀reminiscence。超連結、網際網路、wikis,都繼承於HyperCard,LiveCode也是其中一個分支。

因此我們有應用於數學的分析及計算工具,糟糕的使用者介面設計器,以及用於遊戲、圖形、黑客的特定領域工具。下一代能夠讓程式設計師和非程式設計師都不用寫程式碼就能完成應用功能的產品應該快速的增長,他們不幫你寫程式碼,只是使得寫程式碼不再必要。我希望這樣的工具趕快出現,完成那些現在用編寫程式碼方式實現的功能,讓大家都能夠構建各種有用、高質量的應用。特別地,我們將達到一個更高的境界,這些工具有自我改進功能,非程式設計師可以用工具構建出新的工具,從而構建更多的應用,包括更出色的工具。

那些六位數的工程師並不認為把Photoshop作品與一些指令合起來構建一個可用的使用者介面是一件浪費時間的事情,從這可以看出解決此類問題有很重要的意義。如果你碰巧是一個程式設計師且我的言論讓你感覺不快,請想想如果你不再需要花一半的時間去把PSD轉化為HTML,你將能夠創造多少更多的價值。是的,我知道前端開發並不容易,它確實很複雜。但是絕大多數的複雜性都是由我們所使用的工具引起的,而這些工具並不是解決問題所必需的。高深的軟體工程技能和晦澀難懂的業務知識顯得如此重要,那是因為構建一個使用者介面需要幾千行的程式碼。如果有一天不再需要那麼麻煩,你就可以把你的聰明才智用到更有意義的事情上面。

以前那些嘗試幫助非程式設計師寫程式碼的專案大多都不成功,尤其是通用型的那種。感謝現在正使用我們的介面並提出改進建議的數十億的使用者,最近從他們那裡我們學習到了很多關於使用者介面的東西。開發建立型工具的挑戰在於提供使用者一個功能強大的介面但又不能複雜得讓使用者不知所措。然而在任何領域都有那麼一些專家在攻克不可能與簡單之間的壁壘,就像工具能夠讓曾經要求專業知識和技能的人才能完成的事情變得普通人也能夠處理一樣。我們見證了業餘的音樂和視訊在數量和質量上的爆發式增長,這都得益於生產音樂和視訊的工具變得如此的好,如此的簡單,如此的便宜。隨著我們設計複雜業務介面的能力提高,我們將構建出更好更簡單的可以讓非程式設計師也能設計和實現更多軟體的工具,我對此表示樂觀。在這個過程中,有些人可能成為發展的奠基者,但更多的人只需要使用工具來幫他們完成工作。

程式設計師總是傾向於為程式設計師開發工具。為擁有較高專業技能的使用者開發工具確實是件更容易的事情。但是非程式設計師能夠使用的工具也能夠為程式設計師提供幫助。減少對駕馭計算的認知壓力,將有利於程式設計師騰出更多的時間和精力去更快地解決更多的複雜問題。像虛擬世界裡的成功員工一樣,能夠處理一些份外之事。我們依然需要程式設計師,經驗豐富的工程師以及充滿創造力的問題建模、演算法和資料結構設計、難關攻克、流程管理相關的實踐者。但他們會像今天的農民一樣,只佔總人口的一小部分,足以支撐全民的食物供給。

一個人人會程式設計的未來固然是好的,但現在程式碼只是駕馭計算的一個方法而已。當我們的技術達到每個人都擁有用來思考創造的工具並且很少需要編碼的時候,我們將能更好去攻克一些社會性的難題。程式設計師們現在就可以去構建那個技術了。

教會更多的人寫程式碼是偉大的進步,但一個很少需要寫程式碼的未來會更好。

相關文章