哈,说下写程序

中山野鬼 发布于 2013/12/01 22:01
阅读 2K+
收藏 13

最近正好在研究演绎处理和归纳处理之间的关联和区别。我们写的程序,属于演绎处理。顺带说说写程序的思维方式和方法。哈。

要说这个,不得不说图灵机。并不严谨比较直观的描述,图灵机实际是个抽象的逻辑推理机。简单说,是用于逻辑演绎,特别是数学演绎证明使用的。我们可以将逻辑推理,或数学证明的每个部分,看作描述某个内容,而演绎逻辑推理,实际上是从一个描述内容中判断下一个描述动作,并转入执行,实际还是完成某个内容的描述。

其运行原理主要是两个方面的动作,一个是看当前的内容,这个是对象识别,一个是看当前的状态,这个是状态识别。而前者对应的是描述内容的判定,描述内容的判定后,将进行对应的执行,后者对应的是当前状态与当前执行后(实质也是描述某个内容)的判定以决定下一个执行步骤应当迁入哪个状态。

现在很多语言上来就是面向对象的思想。这个不反人类,哈,人类思维,是对象化,概念化的。但这个反机器。简单说,最终的逻辑代码,始终需要机器来实现,最接近机器运行原理的设计方式,那么它的性能、正确性等各方面指标越高,包括其描述自身,逻辑代码的质量越高,等同目标下,逻辑描述也越简单。这或许为什么说,linux如果用c++就是shit的原因。毕竟是操作系统。

我不想争执不同的语言好坏,语言的好坏是根据目标应用和环境来判定的。但无论用什么语言,来源于机器运行原理的逻辑设计思维始终是要存在的。简单说,就是状态机。

写程序,首先明确的不是具体的数据结构和组织方式,甚至什么构造,释放这些具体化的问题,首先是要确定整体逻辑流程,这个逻辑流程的规范描述方法,还是状态迁移图的方式,当然我这里不是说抽象的系统架构的设计。

状态迁移是根据阶段处理目标来的,关联不同状态之间的是数据交互,这中间就涉及很多同步、时序、周期、触发等概念,简单的单线程逻辑并不存在这些问题,而复杂的多线程会扯到这些。

其实有两种面向对象。一种对象是面向处理的对象,一种对象是面向处理的执行单元。貌似现在的程序设计思维,更多关注前者,而忽略了后者。哈。

程序员毕竟不是应用者,而是设计者,面对一个系统,理应先看到整个机器的执行单元和他们互联协同的结构,而不是看到一个个处理的对象。至于最终你喜欢用面向对象编程方式,还是面向模块的编程方式,这不是重点,重点是一个美女放你面前,你究竟看到的是手、脚、胸,这些具体的对象,还是能透视的看到她的骨架和肌肉关联组成。

简单总结一下,无论你用什么语言编程,老思维是不能忘的,除非底层机器的实现方式存在了重大革新。特别建议上来就是从java等高级语言学起并利用的朋友,如果你想提高编程能力和系统设计能力,回头多思考下,状态迁移设计和系统结构性分析等会对你的设计有很大帮助。当然貌似很少有这类的书籍,其实很简单,回顾计算机的发展历史,特别是编程的历史,多少就有感悟了。哈。

加载中
1
gvim
gvim

看样子是在喷OO,感觉说的有些片面吧。 

图灵机是自动推理机,虽然是自动的,但目前的哲学发展来看,形式化的推理模式是命题逻辑,也就是 如果p=>q,且p,则q 的三段式逻辑,或者更进一步的谓词逻辑,而状态机可以看作是肯定前件,它既不是根本也不是最核心的,最核心的是命题本身。所以状态机既可以是C那样的struct,也可以是Java、C++那样的Object,他们封装的都是肯定前件,从这没什么好说是反机器的。 

谓词逻辑也可以是 谓词(对象1,对象2,。。。)这样的形式,看这样的模式,和函数调用没什么区别吧。所以不管是C的函数,还是OO的方法、消息,实质还是谓词逻辑,因此从这也没什么好说是反机器的。

 OO最大的用处是复杂领域的建模,OOP的好处是分割逻辑关注点。OO有一套成熟的并且被使用接近20年而得到证明的建模理论和方法论和表示法,这可以参考boch等人的著作,而对比面向过程,对复杂领域的建模方法论几乎是没有的。当然,如果非要说Linux没用OO也可以很好,但是并不能说OO不能用来建模一套操作系统。OO并没有偏离我们所熟知的,Object本身就是状态,方法和谓词也没什么区别,相反它提供某种降低复杂性的方法罢。

 OO更多的是被滥用,或者由于语言设计的考量而导致的缺陷(参考设计模式),另外C++的复杂性也间接给OO的使用带来某些负面影响。好似前几天喷的if,else,用对象设计来替换if逻辑,只是被滥用,但某些时候这个设计是不错的。 

另外,补充一下的是,“我们写的程序,属于演绎处理”,归纳发生在循环和递归上

0
宏哥
宏哥

这个和图灵不图灵没有多大关系

C++在任何领域都是多余的

就算表现关系上C++也比C要多余

要么C, 要么弱类型, 就这么简单.

要吃九个橙子
要吃九个橙子
回复 @小毛虫 : 宏哥的理论C++都是多余了C#肯定就什么都不是了.
jefferywu
jefferywu
C#呢
0
中山野鬼
中山野鬼

引用来自“宏哥”的答案

这个和图灵不图灵没有多大关系

C++在任何领域都是多余的

就算表现关系上C++也比C要多余

要么C, 要么弱类型, 就这么简单.

哈。我扯的比较远,无非找点根子,谈谈。
0
中山野鬼
中山野鬼

引用来自“gvim”的答案

看样子是在喷OO,感觉说的有些片面吧。 

图灵机是自动推理机,虽然是自动的,但目前的哲学发展来看,形式化的推理模式是命题逻辑,也就是 如果p=>q,且p,则q 的三段式逻辑,或者更进一步的谓词逻辑,而状态机可以看作是肯定前件,它既不是根本也不是最核心的,最核心的是命题本身。所以状态机既可以是C那样的struct,也可以是Java、C++那样的Object,他们封装的都是肯定前件,从这没什么好说是反机器的。 

谓词逻辑也可以是 谓词(对象1,对象2,。。。)这样的形式,看这样的模式,和函数调用没什么区别吧。所以不管是C的函数,还是OO的方法、消息,实质还是谓词逻辑,因此从这也没什么好说是反机器的。

 OO最大的用处是复杂领域的建模,OOP的好处是分割逻辑关注点。OO有一套成熟的并且被使用接近20年而得到证明的建模理论和方法论和表示法,这可以参考boch等人的著作,而对比面向过程,对复杂领域的建模方法论几乎是没有的。当然,如果非要说Linux没用OO也可以很好,但是并不能说OO不能用来建模一套操作系统。OO并没有偏离我们所熟知的,Object本身就是状态,方法和谓词也没什么区别,相反它提供某种降低复杂性的方法罢。

 OO更多的是被滥用,或者由于语言设计的考量而导致的缺陷(参考设计模式),另外C++的复杂性也间接给OO的使用带来某些负面影响。好似前几天喷的if,else,用对象设计来替换if逻辑,只是被滥用,但某些时候这个设计是不错的。 

另外,补充一下的是,“我们写的程序,属于演绎处理”,归纳发生在循环和递归上

哈,你的观点中,我有几个认同中不太认同的地方。

1、命题逻辑和谓词逻辑中,命题是核心,不过这个命题,抽象出形式化的具体内容,实际留下有价值的是逻辑关联,不严谨的说,就是谓词逻辑。谓词逻辑中,重要的是迁移方法或规则。至于oo还是不是oo,还是有差异的, 一个是处理对象的组织方式的差异,这个其实无所谓,另一个是处理方法的组织差异,一个脱离处理对象,一个和处理对象关联绑定。

2、oo的最大好处是复杂领域的建模,这个我非常认同。不过oo的好处,是分割逻辑关注点,这个我表示持有异议,谈不上反对,因为我对你的“逻辑关注点”具体的含义尚不明确。

3、object本身是状态,这个我不反对,不过不反对的前提是,这个本身就是状态的 object并不是oo。从数学的定义中,对象域是对象域,对象域之上的操作是操作。例如随便看下半群的定义,集合和操作是两个组成内容。oo将方法和对象的绑定,并不会对逻辑演绎的清晰有帮助。

另外说一下,我这个说的归纳,不是演绎。哈。不是演绎中的归纳法。而是归纳逻辑处理。和演绎处理没什么因果关系。 

0
七念
七念

其实可以捎带上纯函数式编程 

前几天不是王垠在hacker news上喷OO和functional,结果被haskeller,围攻了,,,,

不过在国内喷funcional,估计没几个人懂

OSC首席键客
OSC首席键客
funcional就是函数式编程?我看了好几次概念,都没看懂是干嘛的!读书的时候学校只讲过程式和oo两种……
0
gvim
gvim

引用来自“中山野鬼”的答案

引用来自“gvim”的答案

看样子是在喷OO,感觉说的有些片面吧。 

图灵机是自动推理机,虽然是自动的,但目前的哲学发展来看,形式化的推理模式是命题逻辑,也就是 如果p=>q,且p,则q 的三段式逻辑,或者更进一步的谓词逻辑,而状态机可以看作是肯定前件,它既不是根本也不是最核心的,最核心的是命题本身。所以状态机既可以是C那样的struct,也可以是Java、C++那样的Object,他们封装的都是肯定前件,从这没什么好说是反机器的。 

谓词逻辑也可以是 谓词(对象1,对象2,。。。)这样的形式,看这样的模式,和函数调用没什么区别吧。所以不管是C的函数,还是OO的方法、消息,实质还是谓词逻辑,因此从这也没什么好说是反机器的。

 OO最大的用处是复杂领域的建模,OOP的好处是分割逻辑关注点。OO有一套成熟的并且被使用接近20年而得到证明的建模理论和方法论和表示法,这可以参考boch等人的著作,而对比面向过程,对复杂领域的建模方法论几乎是没有的。当然,如果非要说Linux没用OO也可以很好,但是并不能说OO不能用来建模一套操作系统。OO并没有偏离我们所熟知的,Object本身就是状态,方法和谓词也没什么区别,相反它提供某种降低复杂性的方法罢。

 OO更多的是被滥用,或者由于语言设计的考量而导致的缺陷(参考设计模式),另外C++的复杂性也间接给OO的使用带来某些负面影响。好似前几天喷的if,else,用对象设计来替换if逻辑,只是被滥用,但某些时候这个设计是不错的。 

另外,补充一下的是,“我们写的程序,属于演绎处理”,归纳发生在循环和递归上

哈,你的观点中,我有几个认同中不太认同的地方。

1、命题逻辑和谓词逻辑中,命题是核心,不过这个命题,抽象出形式化的具体内容,实际留下有价值的是逻辑关联,不严谨的说,就是谓词逻辑。谓词逻辑中,重要的是迁移方法或规则。至于oo还是不是oo,还是有差异的, 一个是处理对象的组织方式的差异,这个其实无所谓,另一个是处理方法的组织差异,一个脱离处理对象,一个和处理对象关联绑定。

2、oo的最大好处是复杂领域的建模,这个我非常认同。不过oo的好处,是分割逻辑关注点,这个我表示持有异议,谈不上反对,因为我对你的“逻辑关注点”具体的含义尚不明确。

3、object本身是状态,这个我不反对,不过不反对的前提是,这个本身就是状态的 object并不是oo。从数学的定义中,对象域是对象域,对象域之上的操作是操作。例如随便看下半群的定义,集合和操作是两个组成内容。oo将方法和对象的绑定,并不会对逻辑演绎的清晰有帮助。

另外说一下,我这个说的归纳,不是演绎。哈。不是演绎中的归纳法。而是归纳逻辑处理。和演绎处理没什么因果关系。 

命题逻辑和谓词逻辑不是那样解释的,如果依据标准的名词定义。

脱离对象或者绑定对象哪里没有结论,如同前一句这个其实无所谓。就算有差异且有所谓,可没有说明原因,逻辑中也没有后延,所以不明白在说什么。

google逻辑关注点或关注点,以普世认识为准。

不太清楚这里说数学做什么,也不太清楚为什么要弄一个错误的数学解释。。。在群及其相关代数结构的定义中,对象和操作是有机不可分的,当然还伴随封闭等性质要求。对象域是对象域,对象域之上的操作是操作,这是错误的,因为割裂了操作,够不成域,更别说对象域。。。所以,哈,你用一个错误的概念(名词是对的)来解释一个不相关的问题。说不相关,是因为OO泛指ooa,ood,oop,是一套建模,表示,编码的理论和方法而不是计算方法。哈。另外,逻辑演绎和面向过程,面向对象等无关,更无关乎对象和方法是不是绑定的。演绎只考虑命题或谓词对某事物的真伪,而不考虑事物的具象。比如:人(欧几里德)这个谓词,欧几里德连画像都没有留下了,甚至只是一个符号,甚至英文,希腊文,中文的具象各不相同,可不影响谓词的真伪,哈。或者说将方法和对象解偶,并不会对逻辑演绎的清晰有帮助,也未尝不可,因为它们之间没关系。

演绎和归纳还是用普世接受的定义吧,“你这个说的”,看不明白,哈。


0
gvim
gvim

引用来自“七念”的答案

其实可以捎带上纯函数式编程 

前几天不是王垠在hacker news上喷OO和functional,结果被haskeller,围攻了,,,,

不过在国内喷funcional,估计没几个人懂

喷functional没意义,另一种等价的计算模型,只是这种模型显得很晦涩。这种理论里只有函数和替换,计算的基础自然数也由函数定义,所以functional已经是一套和我们常识所不同,但计算上等价的算术体系。现在所说的functional programming,几乎和functional无关除了函数这个名字,替换被作为无副作用的函数调用。说几乎无关因为在fp里,自然数不是functional里面定义的那样,而无副作用在现实中太理想,因此haskell搞个怪胎monad出来。这样的运算方式自然不招待见,太诡异和大众的认知虽然等价但差别太大,有了作为运算的fp和作为建模的oo的混合,如ocaml,fsharp等。

喷,也只能说某具体语言哪里不爽这种低级论据罢了,哈。

0
铂金小白

楼主肯定是深度lisp和java中毒


java就是狗屎  还建议从java开始学起!!


C++才是王道!  

铂金苍鹰
铂金苍鹰
身为铂金家族,竟然没头像,一千万个鄙视
Hazelnut
Hazelnut
拜托你看完文章再喷
0
梅开源
梅开源

看了那个美女的透视比喻忽然想到程序员看美女的方式:

一个美女在面前,

项目经理:要花多少时间和钱搞定她?

产品经理:用户怎么用她?

设计师:衣服不够漂亮,让我重新设计个UI……

程序员:在吗?你在做啥?

梅开源
梅开源
回复 @beyondforever68 : 看了楼主关于透视美女我想到的啊。不是说程序员喜欢研究状态吗,在吗和在做啥都是查询状态……或许这是程序员容易成为屌丝的背后原因之一
beyondforever68
beyondforever68
求出处
0
OSC首席键客
OSC首席键客
哈。哈哈哈哈哈
返回顶部
顶部