Re: [連結] 下一個主流語言?遊戲設計者的觀點

看板PLT (程式語言與理論)作者 (讀者)時間17年前 (2007/03/05 16:17), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串2/3 (看更多)
※ 引述《noctem (noctem)》之銘言: : http://lambda-the-ultimate.org/node/1277 : Tim Sweeney 在 POPL 給的演講,從遊戲設計者的角度談他所 : 心目中的下一個程式語言應該有的能力。提到的幾點包括 : . 用型別排除大部分的 runtime error. 包括用 dependent : type 來避免 array bounds checking; : . 他認為 garbage collection 是絕對必要的(之前在 programming : 板上好像有不同的看法?); : . 對 concurrency 多支援,他認為這和 type 是相關的; : . 認為 "lenient evaluation" 可能是另一條路。 上述需求幾乎都不是程式語言應該要做的事情,而是 runtime environment 需要做的事情。 我覺得現在的問題是,在作業系統和程式語言之間,需要一個更有效的中介 機制的實作方法,如果都算在程式語言當中,程式語言將無法提供一個穩固 有效的程式設計基礎。 這樣一來,就會變成每個大家覺得重要的東西,都會有人想要塞進程式語言 當中,程式語言愈來愈龐大,愈來愈像作業系統,這樣總有一天會爆炸的。 而我設計的程式語言,就加上了 domain 的設計,每一個 domain 的內容, 就會由 domain handler 在編譯和執行時處理,於是可以自行設計特殊語法 及動態機制,想要加什麼功能都可以,因為 domain handler 就等於是小型 編譯程式,將自行設計的特殊語言轉換為基礎語言。 這在 C++ 就提供了,只是不夠完全,只提供 single operator 層次而已, 但上述的 boundary checking, garbage collection 已經可以自行實作。 而 Perl 6 的 macro 也很強,跟上述的 domain handler 相當接近。 就是有一堆不開發程式庫或使用專業程式庫的懶惰程式員,在成天叫著程式 語言不夠好用,希望程式語言什麼東西都內建。 這些執行時期機制,不應該是由新程式語言來提供,而是讓新程式語言能夠 自行建立執行時期機制才對,讓有新的執行時期機制需求之時,不必去更換 新的程式語言,而是擴充既有的程式語言即可。 : 不知道為什麼他覺得 Haskell 語法很 "scary"... 就是不熟悉吧。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.222.173.26
文章代碼(AID): #15wz8fAM (PLT)
文章代碼(AID): #15wz8fAM (PLT)