最早知曉是 "之前C 中文版的github討論" 里提到了AppleScript有多語言版. 昨天想起, 覺得它畢竟是為數不多(僅有的?)大公司開發的非英語語法的編程語言, 不禁好奇它的前世今生. 於是作了一點調研. 網上相關資料不多, 最早的一本AppleScript專著"AppleScript ...
最早知曉是之前C#中文版的github討論里提到了AppleScript有多語言版. 昨天想起, 覺得它畢竟是為數不多(僅有的?)大公司開發的非英語語法的編程語言, 不禁好奇它的前世今生. 於是作了一點調研.
網上相關資料不多, 最早的一本AppleScript專著"AppleScript in a Nutshell"也是2001年出版, 已經到了Mac 9. AppleScript Not Necessarily in English 提到早先支持日語,法語, 還討論過"a C dialect", 不知指哪個語言, 但在Mac 8.5版就放棄了(1998年左右)
接著有幸找到了2006年的論文"AppleScript", 更多介紹了多語言支持以及相關問題. 這篇論文其他內容也很有價值, 包括這個項目的起源, 相關項目, 以及這一語言系統從需求分析到實現的各階段細節. 本文只關註非英語語法部分, 對項目本身有興趣的不妨自行細閱.
下圖是不同"語種"(英語, 日語, 法語, "專業")的示例代碼:
文中總結的貼近自然語言語法的語言設計的問題:
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.
大致是說, 類自然語言語法(包括英語和日語, 不知為何沒提法語)的嘗試失敗了. 為了實現接近自然語言的語法, 引入了多token的關鍵詞(猜測是類似於"在...中"這樣的用法), 以及日語的無空格語法. 問題是, 這樣"貌似"自然語言而實質仍然語法嚴格的後果之一是, 用戶誤認為小的改動, 其實會導致詞法解析的大變化. 也就是"易讀而難寫". 另一個結論是, "Professional Dialect", 即接近Java的語法被認為是最應該被保留的, 因為它最接近傳統編程習慣.
最後一段的意思是, 即使代碼可讀性好, 也不能取代一套有效的安全機制. 因為大多數人在運行腳本之前, 並不會先讀一遍, 確認它是否安全. 個人認為這個結論對語言設計的借鑒價值有限, 因為安全機制和可讀性應該沒有直接矛盾.
關於文中提到語法近自然語言導致的問題, 個人認為與目標用戶群有關. 文中提到"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.
回頭看是需要考證的, 因為看起來最大的問題在於當時類似自然語言的語法, 即使只使用單純的英語語法.
