robbin 写道
你想做一个合格的程序员的话，你必须主动掌握业务，但是如果你想做一个既合格又高薪的程序员的话，你除了需要掌握业务，你还必须技术上很牛X才行
那么这个
技术是不是算法，是不是数学呢？我想强调的就是NO。这个技术是系统架构的技术，既要精确无误，又要坚不可摧，又要可以随时抽换，在结构复杂度上又要最小最低，维护成本最少，然后又要留有足够的可拓展性，等等等等。举个例子，javaeye的出发点到底是什么？如果没有ROR这样的架构，javaeye会出现么？如果反过来，没有那个文章相关性的算法，javaeye会无法出现么？到底是这个架构的技术比较本质一些，还是那个相关性算法比较本质一些？软件行业的几次革命，windows是由什么paper激发的？facebook是由什么算法革命激发的？推而广之，工业领域里的任何革命，究竟有几成是由发明创造驱动的？有几成是由成熟的市场和需求驱动的？后填装弹枪最早是何时诞生的？何时投入战场改变战斗结果的？蒸汽机最早是何时诞生的？何时融入工业体系变成生产力的？技术当然重要，这里的技术指的是“工程技术”而不是“学术技术”。学术本身永远是受现实制约，为现实服务，虽然有前瞻性但永远改变不了事物发展的内在规律的一个很无奈的东西，所以要出成绩不要搞学术，这是效率很低的策略，除非你天资特别好或者人格特别清高，没办法正经搞实务。
不要说什么搞架构的当民工，搞算法的高薪的高薪出国的出国所以学术才是程序员的最终目标共产主义一类话，资本家买空卖空财源滚滚，工人含辛茹苦辛苦埃命，那么你能说只有资本操作才是社会生产的本质么？软件领域这些年的变革，生产力的提升，我老实的说一句，都是千千万万程序民工熬夜通宵拿命拼过来的，绝对不是什么几十年前的大师睿智一拍脑袋凭空创造出来的，不要立几本书当圣经，没读过就是一辈子代码民工读深了就是大师就是万民膜拜，这种思维方式很宗教很原始，也许作为出发点的善意可以肯定，但当真就真的没必要了。偏激一点说，任何不是出自生产第一线的思维和构想，都是象牙塔空中楼阁，都只能当作达芬奇的直升飞机草稿放进博物馆里然后安心钉马车而已。当然你钉马车的工艺和技术一定要拔尖，不能满足于民工这个级别就完了，将来给你一个蒸汽机你就能装出一架火车头来，而不是看不起一切整天YY直升飞机才是人类交通工具的未来，马车毫无意义什么的，这才是程序员应有的技术态度。你想一想我们赞扬一个老师傅技术上很牛X，我们说的意思是他通晓交通工具的正确的哲学观念，能够预测其未来的变革和前景么？还是说他手艺好执行力强给他外装甲他就能做出坦克来？
分享到：
评论
那么如果没有a就没有b能推出a是b的本质，为什么没有a就没有c就推不出a是c的本质呢？那么如果“没有a就没有b能推出a是b的本质”成立的话是不是就可以推出“爱因斯坦他妈才是发现相对论的本质”呢？
那那,本总现在在培训中心接受无聊的入职培训,就顺便免费给你上上逻辑课.
所谓的因果关系,逻辑学上都是有严格定义的.不是说你觉得能推出来就能推出来.鉴于你对数学的厌烦，本人就勉为其难用冗长而不严谨的中文来表述一下,没有A就没有B，A是B的本质.以及没有A就没有B,没有B就没有C，于是A就是C的本质之间的区别.
在因果关系问题上，最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系，在既不存在充分条件、也不存在必要条件的情况下，就认为不存在因果关系了。二是将因果关系混同于统计相关性关系，找到了数据上的正相关，就以为找到了因果关系。
这两种错误，前者通常对应于单个经验事件或比较直接的因果关联，后者通常对应于大量经验事件或比较复杂的因果关联。今天台上小妞比较PP，本总心情不错就给你讲讲前半段.后半段想听就付钱过来.
比如讲某甲将某乙从五楼上推下来，某乙落地后死掉了。通常情况下，某甲应该为此负责，因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验，这个因果关系就不成立。因为即使某乙不被推下去，他也未必不死，所以某甲推某乙下楼不是必要条件。另一方面，如果某乙落地的地方刚好是一个充气垫子，或者某乙身负绝世轻功，那么他即使被推下去也未必死，所以这里也不存在充分条件。
这和我们的常识显然是相悖的。由此可见，因果关系不一定是充分条件关系，也不一定是必要条件关系。在这里我们需要INUS定义，它可以帮助我们解决这一问题。
INUS定义是一个叫马奇的人提出来的，所以它也被称为“马奇定义”。INUS是它的定义的缩写：
An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.（结果的一个不必要但是充分的条件中，一个不充分但是必要的组成部分）
这句话可以进一步简缩一下，就是：
所谓原因，就是结果的一个充分条件组中的一个必要组成部分。
也就是说，假设A和B是两个事件，那么在以下的情况下，我们称A是B的原因：
1、A加上其他某些事件，可以组成一个复合条件C，C是B的充分条件；
2、如果把A从C中间拿掉，C就不再是B的充分条件。
套用到我们上面的例子中，不难发现：
1、“某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件；
2、单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。
由此我们可以得到结论，“某甲推某乙下楼”是“某乙死亡”的原因。
当然，从上面我们也可以看出，一个结果通常不止一个原因。那么，什么是“主要原因”呢？被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。
比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该，或者去责问那块地的主人为什么不摆上一个充气垫子，这是因为我们在责任认定时，除了因果关系认定之外，还有“不能预计”、“不能选择”这样的免责条款。
又是一堆堆的废话，跑题千里啊。
我已经把推理过程说出来了。
没有a就没有b，没有b就没有c可以推出没有a就没有c。（有问题么？）
如果没有a就没有c，a就是c的本质成立的话。那么把爱因斯坦他妈代入a，爱因斯坦代入b，相对论代入c，结果是什么呢？那么是不是“没有a就没有c，a就是c的本质”这句话是错误的呢？
至于最后原因，你也说了，我看你也认识到了，就是原因不见得是本质原因，既然如此，算法就是软件开发的本质原因了？那么“Knuth,Dijiskala这种人成天捣鼓数学,不搞什么系统架构,也没搞出什么windows,facebook.高老头苦哈哈的写了10年的LaTex，还没有notepad用的人多.但是没有Dijiskala的振臂一呼说"GOTO Considered Harmful",搞什么架构啊,OO啊,DSL啊,都扯淡吧,想都甭想,连结构化编程都没有呢,你就成天对着goto 指令绕吧. ”提到的这些东西就成了软件开发的本质了？
那么如果没有a就没有b能推出a是b的本质，为什么没有a就没有c就推不出a是c的本质呢？那么如果“没有a就没有b能推出a是b的本质”成立的话是不是就可以推出“爱因斯坦他妈才是发现相对论的本质”呢？
那那,本总现在在培训中心接受无聊的入职培训,就顺便免费给你上上逻辑课.
所谓的因果关系,逻辑学上都是有严格定义的.不是说你觉得能推出来就能推出来.鉴于你对数学的厌烦，本人就勉为其难用冗长而不严谨的中文来表述一下,没有A就没有B，A是B的本质.以及没有A就没有B,没有B就没有C，于是A就是C的本质之间的区别.
在因果关系问题上，最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系，在既不存在充分条件、也不存在必要条件的情况下，就认为不存在因果关系了。二是将因果关系混同于统计相关性关系，找到了数据上的正相关，就以为找到了因果关系。
这两种错误，前者通常对应于单个经验事件或比较直接的因果关联，后者通常对应于大量经验事件或比较复杂的因果关联。今天台上小妞比较PP，本总心情不错就给你讲讲前半段.后半段想听就付钱过来.
比如讲某甲将某乙从五楼上推下来，某乙落地后死掉了。通常情况下，某甲应该为此负责，因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验，这个因果关系就不成立。因为即使某乙不被推下去，他也未必不死，所以某甲推某乙下楼不是必要条件。另一方面，如果某乙落地的地方刚好是一个充气垫子，或者某乙身负绝世轻功，那么他即使被推下去也未必死，所以这里也不存在充分条件。
这和我们的常识显然是相悖的。由此可见，因果关系不一定是充分条件关系，也不一定是必要条件关系。在这里我们需要INUS定义，它可以帮助我们解决这一问题。
INUS定义是一个叫马奇的人提出来的，所以它也被称为“马奇定义”。INUS是它的定义的缩写：
An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.（结果的一个不必要但是充分的条件中，一个不充分但是必要的组成部分）
这句话可以进一步简缩一下，就是：
所谓原因，就是结果的一个充分条件组中的一个必要组成部分。
也就是说，假设A和B是两个事件，那么在以下的情况下，我们称A是B的原因：
1、A加上其他某些事件，可以组成一个复合条件C，C是B的充分条件；
2、如果把A从C中间拿掉，C就不再是B的充分条件。
套用到我们上面的例子中，不难发现：
1、“某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件；
2、单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。
由此我们可以得到结论，“某甲推某乙下楼”是“某乙死亡”的原因。
当然，从上面我们也可以看出，一个结果通常不止一个原因。那么，什么是“主要原因”呢？被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。
比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该，或者去责问那块地的主人为什么不摆上一个充气垫子，这是因为我们在责任认定时，除了因果关系认定之外，还有“不能预计”、“不能选择”这样的免责条款。
讲得好，推荐一本书：
Probability Theory: The Logic of Science
程序的据结构只是数据的组织方式，算法才是实际数据运行时的关系
而数学建模本身就是指定数据如何动作的规则
说的真好，终于有人指出了至少还有数据结构。
不过数据结构这门学问可是和数据结构这门课完全不是一个概念。
这里的数据结构说白了就是建模
了解一下什么叫哲学概念上的意识
那么如果没有a就没有b能推出a是b的本质，为什么没有a就没有c就推不出a是c的本质呢？那么如果“没有a就没有b能推出a是b的本质”成立的话是不是就可以推出“爱因斯坦他妈才是发现相对论的本质”呢？
那那,本总现在在培训中心接受无聊的入职培训,就顺便免费给你上上逻辑课.
所谓的因果关系,逻辑学上都是有严格定义的.不是说你觉得能推出来就能推出来.鉴于你对数学的厌烦，本人就勉为其难用冗长而不严谨的中文来表述一下,没有A就没有B，A是B的本质.以及没有A就没有B,没有B就没有C，于是A就是C的本质之间的区别.
在因果关系问题上，最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系，在既不存在充分条件、也不存在必要条件的情况下，就认为不存在因果关系了。二是将因果关系混同于统计相关性关系，找到了数据上的正相关，就以为找到了因果关系。
这两种错误，前者通常对应于单个经验事件或比较直接的因果关联，后者通常对应于大量经验事件或比较复杂的因果关联。今天台上小妞比较PP，本总心情不错就给你讲讲前半段.后半段想听就付钱过来.
比如讲某甲将某乙从五楼上推下来，某乙落地后死掉了。通常情况下，某甲应该为此负责，因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验，这个因果关系就不成立。因为即使某乙不被推下去，他也未必不死，所以某甲推某乙下楼不是必要条件。另一方面，如果某乙落地的地方刚好是一个充气垫子，或者某乙身负绝世轻功，那么他即使被推下去也未必死，所以这里也不存在充分条件。
这和我们的常识显然是相悖的。由此可见，因果关系不一定是充分条件关系，也不一定是必要条件关系。在这里我们需要INUS定义，它可以帮助我们解决这一问题。
INUS定义是一个叫马奇的人提出来的，所以它也被称为“马奇定义”。INUS是它的定义的缩写：
An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.（结果的一个不必要但是充分的条件中，一个不充分但是必要的组成部分）
这句话可以进一步简缩一下，就是：
所谓原因，就是结果的一个充分条件组中的一个必要组成部分。
也就是说，假设A和B是两个事件，那么在以下的情况下，我们称A是B的原因：
1、A加上其他某些事件，可以组成一个复合条件C，C是B的充分条件；
2、如果把A从C中间拿掉，C就不再是B的充分条件。
套用到我们上面的例子中，不难发现：
1、“某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件；
2、单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。
由此我们可以得到结论，“某甲推某乙下楼”是“某乙死亡”的原因。
当然，从上面我们也可以看出，一个结果通常不止一个原因。那么，什么是“主要原因”呢？被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。
比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该，或者去责问那块地的主人为什么不摆上一个充气垫子，这是因为我们在责任认定时，除了因果关系认定之外，还有“不能预计”、“不能选择”这样的免责条款。
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
嗯嗯，貌似是这位女士：http://www.pmg.csail.mit.edu/~liskov/，著名的OO原则之一“里氏替换”原则的老妈。据说这个原则是这位大妈在1987年某次会议上的keynote（http://en.wikipedia.org/wiki/Liskov_substitution_principle），然后在十年以后，这些学院里面的劳什子成了某些群体在广大程序员中间制造个人崇拜的大杀器。正所谓“好事总得善人做，哪有凡人做神仙”
http://www.eurekalert.org/pub_releases/2008-02/cmu-cme020408.php
他的奖是2008年公布的.应该是07年.lisckov是今年公布的应该是08年.
囧，你这T1，害我丢人丢大了……不过今年貌似听到过同事说Liskov得奖是因为模型验证方面的研究，难道是幻觉
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
嗯嗯，貌似是这位女士：http://www.pmg.csail.mit.edu/~liskov/，著名的OO原则之一“里氏替换”原则的老妈。据说这个原则是这位大妈在1987年某次会议上的keynote（http://en.wikipedia.org/wiki/Liskov_substitution_principle），然后在十年以后，这些学院里面的劳什子成了某些群体在广大程序员中间制造个人崇拜的大杀器。正所谓“好事总得善人做，哪有凡人做神仙”
http://www.eurekalert.org/pub_releases/2008-02/cmu-cme020408.php
他的奖是2008年公布的.应该是07年.lisckov是今年公布的应该是08年.
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
嗯嗯，貌似是这位女士：http://www.pmg.csail.mit.edu/~liskov/，著名的OO原则之一“里氏替换”原则的老妈。据说这个原则是这位大妈在1987年某次会议上的keynote（http://en.wikipedia.org/wiki/Liskov_substitution_principle），然后在十年以后，这些学院里面的劳什子成了某些群体在广大程序员中间制造个人崇拜的大杀器。正所谓“好事总得善人做，哪有凡人做神仙”
这行当不热门吧，三年前的一天我前公司有个老人家在那里用黑板苦比划原材料的最佳生产安排时，我说“您用软件模拟生产按得出最优数值的组合不就行了？”他一拍大腿说天啊这还真是个方法
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
嗯嗯，貌似是这位女士：http://www.pmg.csail.mit.edu/~liskov/，著名的OO原则之一“里氏替换”原则的老妈。据说这个原则是这位大妈在1987年某次会议上的keynote（http://en.wikipedia.org/wiki/Liskov_substitution_principle），然后在十年以后，这些学院里面的劳什子成了某些群体在广大程序员中间制造个人崇拜的大杀器。正所谓“好事总得善人做，哪有凡人做神仙”
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主Edmund M. Clarke的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
另外这方面,目前工程化和应用化的做的也不错.Standford的 Dawson Engler 的一篇Paper拿到了OSDI08的Best Paper award .具体的可以看这里.
http://www.usenix.org/events/osdi08/tech/full_papers/cadar/cadar.pdf
KLEE可以为任意source code自动生成覆盖率达90%以上的Test Case。
Dawson自己对这篇paper的评价是：This is one of the very best we've done in the past ten years。当然人家也不是吹牛的.这个人现在是bug finding方面是个超级明星，他的工具为Linux Kernel，OpenBSD，EXT3等等找出了400百多个bug，他还用自己的研究成果startup了一个叫Coverity专做source code static analysis的公司，生意十分红火。
除了现有的算法成果以外,model checking仍然是一个有待深入探索的问题.比如Model checking的关键问题是test case的state explosion,随着程序路径的增加，测试状态呈几何级数增加.怎么降低状态数量,除了现在局部优化算法外最有希望的就是引入代数几何.http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.2570.不远的将来的测试工作就不再是依靠人肉苦力的堆积,而是需要专业的几何学家为工程师们设计自动化算法.
所以凡是你现在认为机器不可能做到需要以人类优雅高深的哲学思想解决的事情,都是计算机科学家数学家们现在捞钱的金饭碗.
说的真好，终于有人指出了至少还有数据结构。
不过数据结构这门学问可是和数据结构这门课完全不是一个概念。
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
debug也不属于软件设计的范畴
我提debug了吗？我提的是bug，设计上的bug。
只有吵架才计较对错
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
一个数学建模的大三学生如果认真学过，可以解决目前我们工作中软件核心模块（涉及）算法的95%以上的问题。
这是我在协助该学生完成软件开发作业时“惊见”的。
说的是软件设计，不是算法。
有句很经典的话：Algorithms + Data Structures = Programs
然。
当时那个作业貌似是一个杂货店商品分类，我也是5年经验了，用递归写出来的程序运行了半个小时，后来那个学生把那个题目之前他们老师的课件PPT发给我，是个*****算法，FT，写出来只需要几十秒。东西相当的复杂，以至于我现在都连题都记不清了。
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
一个数学建模的大三学生如果认真学过，可以解决目前我们工作中软件核心模块（涉及）算法的95%以上的问题。
这是我在协助该学生完成软件开发作业时“惊见”的。
说的是软件设计，不是算法。
有句很经典的话：Algorithms + Data Structures = Programs
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
debug也不属于软件设计的范畴
除去工具和语言的那层皮，软件设计是数学建模的一部分。
忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。
一个数学建模的大三学生如果认真学过，可以解决目前我们工作中软件核心模块（涉及）算法的95%以上的问题。
这是我在协助该学生完成软件开发作业时“惊见”的。
说的是软件设计，不是算法。