※ 引述《Eventis (何逸凡)》之銘言： : ※ 引述《reader (讀者)》之銘言： : : 這大概是最白爛的做法了。但很多情況是得在執行時期處理的。 : @.@ : 沒想到真的得在執行期來做這個東西Orz..... : 我腦子裡只晃了晃這個怪物,就自動略掉了. : 真的在runtime才能處理的東西, : 除非語言中具備有特殊的提示或寫法, : 否擇語法結構/語意上對於實作所能提供的改善幾乎沒有. : 能採取的最佳化策略,在原有的語言上也是可以做, : 那定義這樣的語言能帶來額外的優勢嗎? 我們並不是隨時都需要效能的，很多時候還需要別的軟體品質和特性。 例如生產力、延展性、學習成本等等。 現在的狀況是，我們常常用很多種語言去完成一件事，但如果它們能 整合在一起，效能的最佳化由系統協助完成，那麼語言的壁壘就能夠 減少許多。 比如說，當我們使用 script 寫作時，有多少部分一定要用解譯程式 才能處理? 其實不多吧，寫完之後如果要提昇效能，是不是一定得要 換一種語言重寫? 而以前在寫 C++ 時，會不會有時候覺得某些地方 使用其他語言更為方便? 如果它們是單一語言，就不會有這個問題了，而能夠自然地結合起來。 需要 first-order function 時，往往是需要極大彈性之時，用其他 方法來做，反而會變得更複雜，效能的提昇卻很有限，不如就專注在 程式結構的完善上。 不要說這東西沒有用，那東西沒有效率，一些特性加起來就是不一樣。 就程式語言理論而言，沒有 first-order function, 沒有 delegation, 沒有 meta-class, 沒有 actor, 一些重要特性 C++ 全都沒有，其實 是很不完整的程式語言，這將造成在軟體彈性上過度依靠動態繼承， 程式設計上會產生很大的累贅。 而且其實啊，我的原始設計是沒有 keyword 的, C-style 的程式語言 是用基礎語言模擬出來的產物，例如 if...else, for, while 等等， 在最底層都是可以用 first-order function 做出來的。那才是其中 最為精巧的部分。 : : 這這... 我從來沒覺得 rpc 或 web service 強大或好用過... : : 五年前申請一半的專利就是網路軟體元件自動耦合連結了... 而在 : 對不起 ,是我太亂來了 <(_._)>.... : 我想到那是什麼東西了....>.< : : 十年前，我的天才學弟去留學前的臨別筆記，也就提到了，到現在 : : 我想做的東西，只怕還沒超過他當年的規劃和想像太多。 : : 基本上，只要有一個最基本的支援平台，這一點也不困難。 : 介面整合,module coupling的問題,也不難處理嗎? : (這個部份只有聽老師有如介紹夢想般的帶過去一下下 : 程式內的模組都透過網路堆砌完成的樣子@@) 這沒有想像中的難，關鍵只是在效能和彈性的取捨上。 比較極端的，有把元件都視作黑盒子，用功能網絡來決定的，簡直就是 超大類神經網路，也有全然層級式，和繼承結構沒兩樣的死硬做法。 不過就現實來說，透過名稱、架構、語境的耦合，加上一些認證、信任、 信用體系，其實在單一系統之內就夠用了，太純粹的結構，都會很麻煩， 單一演算法總是很難處理好所有狀況，多重決定的雞尾酒式解法，將會是 很容易達到效益的較佳做法。 實作和理論之間往往是有斷裂的，一個科技創新者，就是要在其中找到 機會。 : : 完全內建和外加是不一樣的。這要做過才知道，如果系統中的物件都 : : 能自主動作，程式設計的概念都會不一樣了。 : 我完全贊同這一段. : : 而當這些物件可以遊走於不同機器時，在程式設計上卻會是一模一樣， : : 當物件能夠自行昇級改版，我們還是可以使用同樣的程式碼持續性地 : : 運作時，那麼它的威力就更會顯現出來。 : @@;;;; : 等等..... : C++的object code不是有平台相依性@@ : 怎麼確保portability@@? : 每port一次就從頭compile一次@@? native code 一般是不能直接傳遞的，它得經由原始碼轉化為 op-code 或是以 script 形式才能傳遞，要不要再編譯，那是另一回事了。 簡單來說，程式語言層次只提供執行 op-code, script 和 macro 的能力， 而這些都是 portable 的，這樣就夠了。 只要 code, script, macro 都完全相容，其中要怎麼轉換怎麼處理，就是 軟體工程師的創造力的發揮空間了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.222.173.26