注意: 雖然 JavaScript 對於本網站並非必不可少,但您與內容的互動將會受到限制。請啟用 JavaScript 以獲得完整體驗。

人人可程式設計

人人可程式設計

這是我們在 1999 年 8 月傳送給 DARPA 的一份修改後的資助提案的文字。3 月,我們聽說至少該提案的早期版本已被 DARPA 接受;工作已於 1999 年末開始,並有望持續兩年,儘管我們僅收到了第一年(到 2000 年 10 月)的資金。我們正在祈禱剩餘的資金。

不幸的是,Python 開發團隊轉到其他僱主意味著我們沒有在 CNRI 完成 CP4E 專案。這一變動在很大程度上是由於 DARPA 對 CP4E 承諾的資金數量令人失望。

該專案現在處於停滯狀態;IDLE仍在開發中,但我們並未積極追求 CP4E 的其他目標。然而,其他人正在努力;這通常在 EDU-SIG 郵件列表中討論。

注意:我對提案的文字做了一個更改:應其他語言的一些支持者的要求,我撤回了一個包含對其他語言的高度個人化且有時毫無根據的意見的語言比較圖表。該表格在上下文中被以一些人認為令人反感的方式使用。(並非所有表格都有爭議,但如果沒有更多文件,似乎不宜直接進行語言比較。)

我還從文字中刪除了一些管理細節,並做了一些細微的更改以適應 HTML。我對寫作風格表示歉意,有時它更像資助提案而不是我所寫的大多數散文。我要感謝 Jeremy Hylton、Barry Warsaw、Al Vezza、Bob Kahn、Randy Pausch 和 David Beazley 的貢獻和建議,使該提案取得了成功。

--Guido van Rossum

更多資源列在以下頁面中

  • Python 教育特別興趣小組(EDU-SIG)
  • IDLE - Python 自己的互動式開發環境
  • DARPA 提案 - 一切的開始
  • 討論關於 Ward Cunningham 原始 Wiki 上的 CP4E。

 
 
 

人人可程式設計
(修訂提案)

為未來程式設計師進行的偵察探險
 
 

國家研究倡議公司

1999 年 7 月

CNRI 提案編號 # 90120-1a

負責人:Guido van Rossum



 
 
 
 
 
 
 
 
 
 

聯絡人:Guido van Rossum
國家研究倡議公司
普雷斯頓懷特大道 1895 號 100 室
弗吉尼亞州雷斯頓 20191-5434
電話:(703) 620-8990
傳真:(703) 620-0913
電子郵件:guido@cnri.reston.va.us


創新主張

在 70 年代,Xerox PARC 提出:“我們能否在每張辦公桌上都放一臺計算機?” 我們現在知道這是可能的,但這些計算機不一定能讓使用者變得更強大。今天的計算機通常是不靈活的:普通計算機使用者通常只能更改透過“嚮導”(一個用於罐頭對話的高尚詞彙)配置的有限選項集,並且在其他所有事情上都依賴於專業程式設計師。

我們提出一個後續問題:“如果使用者可以自己程式設計計算機,會發生什麼?” 我們期待著未來,每個計算機使用者都可以“開啟”計算機的“引擎蓋”,並改進其中的應用程式。我們認為,這將最終從根本上改變軟體和軟體開發工具的性質。

我們將大規模讀寫軟體的能力與大規模識字能力進行比較,並預測社會將發生同樣普遍的變化。硬體現在足夠快速和便宜,可以實現大規模計算機教育:當大多數計算機使用者掌握建立和修改軟體的知識和能力時,下一個重大變化將會發生。

開源運動聲稱,數千人對軟體進行同行評審可以大大提高軟體的質量。Linux 的成功表明了這一主張的價值。我們認為,下一步,擁有數百萬(或數十億)的程式設計師,將引起不同質量的變化——個性化軟體的充足供應。

這種看待程式設計的新方式所需的工具將與專業程式設計師當前可用的工具不同。我們打算大大改進培訓材料和可用的開發工具。例如,非專業程式設計師不應擔心一個小錯誤可能會破壞他們的工作或使他們的計算機無法使用。他們還需要更好的工具來幫助他們理解程式的結構,無論是明確的還是隱含在原始碼中的。

我們的計劃有三個組成部分

  • 開發一套適合高中生和大學生(非計算機專業)的新計算課程。
  • 建立更好、更易於使用的程式開發和分析工具。
  • 圍繞以上所有內容建立一個使用者社群,鼓勵反饋和自助。
這些元件共同構成了對下一代計算環境中程式設計作用的科學探索。

我們打算從 Python 開始,這是一種為快速開發而設計的語言。我們認為 Python 是學習的絕佳第一語言:與專門為初學者設計的語言不同,Python 也是許多程式設計專業人士的選擇。它擁有一個活躍、不斷增長的使用者社群,該社群已經對該提案表示了濃厚的興趣,我們預計這將是我們計劃建立的教學材料和工具的肥沃的首次部署地。在研究過程中,我們將評估 Python 並提出改進或替代方案。

理由

CNRI 提議進行一項名為人人可程式設計 (CP4E) 的研究工作。這項工作旨在透過授權所有使用者成為計算機程式設計師來改進計算機使用的現狀,而不是引入新的硬體,甚至(主要)透過新的軟體。

計算機和通訊硬體的最新發展使許多人可以訪問強大的計算機,形式包括桌上型電腦、筆記型電腦和嵌入式系統。現在是時候透過教育和支援軟體為這些使用者提供對其計算機的更多控制權了。如果使用者在軟體設計和實現的層面上對計算機有普遍的瞭解,這將導致生產力和創造力的巨大飛躍,其影響範圍之廣,幾乎無法預見或想象。

在短期內,可用的計算機軟體的數量和質量將大幅提高,因為數百萬人的想象力和勞動將應用於解決該問題。富有創造力的使用者將能夠改進支援他們完成任務的軟體,並透過網際網路與面臨相同任務和問題的其他同事或遠方的人分享他們的改進。在專家無法求助的危機情況下,修改或自定義軟體的能力非常重要。它對於日常活動也很重要:目前,一些人估計未填補的程式設計職位數量為 200,000 到 400,000。

研究目標

兩個主要的研究目標是開發一種新型程式設計課程的原型和包含高度使用者友好的程式設計環境的匹配原型軟體。我們設想的典型目標受眾將包括高中生和(非計算機專業)本科大學生,儘管也會考慮年齡較小的學生和成人。課程和軟體通常會一起使用,因此它們應該緊密配合;每個都可以單獨使用。

我們還將探索程式設計在未來的作用。我們正在迅速進入一個資訊裝置、可穿戴計算機和日常物品中深度聯網的嵌入式 CPU 讓使用者控制其物理和資訊環境的時代。終端使用者的可程式設計性將是解鎖這些技術的潛力的關鍵。(這是 DARPA 資訊科技探索的一個共同主題,參見 [Dertouzos]。)

研究工作不會孤立進行。我們將與學術研究小組以及幾所領先的高中進行合作。我們還將透過在網際網路上免費提供我們的課程資料和軟體來建立一個更大的社群。

我們計劃從基於 Python 開始這兩個元件,Python 是一種流行的免費解釋型面嚮物件語言 [Python] [Lutz] [Watters]。Python 最初在阿姆斯特丹的 CWI 開發,目前正在由 CNRI 開發和維護。Python 非常適合教學目的,而且不是一種“玩具”語言:它作為一種快速應用程式開發語言在計算機專業人士中非常受歡迎。Python 將來自幾種主要程式設計範例(過程式、函式式和麵向物件)的元素與一種優雅的語法相結合,這種語法對眼睛來說很舒服,並且易於學習和使用。雖然我們認為 Python 是一個很好的起點,但毫無疑問,我們將會了解到可以進行改進。作為我們研究的一部分,我們將評估 Python 在教育和初學者使用方面的有效性,並設計改進或替代方案。

我們預計,我們的研究成果將在兩年內得到展示,並在十年內影響整個社會。屆時,在高中階段使用我們的課程學習計算機程式設計的孩子們將開始加入勞動力市場(以及軍隊)。我們預計上述新的移動和嵌入式計算與通訊技術也將在同一時間趨於成熟。因此,我們的時間表是完美匹配的。

動機

在黑暗時代,只有那些擁有權力或鉅額財富的人(以及選定的專家)才擁有閱讀和寫作技能或獲得這些技能的能力。可以說,普通民眾的識字率(雖然仍未達到 100%),以及印刷技術的發明,一直是現代歷史上最具解放性的力量之一。

我們只是最近才進入資訊時代,預計計算機和通訊技術將很快取代印刷成為資訊傳播技術的主要形式。大約一半的美國家庭已經擁有至少一臺個人電腦,而且這個數字還在增長。

然而,儘管現在很多人使用電腦,但很少有人是計算機程式設計師。非程式設計師在如何使用電腦方面並沒有真正的“權力”:他們被限制在使用“程式設計師”為他們確定的應用程式。不需要有遠見就能看到這裡的侷限性。

一個更徹底的改變是將計算和通訊嵌入到家庭和辦公系統中。預計未來幾年,包含可程式設計元素的裝置數量將急劇增長。我們必須學習如何以有意義的方式向用戶展示這種可程式設計性,並使非程式設計師能夠輕鬆控制和程式設計這些裝置。

在這個“未來探索”中,我們想探討這樣一個概念:就像學習閱讀和寫作一樣,幾乎每個人都可以在學校獲得某種程度的計算機程式設計技能。

大眾使用的程式語言和環境面臨許多挑戰。如果每個人都是程式設計師,那麼肯定會有很多水平不高的程式設計師。要充分應對這種情況,就需要重新思考程式語言和開發工具的基本屬性。然而,我們認為專業人士使用的工具和教育使用的工具之間不應有明確的區分——就像專業作家使用與讀者相同的語言和字母表一樣!

鑑於計算機和軟體在社會各個方面的使用越來越普遍,我們預計對程式設計技能的需求只會增加。雖然大多數高質量的軟體將由專業人士製作,但終端使用者將需要更多的程式設計和定製。

這種對靈活性的追求在當今的計算及其可能的未來都可以看到

  • 功能日益強大的桌上型電腦和筆記型電腦應用程式使用指令碼和宏功能。
  • 網際網路的發展直接導致了對可程式設計性的更大需求,以建立活躍的和互動式的 Web 內容。
  • 終端使用者的資訊裝置和嵌入日常物品中的 CPU 網路——這兩者都需要使用者控制和個性化。
  • 移動和智慧軟體代理將很常見,並且需要使用者進行自定義。
我們的願景

在未來,我們設想計算機程式設計將在小學教授,就像閱讀、寫作和算術一樣。我們真正指的是計算機程式設計——而不僅僅是計算機使用(這已經在教授)。例如,Logo 專案 [Papert][Logo] 表明,幼兒可以從計算機教育中受益。當然,大多數孩子長大後不會成為熟練的應用程式開發人員,就像大多數人不會成為專業作家一樣——但是閱讀和寫作技能對每個人都有用,因此(在我們的願景中)通用的程式設計技能也將如此。目前,我們設定的目標不那麼雄心勃勃。我們專注於向高中生和(非計算機專業)大學生教授程式設計。如果我們在這一方面取得成功,我們預計低年級很快也會效仿,在他們的能力範圍內。

除了教授計算機如何工作這一目標外,計算機程式設計課程還將恢復對邏輯思維的強調,這曾經是教授幾何學的主要好處。

兩個特別受關注的通用計算趨勢是轉向資訊裝置以及日常機器和裝置中嵌入式 CPU 的增長——無論是在軍事領域還是民用領域。計算規模的縮小和網路覆蓋範圍的擴大,特別是無線網路,使得在裝置之間共享資訊以及與裝置互動成為可能。程式設計能力將大大提高使用者控制這些裝置的能力。想象一下,使用者可以對自己嵌入式 GPS 接收器或掌上電腦中的軟體進行更改,而不是(或者除了)從供應商下載升級或從第三方購買“罐裝”附加應用程式。這將大大增強人們透過程式設計他們的個人工具來準確地做他們需要的事情來改善生活的能力。

如果我們成功,非專業人士將能夠更有效地使用他們的計算機和其他智慧裝置,從而減少他們的挫敗感並提高他們的生產力和工作滿意度。(新的休閒可能性無疑也會隨之而來!)計算機使用者將能夠更頻繁地解決自己的計算機問題,從而減少對技術支援的需求。

即使大多數使用者不經常程式設計,熟悉程式設計和軟體的結構也會使他們更有效地使用計算機。例如,當出現問題時,他們將能夠更好地對可能發生的故障進行心理建模,這將使他們能夠修復問題或解決問題。他們還能夠更好地評估何時可以自己進行更改,以及何時需要專家的服務。他們將更能夠與專家交談,因為他們現在將更多地共享通用語言。一個類比是獲得汽車維護方面的基本知識:您知道足夠多的知識來檢查您的機油並在必要時新增幾夸脫,但是您也知道您不應該嘗試自己更換剎車片。當機械師說“您的轉子變形了,您需要新的剎車片”時,您就明白他在說什麼了。

如果這項工作取得成功,可能會有數百萬,最終達到數十億的計算機程式設計師,他們的熟練程度各不相同。這會對軟體開發技術的現狀產生什麼影響是難以想象的。軟體的性質將發生變化,以適應這些程式設計師的需求,允許透過原始碼修改進行定製,並且個性化將很豐富。

這項努力也可能對吸引婦女和少數族裔加入計算機程式設計領域產生重大影響——目前,這些群體的人數嚴重不足。

最近流行的開源運動 [OpenSource] 有望透過數千人的同行評審以及程式設計師“解決自身問題”(即,以只有個人關心的方式對軟體進行微調)的能力來提高關鍵軟體包的質量。我們預計,從數千名程式設計師增加到數百萬或數十億程式設計師將進一步改變軟體開發過程的性質。在這種規模下,個人程式設計將變得更加重要(和可行),而大規模同行評審的重要性將相對降低,因為收益遞減(整合來自數千個來源的錯誤修復的後勤工作已經是一項艱鉅的任務)。但是,大多數當前的軟體(無論是開源的還是其他的)都過於複雜,無法讓任何人在不首先投入大量精力和時間來理解他們正在使用的軟體的情況下進行個人定製。我們對整個軟體開發過程的改變也很感興趣,這將解決這個問題——特別是開發工具。

此外,透過讓任何人都能對應用程式進行程式設計,我們將在不犧牲使用者對高度個性化軟體的渴望的情況下利用規模經濟。應用程式可以批次生產,而無需強迫每個人在使用軟體時適應相同的模式(或適應開發人員計劃的那些可定製性的漩渦)。使用者想要個性化他們的系統有很多原因;其中包括提高生產力、解決他們需求特有的問題,或者只是表達他們的創造力並將自己與同齡人區分開來。如果他們具備我們設想的基本程式設計素養,他們將能夠實現這一點。

挑戰

一些廣泛的問題有助於構建我們特定的研究目標,例如:學校教授的程式語言會像我們今天所知的程式語言嗎?它甚至會被稱為程式語言嗎?我們將如何教授它?會只有一種語言嗎?教授和使用這種語言的其他基本工具是什麼?是否有可能擁有一種既適合教學又對專家有用的語言和工具?

同樣有趣的問題還有這些:人們將如何以及出於什麼目的使用他們的程式設計技能?普遍具備閱讀和編寫計算機程式的能力將如何改變計算機軟體的結構和實用性?(這與未來版本的網際網路結合在一起尤其有趣,這些網際網路承諾高速普及對計算和儲存元素的訪問。)一旦他們確信自己可以做到,人們是否會有動力實際程式設計他們的系統?他們一開始就會對此感興趣嗎?

一個明確的擔憂是,如果大多數人都是程式設計師,那麼他們中的許多人很可能都是水平不高的程式設計師。那些用母語都無法寫出易於理解的句子或平衡其支票簿的人不太可能編寫結構良好的計算機程式!然而,我們的意圖是讓每個人都可以訪問程式設計,即使它並不容易。一些使用者將僱用或與第三方程式設計和定製服務簽約。這很像房主外包裝修工作。

因此,我們需要研究如何提高程式設計師與系統之間互動的質量,以幫助即使水平不高的程式設計師也能最大限度地利用他們的計算機。例如,您可能想編寫一個程式來定製您的 PDA 或烤麵包機,但如果一個小錯誤可能擦除您的地址簿或點燃您的房子,您可能會感到沮喪。需要採取措施防止災難,以及從對整個系統的意外更改中恢復過來的方法。(“撤消”雖然非常強大,但通常一次只適用於一個檔案。從不必要的全域性系統更改中恢復通常需要重新啟動,甚至需要從備份介質中痛苦地恢復資料。)

另一個擔憂是關於配置管理。如果沒有出色的配置管理,企業會發現自己要麼無法糾正問題,要麼被那些以某種方式修改了作業系統或應用程式,從而無法升級或進行其他更改的程式設計師所挾持。一般來說,目前對大型軟體系統所做的所有本地更改都可能與未來主要產品的升級不相容。即使是本地開發的軟體,也可能在主要開發人員離職後因多種原因(包括缺乏測試或文件)而變得無法使用。

除了擔心可能會出錯之外,對有興趣自定義計算機的初學者程式設計師來說,另一個擔憂是試圖理解大型現有軟體的艱鉅任務。我們需要研究使用者友好的程式分析工具;稍後會詳細介紹。另一個智力挑戰是以幫助新手的方式視覺化(應用程式生成)資料。電子表格在這裡很有價值,但並非所有資料都適合矩陣形式。

指令碼語言在專業程式設計師中越來越受歡迎[Ousterhout],但關於效能、軟體重用以及與其他語言編寫的元件整合的問題仍然存在。我們可以透過增強 JPython [Hugunin1] 的功能來應對這些挑戰。JPython 是一種與 Java 無縫整合的 Python 方言,以及 SWIG,一種在指令碼語言和 C 或 C++ 等系統語言之間建立介面的介面生成器。

為什麼要教授“通用”程式語言?

眾所周知,“通用”程式語言和“領域特定”語言之間存在某種二分法。對於本文的討論,我們廣義地使用“通用”一詞,包括函數語言程式設計語言,甚至可能是邏輯程式語言,只要它們可以用作通用程式設計工具即可。圖靈完備性是這裡的關鍵概念。

領域特定類別則包含其他所有內容,從命令列引數語法到電子郵件標頭和 HTML。這裡的區分因素是存在相對狹窄的應用領域。在此類別中,我們還將諸如 Microsoft 的“嚮導”(實際上只是一系列由簡單流程圖連線的預定義對話方塊)以及微波爐或核反應堆上的控制元件和撥盤之類的東西放在一起。

領域特定語言的一個典型特性是,它們在預期的應用領域中提供了出色的控制,並且在未預料到的領域中(幾乎)沒有自由度。例如,HTML 沒有文字條件包含或變數擴充套件的固有能力。(事實上,這種特性已經被多次新增為不相容的擴充套件,這僅僅證明了這一點。)

另一方面,通用語言在任何特定領域通常都不是那麼好。例如,用通用語言編寫一個格式化文字段落的程式比用 HTML 要困難得多。但是,通用語言透過其圖靈完備性彌補了這一點,這使得解決可能出現的任何問題成為可能(假設有足夠的資源可用)。因此,通用語言在與領域特定語言結合使用時是理想的。

例如,如果手機是可程式設計的,人們仍然會使用常規的領域特定介面(鍵盤)來撥打特定的號碼,因為這是訪問該特定功能的最方便方式。但是,如果沒有可程式設計性,就無法使其嘗試某個特定朋友的幾個不同號碼,直到有人接聽為止,除非手機供應商預料到此特定功能。

為什麼要從 Python 開始?

我們建議從使教授 Python 程式設計成為可能開始,Python 是一種現有的指令碼語言,並專注於為其建立新的開發環境和教學材料。我們有軼事證據表明 Python 是一種適合作為第一門程式語言教授的好語言。我們的工作將專注於為此目的建立工具和教育材料,並圍繞這些材料培養一個社群。這將使我們能夠研究 Python 在哪些方面是適合(或不適合)教學的語言,並引發未來發展的方向。

為什麼要從現有語言開始?我們的經驗表明,一種新語言的設計和實現需要數年時間 - 而且這項工作必須(幾乎)在建立使用者友好的開發環境和教學材料之前完成。因此,我們透過使用現有語言來快速啟動我們的專案。根據使用者反饋,我們可能會在專案期間對 Python 進行更改或完全設計一種新語言。

我們已經有一些證據表明哪些地方可能需要更改。卡內基梅隆大學的 Randy Pausch 教授(見下文)在其有限的問題領域內對 Python 進行了一些可用性研究。他們的使用者似乎最困惑的是 Python 變數名的區分大小寫以及整數除法的截斷。更廣泛和更普遍的研究將有助於推動對 Python 的特定更改,或表明需要一種新設計的語言。

Python 是一種適合教絕對初學者的好語言。它從 ABC 中衍生出許多關鍵特性,ABC 是一種專門為向非專業人士教授程式設計而設計的語言[ABC] [Geurts]。Python 社群已經收到許多個人報告,他們使用 Python 教他們的孩子程式設計。這些報告的共識是,該語言本身非常適合此目的 - 與 C++、Java、Perl、Tcl 或 Visual Basic 等不同,後者充斥著太多特質。

下一頁的表 1 是一個(高度主觀的)圖表,比較了 Python 與其他一些語言的一些相關方面。從該表(和我們的經驗)中,我們得出結論,Python 是教學的良好首選,它也可以很好地用作更嚴肅的應用程式開發的語言。與為初學者提出的其他教學語言(例如 Logo、LogoMation,甚至 Python 的祖先 ABC)不同,Python 不僅僅是一種教學語言。它適用於開發大型實際應用程式,正如 CNRI [Knowbots] [Mailman] 以及其他地方的專案所證明的那樣。例如,工業光魔已將其整個工具庫轉換為 Python,並認為這是一個優於競爭對手的優勢。

此外,Python 可以透過用其他語言(例如 C、C++ 或 Java)編寫的模組進行擴充套件,以調解對 Python 無法直接訪問的高階功能的訪問(例如,高速 3-D 計算機圖形包)。雖然我們不希望學生編寫這些擴充套件模組,但這些模組的使用可以極大地豐富他們的學習體驗。這種可擴充套件性使教師有機會透過為學生提供對其他軟體包的有控制的訪問,來根據學生的興趣定製課程。

Python 可用於開發大型應用程式這一事實也符合我們願景的另一個方面,即開發可以由非專業程式設計師但已掌握一些程式設計技能的使用者定製的開源應用程式軟體。儘管這不是我們這裡工作的重點,但我們希望看到至少一些朝著這個目標邁進的舉措,並且我們將鼓勵希望朝著這個方向邁進的公司和組織。我們預計 JPython 的存在將成為這裡的重要推動因素。

Python 的程式設計環境和文件對於向新手教學來說不夠理想。特別是,現有的 Python 程式開發工具和教程(每個都有幾種)都假設使用者是鐵桿開發人員,他們知道一整套用於編輯、執行和除錯程式的外部工具,並且已經瞭解一種或多種其他程式語言及其開發環境。這目前阻礙了 Python 作為第一門程式語言的更廣泛的實驗。

表 1. 語言比較圖

(已撤回)

方法

我們將建立一個下一代程式設計環境和教學材料,使普通使用者能夠編寫簡單的程式,並理解更大程式的結構和組織。我們還將探討普及程式設計素養將如何影響普遍計算環境中軟體的生產和使用。

我們的工作分為三個不同的領域:

  • 適合高中和大學生的新計算課程。
  • 更好、更易於使用的程式開發和分析工具。
  • 圍繞上述內容形成的使用者社群,鼓勵反饋和自助。
如前所述,我們最初將使用 Python 程式語言。這將為下一步做好準備。“下一代計算環境”可能不會使用 Python,但 Python 和 CP4E 是朝著正確方向邁出的有益的實驗步驟。

一旦將新開發的課程和工具的初始版本釋出給社群,反饋渠道將開啟。最初的反饋將主要用於改進環境和教學材料。這就是社群建設開始的地方。

課程開發

CP4E 工作的一項關鍵目標是開發一個課程,向從非計算機科學專業的本科生到中學生,最終到小學和初中學生教授程式設計素養。每個年級的學習方法可能會有所不同,以便更好地與學生成熟時的情況聯絡起來並接觸到學生,但 CP4E 努力提供一種統一的方法,該方法將隨著學生的成長而發展,一路呈現更豐富和更深入的主題材料。最初的工作將主要集中在高中生和本科生身上。

CNRI 將開發課程的基本材料,包括將在教學環境中使用的軟體,以及可以作為程式設計教科書基礎的教程和入門材料。CNRI 將與在編寫教科書和其他教學材料方面經驗豐富的教育工作者緊密合作,以便最好地為目標年齡段定製這些工具。

我們的目標是採用更有經驗的程式設計師使用的軟體環境和工具,並生成這些工具的版本,這些版本在教授程式設計技能方面將很有用。我們受到了現有 Python 互動式直譯器和 IDLE(Python 的圖形開發環境)的啟發,這兩者既可以作為專業程式設計師的生產力工具使用,也可以在與教程材料結合使用時作為教學輔助工具使用。我們的新工具將為新手和經驗豐富的程式設計師提供有用的功能。

新計算課程

CNRI 建議與芝加哥大學合作開發一門新的計算機科學課程,使用 Python 作為所有級別程式設計教學的程式語言。Python 是一種特別適合此目的的語言,因為它易於學習、閱讀和使用,但功能強大,足以說明程式語言和軟體工程的基本方面。因此,即使是年輕的學生也可以使用 Python 學習程式設計的基礎知識,但他們不會像使用 Logo 那樣在應用領域受到限制。使用 Python 可以讓每個學生按照自己的進度進行探索和進步。尤其令人興奮的是,如果有天賦的學生受到激勵想要學習更多或更快地學習,他們將可以輕鬆獲得強大的程式語言和環境。

芝加哥大學將為非計算機科學專業的本科生和高中生開發一系列介紹程式設計和計算機概念的課程。目前,這一級別的課程往往側重於程式語言(具有濃厚的數學味道)或諸如 HTML 和 JavaScript 等 Web 程式設計主題。不幸的是,這兩種方法都有嚴重的侷限性。如果課程過於正式和數學化,它可能只會吸引計算機科學專業的學生和具有技術思維的學生。另一方面,Web 程式設計課程雖然極大地利用了網際網路的普及,但往往狹隘地關注 HTML、Perl 或 JavaScript 等特定技術。因此,學生對計算機在更大範圍內的應用知之甚少,也無法獲得解決未來計算問題所需的解決問題的技能。

在芝加哥大學開發的課程將涵蓋我們認為每個人都必須瞭解的計算機知識,以便成為一名知識淵博的計算機使用者。

  • 基本計算機組織結構。學生將學習計算機如何工作以及如何組裝的基本知識。主題將包括布林代數、邏輯和簡單的計算機架構(例如 CPU、記憶體、I/O)。簡而言之,這就是“幕後”發生的事情——以容易理解的方式陳述。最終,我們希望儘可能地揭開計算機的神秘面紗。
  • 程式設計入門。這將介紹人們使用計算機進行程式設計的不同方式。學生將以非正式的方式瞭解程序式程式設計、函數語言程式設計和麵向物件程式設計。目標不是將學生培養成專業程式設計師,而是向學生介紹人們如何嘗試簡化計算機的使用。
  • 軟體架構。未來,計算機越來越有可能主要透過組裝現有軟體元件並編寫少量膠水程式碼進行程式設計。為了實現這一點,瞭解軟體是如何組裝的至關重要。學生將學習軟體設計和軟體組織(到底那些 DLL 是什麼?)。
  • 除錯和問題解決。如何在所有方法都失敗時生存下來——而無需致電客戶支援。
在所有教育階段,對軟體工具和教材進行可用性研究並進行評估至關重要。這是改進此類材料和工具並使其適合特定年齡和經驗群體的唯一方法。由卡內基梅隆大學的 Pausch 教授進行的可用性研究將在所有三個教學級別進行開發和實施。當然,我們還將開發傳統的測試來衡量每個學生的表現。

3D 遊戲

我們打算自己進行小規模的教學工作,例如在合作部分列出的當地高中,但我們不期望會做太多的教學工作。如果我們對 Python 的普及程度的經驗可以作為參考,我們將不必這樣做:其他人也渴望參與這個實驗。

這些課程將使用下一節中描述的新開發環境。為了激勵程式設計更有“樂趣”,我們打算將開發環境連線到流行的計算機遊戲中使用的現有可程式設計 3D 遊戲引擎。有幾個這樣的引擎已經或很可能可以與 Python 一起使用;我們將選擇一個併為我們的受眾建立一個合適的介面庫。

為什麼要使用 3D 遊戲引擎?Logo 的經驗表明,圖形是吸引年輕觀眾注意力的好方法,但與現在青少年熟悉的電子遊戲相比,它的 2D 圖形看起來有些枯燥。Alice 是一個很好的引人入勝的 3D 圖形環境的例子。

Knowbot 程式

除了使用 3D 遊戲作為測試平臺外,我們還可以使用 CNRI 的 Knowbot 技術 [Knowbots] 作為新手程式設計師的激勵性應用。Knowbot 程式是獨立的移動程式,能夠在整個網際網路的 Knowbot“服務站”(特殊配備的主機)之間遷移。服務站向 Knowbot 程式提供服務,例如搜尋服務、數字物件儲存庫、拍賣服務等。

看待 Knowbot 程式的另一種方式是將其視為在服務站的更大框架內工作的小元件。Knowbot 程式是一個模組化的獨立程式,可以很容易地編寫成在網際網路上移動,但由於其整合到框架中以及對它遇到的環境的利用,它具有強大的功能。

我們將探索如何在教學課程中使用 Knowbot 程式的幾種想法。我們設想協作遊戲場景,學生可以在其中建立表現出某些行為的 Knowbot 程式,並且必須協同工作才能解決一個共同的問題。這將是激勵來自網際網路各地的學生進行協作的好方法。

我們可能會設想尋寶遊戲,學生必須應用他們剛剛學到的程式設計技能才能發現並遷移到服務站,解決該站點上的難題並獲得寶藏。我們可能會設計分散式虛擬模擬,類似於麻省理工學院的虛擬魚缸 [Fishtank],學生可以在其中建立複雜系統的離散元素(例如,在 Knowbot 程式中實現虛擬魚),並觀察自己的元素如何與他人互動。由於 Knowbot 技術允許在整個網際網路上進行高度分散式、非常複雜的互動,因此它為我們提供了一個獨特的平臺來嘗試豐富的協作學習機會。

程式設計工具

我們將設計和構建一個專門用於支援向沒有程式設計經驗的使用者教授程式設計的程式設計環境。我們的目標是為使用者在學習程式設計以及在家和辦公室中使用這些技能時提供支援工具。

我們相信,大多數普通使用者將利用他們的程式設計技能來定製和擴充套件他們的計算環境。大多數人不會從頭開始編寫新程式,而是會向現有程式新增新程式碼。面向此受眾的程式設計工具必須解決三個重大挑戰。

首先,該環境必須顯著減輕編寫、安裝和除錯新程式的負擔。當前一代的開發工具對於專家使用者來說可能很麻煩,更不用說新手了。我們必須將精心的設計和可用性研究集中在新程式設計環境的開發上。

第二個挑戰是為消費者和生產者提供軟體工件的持續演變和修改。我們將開發工具來幫助使用者理解大型程式的結構,以便他們可以確定在哪裡進行更改以及這些更改將產生什麼影響。我們的工具還將幫助使用者管理和配置軟體,以便可以隨著時間的推移替換或升級單個元件。這些工具將透過自動跟蹤版本和依賴關係來幫助使用者共享新的和修改的程式。

最終的挑戰是構建在無處不在的計算環境中將有用的工具。桌面計算環境將很快被計算機控制的裝置和物理系統的網路所取代。這種新環境加劇了安裝、除錯和管理軟體的問題。它還為系統設計人員提出了構建允許終端使用者自定義的軟體的新挑戰。

本節圍繞這三個挑戰組織。第一部分討論擬議的程式設計環境。第二部分討論程式分析和配置管理工具。第三部分討論用於支援無處不在的計算環境的終端使用者可程式設計性的應用程式框架。

我們解決這個問題的方法是研究如何透過更高階的分析、檢查和理解程式的方法來增強和改進傳統的程式設計工具,例如編輯器、偵錯程式和類瀏覽器。

程式設計環境

程式設計師最基本的活動是編輯原始碼、執行程式進行測試以及除錯程式。(Python 沒有單獨的編譯階段。)程式設計環境當然必須支援這些活動。我們一直在為 Python 開發一個名為 IDLE 的可移植程式設計環境,它允許使用者互動式地執行單個語句。它主要面向有經驗的程式設計師,但將作為絕對初學者環境的起點。

IDLE 只是觸及了幫助新手程式設計師所需的程式設計環境的表面。例如,它的原始碼著色和縮排功能可以被更強大的程式檢查器所取代,該檢查器會在使用者鍵入時指出所有語法錯誤、未定義的識別符號、型別不匹配等等(如拼寫檢查器)。偵錯程式可以支援回溯執行步驟、編輯正在執行的程式的原始碼等。程式編輯器可以支援靈活的基於模板的編輯形式(Alice 小組在其有限的領域中擁有非常好的經驗)。撤消功能(目前只允許撤消原始碼更改)可以擴充套件到撤消對程式的執行時狀態甚至對環境的副作用的更改(在合理的範圍內——我們不能指望撤消列印或傳送電子郵件訊息)。例如,Alice 軟體為所有涉及更改其管理的 3D 世界的操作提供了完全撤消功能。

兩個具體的工作領域是撤消和擴充套件的型別檢查器。

“撤消”對於初學者來說是一個極其重要的工具,因為它是程式設計師的第一道防線。除了版本控制、自動儲存和其他功能外,回滾無限數量的近期更改的能力意味著程式設計師有更多的自由進行實驗和學習。然而,大多數撤消實現的功能範圍都非常有限。我們的方法將研究諸如選擇性撤消和全域性撤消之類的概念。在傳統的撤消系統中,編輯器只是保留檔案更改的連結列表,並且可以透過在此列表中移動來取消應用或重新應用這些更改(此主題有多種變體,包括撤消環和撤消/重做)。傳統撤消的問題之一是,某些不良更改與某些可取更改重疊;程式設計師通常必須丟失可取更改才能消除不良更改。

透過選擇性撤消,可以將更改區域性化到更精細的粒度。例如,假設程式設計師對檔案頂部的函式 A 進行了三個更改,並且對檔案底部的函式 Z 進行了四個更改。現在,程式設計師發現函式 A 應該永遠不會更改;選擇性撤消允許回滾對函式 A 的更改,而不影響對函式 Z 的更改。

全域性撤消類似於版本控制提供的功能,其中可以在系統受到不利影響時標記和回滾系統級別的更改。但是,全域性撤消的不同之處在於不必預先決定標記。

我們還計劃使用型別檢查工具增強開發環境,這些工具可以幫助程式設計師發現程式碼中的錯誤並提高編譯程式碼的效能。Python 是一種動態型別語言,如 Smalltalk 或 Scheme,它依賴於廣泛的執行時檢查來確保正確使用內建操作。軟型別 [Cartwright] 是一種靜態檢查動態型別語言中的程式以檢測錯誤並消除不必要的執行時檢查的機制;該分析與程式設計環境整合,而不是與語言執行時整合。此機制已應用於 Scheme [Wright][Flanagan]。我們將為 Python 開發類似的型別檢查機制。為 Python 開發軟型別系統的關鍵挑戰是將分析擴充套件到物件和模組,並適應 Python 極其動態的執行環境,該環境允許在執行時修改類和例項。

CNRI 的初步工作證明了型別分析對於提高 JPython 程式效能的價值。Hugunin [Hugunin2] 證明了 JPython 的效能提高了三個數量級。

程式分析和配置管理

我們將透過一系列工具來增強基本程式設計環境,這些工具可以幫助使用者理解大型程式,以便他們能夠自定義和修改程式;以及管理軟體的安裝和配置,以便他們能夠在不破壞修改的情況下升級軟體。我們還將開發和擴充套件工具,以構建底層軟體元件和指令碼語言之間的介面,這將使使用者能夠更好地控制底層元件。

重要的是,這些面向初學者的程式分析工具要易於使用,並且能夠在需要詳細瞭解分析如何進行的情況下理解分析結果。同時,我們努力使我們的工具對專家來說也足夠強大——它們應該能夠隨著使用者對工具的熟悉程度提高而適應更高的專家水平,並且應該能夠處理大型程式。一個可以有效地應用於,例如,Netscape 瀏覽器原始碼的分析工具,比一個只能在小型示例程式上執行良好的工具更有用。

我們專注於相對缺乏經驗的程式設計師,這要求我們的工具包含出色的視覺化模組,這些模組可以向用戶展示已發現的設計,而不會導致資訊過載。例如,當前的視覺化工具通常缺乏“常識”,並且會盲目地生成由無數重複的相似子結構組成的大型樹狀或圖形圖,這些圖跨越許多頁面;這種效果會導致使用者只見樹木,不見森林。

我們計劃最初專注於使用 Python 程式的工具。但是,我們期望開發的大多數程式分析技術本質上與所使用的語言無關。我們還將研究跨越語言邊界的工具的使用,以便使用者可以考慮指令碼級別的更改對用 C 或 Java 編寫的底層元件的影響。

程式分析工具將透過識別靜態程式元件之間的關係來幫助使用者理解程式的總體結構。這種分析工具的一個例子是 Womble,它從 Java 位元組碼中提取物件模型 [Jackson]。Womble 直接從原始碼(或目的碼)而不是從正式規範中提取物件模型。因為這種方法不依賴於正式規範(例如 UML 模型)的存在,所以我們相信它更容易被普通使用者接受。類似的方法可以用於分析 Python 程式,儘管 Python 的動態型別和“一等”函式和類帶來了重大挑戰。

我們還將研究程式切片 [Tip] 和程式路徑 [Ball] 作為幫助使用者瞭解在哪裡進行更改以及這些更改將產生什麼影響的技術。切片是一種眾所周知的技術,用於識別影響特定變數的程式子集。透過程式路徑進行的分析顯示了程式碼主體中各種可能的執行路徑。每種技術都對測試和除錯程式有價值。兩個挑戰是將這些技術應用於跨語言邊界,以及識別程式碼中隱含的但型別系統不精確表達的抽象邊界。例如,Womble 認識到 Java 容器類不是應用程式物件模型的有趣部分;它僅表示使用容器的物件和包含的物件之間的關係。類似地,可以針對某些抽象邊界和程式碼的各個方面執行程式切片。一個在不包括併發特定程式碼的情況下呈現程式功能方面的程式切片,可能有助於理解程式結構。(當然,併發特定程式碼對於理解也很重要,但可能是一個單獨的問題。)

第三個工作領域是自動生成低階程式碼(如 C、C++ 或 Java)的指令碼語言介面。由我們的合作者 David Beazley 開發的 SWIG 工具 [SWIG](請參閱下文的“協作計劃”部分)幫助使用者從 C 和 C++ 生成指令碼語言繫結。我們將努力改進和擴充套件 SWIG,以提高可以完成的自動處理量,並允許使用者對繫結進行更大的自定義。我們還將增強 SWIG 以生成更自然的語言繫結;例如,當字串作為 C 程式中的函式引數傳遞時,它們通常由兩個變量表示:一個指標和一個長度。SWIG 繫結應該自動在這兩個 C 變數和一個 Python 字串引數之間進行轉換。

如果使用者有權修改和自定義程式碼,那麼當底層軟體升級或系統元件被替換時,他們將面臨維護這些更改的挑戰。對於軟體開發人員來說,版本控制已經是一個令人頭疼的問題,他們必須確保他們的產品與許多作業系統和共享庫相容。使用者也希望與他人(同事或親朋好友)分享他們的自定義設定。我們將提供工具來幫助使用者維護和共享程式以及對程式的修改。

我們的程式設計工具研究將解決的最重要的問題之一是使用者可自定義性給系統配置管理帶來的負擔。當用戶更改應用程式時,如何保證供應商對應用程式的未來更新與這些更改相容?使用者自己如何跟蹤他們對應用程式所做的更改?當產品的未來版本添加了一個以前缺失的、使用者已經新增的功能(以不同的形式)時會發生什麼?

我們的工具將透過連續的修訂來幫助使用者跟蹤他們所做的更改,並幫助使用者在主應用程式本身被供應商修改或更新時合併他們的更改。這種方法的關鍵是識別每個軟體版本,以及一種用於描述其屬性和依賴關係的簡單語言。例如,我們打算改進版本控制系統,以便它們跟蹤不同抽象級別和粒度的更改,例如根據它們實現的功能而不是它們修改的原始檔(或檔案的一部分)來標記更改。該工具將自動識別對其他庫和元件的依賴關係。我們將研究將測試框架整合到配置管理系統中的方法,以便在主應用程序升級時,使用者安裝的每個功能更改都將被合併和測試。

我們還將建立社群增強工具,以便更輕鬆地共享、整合和使用同行開發的軟體。需要解決的問題包括軟體包之間的依賴關係管理、易於安裝(和解除安裝!)、應對作業系統、應用程式和庫的更改、版本控制和軟體包維護。必須描述和分類軟體,並且必須建立用於討論、反饋、錯誤報告和補丁的論壇(無論是給維護者還是來自維護者)。最重要的是,這些社群建設工具必須主要由社群本身管理;它們必須高度分散式、複製和安全。例如,使用者可以共享有關各種庫之間相容性問題的資訊;當與自動分發工具結合使用時,此資訊可以防止導致其他應用程式無法正常工作的軟體升級。

有幾種現有工具試圖解決其中一些或所有問題。綜合 Perl 存檔網路試圖包含 Perl 程式設計師可能需要的所有 Perl 材料 [CPAN]。它是分散式的和複製的,並且使安裝 Perl 模組的工作更容易(儘管並非總是足夠容易)。但是,它不太適合其他型別的存檔材料。在 Python 社群中,distribution-utilities 特別興趣小組正在嘗試使第三方軟體的分發和安裝更容易,但是它沒有解決所涉及的更廣泛的問題,而且,它仍然只專注於 Python 軟體 [Distutils]。我們所熟悉的最雄心勃勃的相關工作是自我更新軟體 [Liskov] 專案。

應用框架

我們將研究未來計算和通訊方面的變化對使用者控制計算機的方式的影響,以及諸如近乎無限的頻寬、更易於訪問功能更強大的計算機、無處不在的計算資源以及更高水平的網際網路連線(即使在微型裝置級別)等發展的影響。這些變化會影響使用者將編寫的程式型別以及這些程式將執行的計算機型別。

我們在這個領域的方法是使用實驗性和原型系統來了解終端使用者的可程式設計性應該如何暴露。隨著這些技術的成熟,我們可能會將我們的經驗融入到教學材料中。

許多非程式設計師開始編寫在特定領域和應用程式框架上下文中使用的的小程式。電子表格可能是有限環境中程式設計的最佳示例。它提供了一種專門針對運算元字資料表的有限語言。該應用程式提供了協調框架——管理顯示、控制流、I/O 等——並讓使用者專注於特定問題。宏工具是電子表格程式設計套件的一部分,它有助於許多應用程式的使用,允許使用者自動化重複性任務。第二個例子可以在 MS Word 宏中找到,它也是使用者自定義的常見形式。

網際網路已經讓許多非專業人士接觸到程式設計,尤其是在特定領域的語言(如 HTML)和動態內容語言(如 JavaScript、PHP 和 CGI)中。在這些情況下,非程式設計師通常也會建立適合較大上下文的小型程式,例如,Web 伺服器負責管理與客戶端的 TCP/IP 連線、設定使用者程式執行的環境、處理錯誤情況以及遵守標準協議等細節。

未來,非程式設計師將使用大量的資訊裝置。這些裝置的可程式設計性將大大提高其用處的一個示例領域是在資訊流管理中——也許更重要的是,限制資訊流。一個人可能會收到來自多種媒體(文字、語音、影片)的訊息,並透過 PDA、手機和計算機螢幕等多種裝置訪問它們。我們期望無縫的互操作性,因此例如,可以使用手機跟進電子郵件,透過語音回覆而無需查詢號碼。小型程式可用於自定義這些裝置上的介面,並過濾和限制透過它們的訊息流。

一些示例包括

  • 嘗試幾個不同的電話號碼來聯絡某人,可能取決於一天中的時間或一週中的一天。
  • 當您不想被打擾時,將呼入電話轉接到語音郵件或電子郵件,但仍然讓重要電話透過。
  • 接聽電話時降低電視或收音機的音量。
  • 記錄某些電話的副本,可能透過呼叫語音到文字轉換器。
  • 限制作為電子商務交易的一部分傳輸到商店或公司的個人資訊量。
這些介面特性中的每一個都可能被特定裝置的設計者所考慮。然而,功能豐富的介面更難使用,因此設計者可能會有意限制介面。此外,有創造力的使用者總是會想到設計者忽略的功能。允許終端使用者進行程式設計和定製,可以讓使用者根據自己的特定需求調整裝置。

這些例子表明了程式設計範圍中一個重要的模式:使用者將在系統的計算模型和軟體框架的上下文中定製應用程式和裝置。因此,我們的探索將著重於如何模組化應用程式,並組織這些模組,以便使用者可以新增他們想要的小功能,而不必關心整個系統的執行。

在應用程式框架或嵌入式裝置的上下文中,授權非程式設計師修改和定製軟體的關鍵目標之一是減少理解修改如何融入更大程式所需的認知負荷。即使對於剛接觸應用程式程式碼庫的經驗豐富的程式設計師來說也是如此。應用程式必須是模組化的,並提供足夠的高階抽象,以便可以快速且獨立地理解它們的組成部分。這可以讓人們主要關注需要更改的部分。在我們的方法中,我們將探索一些旨在提高軟體模組化的想法。

我們打算研究現有的技術,例如面向物件程式設計和元件組合,作為組織軟體的方法。理論上,只要介面和輸入/輸出語義保持不變,交換一個黑盒元件以實現不同的功能會容易得多。但在現實中,編寫獨立於系統其餘部分的類和元件目前非常困難。我們還將探索新的概念,例如面向方面程式設計 [AOP],這是一種基於橫切關注點來模組化軟體的新方法。也許這些技術的某種組合,或新的模組化技術將會證明是有效的,例如,將每個函式組織為元件的一個方面。

社群建設

除了與選定的合作伙伴合作外,我們還將尋求廣大社群的參與。我們將透過網站分享開發的課程和軟體的原型,並透過新聞組和郵件列表等多種渠道徵求對這些材料的反饋。CNRI 在透過網路和其他方式進行社群參與方面擁有豐富的經驗。例如,Python 社群的關鍵焦點是 Python 網站 [Python],該網站還託管許多與 Python 相關的郵件列表;數字圖書館社群的一個重要焦點是 D-Lib 網站 [D-Lib]。這兩個網站都由 CNRI 運營。現有的 Python 社群已經對 CP4E 提案表現出濃厚的興趣,我們預計這將是啟動 CP4E 專案社群活動的理想場所。

這種明確的社群參與機制將極大地有利於我們的研究,並讓社群從我們的研究中獲得最大的收益。早期和大規模的社群參與對我們研究的好處將包括:志願者幫助“試駕”我們的課程和軟體原型;社群成員為特定目標受眾或教授特定技能或主題而開發的新課程;現有課程的本地化版本、翻譯等;新的或修改的示例(您永遠不會嫌示例太多,而且為特定受眾量身定製的示例更有效);由我們課程的學生使用我們的程式開發軟體開發的新應用程式;等等。在 Python 社群中,我們收到了許多此類貢獻(包括關鍵文件的完整外語翻譯),完全是不請自來的!

社群的好處包括提前訪問新課程和軟體,以及幫助教師進行教學並說服他們的管理層讓所有學生(而不是那些成績優秀的學生)學習計算機程式設計的重要性。我們還期望擬議的社群設施將在社群成員中培養大量的自給自足能力。例如,在合作輔導專案中,需要輔導的學生將在網上找到志願者輔導員(通常是更高階的其他學生),教師將能夠直接交流他們的經驗。這種輔導活動已經在 Python 社群中發生,並將有助於減輕我們的研究團隊因反覆回答簡單問題而造成的負擔。

本著“大眾計算機素養”和開源運動 [OpenSource] 的精神,我們的網站將廣泛且免費地提供課程和軟體。除了網站之外,我們還將建立和維護一個或多個帶有存檔的郵件列表,以及可能為使用者提供的“聊天”服務。我們將積極參與郵件列表,以培養社群,並收集和分析社群透過這些(和其他)渠道向我們提供的反饋。

很明顯,我們認為社群參與對於該專案的成功至關重要。因此,我們希望超越典型的網站設定。我們計劃為教師、學生和程式設計師建立一個自動存檔站點,該站點可用於交換課程筆記、示例、有用的軟體等。我們還計劃開發原型軟體,以幫助使用者維護本地開發和下載的軟體程式包在多臺計算機上的一致集合。預期的擴充套件、升級、補丁、終端使用者修改等的頻繁交換,將導致使用現有實踐的版本控制問題成為一場噩夢。這在上面的“共享和維護”小節中有所闡述。

合作計劃

我們將在專案中加入一定程度的計劃合作,與其他學術和非學術機構合作,以確保研究的成功。特別是,我們建議將一些活動分包給卡內基梅隆大學和芝加哥大學的團隊。卡內基梅隆大學的 Alice 團隊已成功將 Python 作為其流行的虛擬現實軟體的終端使用者程式語言;芝加哥大學在計算機科學課程開發方面擁有豐富的經驗和興趣。我們還計劃與其他人進行非正式的合作,並在可行的情況下向其他人開放參與。

卡內基梅隆大學

Alice 團隊 [Alice] [Pausch] 在 Randy Pausch 教授的領導下,為 Windows 開發價格合理的 3D 圖形和虛擬現實軟體,最初在弗吉尼亞大學,現在在卡內基梅隆大學。他們將 Python 用於終端使用者程式設計以及其系統的大部分實現(除了渲染引擎之外幾乎所有部分)。他們可能擁有最廣泛和記錄最完善的案例研究,即將 Python 程式設計(儘管是在有限的領域內)教授給沒有程式設計經驗的使用者,並且他們對 Python 的熱情極大地鼓勵我們考慮在通用程式設計課程中使用 Python。他們也是唯一將可用性測試應用於程式語言和應用程式程式設計介面的團隊之一。

我們計劃為 Alice 團隊提供有限的資金,以互利的方式繼續這部分研究。我們期望從他們教授 Python 給新手使用者的經驗、他們構建到 Alice 系統中的簡單但有效的程式設計工具以及他們在使用者測試方面的熟練程度中獲益——這對於我們計劃開發的教程和軟體都非常重要。他們將從我們的教程(為 Alice 使用者提供更廣泛的軟體開發指導)以及我們的軟體(更強大的程式構建工具)中獲益。

芝加哥大學

芝加哥大學可以在兩個核心領域為 CP4E 研究工作做出貢獻:課程開發和軟體開發工具。我們還計劃與芝加哥大學實驗室學校合作,這是一所由芝加哥大學運營的私立 K-12 學校。我們在芝加哥大學的聯絡人是經驗豐富的 Python 使用者 David Beazley 教授。我們計劃為芝加哥大學提供有限的課程開發資金。這將對我們有利,因為他們對教學有興趣和經驗;他們的好處是使用一種更優秀的程式語言和工具。

當地學校

最後,我們計劃直接與選定的當地學校合作“試駕”開發的材料。與當地學校合作可以定期與教師和學生進行面對面的會議;我們認為這對於評估我們的原型課程和軟體至關重要。弗吉尼亞州阿靈頓縣的約克鎮高中已經對該提案表示出興趣 [Yorktown]。

另一個可能的候選學校是托馬斯傑斐遜科技高中,這是一所弗吉尼亞州費爾法克斯縣的公立磁鐵學校,該學校已經為優秀學生提供計算機科學課程 [TJHSST]。在本專案的過程中,我們將聯絡馬里蘭州、弗吉尼亞州和哥倫比亞特區的其他當地學校進行合作。

其他研究小組

我們還計劃與正在為未來開發個人計算硬體和軟體(“普適計算”專案)的學術和其他研究小組進行非正式合作;這些專案都設想了某種形式的終端使用者可程式設計性。此類專案的一些示例包括麻省理工學院的 Project Oxygen [Dertouzos]、Xerox PARC 和華盛頓大學的 Portolano/Workscape [Portolano] 以及卡內基梅隆大學的 Invisible Computing。

我們期望這種合作的主要好處是我們的技術能夠在先進系統中儘早部署,而他們的好處是他們正在開發的系統可以改進終端使用者可程式設計性。請注意,這裡的時間安排非常好:例如,在 Project Oxygen 中設想的個人嵌入式系統的廣泛部署預計將在我們的課程和軟體可以廣泛使用的大致同一時間左右。

與其他研究的比較

ABC。Python 的前身 ABC 是在 80 年代早期被設計為一種教學語言。它的座右銘是“消滅 Basic”——這承認了當時非專業人士使用的主要語言競爭對手。ABC 的設計者在向新手教授 “經典” 程式語言(如 ALGOL)方面擁有豐富的經驗。他們發現,學生經常被計算機語言的偶然細節(例如執行編譯器、處理不同的數字格式、神秘的 I/O 操作和底層記憶體管理)所淹沒,以至於他們從未能夠專注於良好的程式和演算法設計的基本要素。

為了克服這種影響,ABC 的設計者回到了第一性原理。他們著手設計一種語言和該語言的環境,以便處理所有這些偶然細節,從而讓學生有更多的時間學習程式設計的基本要素,而無需考慮手頭的程式語言,例如清晰的控制流程和強大的資料結構,並專注於程式的優雅表達。他們提出了新的語言設計和新術語,這些術語與計算機科學家和程式設計師之間當時(以及現在仍然是)流行的做法截然不同。事實上,ABC 沒有像預期那樣產生重大影響的最大原因可能在於,他們偏離了當前的實踐太多。那些可以訪問執行 ABC 所需硬體的人(最初它只在 Unix 系統上執行,儘管後來被移植到 Mac 和 PC)通常是有經驗的計算機使用者,他們感到沮喪,因為 ABC 沒有像其他應用程式一樣“使用相同的語言”。

大約十年後,Python 在這種挫敗感中誕生。它與 ABC 一樣,專注於表達的優雅性、程式設計基礎知識和消除偶然因素,但增加了面向物件、可擴充套件性以及一個強大的模組庫,該模組庫透過多種不同的機制(共享檔案、程式嵌入、CORBA 或 COM 等 RPC 介面以及網路協議(支援 Internet 上常用的所有協議))與其它應用程式進行介面。

Logo。實際上是與 Lisp 相關的一系列語言,主要在麻省理工學院開發,Logo 當然是最著名的兒童程式語言。它擁有豐富的傳統、在學校的強大根基以及許多商業產品。麻省理工學院媒體實驗室的認知論和學習小組正在進行持續的研究,例如“可程式設計磚塊”(與樂高合作)。

Logo 和我們的提議之間的關鍵區別在於,我們認為數百萬(業餘)程式設計師將一起開發開源軟體——Logo 似乎滿足於向年幼的兒童教授有限的程式設計技能,對於他們來說,計算機程式設計主要是訓練他們進行抽象思維的一種方式。Logo 在現實世界的軟體開發中的適用性也有限。

LogoMation。一家名為 Magic Square 的公司銷售 LogoMation,一種與 Logo 相似的語言,同樣強調海龜繪圖。它附帶一份非常適合 8 歲及以上兒童的優秀教程。LogoMation 的語法與 Python 相似(比 Logo 的語法更相似);這表明我們使用 Python 是走對了路。

但是,像 Logo 一樣,LogoMation 在其提供的成長路徑方面是有限的。它沒有直接解決“下一步做什麼”的問題,而是期望其使用者轉到其他程式語言進行實際工作。

Alice。Alice 網站上的評價清楚地表明,Alice 在向兒童以及沒有計算機經驗的成年人教授程式設計方面取得了成功。它還表明了“有趣”環境的重要性(並且 Alice 的 3D 圖形比 Logo 的海龜圖形更具吸引力)。Alice 還為我們提供了一些關於如何改進 Python 的提示:例如,他們的經驗表明,Python 的大小寫敏感性是一個問題。

但是,Alice 專案的重點是 3D 圖形——Alice 教程實際上並沒有教授太多的程式或資料結構技術。雖然我們同意 3D 圖形是吸引和保持年輕觀眾的絕佳方式,但我們更感興趣的是教授一般的程式設計,而不僅僅是圖形。因此,我們初期工作的重點將是開發一個程式設計環境和教程,其中 3D 圖形只是計算機的可能用途之一。

DrScheme。萊斯大學的 TeachScheme! 專案 [TeachScheme] 旨在開發一種基於 Scheme 程式語言的新的入門計算課程。萊斯大學工作的一個核心部分是開發 DrScheme [Findler],這是一種針對初學者的程式設計環境。TeachScheme 的重點是相對狹窄的受眾——那些具有紮實高中代數基礎並有興趣學習計算及其在科學問題中的應用的大學生。我們設想一個更廣泛的受眾,他們不具備強大的數學背景和對科學問題的興趣。我們還認為,對於大眾受眾來說,Scheme 這種擅長為教學目的揭示計算基本構建模組的語言是不合適的。

然而,值得注意的是,TeachScheme 專案的關鍵部分之一是開發環境。雖然受眾和方法不同,但我們的專案和 TeachScheme 都認為開發環境是一個至關重要的組成部分。需要一個互動式的讀取-求值-列印迴圈、一個強大的偵錯程式以及理解程式如何工作的工具。

設施

我們將使用 CNRI 現有的計算基礎設施來開發和分發擬議的材料,並輔以專門為該專案購買的桌面工作站和 Web 伺服器。我們將使用 Internet 和全球資訊網來分發所有材料。

主要人員名單

Guido van Rossum 將在 CNRI 領導這項工作。他是 CNRI 的小組負責人,也是 Python 的建立者,他仍然是 Python 的主要開發者。他還是 Knowbot 移動代理系統的首席設計師。過去,他曾從事 ABC(一種為教學目的而開發的程式語言)和 Amoeba(一種在 80 年代開發的著名的分散式作業系統)的工作。他擁有阿姆斯特丹大學的數學和計算機科學碩士學位。

Jeremy Hylton 是 CNRI 技術人員的高階成員。他是 Knowbot 移動代理系統的設計者之一,並且設計和實施了多個基於代理的資訊管理應用程式。他於 1996 年獲得了麻省理工學院的電氣工程和計算機科學碩士學位以及計算機科學和工程學士學位。

Barry Warsaw 是 CNRI 技術人員的高階成員。他曾為包括應用程式網關係統、Knowbot 作業系統和 JPython 在內的多個 CNRI 專案做出貢獻。他為 Python 語言的開發和 Grail Internet 瀏覽器做出了貢獻。他於 1984 年獲得了馬里蘭大學的計算機科學學士學位。在加入 CNRI 之前,他曾在 1980 年至 1990 年期間在美國國家標準與技術研究院從事機器人系統操作員介面的工作,並在 1990 年至 1994 年期間在美國國家醫學圖書館從事醫學資料庫資訊科技的工作。

工作說明

CNRI 將執行以下工作

  • 開發用於 Python 的原型程式設計環境,包括適用於新手使用的程式分析和管理工具。
  • 開發一個原型教程,使用上述程式設計環境,向非程式設計師(尤其是在高中或大學)教授 Python 程式設計。
  • 開發針對上述受眾的示例軟體;例如,一個允許操作第三方 3D 遊戲環境的 Python 擴充套件。
  • 建立和維護一個網站和郵件列表,以推廣上述軟體和教程並徵求反饋。
  • 與選定的高中和大學合作。
  • 進行小規模的教學和使用者測試工作。
  • 從使用者、學生和教師那裡收集有關上述軟體和教程的反饋,並使用這些反饋來改進軟體和教程。還可以使用它來改進 Python 語言本身,或者提出更好的語言。
  • 釋出一份最終報告,記錄研究、經驗教訓、研究結果以及建議的後續研究。
卡內基梅隆大學的 Alice 小組將執行以下工作
  • 將 CNRI 開發的工具整合到 Alice 中。
  • 對 CNRI 開發的工具和教程進行使用者測試。
芝加哥大學將執行以下工作
  • 與 CNRI 合作,將 CNRI 開發的教程開發成適合高中使用的計算機科學課程,並分別開發成適合大學非計算機科學本科生使用的計算機科學課程。
  • 使用開發的課程進行授課,以便提供反饋。
為了最大限度地訪問所產生的材料,為本專案製作的所有軟體、教育材料和報告都將在全球資訊網上免費作為開源材料提供。

時間表

我們設想了以下工作時間表

  • 第 1 年。CNRI 的初步研究:開發初始原型程式設計環境;設計程式分析和測量工具;開發第一版教程;與其它研究人員和感興趣的教師建立聯絡。
  • 第 2 年:在 CNRI:初步實現程式分析和測量工具;收集來自第一個軟體和教程體驗的反饋。在 CMU:開始將 CNRI 開發的工具整合到 Alice 中,並開始使用者測試。在芝加哥大學:開始為高中生和大學生開發課程。
  • 第 3 年:繼續上述活動。此外,在 CNRI:將第一個程式分析和測量工具整合到程式設計環境中;小規模推出增強的程式設計環境;開發初始示例應用程式;定義成功的評估標準。在 CMU:對程式分析工具進行使用者測試。在芝加哥大學:將程式分析工具的使用整合到課程中。
  • 第 4 年:繼續上述活動,完成大部分活動。此外,在 CNRI:大規模推出增強的程式設計環境;改進示例應用程式;開始大規模收集終端使用者反饋;開始研究 Python 語言的更改。在 CMU:完成使用者測試,整合到 Alice 中。在芝加哥大學:完成並推出課程。
  • 第 5 年:專案完成:報告經驗,評估成功,將技術轉讓給教育界和工業界。
可選任務

提案中沒有可選任務。

參考文獻

[ABC]

http://www.cwi.nl/~steven/abc/ [Ball] Thomas Ball 和 James R. Larus,《程式跟隨路徑》。微軟研究院技術報告 MSR-TR-99-01,1999 年 1 月。 [Alice] http://www.alice.org/ [AOP] Gregor Kiczales、John Lamping、Anurag Mendhekar、Chris Maeda、Cristina Videira Lopes、Jean-Marc Loingtier 和 John Irwin。面向方面的程式設計。
歐洲面向物件程式設計會議(ECOOP)的論文集,芬蘭。施普林格出版社 LNCS 1241。1997 年 6 月。

http://www.parc.xerox.com/spl/projects/aop/

[Blair] http://www.mbhs.edu/ [Cartwright] Robert Cartwright 和 Matthias Felleisen。 透過軟型別進行程式驗證。 ACM Computing Surveys,1996年6月,28(2): 349-351。 [CPAN] http://www.cpan.org/ [Dertouzos] Michael L. Dertouzos。 計算的未來。科學美國人,1999年8月。 [Distutils] https://python.club.tw/sigs/distutils-sig/ [D-Lib] http://www.dlib.org/ [Findler] Robert Bruce Findler,Cormac Flanagan,Matthew Flatt,Shriram Krishnamurthi 和 Matthias Felleisen。 DrScheme:一個用於 Scheme 的教學程式設計環境。載於1997年程式語言:實現,邏輯和程式研討會論文集,英國南安普頓,1997年9月。(計算機科學講義,第1292卷。) [Fishtank] http://el.www.media.mit.edu/groups/el/projects/fishtank/ [Flanagan] Cormac Flanagan 和 Matthias Felleisen。基於元件的集合分析。 ACM 程式語言和系統彙刊,即將發表。 [Geurts] Leo Geurts,Lambert Meertens,Steven Pemberton。ABC 程式設計師手冊。 Prentice-Hall,1990年。 [Hugunin1] Jim Hugunin。 Python 和 Java - 兩全其美。 載於第六屆國際 Python 會議論文集,加利福尼亞州聖何塞,1997年10月,第11-20頁。 [Hugunin2] Jim Hugunin。 JPython 更新。特邀演講,第七屆國際 Python 會議。德克薩斯州休斯頓,1998年11月。PowerPoint 幻燈片:http://www.jpython.org/jpython-talk-1.ppt [Jackson] Daniel Jackson 和 Allison Waingold。 從位元組碼中輕量級提取物件模型。 載於1999年5月在加利福尼亞州洛杉磯舉行的國際軟體工程會議論文集。 [JPython] http://www.jpython.org/ [Knowbots] http://www.cnri.reston.va.us/home/koe/ [Liskov] http://sdg.lcs.mit.edu/~dnj/research/self-updating.html [Logo] http://el.www.media.mit.edu/groups/logo-foundation/ [LogoMation] http://www.magicsquare.com/LM2/ [Lutz] Mark Lutz。 Python 程式設計。O'Reilly,1996年。 [Mozilla] http://www.mozilla.org/ [Mailman] http://www.list.org/ [Ousterhout] John K. Ousterhout。 指令碼:21世紀的高階程式設計。IEEE 計算機,1998年3月。 [Papert] 思想風暴:兒童,計算機和強大的想法。紐約:基礎書籍,1980年。 [Pausch] Randy Pausch,Tommy Burnette,A.C. Capeheart,Matthew Conway,Dennis Cosgrove,Rob DeLine,Jim Durbin,Rich Gossweiler,Shuichi Koga,Jeff White。 Alice:虛擬現實的快速原型系統IEEE 計算機圖形學和應用,1995年5月。 [Portolano] http://www.cs.washington.edu/research/projects/portolano/ [Python] https://python.club.tw/ [SWIG] http://www.swig.org/ [Tip] Frank Tip。 程式切片技術概述。 程式語言雜誌,3(3):121-189,1995年9月。 [TeachScheme] http://www.cs.rice.edu/CS/PLT/Teaching/ [TJHSST] http://www.tjhsst.edu/ [Yorktown] http://yhspatriot.yorktown.arlington.k12.va.us/ [Watters] Aaron Watters,Guido van Rossum,Jim Ahlstrom。使用 Python 進行網際網路程式設計。 MIS Press/Henry Holt,1996年。 [Wright] Andrew K. WrightRobert Cartwright Scheme 的實用軟型別系統。 ACM 程式語言和系統彙刊,1997年1月,19(1): 87-152。