相关言论：
1、语言只应该涉及到逻辑，不对应任何具体的运算机器。
2、应该有一个独立的，对硬件和运算架构的逻辑描述语言
3、现有的编译器只是在内部隐含了对硬件的要求，没有独立表达为知识。
4、硬件不仅可以包括各种CPU架构，还应该可以包括FPGA
5、最大胆的期望，通过对X86架构的描述和对FPGA的描述，可以把一个操作系统的二进制版本转换到FPGA计算架构上运行。

越来越像逻辑编程。

估计你没自己搞过公司，我是有失败的经验，市场运营和资本运作所需要的技巧、脑力和经验，大多数只搞技术的工程师都会严重低估。

本来就是个超高难度的东西嘛。

按照自己不太可靠的感觉，已经进入到快揭开谜底的阶段了。
入口大概是一个我想称之为元演算的一个系统，这个系统可以成为lambda演算，谓词演算和各种形式系统的构造基础。在这个层次上倒是没多少细节了。
方法还是用prolog做一些小练习，代码量撑死也就几百行的规模，要是超过1000行就该怀疑是不是有问题了。

SICP
P248
正文
本章开始时提出了一个目标，那就是构造出一些计算模型，使其结构能够符合我们对于试图去模拟的真实世界的看法。我们可以将这一世界模拟为一集相互分离的、受时间约束的、具有状态的相互交流的对象。或者可以将它模拟为单一的、无时间也无状态的统一体。每种观点都有其强有力的优势，但就其自身而言，又没有一种方式能够完全令人满意。我们还在等待一个大统一的出现。
SICP讲的重点不是FP，它只是语言上采用了lisp，事实上它的内容涵盖了几乎所有的方面，而且一点都不过时。

这么多天没见，已经快变成自费五毛了？仔细想想你的逻辑，在什么地方出了问题吧。
温二逼当众撒谎说病了，结果被揭穿的事情呢？

我在琢磨新的语法设施，前面弄出来一个合并句，后来弄出来一个“摹状词”，这两个语法设施，发现用关系代数的方法来定义可以更数学化，更简洁。合并句就是一个笛卡尔积，“摹状词”可以定义为一个关系值。
现在额外增加的工作是，找到关系代数和谓词逻辑的对应关系，并用谓词逻辑和时态为关系模型补上缺失的部分。

这几天有个搞数据库的关注上了我，还翻译了一篇我的日记发到英文社区。
而且这段时间在设计基础语法的时候，也不可避免地和关系数据库挂上了钩，一些地方要用到关系代数或者关系演算。
你可以看看有没有什么启发：
http://thinkinmodels.wordpress.com/
从关系数据库的发展来看，SQL被搞理论的大牛贬低得很厉害，而且对对象数据库的批评也深得我心，还包括我提到的并且认为是错误的E/R模型，他们也有很尖锐的批评意见。

引用

说到Anders和Knuth，你的评价是不公的。微软M语言原来的规划是大的，只是不知道为什么缩减了。而且即便如此，类似于Anders这样的人，他们掌握的实践经验和其它能力，其信息量就已经巨大了。Knuth在学术那块也是这样，我靠让我把那些东西整理出来还能弄个TeX，即便我有他的环境也完全没戏。

不好这么比啊，你把图灵本人放到anders的位置上说不定还干得一团糟。让邱奇来写《计算机程序设计艺术》也未必写得出来。至于我，往这两个方向上发展，在我见过的并且认为还不错的程序员中至少有一半都会比我干得好。
各人有各人的造化，各人有各人的安排。

也让我这个老Delphi程序员觉得微软终于要在程序设计语言上翻身了。
不过呢，反正都是要刺激人，不如狠点说，如果计划能达到预想中最基本目标，anders那点花样也就是小孩子过家家，记住，前面有个如果，我对如果能否成立不做预测。
anders也就是被大众所熟知罢了，真正有意思的东西，在喧嚣的软件业，大家可能都没听说过名字的人的论文中。我说的可不是高德纳，这家伙虽然被人捧上天但我觉得没什么意思，但还不如joe深刻，更谈不上跟john mccathy相比。
最后，还得说点不好听的，反正是实话，听者勿怪，guaiguai的思考很多的确触及到了真正的问题所在，不过以我的角度，以我非常有限的了解，所

略。
等等等等。
现在传统上的编译概念，只不过是其中一个非常没特色甚至没啥用的案例：
尽可能的把计算调度到用户进行输入之前，然后把这个调度的结果保存为一个快照。
计算的时空调度意味着，代码不一定（一般情况下都不是）按照我们所写的流程严格执行，很有可能进行各种变化。
也就是说，即使写的是顺序执行的命令式语句，但系统却只将其看做一段语义说明，也就是代码功能的完备描述。
调度还包括了并行的概念，这个机制可以把顺序代码变成并行代码，并分配出去。
最后，这一切都应该自动完成，不和程序员产生任何关系。
...

收缩目标是不对滴，对我来说让理论变得尽可能纯粹才能解决好工程实践问题，比如优化。

现在除了看得上一点John McCathy老爷子的elephant，其余我知道的语言都看不上。
最民科的我还没说：计算机软件的发展道路完全错了，从一开始就错了，而且错得离谱。

提示，这在我现在的设计中是绝对会有的一环，因为这已经成了语言特性，而不是一个辅助功能。到时候效果出来那应该是相当惊艳，绝对不是那种打个点后面出选择的简单功能，而是，举个例子？比如有点像word的校对功能，比这个还丰富得多。
不好意思的说，我现在已经不怕什么民科不民科的了，本来就是么，现在我又不混软件业。
这里有篇综述，大致是对我的思路和研究纲领及现在工作重点的概述：
http://www.douban.com/note/147749382/
其中有个链接是关于我的5层论的，已经狂得没边了，嘿嘿。...

比OO的理论（如果说OO还有理论的话）要深刻得多。
4、采用OO思维方式下很复杂的模型，在关系数据库中会变得很简单，如果关系数据库往提供图灵完备的语言，而不是SQL的方向去发展的话，会更简单。
5、ORM是一个严重的错误，它把真实世界的关系强行用OO建模，又用ORM映射到关系数据库中，也就是说，在两个本来兼容的世界之间搭起一座与它们都不兼容的桥梁，没有比这更荒诞的事情了
还有：
关系模型中并没有什么实体的概念，而仅仅是一个基于集合论的数学结构，但基于关系理论发展起来的关系数据库乃至E-R模型，却落入了实体的陷阱，把建模导向了完全错误的方向。这再一次证明，软件的发展史就是一部走向庸俗

奇怪，本来还讨论得这么热闹，我一来怎么都跑了?

不得不说，大多数prolog代码虽然精巧，但同时也是相当晦涩的，其中的原因同函数式，而且比函数式更甚。

合并句就是自然语言中的常见现象啊。
我现在的支持还很简陋，因为还没有真正的搞语法解析，还是依赖prolog自己的模式匹配。
prolog的开源也有一些，你看一下swi-prolog的主页，上面资料有一些了，不过和我搞的东西风格还有很大不同。
推荐你学完prolog的基本语法之后，看一篇erlang发明人的的论文，是讲如何用prolog实现erlang的，代码很浅显。名字叫做Use of Prolog for developing a new programming language

;,email-"abc@126.com")-is-valid.
Yes
?-(username-"zhang3",password-"12345",email-"abc@126.com",status-"1")-is-valid.
Yes
后面两个调用是自然语言中合并句的形式，如下：
(a,b)-c的含义是a-c,b,c
(a,b)-(c,d)的含义是a-c,a-d,b-c,b-d
至于进度，没什么计划，都在豆瓣日记上写着呢。
...

做到这一点？这必须以我们考虑问题的方式来参考，在写作代码之前，我们的大脑会通过语言描述代码的功能，然后转化为代码。而在需求变化时，大脑会改变先前的语言描述，取代以新的语言描述，然后把这新旧两种语言描述之间的差别，转化为代码的差别。
无论如何，符合自然思维的描述是最好的，因为在上述各种转化中，如果代码尽可能的符合语言描述，那么转化的代价将会很低。
...

引用

最后骂一句，我怎么干上程序员这行当了，弄这些繁琐的旁枝末节真TM无聊的紧。还有，早知道要处理整套页面应用相关问题，绝B用C/C++写了，从webkit里直接copy，还能顺便学点其它不相干的经验，日了。

记得有个人在豆瓣上说过：
如果说17世纪缺乏逻辑基础的数学体系是一片沼泽地，那我们现在的程序员简直就是在淤泥里面挣扎。而且还能骄傲地宣称世上没有无bug的程序，俺们程序员是不是有点太不思进取了。
我补充：
哼哼，而且他们还怡然自得的炫耀那些七拼八凑的救生用品。

不过我支持你去试试，不试怎么知道呢，这个过程肯定也很长经验值。

我也没搞过，主要无门无派没有山头的话，估计不是那么好弄的。
投正式的论文而且发表在正式的学术期刊上，说明到了某个级别，也可以拿出来当资历了，而且随着你论文被别人引用次数的增加，级别也会上升。学术圈的人，什么升教授，涨工资，立项目，都跟这个关系很大。
有一点可能得注意，学术论文公开的是技术细节，一般认为就是free了，除非同时申请专利，否则别人用起来没商量。
我感觉弄不弄无所谓，又没有给我评职称，涨工资，立项目，反正到时候就是扔一个软件出去大家用吧，好就火一把，不好就拉倒了。

要申请加入才行啊，页面上应该有提示。

就开始口水战。我那个贴就不幸被管理员口头提醒，email过去之后管理员才告诉这么多规矩。
以后我也不想发什么正式论文，到这个LTU上宣告一下产品，在博客上提供非正式论文和下载试用就可以了，好的话自然会有反响。...

恭喜，里程碑一个。

一个重要区别：我不把可计算性当做目标。
真正关键的是可理解性，这不仅仅是指代码的可理解性，而包括整个后台环境的可理解性，语言被解析，被解释的整个过程的可理解，可调试。
要做到这一点，我第N次的重复，语言，一切都归于语言。
一旦做到了这一点，写出一段难以编译的代码就和写出来一个无限循环的错误那样普通，也很好纠正。

ttp://www.douban.com/note/131733294/
...

In pure Prolog, normal DCG rules with no extra arguments on the functors, such as the previous example, can only express context-free grammars;
Pure Prolog is restricted to Horn clauses.
但实际用的prolog都不是纯pure prolog，不是纯prolog的意思不是指副作用，而跟语言的层次有关系，如果prolog能够对自己的代码进行处理就不是纯prolog了。