好几年前看了JetBrains的CEO Sergey Dmitive一篇**Language Oriented Programming - The Next Programming Paradigm才开始知道LOP的,当时也试用了MPS,觉得眼前一亮。到现在隔了好几年了,对LOP的具体内容也有点忘记了,而近期在思考OpenExpressApp的模型驱动开发(MDD)方面的内容,所以在这里再次整理一下这方面的内容,这样也会有更多人了解它,下面的内容会参考前面说的那篇**以及其他LOP内容与大家分享下。
LOP和MPS背后的思想并不新鲜,实际上已经出现超过20年了;Language Oriented Programming本身这个词也已经提出十多年了。LOP放弃了传统的基于文本的语言,用创造新的语言来代替类库,可以和编辑器所整合,并且每个程序员都可以创造自己的语言。Martin Flower却对此饶有兴趣,并写了Language Workbenches和A Language Workbench in Action - MPS两篇**进行了介绍。
概述
按照Dmitriev先生的观点,通用语言的问题在于:它们描述领域模型的能力太差。在完成概念性的领域建模之后,开发者们还必须经过一个漫长的编码过程,才能把模型描述为机器可理解的程序,反过来要理解这些代码所描述的领域模型也是同样困难。而DSL虽然能够很好地描述领域模型、解决领域问题,但这种语言又太少了,而且大多数开发者必须苦苦等待少数大厂商为他们提供适用的DSL。很大程度上,这种“语言的失位”造成了软件开发的低效。
Dmitriev先生提出的解决方案就是LOP:借助工具的帮助,允许开发者创建自己的DSL。这样的DSL当然能够最贴切地描述领域问题,从而大大提高开发效率。而且,这样的“自定义DSL”也不必是文本形式的,它可以直接保存为树状结构(或别的结构),并直接以图象的形式展现。
主流编程中三个最糟糕的问题
从理解问题后到实现的时间很长
在明白问题和解决方案后,将解决方案编码到计算机中将会花费很长的时间。这是因为可以使用非常丰富的自然语言表达问题,但我们只能通过通用的编程语言与计算机交流。而现在的编程语言只有几十种,而自然语言表达可以有千万上万种,因此这种转换的成本是比较大的。
在主流编程中,大部分时间都是在“编程”上,这实际上是在用编程层次的抽象术语来表达自然语言的概念,而这是很困难的,没多少创造性,或多或少也是一种时间的浪费。举个例子,今天大量的开发时间花费在面向对象的设计(OOD)上,在程序员表达类、继承、关联等方面这确实是一种还算有创造性的过程,但是使用Language Oriented Programming,OOD根本就不需要。
(个人观点:这个我还不是很了解,我想底层还是需要的吧,有待进一步了解)
理解和维护代码
在通用语言的程序中,很多高度概括的视角、蓝图都丢失了,这不利于我们对产品理解。解决这个问题的传统方法是写注释或用其它形式的文档来记录设计信息和模型信息,但这证明了这是一种脆弱的解决方案,因为它需要编写这些辅助文档的成本、以及文档和代码带来的不同步麻烦等问题;理想情况下,代码应该是自我描述的,我应该只阅读代码本身来理解代码,而不是什么注释和外部的文档。
学习曲线高
OOP很少能够直接表述领域概念,它们必须引入额外的枝节(如一个类的运行时行为)来完成到领域概念的映射。理解这些领域、学习这些类库不是一项简单的任务,我们需要用大量的指南和文档来解决这个问题,但是学习这些将花费大量时间;当一个类库变得复杂的时候,它也变得更难以学习,程序员将因此失去学习它的动机。即使掌握了领域问题和技术的这种复杂映射之后,依然还会很容易的误用类库,因为开发环境(像编译器和编辑器)不能帮助你正确的使用类库。
LOP的切入点
通过计算机改变世界,程序员都希望自己对计算机有完全的控制,但实际上,我们经常被那些不能轻易改变的编程语言和开发环境等基础设施限制。当需要进行一些语言扩展时,我们只能等待语言的设计者去更新它;如果需要我的IDE有一些额外的强大功能,只能等待供应商来添加新特性;就是这些依赖限制了我们完全的自由;当然,程序员也可以写自己的编译器和IDE,但这样将会花费大量的时间和努力,并且并不一定能成功。
LOP的切入点就是允许我们可以创建、重用、修改语言和环境。要理解LOP是什么,可以从下图的主流编程和LOP方法过程进行一下比较,它使得编程阶段已经不是瓶颈了,而转移到了“创建”这一步,作者开发可一个通用的平台(the Meta Programming System)来设计DSL,它允许程序员像现在编写程序一样非常容易的就可以定义自己的语言;这个平台将完全支持LOP,给程序员为程序的每一部分选择使用最合适的语言的自由,而不是将他们绑在某个固定的通用编程语言之上。
|