為大眾設計計算機程式設計

這是我們於 1999 年 8 月提交給 DARPA 的修訂後的資助提案文字。3 月份，我們得知 DARPA 至少接受了該提案的早期版本；這項工作於 1999 年底開始，有望持續兩年，儘管我們只收到了第一年（截止 2000 年 10 月）的資助。我們對剩下的部分抱有希望。

不幸的是，Python 開發團隊遷往其他僱主，這意味著我們未能完成 CNRI 的 CP4E 專案。這次搬遷很大程度上是由於 DARPA 為 CP4E 提供的資金少得令人失望。

該專案現在處於停滯狀態；IDLE 仍在開發中，但我們沒有積極追求 CP4E 的其他目標。不過，其他人正在這樣做；這通常在 EDU-SIG 郵件列表中討論。

注意：我對提案文字做了一處修改：應其他語言一些支持者的要求，我撤回了一份語言比較表，該表包含對其他語言高度個人化且有時毫無根據的看法。該表被斷章取義地使用，導致一些人認為 objectionable。（並非所有表格內容都有爭議，但在沒有更多文件的情況下，似乎更明智的做法是不要進行直接的語言比較。）

我還從文字中刪除了一些行政細節，並進行了一些細微修改以適應 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 的討論。

創新主張

在七十年代，施樂帕洛阿爾託研究中心（Xerox PARC）提出了一個問題：“我們能否讓每個辦公桌上都有一臺電腦？”現在我們知道這是可能的，但這些電腦不一定賦能了它們的使用者。今天的電腦往往不靈活：普通電腦使用者通常只能透過“嚮導”（一個對預設對話方塊的崇高稱呼）配置有限的一組選項，而其他一切都依賴於專家程式設計師。

我們提出了一個後續問題：“如果使用者可以程式設計自己的電腦，會發生什麼？”我們期待一個未來，每個電腦使用者都能“開啟”他們的電腦，並改進其中的應用程式。我們相信這將最終從根本上改變軟體和軟體開發工具的性質。

我們將大規模讀寫軟體的能力與大規模識字率相比較，並預測對社會產生同樣普遍的影響。硬體現在足夠快且便宜，使得大規模計算機教育成為可能：當大多數計算機使用者掌握建立和修改軟體的知識和能力時，下一個重大變化將會發生。

開源運動聲稱，數千人的同行評審可以大大提高軟體質量。Linux 的成功證明了這一主張的價值。我們相信，擁有數百萬（或數十億）程式設計師的下一步將帶來不同質量的變化——個性化軟體的豐富可用性。

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

我們的計劃包含三個組成部分

• 開發一套適合高中生和大學生的新計算課程。
• 建立更好、更易於使用的程式開發和分析工具。
• 圍繞上述所有內容建立一個使用者社群，鼓勵反饋和自助。

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

基本原理

CNRI 提議開展一項名為人人學程式設計 (CP4E) 的研究工作。這項工作旨在改善計算機使用現狀，不是透過引入新硬體，也不是（主要）透過新軟體，而只是透過*賦能所有使用者*成為計算機程式設計師。

計算機和通訊硬體的最新發展使許多人能夠使用功能強大的計算機，包括桌上型電腦、筆記型電腦和嵌入式系統。是時候透過教育和支援軟體讓這些使用者對他們的計算機擁有更多控制權了。如果使用者對計算機有軟體設計和實現層面的總體理解，這將導致生產力和創造力的大幅提升，其深遠影響難以預料或想象。

短期來看，可用計算機軟體的數量和質量將大幅提高，因為數百萬人的想象力和勞動將被投入到這個問題中。富有創造力的使用者將能夠改進支援他們完成任務的軟體，並與他們的同事分享改進——或者透過網際網路——與面臨相同任務和問題的遠方其他人分享。在危機情況下，當專家無法提供幫助時，修改或定製軟體的能力至關重要。對於日常活動也很重要：目前一些人估計未填補的程式設計職位數量在 20 萬到 40 萬之間。

研究目標

兩大主要研究目標是開發一套新的*程式設計課程*原型，以及一套高度使用者友好的*程式設計環境*匹配軟體原型。我們設想典型的目標受眾將包括高中生和（非計算機科學專業）大學本科生，儘管也會考慮更年輕的學生和成年人。課程和軟體通常會一起使用，因此它們應該緊密協調；每個都也可以獨立使用。

我們還將探討程式設計在未來的作用。我們正迅速進入一個資訊家電、可穿戴計算機以及日常物品中深度聯網的嵌入式 CPU 為使用者提供對其物理和資訊環境控制權的時代。終端使用者可程式設計性將是釋放這些技術潛力的關鍵。（這是 DARPA 資訊科技遠征隊的共同主題，參見 [Dertouzos]。）

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

我們計劃從基於 Python 開始，這是一種流行的免費解釋型面嚮物件語言 [Python] [Lutz] [Watters]。Python 最初在阿姆斯特丹 CWI 開發，目前由 CNRI 開發和維護。Python 非常適合教學目的，而不僅僅是“玩具”語言：它作為一種快速應用程式開發語言，在計算機專業人士中非常受歡迎。Python 結合了多種主要程式設計正規化（過程式、函式式和麵向物件），語法優雅，易於閱讀、學習和使用。雖然我們相信 Python 是一個好的起點，但無疑我們會發現改進的可能性。作為我們研究的一部分，我們將評估 Python 在教育和初學者使用方面的有效性，並設計改進或替代方案。

我們預計我們的研究成果將在兩年內展示出來，並在十年內影響整個社會。屆時，在高中學習我們的課程的兒童將開始加入勞動力（和軍隊）。我們預計上述新的移動和嵌入式計算和通訊技術將在同一時間成熟。因此，我們的時間線匹配得很好。

動機

在矇昧時代，只有那些有權勢或鉅額財富的人（以及少數選定的專家）才擁有讀寫能力或獲取讀寫能力的能力。可以說，普通民眾的識字率（雖然仍未達到 100%），加上印刷技術的發明，是現代歷史上最具解放意義的力量之一。

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

然而，儘管現在許多人使用電腦，但很少有人是電腦程式設計師。非程式設計師在使用電腦方面並未真正“獲得賦能”：他們只能以“程式設計師”為他們設定的方式使用應用程式。無需遠見卓識便可看到其中的侷限性。

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

在這次“未來探險”中，我們想探討這樣一個概念：幾乎每個人都可以在學校獲得*某種程度*的計算機程式設計技能，就像他們可以學習讀寫一樣。

對於大眾使用的程式語言和環境來說，存在許多挑戰。如果每個人都是程式設計師，那麼糟糕的程式設計師肯定會層出不窮。要充分應對這種情況，需要重新思考程式語言和開發工具的基本特性。然而，我們認為專業人士使用的工具和用於教育的工具之間不應該有明確的界限——就像專業作家使用與他們的讀者相同的語言和字母表一樣！

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

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

• 日益強大的桌面和筆記型電腦應用程式使用指令碼和宏功能。
• 網際網路的增長直接導致了對可程式設計性的更大需求，以建立活躍和互動式的 Web 內容。
• 終端使用者資訊裝置和嵌入日常物品中的 CPU 網路——兩者都將需要使用者控制和個性化。
• 移動和智慧軟體代理將變得司空見慣，並需要使用者進行定製。

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

除了教授計算機工作原理的目標之外，計算機程式設計課程還將重新強調邏輯思維，這曾經是教授幾何的主要益處。

兩個特別引人關注的通用計算趨勢是向資訊裝置的轉變以及日常機器和裝置（無論是軍事還是民用領域）中嵌入式 CPU 的增長。計算尺寸的縮小和網路（尤其是無線網路）覆蓋範圍的擴大使得裝置之間共享資訊和進行互動成為可能。程式設計能力將極大地提高使用者控制這些裝置的能力。想象一下，使用者可以對例如他們的 GPS 接收器或手持記事本中嵌入的軟體進行自己的更改，而不是（或除了）從供應商下載升級或從第三方購買“現成”的附加應用程式。這將極大地賦能人們透過程式設計他們的個人工具來精確地完成他們需要它們做的事情來改善他們的生活。

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

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

如果這項工作成功，最終可能會有數百萬甚至數十億的程式設計師，掌握不同熟練程度的技能。這將對軟體開發現狀產生的影響難以想象。軟體的性質將發生變化，以適應這些程式設計師的需求，允許透過原始碼修改進行定製——個性化將變得非常普遍。

這項工作還可能對吸引女性和少數族裔進入計算機程式設計領域產生重大影響——目前，這些群體在這一領域的人數嚴重不足。

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

此外，透過使任何人都能對應用程式進行程式設計，我們將利用規模經濟，同時不犧牲使用者對高度個性化軟體的渴望。應用程式可以大規模生產，而無需強迫每個人在使用軟體時都適應相同的模式（或僅僅適應開發人員計劃的可定製性範圍）。使用者會出於多種原因希望個性化他們的系統；這些原因包括提高生產力、解決他們特有的問題，或者僅僅是表達他們的創造力並使自己與眾不同。如果他們擁有我們所設想的基本程式設計素養，他們將能夠實現這一點。

挑戰

一些寬泛的問題有助於我們明確具體的研究目標，例如：學校教授的程式語言會與我們今天所知的程式語言相似嗎？它甚至還會被稱為程式語言嗎？我們將如何教授它？會只有一種語言嗎？還有哪些其他工具對於教授和使用這種語言至關重要？是否有可能擁有一種既適合教學又對專家有用的語言和工具？

同樣有趣的問題是：人們將如何以及出於何種目的使用他們的程式設計技能？近乎普遍的讀寫計算機程式的能力將如何改變計算機軟體的結構和實用性？（這與未來版本的網際網路結合起來尤其有趣，後者承諾高速、無處不在地訪問計算和儲存元素。）一旦人們確信自己能夠程式設計，他們是否會被激勵去實際程式設計他們的系統？他們最初會感興趣嗎？

一個明顯的擔憂是，如果大多數人都是程式設計師，那麼他們中的許多人很可能都是*糟糕的*程式設計師。那些無法用母語寫出可理解的句子或平衡支票簿的人，也不太可能寫出結構良好的計算機程式！然而，我們的目的是讓程式設計對每個人都 accessible，即使不 easy。一些使用者會僱用或委託第三方程式設計和定製服務。這就像房主承包改造工作一樣。

因此，我們需要研究如何改善程式設計師與系統之間的互動質量，以幫助即使是糟糕的程式設計師也能充分利用他們的計算機。例如，您可能想編寫一個程式來定製您的 PDA 或烤麵包機，但如果一個微小的錯誤可能會擦除您的地址簿或點燃您的房子，您可能會感到氣餒。需要防災措施，以及撤銷對整個系統不需要的更改的方法。（“撤銷”雖然非常強大，但通常只適用於一個檔案。撤銷對不需要的全域性系統更改通常需要重新啟動，甚至痛苦地從備份介質恢復資料。）

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

除了擔心可能出錯之外，對於有興趣定製計算機的初學者程式設計師來說，理解一個龐大的現有軟體也是一項艱鉅的任務。我們需要研究使用者友好的程式分析工具；稍後將詳細介紹。另一個智力挑戰是視覺化（應用程式生成）資料，以幫助新手。電子表格在這方面非常有價值，但並非所有資料都適合矩陣形式。

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

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

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

領域特定類別則包含其他所有內容，從命令列引數語法到電子郵件頭和 HTML。這裡的區分因素是存在相對狹窄的應用領域。在這個類別中，我們還包括像微軟的“嚮導”（實際上只是由簡單流程圖連線的一系列預定義對話方塊）以及微波爐或核反應堆上的控制器和撥盤。

領域特定語言的一個典型特性是它們在其預期應用領域提供了出色的控制，而在意外領域則（幾乎）沒有自由。例如，HTML 沒有固有的條件包含文字或變數擴充套件的能力。（此類功能多次作為不相容擴充套件新增的事實僅僅證明了這一點。）

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

例如，如果手機是可程式設計的，人們仍然會使用常規的領域特定介面（鍵盤）來撥打特定號碼，因為這是訪問該特定功能最方便的方式。然而，如果沒有可程式設計性，就無法在不嘗試多種不同號碼的情況下，直到某一個號碼被接通為止，撥打特定朋友的電話，除非手機廠商預先考慮到這個特定功能。

為什麼要從 Python 開始？

我們提議從使 Python（一種現有的指令碼語言）的程式設計教學成為可能開始，並專注於為其建立新的開發環境和教學材料。我們有傳聞證據表明 Python 是一種很好的作為第一門程式語言來教授的語言。我們的工作將集中於為此目的建立工具和教育材料，並圍繞這些材料培養一個社群。這將使我們能夠研究 Python 作為教學語言的優缺點，併為未來的發展指明方向。

為什麼要從現有語言開始？我們的經驗表明，設計和實現一種新語言需要數年時間——而且這項工作必須（幾乎）完成才能建立使用者友好的開發環境和教學材料。因此，我們透過使用現有語言來啟動我們的專案。根據使用者反饋，我們可能會在專案期間修改 Python 或完全設計一種新語言。

我們已經有了一些需要進行更改的證據。卡內基梅隆大學的 Randy Pausch 教授（見下文）在他們的有限問題領域內對 Python 進行了一些可用性研究。他們的使用者似乎對 Python 變數名的大小寫敏感性和整數除法的截斷最為困惑。更廣泛和普遍化的研究將推動 Python 的具體更改，或表明需要設計一種新語言。

Python 是一種非常適合教授程式設計初學者的語言。它的許多關鍵特性都源於 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 訪問的高階功能的訪問（例如，高速 3D 計算機圖形軟體包）。雖然我們不期望學生編寫這些擴充套件模組，但*使用*這些模組可以大大提升他們的學習體驗。這種可擴充套件性讓教師有機會根據學生的興趣量身定製課程，為他們提供對其他軟體包的受控訪問。

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

Python 的程式設計環境和文件對於初學者教學而言並不理想。特別是，現有的 Python 程式開發工具和教程（各有幾種）都假設使用者是一個經驗豐富的開發人員，他知道一套外部工具來編輯、執行和除錯程式，並且已經知道一種或多種其他程式語言及其開發環境。這目前阻礙了 Python 作為第一門程式語言的更廣泛實驗。

方法

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

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

• 一套適合高中生和大學生的新計算課程。
• 更好、更易於使用的程式開發和分析工具。
• 圍繞上述各項形成的使用者社群，鼓勵反饋和自助。

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

課程開發

CP4E 工作的一個關鍵目標是開發一套程式設計素養課程，適用於從非計算機科學專業的本科生，到中學，最終到小學和初中學生。每個年級的教學方法可能會有所不同，以便更好地與學生在成長過程中建立聯絡和達到他們，但 CP4E 努力提供一個統一的方法，隨著學生的成長而發展，沿途呈現更豐富和更深入的主題材料。最初的工作將主要集中在高中生和本科生。

CNRI 將開發課程的基礎材料，包括用於教學環境的軟體，以及可作為程式設計教材基礎的教程和入門材料。CNRI 將與經驗豐富的教育工作者密切合作，他們擅長製作教材和其他教學材料，以便最好地為目標年齡組量身定製這些工具。

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

新計算課程

CNRI 提議與芝加哥大學合作開發一門新的計算機科學課程，將 Python 作為所有程式設計教學級別的程式語言。Python 是一種特別適合此目的的語言，因為它易於學習、閱讀和使用，但功能強大足以說明程式語言和軟體工程的基本方面。因此，即使是年幼的學生也可以使用 Python 學習程式設計基礎知識，但他們不會像使用 Logo 那樣受到其應用領域的限制。使用 Python 將允許每個學生按照自己的節奏探索和進步。特別令人興奮的是，有天賦的學生將擁有觸手可及的強大程式語言和環境，如果他們有動力學習更多或更快。

芝加哥大學將開發一系列課程，向本科生和高中階段的非計算機科學專業學生介紹程式設計和計算機概念。目前，這個級別的課程往往側重於程式語言（具有濃厚的數學色彩）或網頁程式設計主題，如 HTML 和 JavaScript。不幸的是，這兩種方法都存在嚴重的侷限性。如果課程過於正式和數學化，它可能只吸引計算機科學專業的學生和具有技術思維的學生。另一方面，網頁程式設計課程雖然極大地利用了網際網路的普及性，但往往狹隘地專注於 HTML、Perl 或 JavaScript 等特定技術。結果是學生對更廣闊的計算環境瞭解甚少，也未能獲得解決未來計算問題所需的解決問題技能。

將在芝加哥開發的課程將涵蓋我們認為每個人都必須瞭解的計算方面，才能成為一個知識淵博的計算機使用者

• 基本計算機組織。學生將學習計算機如何工作以及它們如何組合在一起的基本知識。主題將包括布林代數、邏輯和簡單的計算機體系結構（例如 CPU、記憶體、I/O）。簡單地說，這就是“引擎蓋下”發生的事情——用易於理解的術語來表達。最終，我們希望儘可能地揭開計算機的神秘面紗。
• 程式設計入門。這將介紹人們程式設計計算機的不同方式。學生將學習過程式、函式式和麵向物件程式設計，但以非正式的方式。目標不是將學生培養成專業程式設計師，而是向學生介紹人們嘗試簡化計算機使用的一些方法。
• 軟體架構。在未來，計算機將越來越多地透過組裝現有軟體元件和編寫少量粘合程式碼來程式設計。為了實現這一點，理解軟體的組合方式至關重要。學生將學習軟體設計和軟體組織（那些 DLL 到底是什麼？）。
• 除錯和問題解決。當所有其他方法都失敗時如何生存——而無需呼叫客戶支援。

3D 遊戲

我們打算自己進行小規模的教學工作，例如在協作部分列出的當地高中，但我們不期望會做太多教學。如果 Python 的受歡迎程度可以作為任何指標，我們就不必如此：其他人也渴望參與這項實驗。

課程將使用下一節中描述的新開發環境。為了激勵程式設計變得更“有趣”，我們打算將開發環境連線到一個現有的可程式設計 3D 遊戲引擎，就像流行電腦遊戲中使用的一樣。一些這樣的引擎已經或很可能將可用於 Python；我們將選擇一個併為其建立一個適合我們受眾的介面庫。

為什麼要使用 3D 遊戲引擎？Logo 的經驗表明，圖形是吸引年輕受眾注意力的好方法，但其 2D 圖形與青少年現在熟悉的影片遊戲相比顯得有些無聊。Alice 是一個引人入勝的 3D 圖形環境的良好範例。

知識機器人程式

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

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

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

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

程式設計工具

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

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

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

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

最後的挑戰是構建在普適計算環境中仍然有用的工具。桌面計算環境將很快被計算機控制裝置和物理系統網路所取代。這種新環境加劇了軟體安裝、除錯和管理的問題。它也給系統設計者帶來了新的挑戰，即構建允許終端使用者定製的軟體。

本節圍繞這三個挑戰展開。第一節討論提議的程式設計環境。第二節討論程式分析和配置管理工具。第三節討論支援普適計算環境終端使用者可程式設計性的應用程式框架。

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

程式設計環境

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

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

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

“撤銷”對於初學者來說是一個極其重要的工具，因為它是程式設計師的第一道防線。與版本控制、自動儲存和其他功能一起，回滾無限數量的短期更改的能力意味著程式設計師有更大的實驗和學習餘地。然而，大多數撤銷實現在其範圍上都相當有限。我們的方法將研究選擇性撤銷和全域性撤銷等概念。在傳統的撤銷系統中，編輯器只是保留一個檔案更改的連結串列，這些更改可以透過遍歷此列表來取消或重新應用（對此主題有各種變體，包括撤銷環和撤銷/重做）。傳統撤銷的一個問題是，一些不需要的更改與一些需要的更改重疊；程式設計師通常不得不放棄需要的更改以消除不需要的更改。

透過選擇性撤銷，更改可以區域性化到更細的粒度。例如，假設程式設計師對檔案頂部的函式 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 字串引數之間進行轉換。

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

我們的程式設計工具研究將解決的最重要問題之一是使用者可定製性將給系統配置管理帶來的負擔。當用戶對應用程式進行更改時，如何確保供應商未來對應用程式的更新與這些更改相容？使用者自己如何跟蹤他們對應用程式進行了哪些更改？當產品的未來版本添加了一個以前沒有的功能，而使用者已經添加了（以不同的形式）該功能時，會發生什麼？

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

我們還將建立增強社群的工具，使共享、整合和使用同行開發的軟體變得更容易。需要解決的問題包括包之間的依賴管理、易於安裝（和解除安裝！）、應對作業系統、應用程式和庫的變化、版本控制以及包維護。必須對軟體進行描述和分類，並建立討論、反饋、錯誤報告和補丁（既提交給維護者，也來自維護者）的論壇。最重要的是，這些社群建設工具必須主要由社群自身管理；它們必須是高度分散式、可複製和安全的。例如，使用者可以共享有關各種庫之間相容性問題的資訊；結合自動分發工具，這些資訊可以防止導致其他應用程式無法工作的軟體升級。

有幾個現有工具試圖解決其中一些或所有問題。Comprehensive Perl Archive Network（CPAN）旨在包含 Perl 程式設計師所需的所有 Perl 材料 [CPAN]。它是分散式和複製的，它使安裝 Perl 模組的工作更容易（儘管並非總是足夠容易）。然而，它不太適合其他型別的檔案材料。在 Python 社群中，*distribution-utilities* 特別興趣小組正試圖使第三方軟體的釋出和安裝更容易，但它沒有解決更廣泛的問題，而且它仍然狹隘地專注於 Python 軟體 [Distutils]。我們所熟悉的，最雄心勃勃的相關工作是自更新軟體 [Liskov] 專案。

應用程式框架

我們將研究未來計算和通訊變化對使用者控制計算機方式的影響，以及諸如近乎無限頻寬、更易訪問功能更強大的計算機、計算資源的普及以及更高水平的網際網路互聯（即使在微裝置級別）等發展所帶來的影響。這些變化影響了使用者將編寫哪種程式以及這些程式將在哪種計算機上執行。

我們在這一領域的方法是與實驗和原型系統合作，以瞭解應如何公開終端使用者可程式設計性。隨著這些技術的成熟，我們可能會將我們的經驗融入教學材料中。

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

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

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

一些例子包括

• 嘗試幾個不同的電話號碼來聯絡一個人，這可能取決於一天中的時間或一週中的哪一天。
• 當您不想被打擾時，將打進的電話轉接到語音信箱或電子郵件——但仍讓重要的電話透過。
• 接電話時降低電視或收音機的音量。
• 錄製某些電話的副本，可能透過呼叫語音轉文字轉換器。
• 在電子商務交易中，限制傳輸給商店或公司的個人資訊量。

這些示例表明了程式設計範圍的一個重要模式：使用者將在系統計算模型和軟體框架的背景下定製應用程式和裝置。因此，我們的探險將探索模組化應用程式的方法，並組織這些模組，以便使用者可以新增他們想要的小部分功能，而無需關注整個系統的執行。

在應用程式框架或嵌入式裝置的背景下，賦能非程式設計師修改和定製軟體的一個關鍵目標是減少理解修改如何適應更大程式所需的認知負擔。即使對於不熟悉應用程式程式碼庫的經驗豐富的程式設計師來說也是如此。應用程式必須模組化並提供足夠高級別的抽象，以便其組成部分可以快速獨立地理解。這使得人們能夠主要關注需要更改的部分。在我們的方法中，我們將探索幾種旨在改進軟體模組化的想法。

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

社群建設

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

這種明確的社群參與設施將極大地有益於我們的研究，並讓社群從我們的研究中獲得最大收益。早期和大規模社群參與對我們研究的好處將包括：幫助“試駕”我們的課程和軟體原型的志願者；由社群成員開發的新課程，針對特定目標受眾或旨在教授特定技能或科目；現有課程的本地化版本、翻譯等；新的或修改的示例（永遠不會有足夠的示例，而且針對特定受眾量身定製的示例更有效）；學生使用我們的程式開發軟體開發的新應用程式；等等。在 Python 社群中，我們收到了許多這樣的貢獻（包括關鍵文件的完整外語翻譯），完全是未經請求的！

對社群的好處包括早期接觸新課程和軟體，以及幫助教師進行教學，並說服他們的管理層向所有學生（而不是提前入學人群）教授計算機程式設計的重要性。我們還預計，提議的社群設施將促進社群成員之間的自給自足。例如，在共同輔導專案中，需要輔導幫助的學生將在網上找到志願者輔導員（通常是更高階的其他學生），教師將能夠直接交流他們的經驗。這種輔導活動已經在 Python 社群中發生，並將有助於減輕我們的研究團隊因反覆要求解決簡單問題而造成的負擔。

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

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

合作計劃

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

卡內基梅隆大學

由蘭迪·鮑施教授領導的Alice團隊[Alice][Pausch]開發適用於Windows的經濟實惠的3D圖形和虛擬現實軟體，最初在弗吉尼亞大學，現在在卡內基梅隆大學。他們將Python用於終端使用者程式設計，並用於實現其系統的大部分（幾乎除了渲染引擎之外的所有內容）。他們可能是教授Python程式設計（儘管是在有限領域）給沒有程式設計經驗的使用者最廣泛且記錄最好的案例研究，他們對Python的熱情極大地鼓勵了我們考慮在通用程式設計課程中使用Python。他們也是將可用性測試應用於程式語言和應用程式程式設計介面的少數團隊之一。

我們計劃向Alice團隊提供有限資金，以互利的方式繼續他們的這項研究。我們希望從他們教授初學者使用Python的經驗中受益，從他們內置於Alice系統中的簡單而有效的程式設計工具中受益，以及從他們在使用者測試方面的熟練程度中受益——這對於我們計劃開發的教程和軟體都非常重要。他們將從我們的教程（為Alice使用者提供更廣泛的軟體開發指導）以及我們的軟體（更強大的程式構建工具）中受益。

芝加哥大學

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

當地學校

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

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

其他研究組

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

我們預計，這種合作對我們的主要好處將是我們的技術能夠在先進系統中及早部署，而他們的好處將是他們正在開發的系統的終端使用者可程式設計性得到改進。請注意，時機非常好：個人嵌入式系統的廣泛部署（如Project Oxygen所設想的那樣）預計將與我們的課程和軟體廣泛使用的時間大致相同。

與其他研究的比較

ABC。Python的前身ABC在八十年代初被設計成一種教學語言。它的座右銘是“消滅Basic”——承認當時非專家語言的主要競爭對手。ABC的設計者在向初學者教授ALGOL等“經典”程式語言方面擁有豐富的經驗。他們發現學生們常常被使用計算機語言的偶然細節（例如執行編譯器、處理不同的數字格式、神秘的I/O操作和低階記憶體管理）所困擾，以至於他們從未能專注於良好程式和演算法設計的本質。

為了抵消這種影響，ABC的設計者回歸了第一性原理。他們著手設計一種語言及其環境，能夠處理所有偶然細節，讓學生有更多時間學習程式設計中獨立於當前程式語言的本質，例如清晰的控制流和強大的資料結構，並專注於程式的優雅表達。他們提出了一種新的語言設計和新的術語，這些都與計算機科學家和程式設計師中流行（並且仍然流行）的做法大相徑庭。事實上，ABC未能產生預期影響的最大原因可能就是他們偏離了現有實踐太多。那些能夠接觸到執行ABC所需的硬體的人（最初它只在Unix系統上執行，儘管後來被移植到Mac和PC）往往是經驗豐富的計算機使用者，他們對ABC沒有“與他們其他應用程式說同一種語言”感到沮喪。

大約十年後，Python正是從這種挫折中成長起來的。它與ABC一樣，關注表達的優雅、程式設計的基礎和消除偶然性，但增加了面向物件、可擴充套件性以及強大的模組庫，透過多種不同機制與其他應用程式介面：共享檔案、程式嵌入、CORBA或COM等RPC介面以及網路協議（支援網際網路上通常使用的所有協議）。

Logo。Logo實際上是一個與Lisp相關的語言家族，主要由麻省理工學院開發，當然是兒童最著名的程式語言。它擁有豐富的傳統，在學校中根深蒂固，並有許多商業產品。麻省理工學院媒體實驗室的認知論與學習小組正在進行持續研究，例如“可程式設計磚塊”（與樂高合作）。

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伺服器。我們將使用網際網路和全球資訊網進行所有材料的分發。

主要人員名單

Guido van Rossum 將在CNRI領導這項工作。他是CNRI的團隊負責人，也是Python的建立者，至今仍是其主要開發者。他還是Knowbot移動代理系統的主要設計者。過去，他曾參與為教學目的開發的程式語言ABC和80年代開發的著名分散式作業系統Amoeba的工作。他擁有阿姆斯特丹大學的數學和計算機科學碩士學位。

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

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

工作說明

CNRI將執行以下工作

• 開發Python原型程式設計環境，包括適用於初學者的程式分析和管理工具。
• 開發原型教程，使用上述程式設計環境向非程式設計師（特別是高中生或大學生）教授Python程式設計。
• 開發面向上述受眾的示例軟體；例如，一個允許操作第三方3D遊戲環境的Python擴充套件。
• 建立並維護一個網站和郵件列表，推廣上述軟體和教程並徵集反饋。
• 與選定的高中和大學合作。
• 參與小規模教學和使用者測試工作。
• 從使用者、學生和教師那裡收集關於上述軟體和教程的反饋，並利用這些反饋改進軟體和教程。也將其用於改進Python語言本身或提出更好的語言。
• 釋出一份最終報告，記錄研究、經驗教訓、研究結果和建議的後續研究。

• 將CNRI開發的工具整合到Alice中。
• 對CNRI開發的工具和教程進行使用者測試。

• 與CNRI合作，將CNRI開發的教程發展成適合高中的計算機科學課程，並單獨發展成適合大學非計算機科學本科生的計算機科學課程。
• 使用開發的課程授課以提供反饋。

時間表

我們設想以下工作時間表

• 第1年。CNRI的初步研究：開發初始原型程式設計環境；設計程式分析和測量工具；開發教程的第一版；與其他研究人員和感興趣的教師建立聯絡。

• 第2年：CNRI：初步實施程式分析和測量工具；收集首次軟體和教程體驗的反饋。CMU：開始將CNRI開發的工具整合到Alice中並開始使用者測試。芝加哥大學：開始為高中生和大學生開發課程。

• 第3年：繼續上述活動。此外，CNRI：將第一個程式分析和測量工具整合到程式設計環境中；小規模推廣增強型程式設計環境；開發初始示例應用程式；定義成功評估標準。CMU：程式分析工具的使用者測試。芝加哥大學：將程式分析工具的使用整合到課程中。

• 第4年：繼續上述活動，完成大部分。此外，CNRI：大規模推廣增強型程式設計環境；完善示例應用程式；開始大規模收集終端使用者反饋；開始著手Python語言更改。CMU：完成使用者測試，整合到Alice中。芝加哥大學：課程的完成和推廣。

• 第5年：專案完成：報告經驗，評估成功，向教育界和工業界進行技術轉讓。

提案中沒有可選任務。

參考文獻

[ABC]