在主流编程中，大部分时间都是在“编程”上，这实际上是在用编程层次的抽象术语来表达自然语言的概念，而这是很困难的，没多少创造性，或多或少也是一种时间的浪费。举个例子，今天大量的开发时间花费在面向对象的设计（OOD）上，在程序员表达类、继承、关联等方面这确实是一种还算有创造性的过程，但是使用Language Oriented Programming，OOD根本就不需要。

（个人观点：这个我还不是很了解，我想底层还是需要的吧，有待进一步了解）

作者:: 老哇的爪子 Attilax 艾龙， EMAIL:1466519819@qq.com

转载请注明来源： http://blog.csdn.net/attilax

1.2. 理解和维护代码

在通用语言的程序中，很多高度概括的视角、蓝图都丢失了，这不利于我们对产品理解。解决这个问题的传统方法是写注释或用其它形式的文档来记录设计信息和模型信息，但这证明了这是一种脆弱的解决方案，因为它需要编写这些辅助文档的成本、以及文档和代码带来的不同步麻烦等问题；理想情况下，代码应该是自我描述的，我应该只阅读代码本身来理解代码，而不是什么注释和外部的文档。

1.3. 学习曲线高

OOP很少能够直接表述领域概念，它们必须引入额外的枝节（如一个类的运行时行为）来完成到领域概念的映射。理解这些领域、学习这些类库不是一项简单的任务，我们需要用大量的指南和文档来解决这个问题，但是学习这些将花费大量时间；当一个类库变得复杂的时候，它也变得更难以学习，程序员将因此失去学习它的动机。即使掌握了领域问题和技术的这种复杂映射之后，依然还会很容易的误用类库，因为开发环境（像编译器和编辑器）不能帮助你正确的使用类库。

1.4. 扩展性烂

当需要进行一些语言扩展时，我们只能等待语言的设计者去更新它；如果需要我的IDE有一些额外的强大功能，只能等待供应商来添加新特性；就是这些依赖限制了我们完全的*；当然，程序员也可以写自己的编译器和IDE，但这样将会花费大量的时间和努力，并且并不一定能成功。

1. Coc

2. Dsl

3. DSM

4. 4gl

5. 产生式编程(Generative Programming,GP)

因为我们平时写程序一个非常大的苦恼就是领域知识已经深深的隐藏在代码中，而任何一个领域知识的变动对程序来说就是无休止的改动和调试。而产生式编程却可以做到以代码的形式清晰的表现领域模型。

是一种软件工程泛型(paradigm)，基础是对系统族建模。就是说，给一个特定的需求说明书(specification)，就可以根据要求制作出一个高度定制、优化的中间产品或者最终产品。这需要使用基本的、可重用实现组件通过配制知识的方式实现。

在软件中，向自动化制作软件的方向转变需要经历两个步骤：

1. 把焦点从开发一个系统转移到开发一个系统族上来：开发出正确的共性组件

2. 使实现组件的装配自动化：使用产生器达到自动化

　　我感觉它可以作为产品线工程的一种软件工程方法，产生式编程就是设计实现组件，使之适应于通用产品线结构，同时对配置知识建模，强调如何把抽象的需求转变成特定的组件群，并且使用产生器实现配置知识，通过这些工作来解决前面说的高复杂性、高效率和高质量等问题。

GP的目标集中于系统族，而不是一种一个的系统（one-of-a-kind system），它不是从头构造一个单独的系统族成员，而是基于一个通用的产生式领域模型。模型由三部分组成：

1. 指定系统族成员（问题空间 problem space）

2. 组装出每一个成员的实现组件（解空间 solution space）

3. 在问题空间和解空间之间的配置知识映射关系（配置知识）

5.1. 为重用而开发以及使用重用的开发

产生式编程是生成的，如：AOP（AspectJ），DSL（Drools）

产生式编程是组合的，

1.产生式是自底向上，而声明式是自定向下。即产生式编程用的思路是组合概念（用小粒度的概念组合生成大粒度的概念），

而声明式编程是解析概念，用统一的概念来理解，把不同差异性交由具体程序解析。

2.声明式编程的编辑器生成的是xml文件，将由框架程序解析；而产生式生成程序代码，不做解析运行。

3.由于1，导致元数据模型不一样，产生式是相对细粒度的，而声明式是粗粒度的（不能直接比较大小，定义的是无差异性的概念）。如Ant，jbpm都是很大的概念。

6. 在模型驱动开发（MDD）介绍MDA

7. · 元编程

编写元程序的语言称之为元语言。被操纵的程序的语言称之为目标语言。一门编程语言同时也是自身的元语言的能力称之为反射或者自反。

反射是促进元编程的一种很有价值的语言特性。把编程语言自身作为一级数据类型（如LISP，Forth或Rebol）也很有用。支持泛型编程的语言也使用元编程能力。

元编程通常通过两种方式实现。一种是通过应用程序编程接口（APIs）将运行时引擎的内部信息暴露于编程代码。另一种是动态执行包含编程命令的字符串表达式。因此，“程序能够编写程序”。虽然两种方式都能用于同一种语言，但大多数语言趋向于偏向其中一种。

最常见的元编程工具是编译器，它可以将程序员使用高级语言编写的相对短小的程序转换为等价的汇编语言或者机器语言程序。这是最基础的编程工具，在大多数情况下，直接编写机器语言程序是不太现实的。

在程序中嵌入直接处理程序数据的解释器即可实现这一目的。现在已经有一些用于常用高级语言的实现，例如RemObject为Object Pascal编写的Pascal Script。

另一个很常用的元编程例子是lex和yacc，这两个工具用来生成词法分析器和语法分析器。Yacc通常用作编译器的编译器，生成能够将高级语言转换为机器语言的工具。

8. 意图编程

财务人员看见电子表格软件的时候眼睛发亮，我想当程序员看见可用的意图编程工具的时候也会发亮的。

意图编程的提出者也是“所见即所得”文档编辑的发明人。

他说“目前，编程正好和开采钻石过程相反，在开采钻石时你挖出大量的泥土,而找出一点点昂贵的钻石。可编程时，你从一个有价值的真正意图开始, 随后却把这种意图埋在泥土中”。

喷气发动机的例子。他说，拿涡轮叶片来说，它们必须做得非常精确。即使由很细心的熟练工人加工叶片，仍然不可能达到你要求的精度，而必须另造一台机器来加工叶片。其中会有人干预这个过程吗？当然，制造、维修和调整机器必须由人来完成。机器也会出错，机器一旦出错会很显著，你能马上发现，并改正它。程序编码也是如此。不需要人去接触编码。否则程序易于出错。人能制造这种机器。..

9. · AOP

Aspect Oriented

10. · 泛型编程

泛型编程最初诞生于C++中，由Alexander Stepanov[2]和David Musser[3]创立。目的是为了实现C++的STL（标准模板库）。其语言支持机制就是模板（Templates）。模板的精神其实很简单：参数化类型。换句话说，把一个原本特定于某个类型的算法或类当中的类型信息抽掉，抽出来做成模板参数T。比如qsort泛化之后就变成了：

11. FP

12. 面向语言编程LOP（Language Oriented Programming）

LOP放弃了传统的基于文本的语言，用创造新的语言来代替类库，可以和编辑器所整合，并且每个程序员都可以创造自己的语言

按照Dmitriev先生的观点，通用语言的问题在于：它们描述领域模型的能力太差。在完成概念性的领域建模之后，开发者们还必须经过一个漫长的编码过程，才能把模型描述为机器可理解的程序，反过来要理解这些代码所描述的领域模型也是同样困难。而DSL虽然能够很好地描述领域模型、解决领域问题，但这种语言又太少了，而且大多数开发者必须苦苦等待少数大厂商为他们提供适用的DSL。很大程度上，这种“语言的失位”造成了软件开发的低效。

　　Dmitriev先生提出的解决方案就是LOP：借助工具的帮助，允许开发者创建自己的DSL。这样的DSL当然能够最贴切地描述领域问题，从而大大提高开发效率。而且，这样的“自定义DSL”也不必是文本形式的，它可以直接保存为树状结构（或别的结构），并直接以图象的形式展现。

LOP的切入点就是允许我们可以创建、重用、修改语言和环境。要理解LOP 是什么，可以从下图的主流编程和LOP方法过程进行一下比较，它使得编程阶段已经不是瓶颈了，而转移到了“创建”这一步，作者开发可一个通用的平台（the Meta Programming System）来设计DSL，它允许程序员像现在编写程序一样非常容易的就可以定义自己的语言；这个平台将完全支持LOP，给程序员为程序的每一部分选择使用最合适的语言的*，而不是将他们绑在某个固定的通用编程语言之上。

LOP将不只是编写程序，还包括创建用来编写程序的语言

13. 代码生成 VS 模型解释

我们可以解释模型直接运行在领域框架之上，也可以把模型通过代码生成技术转换成代码之后编译运行在框架之上。这两种方式都有利弊，可以搭配使用，在OpenExpessApp中将采用这两种方法，类库通过代码生成，UI等元模型通过框架解释执行。由于代码生成是MDD中很重要的一项技术，所以本篇我将介绍一下代码生成相关的知识。

14. 参考

MDSF：产生式编程（Generative Programming）方法介绍 - 周金根 - 博客园

MDSF：面向语言编程LOP（Language Oriented Programming）方法介绍 - 周金根 - 博客园

MDSF：LOP-使用MPS来做个计算器的示例 - 周金根 - 博客园

MDSF：代码生成 VS 模型解释 - 周金根 - 博客园

码农公寓

1. 主流编程中三个最糟糕的问题

1.1. 从理解问题后到实现的时间很长