早期约束与晚期约束:比较利弊是什么?

在讨论计算机语言的演变时,Alan Kay说他的Smalltalk最重要的一个特性是后期绑定;它赋予语言可塑性和可扩展性,并允许不适当的耦合随着时间的推移被重构。你同意吗?是否有早期约束的补偿优势可以解释为什么它似乎是两个范式的主导,哪个域可以使用? 基于使用javascript,jQuery,jsext,actionscript,php,java,RoR和asp.net实现Web应用程序的个人经验(不是广泛或深度不具有权威性)似乎暗示了后期绑定和膨胀之间的正相关减少。早期绑定我肯定有助于检测和防止某些类型的安全错误,但自动完成和良好的IDE以及一般的良好编程实践也是如此。因此,在我的风险规避方面恢复我的理性观点之前,我倾向于抓住自己支持后期绑定方面。 但我对如何平衡权衡并没有很好的理解。     
已邀请:
传统上,早期绑定的最大优点是性能:后期绑定语言必须在运行时携带有关其所有数据的类型信息,并且失去了在编译时进行一些优化的机会。然而,随着计算机变得越来越快,并且随着虚拟机更快地进行优化,这种差异变得不那么重要了。     
根据我对高性能软件(例如游戏,数字运算)和性能中立软件(网站,其他大多数)的经验,后期绑定有一个巨大的优势:你提到的可塑性/可维护性/可扩展性。 早期绑定有两个主要好处。首先: 运行时性能 通常被接受,但通常是不相关的,因为在大多数情况下,将硬件投入到更便宜的问题是可行的。当然,有例外(例如,如果您不拥有正在运行的硬件)。 早期绑定的第二个好处: 易于开发 似乎被低估了。在开发人员与其他人的组件一起工作的大型项目中,IDE可以读取早期绑定并使用它们来通知开发人员(使用自动完成,文档等)。这对于后期绑定来说不太实用,因为绑定是在运行时创建的。如果IDE可以从代码中推断出结构定义,那么仍然可以使用后期绑定语言,但由于结构总是可以在运行时更改,因此它不那么可靠。 易于开发是一件大事。它最大限度地减少了昂贵的程序员时间 - 而且您的开发团队越大,它就越重要。你需要平衡这与后期绑定语言的灵活性。     
早期绑定与后期绑定实际上是语言架构的一个功能。早期绑定意味着可以构建代码,其中机器指令只是跳转到一个地址并从那里开始执行(可能通过查找表)。后期绑定需要为每次访问查找符号和类型引用(通常是哈希表查找),这会降低语言速度。 虽然一些基于VM的语言(如Java)是早期绑定的,但本机机器代码只能直接进行早期绑定。要做后期绑定,它必须像动态语言解释器那样进行相同类型的哈希查找。然后,后期绑定需要执行一大块代码来获取地址(这就是OLE自动化的工作方式)。它不能由CPU直接完成 - 必须执行代码。 请注意,执行后期绑定的代码实际上在哈希查找功能中具有自己的早期绑定分支目标,依此类推。因此,从这个角度来看,早期绑定对于任何直接由CPU执行的代码都是必需的。后期绑定必须在软件中完成。 早期绑定对于各种各样的代码优化也是必要的。 像C这样的架构在编写接近金属的代码时有一个好处,就像它一样。在您想要这样做的地方,早期绑定方面几乎是语言架构所固有的。在诸如Python的后期绑定语言中,后期绑定也是固有的。有些语言提供了这两种语言,但所使用的特定类型将与正在执行的特定构造相关联。     
延迟运行允许运行系统自身扩展。例如,系统开始了解狼群。随着时间的推移,一个evolveDomesticate()方法,在Wolf(?)中,旋转一个名为Dog的新类并实例化它,我们现在有了Dogs。 Smalltalk将保存整个SYSTEM映像,因此如果关闭并重新启动,Dogs在重启后仍然存在。一旦你发展到在特定硬件上运行并在网状网络中连接的对象,整个生态系统就不会真正关闭(直到Sun爆炸)。我认为这就是Alan Kay谈论后期约束的优势,成为一个上帝。     
我认为有更好的方法/模式可以避免不适当的耦合,例如控制反转,依赖注入,工厂,...... 但是,我喜欢后期绑定的“易于使用”版本独立性 只是用
var excel = CreateObject("Excel.Application");
和后期绑定将弄明白,什么样的Excel.Application,以及从哪里获得它...     
在编译期间执行链接的编译时绑定称为早期绑定 动态绑定,其中在调用函数时执行期间执行的函数的链接称为后期绑定     

要回复问题请先登录注册