程序设计语言的目标
zhang3
让我震惊的是，我在里面发现了一段与我之前所描述的差不多的文字，我的描述是这样的：
见博文（为什么要写这个博客）
我想对于一种程序语言和IDE最关键的问题其实在于，这一点我可以说得清楚一些，你在写一个软件的时候，会在头脑中构思出一些概念，比如软件的架构，模
块之间的关系，某些处理过程。在这些概念变成实际运行的软件之后，显而易见的是，有一些模型保存下来了，但很多模型丢失了。
这样造成了什么问题呢，你在阅读源代码的时候，要从分散在各处的代码中提取出一些主题概念，比如，哦，这些地方的代码是做某某工作的。而不是从那些被丢
失的主题概念入手，直接去关注那一部分的代码。软件设计领域的概念层出不穷，你方唱罢我登场，但我以为这个最关键的问题恒久不变，简单而易于理解的代码
界面，永远是追求的目标。
而这篇文章中说到：
Understanding and Maintaining Existing Code
下一个问题是理解和维护现存代码；不管它是另一个程序员写的还是我写的，问题都一样；因为general-purpose的语言需要我把高层的领域概念
翻译为低层的编程语言特性，在最终的程序中，很多高度概括的视角、蓝图都丢失了；当我在以后重新翻阅程序时，我不得不通过逆向工程来了解我最初的意图是
什么，我头脑中的模型是什么；至少，我必须在脑海中重新建造最初在翻译到general-purpose的编程语言的过程中丢失的信息
解决这个问题的传统方法是写注释或其它形式的文档来记录设计信息和模型信息，已经有几个方面的因素证明了这是一种脆弱的解决方案，至少包括编写这些辅助
文档的成本、以及文档和代码逐渐不同步的趋势；并且，还有一个没被广泛认识到的事实，就是文档并不能直接连接到它所记录的概念；注释和源代码被绑定到同
一个地方，但是概念可能在源代码的多个地方被表达；其它类型的文档彻底从源代码中分离出来，只能间接的引用源代码；理想情况下，代码应该是自我描述的，
我应该只阅读代码本身来理解代码，而不是什么注释和外部的文档
另有：
编译意味着拿到源代码，并从中产生某种形式的可执行代码；对于结果代码有多种可能的形式；为产生可执行代码，你可以生成本地机器码，也可以生成虚拟机字
节码；或者，你可以生成另外一种语言的源代码（比如 Java，C++），然后用现有的编译器转换为可执行代码；类似的，你甚至可以产生某种解释型语言
的源代码，用现有的解释器解释执行
而我在“Zero语言”中的描述是：
Zero语言是和硬件平台层次化分离的。其目标码可以为各种高级语言，虚拟机字节码，也可直接编译为某个CPU平台上的执行码。通过一组最小化的描述原
语，任何满足内存需求的Zero程序就可以实例化到该硬件平台或者虚拟机平台。因此，Zero程序也特别适合在规模极小的单片机或其他嵌入式设备上运
行。
此外，还有一些有趣的地方，可以和我的一些描述对照来看。但从实现方法上，我所领悟到的实现方法与此又有不小的区别，也没有特别的把关注点放在所谓的
DSL上，因为我认为，不必要让一般的使用者意识到自己在创造所谓的专门语言，这一切应该表现为语言本身的抽象能力，而不是所创造的新语言特性上。