指導理念
1. 為人服務的程式語言
程式語言是人們與電腦交談的方式。計算機很樂意說任何明確的語言。我們之所以有高階語言，是因為人們無法處理機器語言。程式語言的目的是防止我們可憐、脆弱的人類大腦被太多的細節淹沒。
建築師知道有些設計問題比其他問題更為平常。一些最清晰和最抽象的設計問題是橋樑的設計。在這種情況下，您的工作就是用盡可能少的材料走完所需的距離。另一方面是椅子設計。椅子設計師應該花時間思考人們的屁股。
軟體開發也有類似的差異。設計透過網路路由資料的演算法是一個很好的抽象問題，就像設計橋樑一樣。而設計程式語言就像設計椅子：你必須應付人類的弱點。
這對我們大多數人來說是很難意識到的。對我們大多數人來說，設計優雅的數學系統聽起來比迎合人類弱點更有吸引力。數學優雅的作用是某種程度的優雅使程式更容易理解。但這並不全是為了優雅。
當我說語言的設計應該適應人類的弱點時，我並不是說語言應該為糟糕的程式設計師設計。事實上，您應該為最好的程式設計師設計軟體，但即使是最好的程式設計師也有其限制。我認為沒有人會喜歡使用所有變數都用整數下標的字母“x”表示的語言進行程式設計。
2. 為自己和朋友設計
如果你看看程式語言的歷史，大多數最好的語言都是設計給自己的作者使用的，而大多數最糟糕的語言都是設計給其他人使用的。
當語言是為其他人設計的時，它總是特定的一群人：人們並不像語言的創造者那麼聰明。這就是你如何獲得對你說話居高臨下的舌頭的方法。 Cobol 是最突出的例子，但大多數語言都充滿了這種精神。
這與語言的高階程度無關。 C 的等級相當低，但它是為作者使用而創建的，這就是駭客喜歡它的原因。
為糟糕的程式設計師設計語言的論點是，糟糕的程式設計師比優秀的程式設計師多。也許確實如此。但這一小部分優秀程式設計師編寫的軟體卻多得不成比例。
我的問題是，如何創造一種能夠吸引最優秀駭客的語言？在我看來，這個問題與「如何創建一種好的程式語言？」的問題相同，但即使不是，它至少是一個有趣的問題。
3.給程式設計師盡可能多的控制權
許多語言（尤其是那些為其他人設計的語言）就像保姆一樣：它們試圖警告您遠離他們認為對您沒有用的東西。我持相反的觀點：給程式設計師盡可能多的控制權。
當我第一次學習 Lisp 時，我最喜歡的是我們平等地交談。在我當時學過的其他語言中，有一種語言，也有我用那種語言寫的程序，它們是完全獨立存在的。但在 Lisp 中，我寫的函數和巨集與語言本身寫的函數和巨集相同。如果我願意的話，我可以重寫該語言本身。它具有與開源軟體相同的吸引力。
4. 簡潔是才華的姊妹
簡潔性被低估，甚至被鄙視。但如果你深入觀察駭客的內心，你會發現他們確實喜歡簡潔。您有多少次聽到駭客津津有味地談論如何在 APL 中僅用幾行程式碼就可以做出驚人的事情？我想真正聰明的人實際上喜歡關注這一點。
我相信幾乎任何能讓程式變得更短的東西都是一件好事。函式庫函數應該很多，凡是能隱式的都應該如此；文法應該更簡潔；甚至實體名稱也應該很短。
不僅僅是程序應該短。手冊也應該簡短。手冊的很大一部分充滿了解釋、免責聲明、警告和特殊情況。如果您需要縮短手冊，最好的選擇是糾正需要大量解釋的語言。
5. 認識什麼是駭客攻擊
許多人希望駭客成為數學，或至少是類似科學的東西。我認為駭客更像是建築。建築是關於物理學的，因為建築師需要設計一座不會倒塌的建築，但建築師的真正目標是創造一座偉大的建築，而不是在靜力學領域做出發現。
駭客喜歡的是創建出色的程式。我認為，至少在我們自己的想法中，我們應該記住，編寫偉大的程式是一件很棒的事情，即使這項工作不容易轉化為科學論文的通常知識貨幣。從智力的角度來看，設計一種程式設計師喜歡的語言與設計一種糟糕的語言同樣重要，因為它體現了你可以發表論文的想法。
開放式問題
1. 大型圖書館如何組織？
庫正在成為程式語言的重要組成部分。它們變得如此之大，以至於可能很危險。如果在庫中找到滿足您需求的函數比您自己編寫該函數花費的時間更長，那麼所有程式碼都沒有任何作用，只會讓您的手冊變得更厚。 （符號手冊就是一個例子。）所以我們必須解決圖書館組織問題。理想情況下，設計它們以便程式設計師可以猜測哪個函式庫函數是合適的。
2. 人們真的害怕前綴語法嗎？
這是一個懸而未決的問題，我已經思考了好幾年，但我仍然不知道答案。前綴語法對我來說似乎完全自然，除了它在數學中的使用。但 Lisp 不受歡迎的大部分原因可能只是由於不熟悉的語法......如果這是真的，是否值得對此採取任何措施，則是另一回事。
3. 您需要什麼伺服器軟體？
我認為未來 20 年內編寫的大多數應用程式都將是 Web 應用程序，從某種意義上說，程式將駐留在伺服器上並透過 Web 瀏覽器與您進行通訊。為了編寫這樣的應用程序，我們需要新的東西。
其中之一是支援發布伺服器應用程式的新方法。伺服器軟體不會像桌面軟體那樣每年發布一到兩個大版本，而是會透過一系列小的變更來發布。您每天可能會發布五個或十個版本。每個人都將始終擁有最新版本。
你知道如何設計可維護的程式嗎？伺服器軟體必須設計為可更改的。您應該能夠輕鬆地更改它，或者至少知道微小的更改意味著什麼以及重要的是什麼。
伺服器軟體中另一個有用的東西是交付的連續性。在網頁應用程式中，您可以使用類似的東西 在無狀態的網路會話世界中獲得例程的效果。如果該功能不太昂貴，那麼保持供應的連續性可能是值得的。
4. 還有哪些新的抽像有待發現？
我不確定這個希望有多合理，但就我個人而言，我真的很想發現一種新的抽象 - 一些可以與一流函數或遞歸或至少默認參數一樣有意義的東西。也許這是一個不可能實現的夢想。這樣的事情往往不被發現。但我並沒有失去希望。
鮮為人知的秘密
1.您可以使用任何您想要的語言
以前，創建應用程式意味著創建桌面軟體。在桌面軟體中，人們普遍傾向於使用與作業系統相同的語言來編寫應用程式。所以十年前，寫軟體一般意味著用 C 語言編寫軟體。最終，傳統演變了：應用程式不應該用不尋常的語言編寫。這種傳統已經發展了很長一段時間，以至於經理人和創投家等非技術人員也學會了這一點。
伺服器軟體徹底破壞了這種模式。透過伺服器軟體，您可以使用任何您想要的語言。幾乎沒有人理解這一點（尤其是經理和創投家）。但有些駭客明白這一點，這就是為什麼我們聽說 Perl 和 Python 等獨立語言。我們沒有聽說過 Perl 和 Python，因為人們使用它們來編寫 Windows 應用程式。
這對我們這些對程式語言設計感興趣的人來說意味著什麼，我們的工作有潛在的受眾。
2.速度來自分析器
語言開發者，或至少是語言實現者，喜歡編寫產生快速程式碼的編譯器。但我認為這並不是讓語言對使用者來說變得更快的原因。 Knuth 很久以前就指出，速度只取決於幾個瓶頸。任何嘗試過加速程式的人都知道，你無法猜測瓶頸在哪裡。探查器就是答案。
語言開發者正在解決錯誤的問題。用戶不需要基準測試來快速運行。他們需要一種能夠顯示程式的哪些部分需要重寫的語言。此時，實務上就需要速度。因此，如果語言實作者將最佳化編譯器的一半時間花在編寫一個好的分析器上，也許會更好。
3.您需要一款能夠讓您的語言不斷發展的應用程式
這可能不是最終的事實，但最好的語言似乎是隨著它們所使用的應用程式而演變的。 C 是由需要係統程式設計的人編寫的。 Lisp 的設計部分是為了符號微分，麥卡錫非常渴望開始，甚至在 1960 年第一篇 Lisp 論文中開始編寫微分程式。
如果您的應用程式解決了一些新問題，這尤其有用。這促使你的語言擁有程式設計師想要的新功能。就我個人而言，我有興趣編寫一種適合伺服器應用程式的語言。
[在討論中，Guy Steele 也提出了這一點，並補充說應用程式不應包含為您的語言編寫編譯器，除非您的語言旨在編寫編譯器。]4. 該語言必須適合編寫一次性程式。
您知道一次性程序的含義：當您需要快速解決一些有限的問題時。我相信，如果你環顧四周，你會發現許多嚴肅的項目最初都是一次性的。如果大多數項目都是一次性的，我不會感到驚訝。因此，如果你想創建一種適合編寫一般軟體的語言，那麼它也應該適合編寫一次性程序，因為這是許多程序的初始階段。
5. 語法與語意相關
傳統上認為語法和語義是非常不同的東西。這聽起來可能令人震驚，但事實並非如此。我認為你想在你的程式中實現什麼與你如何表達它有關。
我最近與 Robert Morris 交談，他指出運算子重載是中綴語法語言獲勝的一大優勢。在具有前綴語法的語言中，您定義的任何函數實際上都是運算符。如果你想添加一個你自己編造的新類型的數字，你可以簡單地定義一個新函數來添加它。如果您在具有中綴語法的語言中執行此操作，您會發現使用重載運算子和呼叫函數之間存在很大差異。
隨著時間的推移，想法會回來
1.新的程式語言
回顧 1970 世紀 XNUMX 年代，開發新的程式語言非常流行。現在情況並非如此。但我相信伺服器軟體將再次帶回創造新語言的時尚。使用伺服器軟體，您可以使用任何您想要的語言，因此，如果有人創建了看起來比其他語言更好的語言，就會有人決定使用它。
2. 時間共享
理查德·凱爾西（Richard Kelsey）提出了這個想法，時機又到了，我完全支持它。我的猜測（微軟也是如此）是，大量計算將從桌面轉移到遠端伺服器。換句話說，時間共享又回來了。我認為這需要語言層面的支持。例如，Richard 和 Jonathan Reeves 為實現方案 48 中的進程調度做了很多工作。
3. 效率
最近，計算機似乎已經夠快了。我們越來越多地聽到有關字節碼的信息，這至少對我來說意味著我們擁有一些儲備能力。但我認為對於伺服器軟體，我們沒有。有人必須為運行該軟體的伺服器付費，而伺服器每台機器可以支援的用戶數量將是其資本成本的除數。
我認為效率很重要，至少在計算瓶頸方面是如此。這對於 I/O 操作尤其重要，因為伺服器應用程式執行大量此類操作。
最終，字節碼可能不是答案。目前，Sun 和微軟似乎正在字節碼領域展開正面交鋒。但他們這樣做是因為字節碼是將自身嵌入到進程中的方便位置，而不是因為字節碼本身就是一個好主意。事實可能是，整個戰鬥將被忽視。這會很有趣。
圈套和圈套
1. 客戶
這只是一個猜測，但唯一受益的應用程式是那些完全伺服器端的應用程式。設計基於每個人都會有客戶的假設運行的軟體就像基於每個人都會誠實的假設來設計一個社會一樣。這肯定會很方便，但你必須假設它永遠不會發生。
我認為支援網路的設備將會快速增加，我們可以假設它們將支援基本的 html 和表單。您的手機上有瀏覽器嗎？您的 PalmPilot 有電話嗎？你的黑莓手機會有更大的螢幕嗎？您可以透過您的遊戲機存取網路嗎？從你的手錶？我不知道。而且我不必知道是否所有內容都會在伺服器上。將所有的大腦都放在伺服器上會更可靠。 。
2. 物件導向編程
我意識到這是一個有爭議的說法，但我認為 OOP 並不那麼重要。我認為對於需要特定資料結構的特定應用程式（如視窗系統、模擬、CAD 系統）來說，這是一個合適的範例。但我不明白為什麼它應該適合所有程序。
我認為大公司的人們喜歡 OOP，部分原因是它讓很多事情看起來很可行。自然地可以表示為整數列表，現在可以表示為一個擁有各種鷹架、喧囂的教室。
OOP 的另一個吸引人的特性是方法為您提供了一些一流函數的效果。但這對 Lisp 程式設計師來說並不是新聞。當您擁有真正的一流函數時，您可以以適合手頭任務的任何方式簡單地使用它們，而不是將所有內容都推入類別和方法的樣板中。
我認為這對語言設計來說意味著你不應該將 OOP 嵌入得太深。也許答案是提供更通用、更基礎的東西，讓人們將任何物件系統設計為函式庫。
3.組委會設計
如果你的語言是由委員會設計的，那麼你就會陷入困境，而不僅僅是因為眾所周知的原因。大家都知道，委員會往往會創造出笨拙、不一致的語言設計。但我認為最大的危險是他們不冒險。當一個人負責時，他會承擔委員會永遠不會同意承擔的風險。
你需要冒險來創造一門好的語言嗎？許多人可能懷疑語言設計必須非常接近傳統智慧。我敢打賭事實並非如此。在人們所做的其他事情中，回報與風險成正比。那麼為什麼語言設計應該有所不同呢？
來源： www.habr.com