1. 程式人生 > >程式設計師是否應該創造面向 IDE 而非人類的程式語言?

程式設計師是否應該創造面向 IDE 而非人類的程式語言?

640?wx_fmt=gif

我一直在思考一個問題:為什麼我們要為人類創造程式語言,而不是為IDE創造程式語言,然後用人類可讀的格式來顯示程式呢?

640?wx_fmt=jpeg

用文字來表示數學表示式是非常糟糕的方式。

640?wx_fmt=png

完全不如下述表示式清晰:

640?wx_fmt=png

在處理程式語言中向量等非簡單型別的時候情況會更糟,你只能通過引用傳遞結構。如果你不想耗費無謂的記憶體開銷,那麼就必須使用如下形式:

640?wx_fmt=png

這些還只是最簡單的公式。我在做圖形引擎的開發時編寫的著色器程式碼在除錯時就是一個噩夢,因為它的表現形式十分晦澀難懂。

其次是變數的命名。再次舉一個數學的例子:P(A | B)能夠精準地表達含義且易於理解,並且簡潔易於辨認。不幸的是大多數的程式語言都不允許我們以P(A | B)的形式命名變數。同樣,有關camelCase和snake_case的爭論也是由於不能在變數名中使用空格而造成的。

另一個問題是:我們如何在智慧手機上程式設計?虛擬鍵盤不適合程式碼,基於圖形的解決方案可能有效,但我很確定沒有多少人喜歡在臺式機上繪製圖形。

製表符和空格的爭論也是另一個由文字書寫程式碼的假設引起的。同時,這兩種方法都是嚴重過時的對齊工具。

對於上述每種情況,關鍵問題都在於格式和語義之間存在緊密耦合。只要我們以純文字顯示程式碼,就會產生這些問題。

連字和自定義運算子提供了一些幫助,但這些方法始終沒有解決核心的問題。

那麼如果我們將檔案的表現從純文字改成其他更豐富或結構化更強的形式呢?通過去除這種格式和語義之間的耦合,我們還可以在不同的系統上使用截然不同的格式(例如圖形編輯器),然後修改底層相同的語義。

對此,你怎麼看?


640?wx_fmt=png

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的熱乎文章,

趕快把CSDN公眾號設為星標吧,

開啟公眾號,點選“設為星標”就可以啦!

640?wx_fmt=gif

640?wx_fmt=jpeg

推薦閱讀:

640?wx_fmt=gif

640?wx_fmt=gif