※ 引述《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