理想的编程语言

不明白领域问题的内在"熵"是什么意思. 我觉得研究问题首先要概念明确, 如果概念很含糊, 那就很难进一步研究. 例如:中国古代哲学中的"气","形"等概念很含糊,概念含糊是中国古代哲学与科技落后的一个重要影响因素.

科学理论是在实践基础上经过研究得来的, 不能只停留于实践, 不然科学怎么能进步.

首先问楼主，会用erlang吗？了解eiffel的思想么？

我学编程十几年了，也有过楼主类似的想法，这个也不好，那个也不行。而语言接触的越多，越觉得“发明”一种新的语言没什么意义。我们需要的“功能”已经早已不是需要“字面表达”方式来解决的了。

我不会用erlang.
函数编程语言中我只会用Clean(前年学的),正像我只会用一种面向对象语言Java一样.
我前年才了解eiffel的思想,其中核心思想是DBC.
我学编程13年,掌握的编程语言可能比你少, 我只会:C, Pascal, Delphi, java, clean, Prolog.


不太明白,想问一句:你说的是什么"功能"? “字面表达”方式是什么方式?

面向进程+函数编程+进程间通信+逻辑编程+约束编程 =C#+F#+Nemerble+Axum+Microsoft.Contract=.net


你能确定哪种情形下采用哪种方式最有效率？ 还是MS的方法好，分而化之，信手拈来。

这是个好帖子，里面的回复更值得细细推敲，顶楼主。

我认为提高生产工具的效率到一定程度之后，就再发挥下劳动者的能动力会更高效。

屠龙刀厉害吧，但内力不够的人用起来威力也不大，这时候需要提高使用者的基本功。
但有的人不需要屠龙刀和倚天剑就可以驰骋江湖了，比如张三丰和张无忌，因为他们的内力十足，用不到这么NB的东西了，他们自己更NB。

衡量好这个点，就会知道你是该创造一个更NB的工具，还是锻炼自身的基本功了。

1. 面向对象和并发不冲突。
T1君曾有引文，论述真正的面向对象是解决并发的好思想。
个人认为c++、java只是初级的面向对象，很多理论细节采用命令式的方法来解决（比如楼主提到的方法调用）。而作为不纯粹的面向对象，当然不能发挥其应有能量。
纯粹的面向对象，内容之一就是对象间使用消息交互，没有任何规定要一个对象“等待”另一个对象。而在单线时代，这些都被做成“必然”了。当我们重新审视面向对象，会发现每个对象独占一个进程是多么的美丽。
2. 单纯的函数编程只能避免代码错误，不能从设计上约束代码混乱。
函数编程，重要的一点是避免了边际效应，并有助计算、策略的分离。但对比接口、类定义，函数式编程不能把代码级的混乱约束在足够小的单位内。还是需要程序员的自觉……
所以面向对象的代码编写促进了高级的设计人才和便宜的软件蓝领的产业结构。
3. 将每一个计算片段（不可再并发的最小单位）分配一个进程，并相互通信（如楼主代码例456），在erlang中可以原生实现。

所以知道，有强大对象的ruby（个人认为）、纯函数的haskell、并发和通信都原生支持的erlang，各有其超长之处，又都不完美。
而如我前述，某些问题可以归结为文字表达的问题，比如代码的约束，这一点，我们可以通过其他辅助手段来实现，成本（实施以及人员更替等）将是低于把一门全新的语言做到成熟的。另一些问题，则是库、底层实现的问题，和代码用<-还是=来取值没关系。Haskell没有好的进程及通信支持，做个库嘛。另外，erlang的强力进程切换，我不认为能在jvm上做出来……

我认为楼主当先把一些编程理论吃透，再行组合。而不是重新造个轮子，然后发现和其他轮子没大区别……

我在google上没搜到Nemerble和Microsoft.Contract.
Axum是基于Actor模型的,它不如通信进程科学,合理.

这门语言是要杜绝赋值语句,如Haskell语言那样. 用通信进程也是为了杜绝副作用.
看来你对相关理论比较熟悉, 有些地方需要向你学习.呵呵.

这个理论的基本思想是经过深思熟虑的, 不是突然心血来潮的产物.
我觉得它是一个值得大家共同思考的理论, 不是一味的反对.
我们现在需要在实践中检验它,不知有没有感兴趣的同行者?