>不过，只要“数据+算法=程序”在Jdon出现一次，我就骂它个臭狗屎
在骂臭狗屎之前，是不是该先弄明白“算法”是什么？
按字面看，算法者，计算之方法也。这“计算”是什么呢？如果是会计、小贩，那就是加减乘除，如果是工程师，还得加上三角函数等等，如果是我们搞电脑的，那应该是“计算机”里的计算一词的含义。因此，计算，就是Computing（计算机能处理的一切事情），而算法，就是计算机做事的方法。这样说，这算法的范围可就广了。不仅仅解决商务需要算法，连做OO都有个算法问题。我的OO构筑得差，你的OO强，其中就有个方法论的问题。
程序，有两点，一是它处理的对象（数据），二是处理的方法（算法）。
过去，人们说“数据+算法=程序”，没人反对。现在，许多新东西出来了，这公式怎么办？我看有三种可能：
1）不变，仍然是
“数据+算法=程序”
2）变成：
“数据+X=程序”
算法没有了，变成数据加某种新东西。
3）“数据+算法+X=程序”
算法还在，又加进了新东西。
请教banq，你认为这公式该怎么改？
banq的说法我依然不敢苟同，数据+算法=程序 这已经是大家认可的真理，用面对对象的方法去分析也不过是如此，不管什么情况下，开发都是以数据为导向，然后是采用什么样子的方法。OO就可以脱离这个了么？？OO的最小单位是什么？？OO的最小运算单位又是什么？？你可以用高屋建瓴的思维去考虑，但是不要掩盖了事务的本质。
至于你举例的牛顿的故事，呵呵，聪明人就从来不被骗了？？那大家都去测试一下智商好了，高分的在高位，低分的就干苦力好了。现在的教育体系除了IQ以为还应该有EQ吧，作为老师你应该明白EQ对人生的影响也是不可估量的。
搞数学的人从不相信直觉，直觉只是会让他们的成功来的更快一些，但是不能取代辛苦的演算，反复的求证的，只有通过推导确实存在的才能够令人信服，也许亚里士多德够出名，但是总有一天会被一个伽利略的人通过事实证明真理不是靠感觉的。
考虑楼上两位观点，我们对真理公式做个中庸变动，变为：
数据 ＋ 算法 ＜＝ 程序
我加了一个小于号，我想大家应该明白这个意思，程序不只是由数据和算法组成，应该有无形的设计思想等等其他，这个设计思想不属于数据，也不属于算法，甚至是管理算法的（比如让算法可替换的策略模式）。
请注意：一旦我加了小于号之后的这个公式，其实已经变得没有意义了，因为它不符合数的精确定义了，我们可以罗列出类似这样很多公式：
对象 ＋ 设计模式 ＜＝ 程序
等等，其实，这些公式都属于正确的废话。
我们搞软件的都讲领域模型，领域是定语，意思是在一个范围内的模型，否则同一个模型在不同范围就有不同意义，你在工作单位范围是经理，回到家这个范围你就是做饭的伺候老婆孩子的“奴隶”。
没有范围定义前提下的所有真理都是正确废话，没有意义。我们对算法数据和对象设计模式各执一词，都是有定语前提的，前者是简单系统或纯粹的数据计算范围；后者是需求多变的复杂软件系统。
[该贴被banq于2009-04-07 12:03修改过]
[该贴被banq于2009-04-07 12:04修改过]
呵呵，hello world算程序么？？
唉，各位真的是大师啊，老子，道家都运用到软件开发来了。佩服。。。唉，感觉是不是空谈呢。。。。
我也不知道是不是空谈，我只是想说明OO只是一种方法，我们可以有一个地方来讨论与发展他，但是不要过分的强调一种方法的用处而否定一件事物应有的本色。
>老子，道家都运用到软件开发来了。佩服。。。唉，感觉是不是空谈呢
不空，不要见到讨论无形的大象之道就以为空的，说明你也许没有具备象数综合思维哦，哲学讨论是基本方向性问题，否则辛苦半天，方向走反了，得不到应有成果，这是南辕北辙的道理，看这个帖子，就是因为没有统一哲学认识，个说个的，他们能够对话沟通吗？
http://www.jdon.com/jivejdon/thread/35923.html
另外，不能为谈方向问题争执，就不迈开第一步，千里之行，始于足下，具体数能力也是需要的，看这个帖子用直观的四色图来分析需求，这个方法可以帮助我们应付我们不熟悉的陌生领域，这是哲学方法论的好处：
http://www.jdon.com/jivejdon/thread/35925.html
[该贴被banq于2009-04-07 19:07修改过]
好，Banq总算承认，OO不能替代或消灭算法。Banq显然赞成3）。现在只剩下1）和3）。
设计思想也好，OO也好，都是在算法之后的东西。
算法定下来了，这码怎么编，是搞成面条式的？还是结构化的？还是面向对象的？同是OO，他是这样OO，你是那样OO。
现在你再看看，这设计思想，这OO，能不能去否定算法？在公式“数据+算法=程序”里，OO能挤进去嘛？
我不反对你去比较武松厉害，还是李逵威猛。我只反对你让秦琼去和关羽打仗。
学电脑，学网络，到处都得讲究个层次问题。
[该贴被beepbug于2009-04-07 20:16修改过]
>都是在算法之后的东西。算法定下来了，这码怎么编 然后是OO
因为你接受的软件教育是这样，所以你就看成这样的过程，以为算法在前学，但是如果我让你先学对象，然后模式，再学算法，那么不是先有对象，后有算法，而且对象直观，更容易学。
你先学了算法，以为算法就是基础，是先入为主，是中毒在先，是走弯路，你走了弯路，才发现对象OO好处，但是因为你已经左撇子了，你能改正吗？所以，你们一直在这里和我较劲，没多大意思吧？树欲静而风不止，是你的心在动啊。
[该贴被banq于2009-04-08 08:33修改过]
我觉得这不是那个先学的问题，而是都要学习都要掌握的问题，难道你只用右手就从来不用左手么？？为什么一定要强调除了OO剩下都是错误的那？？而且我相信你所推崇的MF也是从算法学起的，难道他也错了？？
尊重ACoder观点，你带了红色眼镜，所以看到都是红色，我戴了蓝色眼镜，看到都是蓝色（或许是我色盲），本来就不是两个世界，这就是面向对象和面向数据库矛盾之处，
我们的争论也正说明：一个人不可能真正同时学好掌握好这两个知识，他们是矛盾的，徒增软件的复杂性，搞得软件四不像。这就象一个人同时练九阳神功，一个人九阴真经，他不发疯才怪呢，我不想发疯，所以，我只选择OO，现在数据库SQL我都不会写了，但是我还是开发软件。
[该贴被banq于2009-04-08 09:08修改过]
恰恰相反，我觉得作为一个程序员，这是他应该具备的相关素质，难道MF写不出排序算法嘛？？但是影响他在OO上的成就么？？为什么不能一起掌握？？一个学生如果你可以让他先去背高级的口诀，但是他根本就无法体会到OO在实战中的作用，只有通过项目逐步体会OO的重要性。这不是你我几句话说出来的，而且这样培养出来的人是为了OO而OO，根本无法继续发展OO的思想，你教他SSH，他就SSH，那一天出来别的东西他又要重新学习，最后的后果很可能是觉得程序员是一个枯燥的工作，无法体会中间的乐趣。那么如果在暂时无法理解OO的时候是否应该利用一段时间打好基础，掌握一些基本的算法，看一些基本的常识？？基础并不是单只SQL，SQL没有任何技术含量（如果惹怒了那位DBA我这里说一声对不起），我这里的基础是指算法以及数据结构，了解一些操作系统的基本特性，如果是写网络程序的，要了解网络的基本原理，明白一些基本的协议以及层次结构。这才是基础，是我所说的算法。
我再贴一遍，请Banq再看一遍。
好，Banq总算承认，OO不能替代或消灭算法。Banq显然赞成3）。现在只剩下1）和3）。
设计思想也好，OO也好，都是在算法之后的东西。
算法定下来了，这码怎么编，是搞成面条式的？还是结构化的？还是面向对象的？同是OO，他是这样OO，你是那样OO。
现在你再看看，这设计思想，这OO，能不能去否定算法？在公式“数据+算法=程序”里，OO能挤进去嘛？
我不反对你去比较武松厉害，还是李逵威猛。我只反对你让秦琼去和关羽打仗。
学电脑，学网络，到处都得讲究个层次问题。
你的回答是答非所问。鸡说鸭说，没意思，硬拗更没意思。
对算法，我还是要说，Banq的看法是很狭窄的。估计Banq是科班出身，你是从书本里或老师的嘴里理解的算法。我是自学的，学得乱，我也整不明白，我是先学的算法，还是先学的OO？我只知道，如果把算法比作秦琼，那OO可能是关羽，或是武松，或是项羽，而绝不会是单雄信、程咬金，可以拉来比试比试。
做为一个外行人说句话
觉得这种争议没有必要
反而让那些初学者犯了迷糊
让他们觉得我还要不要学啊
其实大部分人的目的就是要知道怎么用
至于有什么其他的东西
那就只有专家说说了
不知道有什么好争论的。
我不是计算机科班出身的，但各个领域的问题其实是相通的，无非就是个方法论的问题，什么是核心？什么是标准？依我看，根本就是无所谓的事，我最关心的就是在当前的条件（包括经济、人文、社会、科技等等各种客观主观条件）下如何解决实际问题，什么方法适合用来解决问题，就采用什么方法。
像现在比较主流的“面向对象”和“领域建模”，就是在当前科技条件下，针对现实世界信息化的过程中碰到的一类问题，所提出的比较合适的思想方法。但这种方法也并不是万能钥匙，它只是为了解决某一类问题而存在，有些明明应该是在算法领域解决的问题偏偏要套用“面向对象”的思路那就有点偏执了，就像把“面向对象”和“面向服务”放一起比较孰优孰劣一样，根本没有可比性，而将来随着科技的进步或者社会需求的变化，同样也会有新的思想来淘汰掉现在看似真理的方法论调。
至于“数据+算法=程序”，这就是个没有任何上下文的所谓公式，没什么意义，在不同的角度来看会有不同的结果，狭义来讲，算法只是些数学上的公式或技巧变通在计算机上的实现，广义来讲，应该还包括架构等等。公式是否正确，完全取决于人们对“程序”这个词语的主观理解，学生或老师也许会比较认同程序=数据+算法，但系统架构师大概会认为程序应该=数据+算法+结构，项目经理眼里的程序又或许=良好的用户体验，而作为一个市场经理他更多的会把程序等同于客户潜在的需求+未来的商机，不在其位不谋其政，关注的角度不同而已。
ps：banq的那段“象数之争”写的非常精彩