理想的编程语言

理想的编程语言  鞠文广

以下纯粹是个人观点, 不代表任何组织或社团.
关键词: 并发编程 函数编程 逻辑编程
摘要: 由于现有语言不能很好的为现实世界建模, 我提出一种编程方法论和编程语言Processlog. 它的编程思想是"面向进程 + 函数编程+ 逻辑编程等", 用它写的程序的软件体系结构很清晰, 程序简洁优美, 程序的正确性容易用数学推理证明, 适用于各种领域.

现在流行的编程语言如Java和C#, 大多是面向对象的, 程序的各部分是通过方法调用连在一起, 其编程范式是命令编程, 即使支持其他范式也包装得很难理解和使用.

面向对象实际上只适合实现抽象数据类型, 让它去完成除此之外的任务确实是勉为其难, 即便能完成也给人不伦不类的感觉, 既不像面向对象编程, 也不像它的前任(过程编程). 这些语言中的对象与物质世界的物质(或对象)很不一致, 它使用方法调用的方式与其他对象进行相互作用, 而这与物质之间的(通过通信或媒介)相互作用是截然不同的, 因此用面向对象无法很确切地模拟现实世界(面向对象思想的初衷), 更不用说准确地为现实世界建立模型.

这几年流行的web服务和SOA虽使程序间交互更方便, 但它从本质上说还是使用”面向对象+命令编程+方法调用”的思路, 在编程方法论上并没有实质的进步.

用现在流行的语言实现的完成复杂功能的程序逻辑不清晰, 原因在于”命令编程+方法调用”的设计机制. 这使程序很难模块化, 副作用无所不在, 因此很难正确实现复杂功能.

现实世界的发展变化是通过事物间的相互作用实现的, 而这种相互作用用计算机科学的语言来说就是进程间的并发(concurrency). 软件的本质是什么? 我觉得:软件总是完成某种功能的,归根到底是对现实世界的事物间相互作用进行建模. 因此软件的组成部分间自然就是并发的关系, 而不是过程调用的关系. 用相互通信的进程来对现实世界的事物间相互作用进行建模是比较合理的. 所以进程应该作为语言的基础成分, 是软件的基本组成部分, 而不是只为了提高效率才采用的.

为了使程序能准确地为现实世界建立模型, 从而正确性更高, 结构更合理, 模块化程度更高, 因此在几种编程思想或语言的基础上(见references), 我提出一种新的编程思想: 面向进程+函数编程+逻辑编程+约束编程(constraint programming)+其他合理的范式(命令编程除外)和以此为方法论的一门编程语言Processlog (全称process logic).

由于现有的并发机制要么不够理想, 存在不能接受的缺陷(如Java中的monitor机制); 要么很难应用于实际(如CSP的通道(channel)通信), Processlog中采用的并发机制是: 程序中同时运行的进程相互间通过端口来通信. 这种并发机制是我根据Abstract Behavior Types[1]的思想提出来的. 要完成两个进程间通信, 需把一个进程的输出端口和另一进程的输入端口相连, 然后在输出端口发送消息, 在输入端口接收消息就可以了. 这种机制很自然, 和现实世界的事物间相互作用是类似的.

Processlog的语法概要如下:

1 运算符
(1)  ?  输入;  c ? x 从输入端口c上接收输入值放到变量x中
(2)  !  输出;  c ! v 把v的值从输出端口c上输出
(3)  ->  顺序进行的事件的先后关系
(4)  | b : s  分支
(5)  a >> p.b 输出端口a连接到进程p的输入端口b
(6)  a << p.b 输入端口a连接到进程p的输出端口b
(7)  and, or, not 逻辑运算符
(8)  算术运算符和关系运算符  与Java中相同

2 程序的组成成分
(1)  Unit 程序单元
(2)  Process  进程
(3)  Function  函数
(4)  Predicate 谓词
(5)  DataInPort 数据输入端口类型
(6)  OutPort  输出端口类型
(7)  InPort  输入端口类型
(8)  ResultPort 结果输出端口类型

3 原子数据结构
(1) List (函数编程中的List类型, 对List的操作函数与函数编程中相同);
(2) Tuple 元组, 同Clean.
(3) Set 集合
没有数组

4 进程的定义
Process ChangeRel
( DataInPort dataIn(List, Em, Em);
ResultPort resultOut(Em);
InPort fromGetRel;
OutPort toGetRel, toDetach, toAttach, toChangeRel
)
% 生成与当前进程相连接的进程, 并配置端口间的连接
(
  GetRel getRel; Detach detach; Attach attach;

  toGetRel >> getRel.dataIn,
  fromGetRel << getRel.resultOut;

  toDetach >> detach.dataIn;

  toAttach >> attach.dataIn
)

{
dataIn?(list, rlEm, em) ->
( | list=[cem:cems]:
(  ChangeRel changeRel;
     toChangeRel >> changeRel.dataIn  % 递归进程
  )
  toGetRel!(rlEm.id) -> fromGetRel?rel
  -> toDetach!(cem, rlEm.id)
  -> toAttach!(cem, em.id, rel.level, rel.weight, rel.relation)
  -> toChangeRel!(cems, rlEm, em)
)
}

进程由事件组成, 如fromGetRel?rel是输入事件, toGetRel!(rlEm.id)是输出事件.
用Processlog写的程序都可以用动态视图(见附件)来表示, 其中的方形表示进程, 箭头表示数据流向. 进程间是并行运行的, 相互通信.

5 函数
[Function] compute(double x)=
| x<=0: x*x+3
| x>0:  compute(x-5)* compute(x-3)
函数只能以事件的方式在进程中使用或在其他函数中使用, 不能独立使用.

6 谓词
/* 建图 */
Predicate createGraph(t, graph):-
addNode(t, null, ({},{}), graph1),
getDS(t, graph1.ns, tlist),
addList(tlist, t, graph1, graph).
/* 加节点 */
Predicate addNode(t, null, (ns, es), (ns1, es):-
merge(ns, {t}, ns1).
Predicate addNode(t, upper, (ns, es), (ns1, es1)):-
merge(ns, {t}, ns1),
merge(es, {(upper, t)}, es1).

7 把谓词转换为函数
create(t)= graph
where createGraph(t, graph)

谓词不能独立使用也不能在进程中直接使用, 先转换为函数后再在进程中使用.

8 程序单元: 包含进程和数据类型
Unit PMDAO;
interface
Tuple M;
Process GetReleasedVersion(DataInPort dtIn, OutPort pt1 , InPort pt2);
…
implementation
M=(String id, String name, String version, …);
Process GetReleasedVersion(DataInPort dtIn, OutPort pt1 , InPort pt2)
(…)
{
…
}

指导原则: 程序是由通过端口相连接的进程组成的. 数据处理和算法用函数编程实现, 如果函数编程不适用于要处理的问题, 就使用逻辑编程或约束编程.

Processlog语言限制了编程的随意性, 要求只能用进程+函数编程+逻辑编程的方式编程, 不允许用Java或c#的命令方式编程.

Processlog 现在还没有在机器上实现. 我用该语言重写了实际项目中的一些复杂代码(原是Java代码), 证实用它写的程序确实简单清晰, 有类似数学的简洁美. "7 谓词"就是其中一部分代码.

我的想法是: 应先在纸面上规定它的语法与语义, 再通过使用它完成一些复杂的项目代码来发现它的不足, 再进而改进它, 再实践, 再改进, 直到它基本完善再在机器上实现.

现在需解决的问题是: 软件分析设计方法(不同于面向对象编程和面向过程编程)?

希望有识之士和我一起共同发展这种编程方法论和这门语言.

联系方式: [e-mail]
博客: http://www.cnblogs.com/forrestju/

References
1. Farhad Arbab, Abstract Behavior Types: a foundation model for components and their composition
2. Clean  http://clean.cs.ru.nl/
3. Prolog
4. Delphi
5. JCSP
注: 转载时请注明作者.

评论

37 楼 forrestju 2009-08-11  

JBeans 写道

楼主原来是科箫家啊！可是怎么也没看到点儿科箫的影子呢？难道是山寨的？科学的起点是自然辩证法，楼主要想做学术研究先学好范儿吧，一个没有学术和足够的理论支撑的东西真的很山寨

我已经说过"我觉得在讨论问题时,大家不要太过于情绪化了,否则只知道维护自己的已有观点,而不是要探寻真理. "

请不要做这种人身攻击,这样很没意义.

36 楼 CharlesCui 2009-08-11  

night_stalker 写道

CharlesCui 写道

night_stalker 写道

有回帖已经是很捧场了 …… 不信拿去 LtU 发发看。

NS是LTU毕业的?

终极拉姆达 。。。

：）

35 楼 JBeans 2009-08-11  

楼主原来是科箫家啊！可是怎么也没看到点儿科箫的影子呢？难道是山寨的？科学的起点是自然辩证法，楼主要想做学术研究先学好范儿吧，一个没有学术和足够的理论支撑的东西真的很山寨

34 楼 jonathan_zz 2009-08-11  

我觉得现在真正应该思考的不是怎么做和用什么做，关键是我们做了什么：刀不在快，技为其刃……

33 楼 night_stalker 2009-08-11  

CharlesCui 写道

night_stalker 写道

有回帖已经是很捧场了 …… 不信拿去 LtU 发发看。

NS是LTU毕业的?

终极拉姆达 。。。

32 楼 CharlesCui 2009-08-11  

night_stalker 写道

有回帖已经是很捧场了 …… 不信拿去 LtU 发发看。

NS是LTU毕业的?

31 楼 Magicloud 2009-08-11  

兄弟，我再只说两句。
1. 你根本没明白eiffel语言的思想，注意，我不是说开发的思想。
2. 从你的说法来看，我认为是你没看懂csp。

30 楼 forrestju 2009-08-11  

刚才用chrome浏览器上传ppt一直不行, 这次用ie试试看吧.

我觉得应有一个开放的态度去了解自己没接触过的思想或理论, 否则会固步自封,而不是还不了解就根据自己已有的经验或观念去反对它. 希望大家能用这种开放心态看这两个ppt.

29 楼 night_stalker 2009-08-11  

有回帖已经是很捧场了 …… 不信拿去 LtU 发发看。

28 楼 forrestju 2009-08-11  

我觉得反对或支持一个理论首先需要理解这个理论.我觉得大多数讨论者并不理解这个理论,原因主要在我没有完全清楚地说明这个理论的所有好处和它各部分的提出原因,很抱歉,时间有限做不到这点.
我在文中说了需要明白csp和jcsp.
"看看jcsp或Hoare的CSP(http://www.usingcsp.com/)就明白了.推荐网址:
http://www.cs.kent.ac.uk/projects/ofa/jcsp/,
其中有两个ppt说得很明白:
Process Oriented Design for Java: Concurrency for All,
Communicating Processes, Components and Scaleable Systems.
"

希望愿意讨论的人先看明白csp和jcsp, 最起码要明白jcsp的思想.我估计参与讨论的人都没去看这两个ppt.
那我就把那两个ppt贴上去吧,看完之后再讨论吧.

27 楼 night_stalker 2009-08-11  

forrestju 写道

语言本身应有的要素应该是语法本身的一部分, 而不是支持库这种外在的附加物.

你有没有想过 …… 理论上，只要可以 eval ，就能通过支持库添加大部分语法 ……

26 楼 forrestju 2009-08-11  

Magicloud 写道

forrestju 写道

Magicloud 写道

forrestju 写道

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

为何进程通信和副作用会拉上关系？
而且haskell没有真正意义的赋值……

你没有明白我的意思.
再重复一下
"这门语言是要杜绝赋值语句,如Haskell语言那样."

那么haskell不是已经杜绝了么？
如果你想做个新的语言，为何不干脆给haskell写个相应的支持库？

语言本身应有的要素应该是语法本身的一部分, 而不是支持库这种外在的附加物.

25 楼 night_stalker 2009-08-10  

避免传引用（指针）就差不多了。

别人可以吐槽说 进程是一种对象 ……

24 楼 Magicloud 2009-08-10  

forrestju 写道

你看看jcsp的相关理论就明白用通道通信可避免副作用. 而在面向对象中的方法参数如果是对象的话,不特意避免的话,一般都会有副作用,相信在一个实际的项目组中不会特意制定规则说"要避免对象参数的副作用".
我的文章中推荐:
http://www.cs.kent.ac.uk/projects/ofa/jcsp/,
其中有两个ppt说得很明白:
"Process Oriented Design for Java: Concurrency for All",
"Communicating Processes, Components and Scaleable Systems".

这个问题分开看。
首先你设计的不是面向对象语言。而对如haskell而言，副作用已经避免，不因进程通信而变化。
其次，通信避免副作用基于值传递，而对面向对象一直难以解决的问题，就是由引用构成的一个对象如何进行不需要人工参与的值传递。对此你甚至可以单独出一篇论文。另外，“对象”暗含了保存内部状态的功能，这与纯函数的理念相悖。没有仔细研究过“对象”是否可以和“无边际效应”简单的融合，初步考虑只有彻头彻尾的标记对象是否变化，而这将带来巨大的性能损失。

另外，我认为“对象”是一个模型概念，在技术理论中不应该使用这个名词。

23 楼 forrestju 2009-08-10  

Magicloud 写道

forrestju 写道

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

为何进程通信和副作用会拉上关系？
而且haskell没有真正意义的赋值……

你看看jcsp的相关理论就明白用通道通信可避免副作用. 而在面向对象中的方法参数如果是对象的话,不特意避免的话,一般都会有副作用,相信在一个实际的项目组中不会特意制定规则说"要避免对象参数的副作用".
我的文章中推荐:
http://www.cs.kent.ac.uk/projects/ofa/jcsp/,
其中有两个ppt说得很明白:
"Process Oriented Design for Java: Concurrency for All",
"Communicating Processes, Components and Scaleable Systems".

22 楼 Magicloud 2009-08-10  

forrestju 写道

Magicloud 写道

forrestju 写道

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

为何进程通信和副作用会拉上关系？
而且haskell没有真正意义的赋值……

你没有明白我的意思.
再重复一下
"这门语言是要杜绝赋值语句,如Haskell语言那样."

那么haskell不是已经杜绝了么？
如果你想做个新的语言，为何不干脆给haskell写个相应的支持库？

21 楼 forrestju 2009-08-10  

Magicloud 写道

forrestju 写道

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

为何进程通信和副作用会拉上关系？
而且haskell没有真正意义的赋值……

你没有明白我的意思.
再重复一下
"这门语言是要杜绝赋值语句,如Haskell语言那样."

20 楼 Magicloud 2009-08-10  

forrestju 写道

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

为何进程通信和副作用会拉上关系？
首先对纯函数而言，没有副作用。
对非纯函数，因为没有变量这个东西，就不存在隐式修改的可能了。

而且haskell没有真正意义的赋值……

19 楼 forrestju 2009-08-10  

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

18 楼 forrestju 2009-08-10  

Magicloud 写道

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

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

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

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