我是一位 ALGOL 的叛徒。在 ALGOL 語言的環境中成長後，我卻在晚年接觸了 APL。如同所有晚年才接觸新事物的人一樣，你會很快地深入其中。我認為分享我是如何接觸 APL 的，或許會很有趣，因為也許你們許多人也走了相同的路。
當時我在英格蘭的紐卡索參加一個會議，受邀發表演講的還有史丹佛大學的 Don Knuth、IBM 的 Ken Iverson，以及其他幾位專家。我坐在聽眾席中，夾在兩位電腦科學領域的權威之間——一位是 Fritz Bauer，他從慕尼黑的總部管理著巴伐利亞的電腦事務；另一位是 Edsger Dijkstra，他從荷蘭的總部管理著全球的電腦事務。
Ken 當時正在展示一些投影片，其中一張投影片上有一段後來我才知道是 APL 的單行程式碼。他把它當作 APL 語法表達力的範例。我認為那段單行程式碼是用來指示代數表達式中括號的巢狀層級的標準範例。但那段程式碼非常簡短——大約只有十個字元。我長期以來一直從事這類程式設計工作，深知要完成這樣的任務需要相當多的程式碼，所以我看到時便說：「我的天，這門語言肯定有什麼特別之處。」我左邊的 Bauer 並沒有看到。他看到或聽到的，是 Ken 提到 APL 是教授代數的極佳語言，他低聲對我說了一句我永遠不會忘記的話：「只要我還活著，APL 就永遠不會在慕尼黑使用。」而坐在我另一邊的 Dijkstra 則傾向 Bauer 說：「荷蘭也不會。」我們三個人聽著同一場演講，但顯然聽到了不同的東西。
當時吸引我的，是對 APL 的一種感覺，或許透過 APL，我們可以開始在程式設計中獲得一些我們在自然語言中崇敬的維度——一些組合的樂趣；優雅地表達事物；簡潔、詩意、藝術性，這些讓我們的自然語言如此珍貴。程式設計的這方面是我長期以來一直感興趣的，但在 FORTRAN、ALGOL、PL/I 等語言的經驗中，我從未找到接近它的層次。在那些語言中，程式設計顯然是一種「水管工」式的練習。我們在建造一個複雜的物體，而主要問題只是要讓自己不被淹沒。但由於這些語言的難度如此之高，以至於程式設計語言的這方面從未浮現。對我而言，當時聽 Ken 演講——我以前也聽過他演講——在那一刻，我經歷了一次我只能稱之為啟示的時刻。
我在 1963 年的普林斯頓程式語言會議上聽 Ken 演講，他談到了 APL。但當時 APL 尚未在任何電腦上運行；他堅決認為它不必在電腦上運行。對他而言，這是一種可以表達演算法概念的符號；當時他覺得這樣就足夠了。對於我們這些關心讓程式在真實電腦上運行的人來說，這似乎遠遠不夠。幾年後，由於天象的有利結合——一些非常優秀的程式設計師，哈佛大學沒有給 Ken 終身職位而他去了 IBM，以及 360 的出現，人們認為應該可以利用它進行分時系統——這些有才華的程式設計師、Ken、Adin Falkoff 等人的出現，以及 360 的可用性，讓我們都擁有了 APL。我認為我們今天都應該意識到，APL 之所以是現在這樣，是因為這樣的結合。它運行的系統非常穩定，以至於在分時系統極不穩定的時期，人們可以真正確保合理的連續運行；語言，如在第一個 360 版本中所呈現的；以及一群狂熱的追隨者，他們在 IBM 之外推廣這門語言——因為在那些日子裡，IBM 的接受程度遠不如應有的。但這一直是 IBM 的歷史。像所有大公司一樣，它事後有很多智慧。但這實際上意味著我們——尤其是你們這些在 IBM 工作的人——必須始終意識到，IBM 樂於接受好主意，但需要時間，很多時間，才能克服這個巨人的慣性。
現在，回到 APL 作為一門語言的問題。與人交談時，我總是驚訝——但回想起來並不意外——當我談論 APL 時，我們似乎在談論兩件不同的事情：他們對 APL 的看法和我的看法。當我閱讀你們的研討會論文時，我發現你們中的許多人關心的是我根本不感興趣的 APL 方面，而且我確信我感興趣的方面可能也不會引起你們的興趣。這意味著什麼？在我看來，這意味著 APL 作為一門語言，正在接近我們對一門優秀、豐富語言所期望的那種完整性。有許多聰明、有用的群體發現這門語言有價值，並且在共同的興趣點上幾乎沒有交集。這不是壞事；我認為這是好事，也是不可避免的。我認為，在試圖安排 APL 的未來發展時，我們可能會發現這項任務異常困難。因為我們使用 APL 的人從許多不同的途徑接觸它，並且關心語言應該如何改變的許多不同方面。從某種意義上說，我認為我們很幸運，這門語言如此優秀，並且變化如此緩慢。我們在程式設計領域的人們多年來肯定意識到的一件事是，人們並不介意使用一門糟糕或不完整的語言進行程式設計。只要他們能從中獲得一些有用的工作和一些樂趣，他們就會找到任何合理的理由來支持他們繼續使用這門語言——即使有許多更好的語言工具存在，正如 FORTRAN 的蓬勃發展所證明的那樣。我幾乎不認識任何對程式設計語言本身感興趣的人，除了它影響力和使用量持續增長這一事實外，對 FORTRAN 有什麼好評。對於任何語言來說，這都是一件非常值得稱讚的事情。當然，FORTRAN 的情況是，它已經成為計算世界的通用語言。它是每個人在某種程度上都理解的語言——它存在於每台電腦、每個國家、由每個製造商製造——人們可以透過閱讀各種複雜程度的書籍來學習使用 FORTRAN，這些書籍用地球上各種語言寫成。它是普遍的，就像我們呼吸的空氣一樣，我認為它在很長一段時間內不會被取代。它不會被取代，也許也不應該被取代的原因之一是，總是有新的程式設計師群體出現，對他們來說，FORTRAN 是母親的乳汁。如果我們將一個可以完成 50 行 FORTRAN 代碼的 APL 單行程式碼擺在他們面前，對我們來說一點好處也沒有。首先，人們需要很長時間才能學會如何使用這個單行程式碼，甚至更長時間才能編寫一個，所以 FORTRAN 將繼續成長和成功。我認為 APL 不會取代它的地位；沒有理由應該這樣。而且，使用 APL 的人的目標絕對不應該是站出來說：「你們這些傻瓜為什麼要使用這些低劣的語言工具，而我們有如此珍貴、如此優雅、給我帶來如此多樂趣的東西？你們怎麼會如此盲目和愚蠢？」你永遠贏不了那場辯論，我認為你不應該嘗試。
現在，今天有很多關於讓 APL 變得完美的談論——因為 APL 是一個近乎完美的工具。我們不會成功的。原因很簡單，因為對我們所有人來說，有太多不同的途徑可以讓 APL 實現其價值或完美。沒有單一的途徑。有些人說當前最重要的問題是改進 APL 的資料結構。有些人說 APL 需要一點「法語-英語混合語」，用我們的術語來說就是 APLGOL。「如果 APL 只有 while 語句，或 if-then-else，或 for 語句，它就會成為一門完美的語言。」這太荒謬了。說如果 APL 有陣列的陣列，我們所有的麻煩都會消失，這也很愚蠢。事實上，如果發生這種情況，麻煩的數量只會呈指數級增長。
然而，沿著這些和其他方向擴展語言是很重要的。人們會這樣做，無論我說什麼或你們做什麼。如果不在 IBM 內部完成，它也會在其他地方完成，因為人們對能夠採用一門語言，透過今天做一些小改動，明天再做一些小改動，就能帶人們走向彩虹盡頭的黃金鍋的信念有巨大的迷戀。我們許多人忘記了——當然，我們永遠不應該忘記——逐步編程有一天必須，雖然我們不知道如何，達到普遍能夠表達我們思想的程度，至少在涉及如何做事時是這樣。程式設計就是思考——還不是所有思考，也許永遠不是所有思考——但就當我們坐在電腦前時，我們面臨著許多直到我們編程才想到的誘人可能性而言，我們將對我們擁有的程式設計語言感到不滿。這包括有史以來創造的每一種語言以及即將出現的語言——還會有其他語言出現。所以，我對 APL 應該如何改變的看法將不可避免地與你們不同。而且沒有理由不應該這樣。讓我對 APL 感興趣的東西不一定讓你們感興趣，這就是我認為這門語言如此輝煌的原因。
作為一名教授，我感興趣的一件事是教人們如何編程；但這不僅僅是教他們如何編程，因為要教人們如何編程，任何程式設計語言都足夠了。認為只有一種語言或任何特定語言對於學習編程的意義至關重要是錯誤的。如果你的目標是教人們如何構建程式，BASIC 是完全令人滿意的。有些事情你無法在其中完成；因此，你會發明完成它們的結構；而這些結構的發明就是學習編程。遲早，在所有語言中，我們都必須使用我們從語言組件中費力而艱難地構建的結構。我們詛咒語言中沒有這些結構的事實。但它們現在並非全部存在，而且永遠不會存在。我與程式設計相關聯的詞——我相信每個人都與程式設計相關聯——是：「挫折」。一切皆有可能，但沒有什麼是容易的。我們坐下來編寫程式，我們最初的美好想法很快就會陷入不可用結構的泥潭。我們編寫過程、函數或任何東西，以及更多的函數；我們發明資料結構，以及更多的資料結構；最初看起來很不錯、很優雅的程式很快就會陷入困境，沒有結構。我們發現很難向別人描述它們的作用。我們說：「如果我編程方式不同，如果我使用，例如，『結構化編程』，這就不會發生……如果我有陣列的陣列，這就不會發生……如果我有 while 語句，這就不會發生……」胡說。如果今天沒有發生，明天就會發生，即使所有這些東西都存在。因為程式設計的本質就是一種自舉活動。Iverson 和上帝今天給你的，明天你會覺得不夠。
因此，對我所謂的「球形語言」——一種能夠以我們今天以及我們的後代以及再往後的後代所設想的每一個方向優雅、均勻地成長的語言——的追求，不太可能實現。我們不應該太不耐煩，因為我認為，在你處理的任何語言中，你都可以說出你真正想說的關於程式設計的一切。其中一些總是在建構層面——語言的原始語法之外。但對於 APL，還有額外的東西；至少我發現是這樣。
幾年前，卡內基梅隆大學來了一位來自 MIT 的訪客，我忘了他的名字。他在一個小辦公室裡開始給我們講述 LISP 的一些程式設計問題。他走到黑板前，開始講 LISP。他想描述的一切，都用括號、CONS、CARS 和 CDRS 來表達。他發現自己能夠用他編程的語言來表達他的想法。在他向我們講課的半小時左右的時間裡，我從未見過他畫出那種不可避免的方塊圖、流程圖，上面寫著半英語的文字。他不需要它們。當時我對自己說：「LISP 具有非常寶貴的特質，如果真的有人能夠用他們編程的語言向別人表達程式設計的想法的話。」我無法用 ALGOL 做到這一點；我從未用 ALGOL 做到過。每當我用 ALGOL 編程並想對我正在編寫的程式發表一些評論時，我都不得不跳出語言，使用英語、數學、某些方塊圖或類似的東西。在 APL 中，我發現比我用過的任何其他語言都要好得多，我可以對我正在編寫的程式發表評論，用 APL——實際上不是嚴格意義上的 APL，而是 APL 加上一些我當時夢想出來的、但從未想過要實現的漂亮小擴展。但總的來說，我發現這門語言允許我用這門語言來表達我正在處理的事情。我發現這是程式設計語言一個非常寶貴的特性。
我發現的第二個寶貴特性，與 APL 相關，是我在那篇發表在 SIAM News 上的小文章中使用的詞——「抒情」。我發現編寫 APL 很有趣。它很迷人。它很令人愉快。我發現編寫程式不再是一件苦差事，其中一個原因是我總是有這麼多選擇。然而，結構化編程的人告訴我，如果你在程式中加入足夠的結構，這裡的每個人都會編寫相同的 ALGOL 或 PASCAL 程式。因此，它會更容易閱讀——但也很枯燥。
上帝造我們每個人都不同。沒有兩個人的思維方式完全相同，而英語的一大力量在於，那些學會用它來磨練智慧並正確使用它的人，可以與他人以不同的方式表達事物。因此，當你閱讀一位有才華的人寫的英語時，你會感到愉快。前幾天我讀報紙，一位藝術界人士的文章說，如果莎士比亞還活著，他會為電視寫作。我讀到那時心想：「不對。如果莎士比亞還活著，他會是個程式設計師，他會用 APL 編寫單行程式碼。」
如果你解決一個問題，即使是一個非常簡單的問題，並讓 50 個人用 APL 編寫，很有可能你會得到 35 到 40 種不同的解決方案。對某些人來說，這是一種可怕的狀況。對我來說，這表明這門語言確實具有一定的力量，一定的價值；在某種意義上，它非常適合那些喜歡原創思考，即使可能思考得不好的人。這種變化，這種可用的選擇，為 APL 編程帶來了我幾乎稱之為文學的品質，這是我在任何其他程式設計語言中都找不到的。現在，人們總是說：「去他媽的文學品質，我們必須遵守截止日期；我們必須在電腦上運行程式。如果你花 10 分鐘而不是 7 分鐘，那就是三分鐘的金錢必須支付。」等等。這是真的，我並不說這不重要。但我想說的是，當人們用 APL 編寫任務時，乍一看，他們面前有大量的選擇——這不是壞事，而是好事——他們可以從中滿足任何數量的標準，而我認為，機器效率只是其中之一。
我剛開始學習編程時，每個人都使用組合語言。我們用機器碼編程。回想起來，我意識到當 FORTRAN 出現時，程式設計中有些東西消失了。消失的是編寫優雅且巧妙的程式的樂趣、挫折感和挑戰！優雅和巧妙並沒有錯；事實上，在我所知的幾乎所有領域，這都被認為是值得稱讚的。我不知道為什麼軟體不應該如此。當 FORTRAN 出現時，實際上你所做的就是以 DO 或 INTEGER I 語句開始程式。我喜歡告訴我的 ALGOL 朋友們，他們都有信箋，他們從當地文具店購買，右上角有他們的名字；左上角有 begin 字樣；下面是 integer i,j 字樣；底部，右下角是 end 字樣，後面還有簽名的地方。而且，我發誓，當你用 ALGOL 編程時，那個模板就在你的腦海裡。你從 begin 開始，聲明 i 和 j 是整數，然後說：「現在我該做什麼？」在 APL 中，你腦海中閃過的是一連串的操作：數據在陣列中穿梭，從另一端出來的是——跛行且遍體鱗傷，你知道——七個數字。在構建了秩為八的陣列，並瀕臨工作區滿載之後，從另一端出來的是這七個數字——它們幾乎是痛苦地被提取出來——然後你對自己說：「我的天，太棒了！這是一個機制！」
我知道對單行程式碼綜合症有很多批評。Phil Abrams 使用了「APL 色情」這個詞。但正如我們這些世故的人都知道，色情作品會蓬勃發展！它之所以蓬勃發展，不是因為我們邪惡，而是因為我們是人類。同樣，單行程式碼也會蓬勃發展，無論我們給它們貼上什麼標籤，因為 APL 這門語言就是創建單行程式碼的邀請，而學習或欣賞這門語言沒有比編寫它們更好的方法了。事實上，我認為 APL 只能透過編寫單行程式碼來學習——也就是透過在某種意義上看到你能壓縮進一行代碼的內容。當然，過了一段時間，你會變得更加世故，更加厭倦世界，然後你會開始編寫像 i=3 這樣的小短語。但至少在最初的熱情中，人們透過編寫單行程式碼來最好地欣賞這門語言。當我們教授 APL 時，自從我來到耶魯大學以來，我們一直在那裡教授 APL，我總是對學生們強調：「我不想看到任何循環，任何 go to 語句」——不是因為他們這樣寫的程式效率更高，因為確實許多情況下，循環程式的運行效率比單行程式碼更高，而是因為只有透過嘗試構建這些「絞肉機」，你才能將 10,000 個數字運行以得到兩個或五個——只有透過構建它們，你才能開始欣賞 APL 絕對華麗的和諧。我希望我的學生來找我說：「在這段 5 行的程式碼中，我使用了每一個 APL 原語，因為它很適合。有一個地方適合 decode，我就用了它。」
事實上，我們觀察到，經過短時間的學習，學生程式設計師開始覺得語言中的每一個原語都起到了相當於的作用。轉置不再讓他們害怕——[二元]轉置被經常使用。它很適合；所有的一切都很適合。現在，在改變 APL 的過程中——有跡象表明這將在未來幾年發生——我們必須在我們想保留在語言中的所有東西中，保留我所謂的這種「球形和諧」。永遠不要讓 APL 變成我選擇稱之為「語言的啞鈴模型」：有兩個團塊——一個在這裡，一個在那裡——它們透過一個狹窄的通帶進行通信；而程式設計師在編寫程式時，要麼花所有時間在這裡，要麼花所有時間在那裡，中間的時間非常少。我們的自然語言沒有發生這種情況，APL 也不應該發生。
現在，我對 APL 有一些不喜歡的地方，這是自然的。沒有語言是完美的。而我討厭它的地方，正是我和我的一些學生正在試圖改變的地方。但它們絕不代表改變 APL 的首要任務或最重要的智力問題。我無法說出那些。我現在就說，沒有人能說出 APL 的這些事情。它已經，可以說，太屬於公共領域了，而且 APL 程式的許多方面都涉及我們可能稱之為程式的「商業」。沒有人能說透過進行某些更改而僅僅這些更改，這門語言就會從其當前水平提升到更高的水平。
例如，我觀察到的第一件讓我感到困擾的 APL 特性是，當我執行語句時，我會創建這些巨大的陣列，然後從另一端出來三個數字。在此期間，使用了大量的儲存空間；因此，我首先想到的是，我必須找到一種方法來避免使用那麼多儲存空間。我們找到了一個非常簡單的解決方案，能夠大幅減少儲存空間的使用量。它並沒有太多地改變語言，而且我也不知道它對 APL 會產生什麼重大影響。
我們想到的第二件事是，我們需要一台 APL 機，因為 APL 現在運行在 FORTRAN 機上。FORTRAN 之所以是現在這樣，是因為電腦在 FORTRAN 發明時就是那樣的。當你看看 FORTRAN 時，你會發現它是一門語言，非常適合當時的電腦：一個累加器；一個用於處理乘數第二部分的溢位暫存器，以及除法的餘數；幾個索引暫存器；一個單一程式計數器；以及大約一百條指令的指令集。FORTRAN 就是為 IBM 704 而設計的。APL 則不同，因為它不是從同一條發展路線來的。我相信 Iverson 在開發 APL 時——我從未聽他親口說過——並不是在開發一門必須適應當時電腦的語言。我相信他是在 Mark IV 或 Mark III 之一上成長起來的——APL 與那些機器之間的關係非常小。結果，APL 出現了，並被適應到當時市面上可用的硬體上；順便說一句，這些硬體是沿著 FORTRAN 的路線發展而來的。那麼問題就來了：「我們應該擁有能夠比這些機器更好地執行 APL 的機器。那些機器應該是什麼樣子的？」嗯，再次運用我們將這三個數字推過絞肉機的想法，我所看到的 APL——我相信其他人也看到了——是一種串流處理語言，一種處理數據串流的語言。因此，我們應該擁有的機器應該是為執行這些串流而建構的——從中我們可以非常快速、相對容易地推導出機器設計。這樣的機器現在正由加州理工學院的幾個人在今年建造。然後我們就會看到它是否真的像我們希望的那樣好。它可能不會！
我們想到的第三個問題是，當然，虛擬記憶體——它是為了讓我們能夠交換程式和分頁數據，並使用相對較小的作用集而從作業系統中誕生的——虛擬記憶體，它是沿著那條路徑來的，但絕不是組織像 APL 這樣的陣列語言記憶體的正確方法。如何處理大型陣列？嗯，我們想到，我相信其他人也想到了，解決這個問題的一種方法是研究這些 APL 單行程式碼中的數據調度——再次使用數據串流模型，數據通過絞肉機並從另一端出來。數據需要什麼順序？我們如何從備份記憶體中調入它們，以便使用相對較小的緩衝區，我們總是可以將執行我們正在執行的表達式部分所需的數據保存在記憶體中？我們已經取得了一些非常好的結果，表明使用這種模型，數據儲存所需的記憶體量僅僅是我們習慣認為虛擬記憶體機器所需的記憶體量的一小部分。
在我和我學生的腦海中，所有這些發展的背後，都有一個想法：我們必須讓 BASIC 從公立學校系統中消失。BASIC 對年輕人來說確實有害。對老年人來說還可以。但對於高中十一年級和十二年級、大學預科和大學的年輕人來說，他們認為透過編寫 BASIC 程式，他們就能在他們可用的時間內，以他們所做的、能夠做的練習水平來欣賞程式設計的美，這個想法是惡毒的。而且，它也很危險。我們正在創造一群半文盲，你們 IBM 的人，不幸的是，將不得不試圖重新培訓他們。相信我，要讓一個接觸過 BASIC 的人——因此認為他現在已經掌握了關鍵——並教他如何用 APL 思考，這非常困難。這幾乎就像要求他們用另一個大腦的一部分來交換一個大腦的一部分——而他們還沒有準備好。所以，我們腦海中一直存在這個問題：如何以如此低的成本獲得一台 APL 機，使其能夠在全國的公立學校系統中使用，以便人們能夠開始欣賞 APL 的抒情本質？因為我們已經學到——我認為每個人都學到了這一點——一旦你學會了 APL，你就學會了 BASIC，你就學會了 FORTRAN，你就學會了 ALGOL，事實上，我認為你就學會了所有程式設計語言。你不知道你是怎麼學會的，但你知道。掌握將這些「玩具」組合起來的複雜性——這種掌握本身就包含了對所有程式設計的啟示。而你在 BASIC 中編程時所處的智力低層次，卻無法讓你欣賞到切換到 APL 時所涉及的美學。事實上，它看起來就像一個你還沒準備好處理的艱鉅謎題。
我聽過很多使用 ALGOL——或者現在大學裡使用 PASCAL——的人說，他們不願意學習 APL，因為學習它需要大量的時間投入。他們不願意花時間去思考我認為你必須學會的思考方式，如果你要用 APL 編程的話——學會像這樣思考，陣列不僅僅是數學對象，而是載體。因為當你用 APL 編程時，我認為你意識到的一件事是，陣列，總的來說，被你用作控制載體，你透過它們來處理一系列操作。而秩的使用僅僅是將小型陣列載入大型陣列背面的方便方法。當人們習慣了 BASIC 和 ALGOL 等語言時，很難讓他們這樣思考，作為一名教授，這讓我感到痛苦。但解決方案當然不是 5100；它太貴了。解決方案是推出一台價格在 1000 美元或 2000 美元左右的電腦，最多，擁有合理的記憶體和某種備份軟碟或其他東西，人們可以在上面相對高效地運行 APL。要做到這一點，需要一台 APL 機。需要某種 APL 編譯器，以便你可以將那些你會一遍又一遍重複執行的東西綁定起來，並讓它們非常快速地完成。還需要某種明智的備份記憶體處理。
這些是我們試圖解決的問題。它們絕不是處理 APL 最重要的問題。因為 APL 是我們程式設計世界商業中的一個項目；我們都知道這意味著人們能夠互相交流，交換程式，保證合理的效率，保證同一門語言能在各種機器上運行——這些在你們的商業世界中同樣重要，甚至更重要。但是，要讓人們進入那個世界，讓大學和高中的人們進入那個世界，在他們被 BASIC 污染之前學會 APL 是至關重要的。我非常認真地說這句話。
好吧，最近我腦海中出現了一些其他問題，我相信你們腦海中也出現了。今天我們面臨著一場迫在眉睫的計算革命。這場革命，為了尋找一個更好的詞或短語，就是大規模集成電路。現在，硬體人員多年來向我們承諾了很多東西，總的來說他們也實現了。我認為理所當然並指導我的一件事是，硬體驅動著我們的領域——不是軟體，而是硬體。是硬體人員提供的東西決定了我們可用的機會集。嗯，在接下來的五年左右，他們將在很小的空間裡給我們提供大量的電路元件——他們完全不知道這些電路元件應該做什麼，如何組合它們，什麼樣的程式語言將在這些機器上運行——他們擁有巨大的資源。嗯，正如你們可能猜到的那樣，APL 是利用這些空間的理想語言，或者比任何其他語言都更接近。因此，我們都面臨的一個問題是，我們軟體領域的人，如何彌合我們這個領域的軟體需求——提供人們可以使用的語言——如何彌合我們這個領域的需求與物理學家和電氣工程師將提供的硬體之間的差距——固態設備潛力巨大，但除非我們告訴它們應該做什麼，否則它們什麼也做不了。我無法想像還有什麼比得到一台功能強大無比的機器，卻發現它不過是 IBM 704 或 IBM 360 在晶片上的複製品更令人失望的了。這不算差，但我認為我們有更高的期望。因此，在未來幾年，在我看來，APL 的主要推動力將來自這個方向——APL 將是一個非常好的候選語言，以適應我們在這些矽晶片上將獲得的巨大空間的增加。
這是 Perlis 教授於 1978 年 3 月 29 日在加州 Los Altos 的 Foothill College 舉行的 APL’78 會議上的演講記錄。