何为开源EGL，为什么是它？

何为开源EGL，为什么是它？

作者：Tim W Wilson，EGL架构师，EDT项目领导者 （2011/12/25）

翻译：金发华，EDT项目committer；陈樟洪，EDT架构师和committer (2012/01/08)

原文请参见：http://xeglblog.blogspot.com/2011/12/what-is-egl-and-why-should-i-care.html

注：EDT（EGL Development Tool）项目是EGL语言的开源版本，于2011年12月份发布了第一个版本0.7。详细的版本发布消息，你可以参见http://blog.csdn.net/rationalgroup/article/details/7062600。EDT的官方网站是http://www.eclipse.org/edt/

---

        每次有人建议或者推出一门新语言的时候，一个永恒不变的问题是：我们真的需要另外一门编程语言吗？以本人之拙见，在大部分情况下确实不需要，除非它确实跟别的语言有很大的区别。那到底EGL语言为什么与众不同，值得大家关注呢？

        EGL通常只是被描述成一门第四代语言。是的，当EGL只是包含在IBM的产品中，并以一个封闭的黑匣子方式提供给大家的话，这种说法也是合理的。不过现在基于Eclipse的开源版本的EGL并不是把原来的EGL老酒装新瓶重新封装一下，它是以编程语言的方式来表达特定的领域概念，一个完全泛化和可扩展(generalized and extensible)的框架，也提供了可扩展的编译器和代码生成器框架。EGL编程语言本身确实只提供了一套语法和编译器来创建和验证EGL元模型实例。然而真正有意思的地方是那些代码生成器，它们能解释这些模型并生成目标代码。而且任何代码生成器能被扩展以支持新加入的语言模型元素，或者改变既有的代码生成方式而对既有的代码生成器不产生影响。用户也可以自己写一个代码生成器以支持现在EGL不支持的目标运行时（现在EGL提供了Java和JavaScript代码生成器）。一个很好的例子是写一个新的面向Objective C的代码生成器；另外一个扩展代码生成器的例子是基于现有的Java代码生成器进行扩展，使之能理解如何把用户界面应用概念对应到目标Andriod运行时框架。

        这种定义一个模型并使用模型编译器把它们匹配到运行时的方式看起来跟以前的模型驱动开发（Model Driven Development）很相似。在很大程度上是这样的，但是EGL不一样的地方是它是通过编程语言来实现这一切的，包括建模自身，因而也从不需要去编辑生成出来的代码。换句话说，模型就是代码。此外，EDT项目里的工具提供了基于EGL代码调试的功能，而不是生成出来的代码（虽然也有可能需要调试生成出来的代码）。

        EDT项目真正有价值的地方是提供了一个编程语言的基础架构，这个架构下生成的低层次的“汇编”语言是给定的目标平台下广为接受的运行时语言，而不是虚机或者硬件上的二进制代码。当前刚发布的EDT0.7提供了面向基于Web 2.0的C/S(客户/服务器)的业务应用的一种实现，客户端基于浏览器（JavaScript），以及服务器端基于JEE的Web服务（Java）。别的选择也可以被实现，并且基于当前的实现的扩展可以、也将被加进来。

        EGL不是说要来替换现有的语言或者框架，它反而是利用当前既有的和将来会出现的任何新的东西。EGL能够这样做是因为它本身是一门元语言，EGL和第三代语言（比如JavaScript）之间的关系跟传统的第三代语言与汇编语言的关系非常类似。EGL和其他生成第三代语言代码的第四代语言不一样的地方是，暴露给EGL程序员的编程模型是可扩展的，并且将那些编程模型匹配到真正的运行时的代码生成过程也是完全可扩展的。

        那到底什么东西能吸引我们呢？下面是一些例子：

• 所有应用程序层上使用一门通用编程语言
• 采用DRY – 不要重复自己(Don’tRepeat Yourself)原则来实现跨层共享的通用数据结构定义。一个很典型的例子是必须存在于客户，服务器端和批处理语言的数据定义及其验证逻辑。
• 通过更换编译器和重新生成代码，就能切换中间件、框架，甚至运行时平台，而不是刚开始做决定的选择。当然这么做的先决条件是编程模型抽象了给定的框架或者中间件要做的事情的语义。典型的例子是持久化、远程调用、交易管理、业务规则定义和管理等。

        EGL适合任何人和问题吗？不。但是，下面有几种情况EGL是理想的解决方案：

• 面向多平台的技术和必须与既有投资集成的多层应用程序。通过使用这些系统本身的技术来集成来整合这些技术是极度困难的。即便是你有某个可以工作的解决方案，但是所支持底层的技术选择可能随着时间的选择需要做出改变。如果使用EGL来做这个解决方案，它既很易于编程和维护，并且在需求产生的时候很灵活地改变底层的目标技术。
• 使用掌握跨技术领域程序员的灵活性。当前的事实是给指定平台创建应用组件的能力只限于那些精通于该平台下的特定的编程语言的人。虽然拥有这些人是绝对必要的，但并不是说在创建一个商业应用时，就需要掌握应用组件可能部署到的所有地方的平台相关技术。我见过大学刚毕业的孩子能很快写出部署到主机上的应用。我也看到COBOL程序员能创建出Web 2.0C/S应用。这种情况太常见了，以至于懂得业务这项真正重要的技能却不被考虑了。像EGL这样的技术允许公司将这项真正重要的技能利用到开发新的应用上。

        我希望这篇博客能说清楚EGL的某些方面，以及为什么说它不只是另外一门已经就有了的编程语言。人们非常谨慎的选择他们的编程语言，EGL不是试图替代那些选择。简单的说，在当今极端复杂的世界里，有一种能在更高、更有效的抽象的层次上写、管理和维护应用程序的需求，编译技术在这方面一直做得很好。让那些在特定技术方面特别精通的人把他们的知识通过模型编译器表达出来，从而让所有其他人能利用上那些知识。

        在不久的将来，我们将会有地方放这些EDT的“扩展”。这将会是一个很好的展示EDT是如何通过扩展来解决社区里感兴趣的特殊问题的例子。为了使这些扩展的项目达到产品级的质量，那些取得足够多的人感兴趣的扩展将最终会作为EDT的子项目来维护。正是像这样的项目，将展示出真正EDT想展示的本质。