當前位置:編程學習大全網 - 編程語言 - 易語言真有那麽垃圾嗎?

易語言真有那麽垃圾嗎?

簡評中文編程語言

中文編程,或者漢語編程,不是什麽新鮮事物,用“非英語編程語言”來進行編程也並非只有中國才有,這裏有個叫“nadeshiko”的日語編程開發工具:/p/nadesiko/,我相信還有很多其它“非英語”編程語言,有興趣的可以看看。

沒用過中文編程語言可以試試,國內有很多類似的東西,要指出的壹點是,中文編程語言的所謂“輸入的問題”沒有想象中的困難,它們往往自帶壹個開發環境,只需要輸入壹個詞語的拼音首字母即可完成輸入(比如輸入b就會彈出壹個補全菜單,裏面有“播放音樂“、”保存頁面”等等選項,和妳在常見IDE裏按下.看到的壹樣)。

編程語言

計算機本不認識語言,而僅僅認識數字,然後根據壹定的規則在存儲器之間傳輸處理好的數字,人類按照機器底層的特性進行編程難度是非常大的,但是按照自然語言指示機器該做什麽可以嗎?首先是機器無法識別人類的自然語言,其次大部分人類自然語言無法表達清晰的邏輯。所以壹些人進行了折中,設計了所謂編程語言的東西。編程語言是壹種形式語言,用壹系列的符號在計算機識別能力範圍內和人類表達邏輯範圍內尋找不同的平衡點。根據編程語言所處環境不同、設計目標的不同、編譯器實現者能力不同等等因素,不同的變成語言所取的這個平衡點也不同。

以C語言為例,C語言所處的環境是,軟件用匯編語言開發無法在各個不同硬件上移植,但是那個時期的硬件往往性能都比較低下,所以出現了剛好計算機編譯器(早期是解釋器)能識別(編譯或解釋),同時滿足了當時開發操作系統直接操作內存的需求(具備有算術運算能力的指針)。如果妳細心點可以發現C語言的很多特征迎合了那個時代的需求,C語言裏有register、auto、inline關鍵字,說明當時的編譯器水平很差,還不能做到高效處理寄存器分配和內聯。int、short、long、char、unsigned、signed等等也恰恰描述了那個時代寄存器處理的數字常見類型有哪些。

中文編程語言

再以某個中文編程語言為例,寫壹個Hello World程序:

#包含 "某語言系統.接口"

整數類型 主函數()

{

輸出("妳好世界");

返回 0;

}

其實本質和C語言:

#include <stdio.h>

int main()

{

printf("Hello World");

return 0;

}

外形幾乎沒有區別,能看得到的區別也就在關鍵字和標誌符被“漢化”了。那麽這些漢化到底能對“不懂英語”的人起到多少幫助呢?可以嘗試拿上面的“中文版C語言程序”給壹個沒學過編程的人看,他幾乎是不可能看懂的,也不可能立即用這種語言寫個其他類似的程序,因為漢化了的那幾個關鍵字和標誌符盡管寫成了漢字,但還是沒有描述他們在實際的計算機程序中表示的是什麽。比如#include ,#開頭的往往是預處理宏,而預處理宏程序的功能是在編譯前對程序進行的所謂預處理,比如include功能就類似與把stdio.h裏聲明的東西都“復制”到當前文件,使得當前文件可以看到stdio.h裏的函數原型等等內容。而int表示的是整數類型,或者說當前計算機系統C語言編譯器認為的默認寬度的整數類型,而不是無限精度的任意整數類型。那麽把這兩個換成“包含”和“整數”類型之後呢?包含的含義和include的含義還是相同,理解了include處理過程的人(或者僅僅理解它有什麽作用的人)固然是會毫無顧忌地寫下這行代碼,而不懂的人還是不會寫,其他的標識符和關鍵字的漢化也是壹樣,說到底,關於寫程序的人,不是因為理解了這些符號在中文或者英文中的含義所以才會用中文或者英文編程語言寫程序,而是因為他理解了這些符號在這個計算機系統和編程語言環境裏的含義。

不要覺得這兩種語句幾乎壹模壹樣語言對應起來很搞笑,其實很多所謂“中文編程語言”真的就是在預處理器上改改,把關鍵字和標準庫的壹些函數弄成中文,然後做個圖形界面的開發環境就發布了,沒有什麽非常重大的科技含量。它們的底層(尤其是後端)本質還是現有常見編程語言的常見實現(比如GCC或者Mono之類的),有的甚至在不遵循自己引用的開源軟件許可證的情況下,閉源還賣錢。

編程語言的目的

我們為什麽要使用編程語言?因為用機器能識別的機器語言寫代碼太痛苦、而且沒有移植性。我們想用編程語言做到的是什麽?是在壹個更高層次清晰地描述希望計算機執行的邏輯。而描述邏輯的過程無論是使用“整數”還是“Int”、或者“int”、“Int32”、“Integer”,難度並不會降低,中文編程僅僅是讓壹些腦子中有定勢“我不會英文、所以中文能幫我學會編程”的人第壹眼看上去害怕的程度稍微降低壹點點,壹旦學會了那幾個關鍵字或者業務相關標識符相關的中文,之後的整理和表達邏輯的過程難度絲毫不會減輕,而這個“之後”,也就是學習這幾個關鍵字和標識符的時間可能占整個編程的時間的99.99%,我們可以說中文編程僅僅減輕了這部分人0.01%的負擔。

中文編程的害處

有人說減輕了壹部分人0.01%的負擔還不錯,還算是改進,但是為了這0.01%的“改進”,又產生了其它更加嚴重的問題。

(1):編程語言實現的匱乏

這些所謂中文編程語言的實現和維護者往往是個人和非常小的公司,而且以自己的實現來定義語言,他們往往不會開源,壹旦這些個人不打算繼續維護、或者該公司倒閉,則該語言寫出的代碼能運行的平臺就僅僅被鎖定在最後壹個實現的發布,而且以後也不會再添加新特性和新功能了,用該語言寫的代碼幾乎沒有未來的發展余地。

(2):庫和其他支持的匱乏

中文編程語言用戶少,而且僅有的用戶還往往連那普通編程語言的幾個英文關鍵詞都害怕學習,更不可能開發高質量的、尤其是底層的庫,於是編程語言的維護者和少量的高級用戶只能擔起開發庫的重擔,大部分庫來自封裝操作系統的API、常見功能的庫(比如MP3播放、XML解析)的封裝,但是這些庫是非常不夠的。

(3):交流的困難

就如我們在國際性的論壇和irc交流使用英語壹樣,這些論壇和irc的用戶除了中國人之外還有大量非英語國家的人,我們使用英語不是因為英語這語言非常精確、非常優美,而僅僅是因為英語用戶多,已經幾乎是國際語言了,大家都多少會點,交流起來非常方便。而使用這些非主流的中文編程語言則會使得自己和大家交流“沒有***同語言”。

結語

我到這裏結論已經很明顯了,總結壹下就是:所謂“中文編程語言”解決的問題不多,但是帶了很多麻煩。如果有讀者屬於僅僅是因為認為自己不會英文而選擇這些“中文編程語言”,請理解“編程語言的目的和編程的真正的難度在於描述邏輯,而不是關鍵字和標識符字面上所對應的自然語言”,然後嘗試壹下自己害怕的“英文編程語言”,買壹本優質的學習該編程語言的圖書,相信會很快發現,英語真的不是問題。

  • 上一篇:近幾年的新型職業有哪些?
  • 下一篇:切實重視高中信息技術理論課的實效性_信息技術手段教學實效
  • copyright 2024編程學習大全網