从语言到库到框架，再到API，再到标记最后到DSL语言
计算机技术发展很快，而且越来越快，结果也是越来越复杂，那么我们到底怎么搞定复杂性并重用代码？
很明显，这是个大难题。一开始我们要解决计算问题，发展了基本的编程语言。
很快，编程语言不能满足需求，我们需要重用一些代码，算法，我们把这些重用部分写成库。
随着库越积越多，需要组织这些库了，这就形成了框架。
这就是我们今天面对的问题，.net,Java，甚至JS，都形成了框架，各种各样的框架，从解决问题，到带来问题。
为什么这么说？因为如今的框架太庞大了，除了JS，其它的动辄几十个名字空间，成百上千的类库，当然API要是少于1万，都不好意思拿出手的。
哪怕我们只是写一个简单的Hello World，也不得不引入一整套的框架。再加上一个巨大的IDE，当然还需要再巨大的执行环境，代码已经无法脱离生态圈生存。
框架这种为了解决通用问题而蛋生的东西，在初期比较有用，但一复杂后，带来的问题比能解决的问题还多。常见的有：
- 引入Bug，这么庞大的类库和API，有Bug很正常
- 复杂，无数的API交织在一起，相当复杂
- 版本问题，因为使用了框架，一个版本API变更，很可能就会引发连锁反应，以前基于框架的东西不能运行了
- 其它无数问题
基本上，框架这玩意，是程序员的朋友，同时也是噩梦。
现在计算越来越复杂，每一个人，已经只能在狭小的领域内工作了。其实通用框架，用处不大，写A应用，只能用它的1/10API，写B应用，又用了另外的1/10，那干麻还要全部使用或学习呢？
于是，借互联网的东风，很多公司推出了API接口，这玩意比框架简单多了，按接口调用就能用。发短信，读博客，提交定单，分享等。
但是问题又出来了，大量的这些东西，不会比框架更简单，好处就是用什么，可以取什么，不象框架那样，不用的也得包进去。但问题就是，这些API虽然都是按标准协议提供，但直接写接口也是相当麻烦。
有没有办法更进一步？当然有，我们把它们变成“标记”，然后在后台去解析这个标记就OK了，比如转发，就@XXX，关键字，就#关键字#，把Html简化成可书写的文本，就成了Markdown，比如这一篇。
这种巨大的进步，现在只看到一个开头，但其传播及流行速度惊人，甚至将来不久，Markdown可能会成为基础教育的标准课程
说这里，继续鄙视一下传统教育，节奏太慢了。在人机交互高度发达的今天，输入，Markdown，还是不能成为基本的课程。
Markdown是标记语言，如果能再进一步，调用各种WebApi，引入编程的一些基本概念，那么将成为一种更高级的页面语言比如机器人语言
同样，我们再来看框架，如果把通用框架，打散变成专业框架，那就进化成了引擎，一种很时髦的东西。大面全的框架，可以靠边站了。
这同时也带来一个问题，通用化的程序员需要选择方向了，妄想靠一套通用框架，通吃所有行业在将来是很困难的。选好方向，学习使用特定领域的引擎，并要结合进此特定领域的领域知识。
比如，熟练使用Unity3D的童鞋，去搞企业开发就不行。这和换行也差不多了。而使用SAP开发企业应用的，换成Hadoop搞数据，也不成。
计算机发展到现在，我们必须面临更艰难的选择，除了选择计算机行业，还要再选择这行业里的细分分支。这个细分要选不好，对职业生涯及技术提升会带来潜在的大影响。
同时，引擎技术要再进一步进化，就会进化成DSL语言，比如JS引擎，Lua语言等，更复杂的应用，会内置或好几种引擎，比如浏览器，有图形，有JS，未来还有语音视频等。
而在基于浏览器的开发上，是不是也可以这么进化呢？当然可以。
如果我们把行业的应用，从库，到框架，到形成一个行业引擎，是完全可行的，这样的专用引擎，能极大的解决行业开发问题，如果在引擎之上进一步抽象，形成“行业语言”也就是DSL语言，那更是贡献，比如Sql，这种建立在数据库之上的东西，还有JSON。
通过抽象出基本的行业规则，规范，标准，形成一些通用表示法，标记，再使用一个底层引擎搞起来，通过这种模式来复用，是一个非常好的方向，是一种比Api更高层次的复用。
