我一直在思考一個問題：為什麼我們要為人類創造編程語言，而不是為IDE創造編程語言，然後用人類可讀的格式來顯示程序呢？
用文本來表示數學表達式是非常糟糕的方式。
完全不如下述表達式清晰：
在處理編程語言中向量等非簡單類型的時候情況會更糟，你只能通過引用傳遞結構。如果你不想耗費無謂的內存開銷，那麼就必須使用如下形式：
這些還只是最簡單的公式。我在做圖形引擎的開發時編寫的著色器代碼在調試時就是一個噩夢，因為它的表現形式十分晦澀難懂。
其次是變量的命名。再次舉一個數學的例子：P(A | B)能夠精準地表達含義且易於理解，並且簡潔易於辨認。不幸的是大多數的編程語言都不允許我們以P(A | B)的形式命名變量。同樣，有關camelCase和snake_case的爭論也是由於不能在變量名中使用空格而造成的。
另一個問題是：我們如何在智能手機上編程？虛擬鍵盤不適合代碼，基於圖形的解決方案可能有效，但我很確定沒有多少人喜歡在臺式機上繪製圖形。
製表符和空格的爭論也是另一個由文本書寫代碼的假設引起的。同時，這兩種方法都是嚴重過時的對齊工具。
對於上述每種情況，關鍵問題都在於格式和語義之間存在緊密耦合。只要我們以純文本顯示代碼，就會產生這些問題。
連字和自定義運算符提供了一些幫助，但這些方法始終沒有解決核心的問題。
那麼如果我們將文件的表現從純文本改成其他更豐富或結構化更強的形式呢？通過去除這種格式和語義之間的耦合，我們還可以在不同的系統上使用截然不同的格式（例如圖形編輯器），然後修改底層相同的語義。
對此，你怎麼看？
1.Hacker News 上開發者的觀點
評論1：
你忽略了一點：文本文件是最簡單的。雖然有時它們可能有點麻煩，但作為“構成表達的物質”，它們是無可比擬的。你可以使用現有最常見的人機界面設備來創建或修改文本，現在的孩子在上學之前就學會使用文本了。你可以閱讀包含一百萬種不同程序的文本，並對其進行樣式化、過濾、格式化、剪切和粘貼以及其他無數的操作。書寫方程式時的不足只是為這種靈活性付出的很小的代價。
如果按照你提議的方式“解耦”格式和語義，那麼將無法避免語義與編輯器的耦合。這種情況下就只能使用一種編輯器，直到你開發出其他一些可以與語法樹的結構化表示交互的東西。並不是說我們做不到或不應該這麼做，APL就曾經做過，像Scratch這樣的教育工具做得也很好，當然還有各種“無需編程經驗”的流程圖和建模語言，但是這種想法只能在一些非常具體的情況下才能與文本文件對抗。
評論2：
我覺得Smalltalk可以作為一個回答你的問題的例子。Smalltalk就像你描述的那樣：一種為IDE構建的語言。你無法在該IDE外部使用這種語言，因為它沒有按照純文本的格式存儲數據，而是採用了圖像格式。該IDE為用戶提供了各種不錯的功能和分析，自從20世紀70年代創建以來，Smalltalk的創意已經影響了許多其他語言和IDE。那麼為什麼我們都不使用Smalltalk呢？我認為關鍵在於互操作性。Smalltalk是一個獨立的世界。它無法與Smalltalk世界之外的工具很好地交互。例如，如果不解決如何以二進制的圖像格式合併代碼，那麼就不能享受Git帶來的便利性。當我需要完成一項特定的任務時（比如某種構建任務），我需要知道如何使用Smalltalk的工具在Smalltalk世界中完成所需的一切。Smalltalk違背了Unix哲學：它提供的不是一個功能，而是所有一切，因為它是一個微型的虛擬機。
我無權說這是我們不使用類似於Smalltalk的語言編程的所有理由，但是我覺得這是其中一部分理由。很多新的編程語言在嘗試用新的方式、交互式的方式推動編程語言（例如Eve），但它們都沒有解決關鍵的問題或贏得人們的認可。其中必然存在一些內在的原因為什麼這樣的語言無法取得成功。希望以上文字可以提供一些見解！
評論3：
Donald Knuth在1979年描述了Literate Programming的概念（https://en.wikipedia.org/wiki/Literate_programming）。
我之前公司的一位同事Raymond Chen在研究生期間是Donald Knuth的學生，他曾用過Donald Knuth的Literate Programming進行編程。
但他建議是不要採用這種編程方式。
原文：https://dev.to/drbearhands/should-programming-languages-be-made-for-ides-rather-than-humans-3dnf
作者：DrBearhands，軟件工程師和數據科學家，他感興趣的領域有人工智能、3D算法（圖形、導航等）、邏輯、高性能計算/並行、功能編程和創新。
閱讀更多 CSDN 的文章
