一些個人建議，僅爲有志於設計和實現中文編程語言的開發者作參考。
編程語言，是開發者爲了實現某個具體功能，使用的工具。
因此它應該將目標開發者羣體的用戶體驗放在首位。
JetBrains 首先是開發了 IDE，在過程中發現 Java 的各種不便才設計了 Kotlin。
個人認爲，編程語言設計不應只單純考慮編程語言本身而已，而是應該將開發者體驗、生態建設、甚至軟件工程綜合考慮之後，得出的一整套設計。
從小處說，比方語法中的中文關鍵字，早先有過討論，已見過至少三個項目（CTS、LingaScript、草蟒）中的風格是儘量使用兩個字作關鍵字，比如”如果/否則/結束“等等。除了順口之外，這種設計的一個好處是（最近才發現）利於視覺上的齊整。當然，個人對所有設計都持開放態度。之前做了這個中文關鍵詞替換體驗頁面原型的目的也就是可以非常迅速直接地測試不同關鍵詞對於開發者的視覺體驗。
另一個常被忽略的方面，是編程環境對開發者的反饋。尤其是編譯器的報錯/警告信息，個人認爲至今都還處於非常原始的階段。對於新手開發者來說，各種如同天書一樣又”言簡意賅“的報錯信息幾乎無法通過自己理解來找到問題所在。作爲中文編程語言，自然應該將反饋信息的本地化放在最高優先級。之前的擴展Python控制檯實現中文反饋信息所作的僅是最簡陋的直譯。如果是自研的編程語言，當然可以自行設計更加易於開發者理解的語句，或者其他形式的提示（最講究用戶體驗的網頁設計可能是個很好的參考）。
如何通過最平緩的學習路徑使開發者上手也應該納入設計考慮。現在的一種方式是通過 IDE 提供模板或者例程，但其實語言設計者本身對“該如何更有效合理地利用我的編程語言”有很大的發言權。或者說，在語言設計時，就應該有了一個全面的認識。這也和既然開發新中文編程語言離不開API, 何不從開發API開始呢? 更進一步, 何不從例程開始呢?一文中在設計之初就從例程着手異曲同工（也可以對例程的視覺效果進行用戶體驗調查）。能否將一套利於新手上手、老手提高效率的模板、例程納入編程語言一道發佈呢？
對中文編程語言來說，在例程選擇方面，應儘可能揚長避短。應該儘可能發揮可讀性強的優勢，使用語義豐富的代碼進行演示。比如編程也可以走中國風。即使要演示算法相關代碼，也可以改進一些標識符，使之更具有語義也更易理解，比如：中文代碼示例之冒泡算法, 後感。也可以與英文代碼進行對比，以顯差別：中英文代碼對比系列之Java一例。哦對了，還有，用於公開演示的，一定儘量帶語法高亮，這樣看起來”炫“的多。
關於生態建設，如何能利用現有編程語言的生態自不在話下。如何快速進行生態建設是個大課題。從立創EDA，Gratipay看中文編程開發環境和推廣運營的一個趨勢的第一部分和潛力需要分享來加速挖掘：大疆機甲大師Python開發兩週感想之一供參考。
對於中文編程語言來說，也應考慮中文 API 的特性如何與編程語言設計結合，這也是用戶體驗的重要部分。前文一種改進中文 API 可讀性的方法：參數不限於在末尾和開發中文 API 的一些策略僅作參考。
關於軟件工程，用最小的代價在儘量早期獲得對代碼的診斷和反饋已經是公認的趨勢。比方說 IDE 用各種手段對代碼進行靜態檢查等等。那麼編程語言設計時，也可以將如何使這種檢查更加簡易納入考慮。
還有 TDD 這一可以改進代碼開發效率的手段，是不是也可以將自動測試框架部分融入語言設計中，省得用戶選用各種第三方開發相關框架的麻煩？
剛想到關於文檔方面，編寫代碼時同時編寫說明，之後通過自動提取說明部分生成文檔，已是常見的實踐。也許編程語言也可以對這一功能提供支持？
當然，所有這些都考驗編程語言該“操辦”多少內容的問題。可以在實踐中總結和演進。
最後，望設計者們既要有堅持初心的毅力，但也儘量將快速開發的思路引入編程語言設計實現中。以儘可能小的工作量試錯，以儘可能小的迭代進行自我改進，儘早建立用戶/興趣者社區（比方說通過發佈例程）。不要太指望“一鳴驚人”，而是穩紮穩打。再小的用戶羣也好，儘早建立穩固活躍正能量的的小社區，比鬆散又噪聲/內耗極大的社區有價值的多。
還有，絕對不用追求語言特性的“高大上”，用 10% 的代價滿足 90% 的需要，對於後發者來說是更加合適的第一步。
祝各位新年快樂，身體健康，萬事如意。