AppleScript類天然語言與非英語語法設計

最先知曉是以前C#中文版的github討論裏提到了AppleScript有多語言版. 昨天想起, 以爲它畢竟是爲數很少(僅有的?)大公司開發的非英語語法的編程語言, 不由好奇它的前世此生. 因而做了一點調研.php

網上相關資料很少, 最先的一本AppleScript專著"AppleScript in a Nutshell"也是2001年出版, 已經到了Mac 9. AppleScript Not Necessarily in English 提到早先支持日語,法語, 還討論過"a C dialect", 不知指哪一個語言, 但在Mac 8.5版就放棄了(1998年左右)git

接着有幸找到了2006年的論文"AppleScript", 更多介紹了多語言支持以及相關問題. 這篇論文其餘內容也頗有價值, 包括這個項目的起源, 相關項目, 以及這一語言系統從需求分析到實現的各階段細節. 本文只關注非英語語法部分, 對項目自己有興趣的不妨自行細閱.程序員

下圖是不一樣"語種"(英語, 日語, 法語, "專業")的示例代碼:github

文中總結的貼近天然語言語法的語言設計的問題:shell

The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. It was assume that scripts should be presented in 「natural language」 so that average people could read and write them. This lead to the invention of multi-token keywords and the ability to disambiguate tokens without spaces for Japanese Kanji. In the end the syntactic variations and flexibility did more to confuse programmers than to help them out. The main problem is that AppleScript only appears to be a natural language. In fact is an artificial language, like any other programming language. Recording was successful, but even small changes to the script may introduce subtle syntactic errors which baffle users. It is easy to read AppleScript, but quite hard to write it.編程

When writing programs or scripts, users prefer a more conventional programming language structure. Later versions of AppleScript dropped support for dialects. In hindsight, we believe that AppleScript should have adopted the Professional Dialect that was developed but never shipped.安全

Finally, readability was no substitute for an effect security mechanism. Most people just run scripts — they don’t read or write them.markdown

大體是說, 類天然語言語法(包括英語和日語, 不知爲什麼沒提法語)的嘗試失敗了. 爲了實現接近天然語言的語法, 引入了多token的關鍵詞(猜想是相似於"在...中"這樣的用法), 以及日語的無空格語法. 問題是, 這樣"貌似"天然語言而實質仍然語法嚴格的後果之一是, 用戶誤認爲小的改動, 其實會致使詞法解析的大變化. 也就是**"易讀而難寫"**. 另外一個結論是, "Professional Dialect", 即接近Java的語法被認爲是最應該被保留的, 由於它最接近傳統編程習慣.app

最後一段的意思是, 即便代碼可讀性好, 也不能取代一套有效的安全機制. 由於大多數人在運行腳本以前, 並不會先讀一遍, 確認它是否安全. 我的認爲這個結論對語言設計的借鑑價值有限, 由於安全機制和可讀性應該沒有直接矛盾.編程語言

關於文中提到語法近天然語言致使的問題, 我的認爲與目標用戶羣有關. 文中提到"The language was primarily aimed at casual programmers."以及"make it accessible to non-programmers", 可見它的設計初衷和推廣目標都是非專業程序員, 而他們是最容易將天然語言和程序語言混淆的. 這個問題一樣能夠適用於今天, 雖然技術上程序語言語法能夠引入更多天然語言元素. 這也許是多數最新的通用型英語編程語言(求反例)仍然與天然語言保持至關距離的一個緣由.

話雖如此, 現今的人機交互已經愈來愈普及, 即便是通常用戶, 對手機喊命令的時候也會清楚是對一個只懂得簡單語法的機器說話. 隨着大衆適應的過程, 上面這個混淆的問題也許會不那麼嚴重. 我的猜測, 編程語言的趨勢仍是逐漸向靠近天然語言的方向發展, 尤爲是適用於大衆編程的語言.

再回到開頭的那個討論, 提到AppleScript時將這一功能的失敗歸因於關鍵詞/語法支持多語言致使腳本內容混亂:

But it found limited adoption and where it was adopted scripts became a mess of mixed languages and Apple eventually dropped support.

回頭看是須要考證的, 由於看起來最大的問題在於當時相似天然語言的語法, 即便只使用單純的英語語法.

2018-02-04

相關文章
相關標籤/搜索