Re:有限自动机与建模

javaing — Fri, 21 May 2010 09:02:37 GMT

@abruzzi 我也下不下来啊,谁有源码?能不能发下我邮箱里,我正在学:ching5346@126.com

javaing 2010-05-21 17:02 发表评论

Re:有限自动机与建模

abruzzi — Sat, 13 Mar 2010 03:30:24 GMT

@我是一头驴子不好意思，本啦是用dropbox的链接，我刚用迅雷试了下，好像真的不能下了，用这个链接吧：http://files.cnblogs.com/abruzzi/machine.zip

abruzzi 2010-03-13 11:30 发表评论

Re:有限自动机与建模

我是一头驴子 — Sat, 13 Mar 2010 02:54:35 GMT

怎么下不下来呢？

我是一头驴子 2010-03-13 10:54 发表评论

Re:有限自动机与建模

我是一头驴子 — Sat, 13 Mar 2010 02:52:44 GMT

攒一下楼主的写作风格，简洁而又调理。实在很难得

我是一头驴子 2010-03-13 10:52 发表评论

Re:函数式编程(javascirpt)

鞠文广 — Thu, 06 Aug 2009 09:01:15 GMT

理想的编程语言鞠文广以下纯粹是个人观点, 不代表任何组织或社团. 现在流行的编程语言如Java和C#, 大多是面向对象的, 程序的各部分是通过方法调用连在一起, 其编程范式是命令编程, 即使支持其他范式也包装得很难理解和使用. 面向对象实际上只适合实现抽象数据类型, 让它去完成除此之外的任务确实是勉为其难, 即便能完成也给人不伦不类的感觉, 既不像面向对象编程, 也不像它的前任(过程编程). 这些语言中的对象与物质世界的物质(或对象)很不一致, 它使用方法调用的方式与其他对象进行相互作用, 而这与物质之间的(通过通信或媒介)相互作用是截然不同的, 因此用面向对象无法很确切地模拟现实世界(面向对象思想的初衷), 更不用说准确地为现实世界建立模型. 这几年流行的web服务和SOA虽使程序间交互更方便, 但它从本质上说还是使用”面向对象+命令编程+方法调用”的思路, 在编程方法论上并没有实质的进步. 用现在流行的语言实现的完成复杂功能的程序逻辑不清晰, 原因在于”命令编程+方法调用”的设计机制. 这使程序很难模块化, 副作用无所不在, 因此很难正确实现复杂功能. 现实世界的发展变化是通过事物间的相互作用实现的, 而这种相互作用用计算机科学的语言来说就是并发(concurrency). 软件的本质是什么? 我觉得:软件总是完成某种功能的,归根到底是对现实世界的事物间相互作用进行建模. 因此软件的组成部分间自然就是并发的关系, 而不是过程调用的关系. 用通信进程来对现实世界的事物间相互作用进行建模是比较合理的. 所以进程应该作为语言的基础成分, 是软件的基本组成部分, 而不是只为了提高效率才采用的. 为了使程序能准确地为现实世界建立模型, 从而正确性更高, 结构更合理, 模块化程度更高, 因此在几种编程思想或语言的基础上(见references), 我提出一种新的编程方法论: 面向进程+函数编程+进程间通信+逻辑编程+约束编程+其他合理的范式(命令编程除外)和一门编程语言ProcessLog (全称process logic). ProcessLog只支持一种并发:通信进程. 它就是计算机科学家在上世纪70年代为了克服现在的Java中仍采用的那种并发方式的缺点而提出的. 它是经过充分研究得到的一种理想并发方式, 看了并发理论(concurrency)和进程代数(Process algebra), 就会明白这种并发方式可解决实际中的各种并发问题, 用它足够了. 这里的进程是进程代数的进程,不是过程,也不是Java中的线程. 看看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". ProcessLog的语法概要如下: 1 运算符 (1) ? 输入; c ? x 从输入端口c或通道c上接收输入值放到变量x中 (2) ! 输出; c ! v 把v的值从输出端口或通道c上输出 (3) -> 顺序进行的事件的先后关系 (4) | b : s 分支 (5) || 进程并行 (6) // 附属进程 (7) and, or, not 逻辑运算符 (8) 算术运算符和关系运算符与Java中相同 2 程序的组成成分 (1) Unit 程序单元 (2) Process 进程 (3) Function 函数 (4) Predicate 谓词 (5) Channel 通道, 有两个端口: in 输入端口, out 输出端口 (6) OutPort 输出端口 (7) InPort 输入端口 3 数据结构 (1) List (函数编程中的List类型, 对List的操作函数与函数编程中相同); (2) Tuple 元组, 同Clean. (3) Set 集合没有数组 4 进程的定义 Process p1 (OutPort pt1, InPort pt2 ){ pt2?x -> pt1! compute(x) -> p1 } 5 进程间相互作用 (1) 进程并行 process1( c1.out, c2.in)|| process2(c1.in, c2.out) (2) 附属进程 (getE: getElements || getR: getReleasedVersion) // X.(in?method -> getE ! method ? elems -> getR ! em ? rem-> … ->X) 6 函数 [Function] compute(double x)= | x<=0: x*x+3 | x>0: compute(x-5)* compute(x-3) 函数只能以事件的方式在进程中使用或在其他函数中使用, 不能独立使用. 7 谓词 /* 建图 */ 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). 8 把谓词转换为函数 create(t)= graph where createGraph(t, graph) 谓词不能独立使用也不能在进程中直接使用, 要在进程中使用需要先转换为函数. 9 程序单元: 包含进程和数据类型 Unit PmethodDAO; interface Tuple Method; Process getLastVersion(OutPort pt1 , InPort pt2); … implementation Method=(String id, String name, String version); Process getLastVersion(OutPort pt1 , InPort pt2){ … } 指导原则: 程序是由通过通道通信的进程组成的. 数据处理和算法用函数编程实现, 如果函数编程不适用于要处理的问题, 就使用逻辑编程或约束编程. ProcessLog语言限制了编程的随意性, 要求只能用进程代数+函数编程+逻辑编程的方式编程, 不允许用Java或c#的命令方式编程. ProcessLog 现在还没有在机器上实现. 我用该语言重写了实际项目中的一些复杂代码(原是Java代码), 证实用它写的程序确实简单清晰, 有类似数学的简洁美. "7 谓词"就是其中一部分代码. 我的想法是: 应先在纸面上规定它的语法与语义, 再通过使用它编写一些应用程序来发现它的不足,再进而改进它, 再实践, 再改进, 直到它基本完善再在机器上实现. 另外, 大家不要把语言分为中国人提出的还是外国人提出的, 科学无国界, 这里不存在狭隘的爱国主义. 我不是那种技术高手, 但我自信我是一个能将理论很好地联系实践的研究者. 希望有识之士和我一起共同发展这种编程方法论和这门语言. juwenguang2000@yahoo.com.cn References 1. CSP http://www.usingcsp.com/ 2. JCSP http://www.cs.kent.ac.uk/projects/ofa/jcsp/ 3. Clean http://clean.cs.ru.nl/ 4. Prolog 5. Delphi 注: 转载时请注明作者.

鞠文广 2009-08-06 17:01 发表评论

Re:基于总线的消息服务(BBMS)的设计与实现

abruzzi — Sun, 26 Jul 2009 04:16:26 GMT

@jhtchina 总的来说，BBMS是一个轻量级的消息服务，还没有Pub/Sub机制，主要考虑到为GUI提供底层的消息机制，当然，可以进行扩展，使得其适应企业级的消息服务。当然，目前还有很多的问题，需要进一步完善。

abruzzi 2009-07-26 12:16 发表评论

Re:基于总线的消息服务(BBMS)的设计与实现

jhtchina — Sat, 25 Jul 2009 17:37:17 GMT

主要是消息的定义这个部分要做好 Bus 就是一个或者几个服务，按照SOA的思想来做消息如果传递成功以后，你是否考虑过回传机制，消息是否成功发送到目的地

jhtchina 2009-07-26 01:37 发表评论

Re:基于总线的消息服务(BBMS)的设计与实现

abruzzi — Sat, 25 Jul 2009 14:38:33 GMT

@Todd Wei 主要是概念上的问题，Queue是一个比较抽象的概念，可以用来实现BUS的内部容器，但是Queue跟BUS并不能等同起来。比如，可以将一个listener“挂”在BUS上，但是不能说挂在Queue上，正如我一直的观点：名称在程序设计，特别是OO中，名称是特别重要的，可以使得代码的可读性和可维护性增强。

abruzzi 2009-07-25 22:38 发表评论