=== 2008/07/01 ===
以下這篇文章是回覆符式協會內討論時我寫的：
我前些時候也考慮使用 lua ，最後我使用 forth 於我目前的計劃中，有以下幾種原因：
1. lua 使用圾垃收集，但是在 realtime 時不能做垃圾收集。我很難在 realtime 時關掉 lua 的圾垃收集。
2. 我使用的高階物件導向語言（編譯式的) 本身就有垃圾收集，lua 又有自己的一套。這兩套要協同運作會讓我頭疼。
3. 我已經很熟 forth ，可以完全掌握我要它走的方向。但是 lua 的方向不是我能掌握的，聽說過去常常發生程式界面改變造成不相容的問題。
4. 速度。比較起來，forth還是比其他的 scripting language 速度快。
因此我在尋找了幾年後最終還是回到 forth 。這之間我考慮用過 lisp, python, scheme, ruby, lua。本來根本不想用 forth ，最後還是回到 forth ，只因上列幾點。最後確定自己的選擇是正確的。很可惜沒在三年前做下這一個選擇。
Forth 不是萬靈丹，但是有時就是沒得選，只有它合用。
Forth 和其他語言尤其是 c 語言的相容性不足，的確限制它在接受的程度。但是光改變這個並不能讓它被更多人接受。FICL 已經做過這樣的嘗試了。不必去煩惱如何讓forth被更多人接受，不如換個想法，想想如何讓 forth 對自己更有用。這種自私的想法很可能才是最適合 forth 的玩家。因為，每一個人都有能力寫出自己的 forth 。
現在的我完全放棄 forth 會被很多人接受的想法。也放棄了會有某個人長期維護我使用的 forth 的想法。以 retroforth 為例，在 10.0 版之前有過一兩年未曾維護的時期。因此，必須抱著「使用 forth 於產品開發時，要能自己完全維護」這樣的心態來選擇
forth 。這是我目前選擇 ATLAST 的原因。因為我知道我可以做到自我維護這點。雖然它比較舊，不合 ANS 的標準。同樣的，我覺得 FICL 也很不賴。它沒再維護，不如說它已經實現了作者的期望了。
架構在我目前選擇的 ATLAST 上，我加上了物件堆疊以和其他物件導向編譯式語言溝通。但我不要物件導向的 forth，那條路我十八年前走過，沒有必要，不是 forth 擅長的。未來我還想做的就是為 forth 加上一件非後位運算的外衣。比如，讓它的文法看來和 lua 一樣，當 forth 只是一個 virtual machine，最後，我很可能為了追求更高的速度將這個 virtual machine 以 LLVM 改寫。你可以說，那就不是 forth 了。但只要產品成功，最後它是不是 forth 並不重要。
所以，forth 對我來說就是一個可以變化的語言。只要我放棄有人會維護它的想法自己擔起維護它的責任，它可以隨我產品的需求一直改變。它很簡單，是一個很好的起點，雖然不一是終點。由於有很多種不同的 forth ，我可以選擇一個適合我的起點，不斷改進它。
另一篇文章中提到 labview、plc 有關 forth 的構想。我相信若現實中真的感受到那需求， 在這個領域，forth 很可能個好選擇。我不開發韌體。也不懂 labview。但是我想 mcusir 是想使用 labview 的簇來實現 forth 的 virtual machine，也就是實現 forth 的 internal interpreter。那麼，可以參考
http://www.ece.cmu.edu/~koopman/stack_computers/index.html 這本書。或是選擇一個最簡單的 forth ，這兒大家都懂的，比如 eforth ，自行揣摩 internal interpreter 的設計，改寫成 labview 的語言。
