Y**G
发帖数: 1089 | 1 如果你用一个支持 fp 的动态语言。比如 ruby 或 python 等 |
c******o
发帖数: 1277 | 2 。。。
fp有fp的pattern
【在 Y**G 的大作中提到】
: 如果你用一个支持 fp 的动态语言。比如 ruby 或 python 等
|
n******t
发帖数: 4406 | 3 很多年前，能claim自己会xxx语言的人，同时也意味着这个人可以用xxx语言写出能用
的程序。不过随着时代变迁，这两个看起来似乎等同的事情，变得完全不沾边了。
为了让这些人能写出能用的程序，就有了design pattern这个东西。
【在 Y**G 的大作中提到】
: 如果你用一个支持 fp 的动态语言。比如 ruby 或 python 等
|
c****3
发帖数: 10787 | 4 design pattern是给比较笨的人用到。
会的人还是可以象以前那样，那些open source项目，没有谁用什么design pattern的
【在 n******t 的大作中提到】
: 很多年前，能claim自己会xxx语言的人，同时也意味着这个人可以用xxx语言写出能用
: 的程序。不过随着时代变迁，这两个看起来似乎等同的事情，变得完全不沾边了。
: 为了让这些人能写出能用的程序，就有了design pattern这个东西。
|
s*****V
发帖数: 21731 | 5 不能这么说，就像围棋的定式，入门的时候还是要学。 不会定式的肯定成不了高手，
拘泥于定式也没法成为顶尖高手。
【在 c****3 的大作中提到】
: design pattern是给比较笨的人用到。
: 会的人还是可以象以前那样，那些open source项目，没有谁用什么design pattern的
|
c******o
发帖数: 1277 | 6 那些open source项目的committer, 本身就是design pattern的创造者。
他们是第一批用design pattern的。。。
你要是觉得牛人不用design pattern就错了，他们才是开始用的人，然后觉得好，推广
开。
【在 c****3 的大作中提到】
: design pattern是给比较笨的人用到。
: 会的人还是可以象以前那样，那些open source项目，没有谁用什么design pattern的
|
c****3
发帖数: 10787 | 7 和围棋定式不同，定式是要学的。但design pattern 很多人从来不学这个，照样挺厉
害的。
我看到很多开源的项目，都是在校大学生做的，有的相当复杂。有人天生就有这种能力
，就像顶级黑客很多是十几岁的小孩一样。
【在 s*****V 的大作中提到】
: 不能这么说，就像围棋的定式，入门的时候还是要学。 不会定式的肯定成不了高手，
: 拘泥于定式也没法成为顶尖高手。
|
g*****g
发帖数: 34805 | 8 Design pattern is nothing but a common practice for a language. It doesn't
surprise me at all FP doesn't use OOP's design patterns. But FP does need
design pattern of their own. e.g. Scala needs this so called cake pattern.
【在 Y**G 的大作中提到】
: 如果你用一个支持 fp 的动态语言。比如 ruby 或 python 等
|
g*****g
发帖数: 34805 | 9 纯粹瞎说，你懂design pattern吗？
【在 c****3 的大作中提到】
: design pattern是给比较笨的人用到。
: 会的人还是可以象以前那样，那些open source项目，没有谁用什么design pattern的
|
Y**G
发帖数: 1089 | 10 Many pattern is for static typed language, for dynamic typed language, a lot
pattern is not needed.
I am not saying all patterns are not needed.
【在 g*****g 的大作中提到】
: Design pattern is nothing but a common practice for a language. It doesn't
: surprise me at all FP doesn't use OOP's design patterns. But FP does need
: design pattern of their own. e.g. Scala needs this so called cake pattern.
|
|
|
g*****g
发帖数: 34805 | 11 design pattern != GOF DP. Let's make this clear.
GOF DP are based on C++, what do you expect?
lot
【在 Y**G 的大作中提到】
: Many pattern is for static typed language, for dynamic typed language, a lot
: pattern is not needed.
: I am not saying all patterns are not needed.
|
c****3
发帖数: 10787 | 12 design pattern啥时候才有的。
很多人写电脑程序，就是为了解决实际问题，设计和思路都是从解决问题的角度出发的
。虽然可能设计和某种design pattern重合，但是人家不需要学习design pattern。
就像古代不少会打仗的人根本不认字，从来不看兵书，虽然战法和某种兵书重合，并不
等于他们学过兵书。
【在 g*****g 的大作中提到】
: 纯粹瞎说，你懂design pattern吗？
|
g*****g
发帖数: 34805 | 13 你武侠小说看太多了。至少在我常用的类库里里，从JDK到Spring，到处是design
pattern。
【在 c****3 的大作中提到】
: design pattern啥时候才有的。
: 很多人写电脑程序，就是为了解决实际问题，设计和思路都是从解决问题的角度出发的
: 。虽然可能设计和某种design pattern重合，但是人家不需要学习design pattern。
: 就像古代不少会打仗的人根本不认字，从来不看兵书，虽然战法和某种兵书重合，并不
: 等于他们学过兵书。
|
c****3
发帖数: 10787 | 14 你在大公司呆多了，这个社会上很多人，从来不研究design pattern，照样能写出很好
的程序。
【在 g*****g 的大作中提到】
: 你武侠小说看太多了。至少在我常用的类库里里，从JDK到Spring，到处是design
: pattern。
|
g*****g
发帖数: 34805 | 15 我老举的是写java的人人要用的著名类库, jdk, spring，都是开源的。比你这嘴巴一
张就胡扯强了1000倍。
【在 c****3 的大作中提到】
: 你在大公司呆多了，这个社会上很多人，从来不研究design pattern，照样能写出很好
: 的程序。
|
c****3
发帖数: 10787 | 16 你非要从java硬套，这个世界又不是都是java的。
写linux kenel的人，肯定没有几个用什么design pattern的。
【在 g*****g 的大作中提到】
: 我老举的是写java的人人要用的著名类库, jdk, spring，都是开源的。比你这嘴巴一
: 张就胡扯强了1000倍。
|
f*******t
发帖数: 7549 | 17 你以为linux kernel没有pattern?
【在 c****3 的大作中提到】
: 你非要从java硬套，这个世界又不是都是java的。
: 写linux kenel的人，肯定没有几个用什么design pattern的。
|
c****3
发帖数: 10787 | 18 我认为他们设计的时候，肯定没有考虑什么design pattern，文档里没有看到。
那些所谓的linux kernel design pattern的书，估计都是其他人看到设计以后，生搬
硬套design pattern进去的。
其中有个著名kernel的作者，是澳大利亚的麻醉师，这种人才不会有兴趣学什么design
pattern，他估计只是业余时间添砖加瓦，能让他设计的部分工作就行了
【在 f*******t 的大作中提到】
: 你以为linux kernel没有pattern?
|
g*****g
发帖数: 34805 | 19 kernal是c 写的。不套用gof很奇怪吗？ 本来就是 oop pattern.
design
【在 c****3 的大作中提到】
: 我认为他们设计的时候，肯定没有考虑什么design pattern，文档里没有看到。
: 那些所谓的linux kernel design pattern的书，估计都是其他人看到设计以后，生搬
: 硬套design pattern进去的。
: 其中有个著名kernel的作者，是澳大利亚的麻醉师，这种人才不会有兴趣学什么design
: pattern，他估计只是业余时间添砖加瓦，能让他设计的部分工作就行了
|
c****3
发帖数: 10787 | 20 OOP的也有很多人不用，Windows里面的应用程序在MFC时代，大部分是C++的，有几个用
什么design pattern 的。现在用的最多的，不还是网上下载的各种Windows下的程序
【在 g*****g 的大作中提到】
: kernal是c 写的。不套用gof很奇怪吗？ 本来就是 oop pattern.
:
: design
|
|
|
f*******t
发帖数: 7549 | 21 MFC程序质量如何你应该清楚吧。稍微写大点，不搞MVC就悲剧了。
貌似你对design pattern理解就是OOP书上那几个单词，这样要不得啊。来，看这篇文
章 http://coolshell.cn/articles/8961.html
【在 c****3 的大作中提到】
: OOP的也有很多人不用，Windows里面的应用程序在MFC时代，大部分是C++的，有几个用
: 什么design pattern 的。现在用的最多的，不还是网上下载的各种Windows下的程序
|
c****3
发帖数: 10787 | 22 我看网上那些independent programmer写的程序，比大公司写的质量还强点。MFC时代
，flashget，emule还有好多程序都质量挺好的。人家也不一定非要搞什么MVC才能设计。
反而是大公司搞出来的程序，都变成bloatware了，同样功能，速度慢，体积大，在
互联网上下载程序，特别明显能看出是个人还是公司写的。
搞 design pattern 还有agile 开发之类的流程，是因为参与开发的人太多，很多是大
妈转行编程的，水平参差不齐，需要控制。
条条大路通罗马，不用 design pattern 就不能编程了？design pattern 里面的设计
也不见得合适？
好多人似乎都是根据需要解决的问题去设计程序，需要解决什么问题，就会有相应设计
。不是非得根据问题，一定要套进某个design pattern才可以。
【在 f*******t 的大作中提到】
: MFC程序质量如何你应该清楚吧。稍微写大点，不搞MVC就悲剧了。
: 貌似你对design pattern理解就是OOP书上那几个单词，这样要不得啊。来，看这篇文
: 章 http://coolshell.cn/articles/8961.html
|
g*****g
发帖数: 34805 | 23 你懂个啥，boost之类类库，同样大量使用design pattern. dp 本来就是个模式的总结。
计。
【在 c****3 的大作中提到】
: 我看网上那些independent programmer写的程序，比大公司写的质量还强点。MFC时代
: ，flashget，emule还有好多程序都质量挺好的。人家也不一定非要搞什么MVC才能设计。
: 反而是大公司搞出来的程序，都变成bloatware了，同样功能，速度慢，体积大，在
: 互联网上下载程序，特别明显能看出是个人还是公司写的。
: 搞 design pattern 还有agile 开发之类的流程，是因为参与开发的人太多，很多是大
: 妈转行编程的，水平参差不齐，需要控制。
: 条条大路通罗马，不用 design pattern 就不能编程了？design pattern 里面的设计
: 也不见得合适？
: 好多人似乎都是根据需要解决的问题去设计程序，需要解决什么问题，就会有相应设计
: 。不是非得根据问题，一定要套进某个design pattern才可以。
|
b******0
发帖数: 101 | 24
瞎子阿炳估计不懂五线谱也整出了二泉映月。但是那就能说五线谱没用了？你这逻辑有
问题，建议好好琢磨琢磨模版。
【在 c****3 的大作中提到】
: 你在大公司呆多了，这个社会上很多人，从来不研究design pattern，照样能写出很好
: 的程序。
|
c****3
发帖数: 10787 | 25 design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
的理论和他们推崇的做事方法。
但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
不见得差。
这和五线谱是标准化音乐记谱符号，这是两回事。
【在 b******0 的大作中提到】
:
: 瞎子阿炳估计不懂五线谱也整出了二泉映月。但是那就能说五线谱没用了？你这逻辑有
: 问题，建议好好琢磨琢磨模版。
|
h*****a
发帖数: 1718 | 26 怎么可能Open source 里面没有design pattern?项目大了都要用已经成熟的pattern才
能scale.
【在 c****3 的大作中提到】
: design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
: 的理论和他们推崇的做事方法。
: 但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
: 不见得差。
: 这和五线谱是标准化音乐记谱符号，这是两回事。
|
h*****a
发帖数: 1718 | 27 这很正常。也许他们写的程序也恰好fit某个pattern，design pattern本质上就是工程
中总结出来的一些行之有效的经验，street smart和school smart的人在这个方面完全
可能殊途同归。
【在 c****3 的大作中提到】
: 你在大公司呆多了，这个社会上很多人，从来不研究design pattern，照样能写出很好
: 的程序。
|
c*********e
发帖数: 16335 | 28 en,design pattern还是很有用的，比如用interface,solid设计原则，abstract
factory 模式。。。
【在 n******t 的大作中提到】
: 很多年前，能claim自己会xxx语言的人，同时也意味着这个人可以用xxx语言写出能用
: 的程序。不过随着时代变迁，这两个看起来似乎等同的事情，变得完全不沾边了。
: 为了让这些人能写出能用的程序，就有了design pattern这个东西。
|
c****3
发帖数: 10787 | 29 这点我同意。design pattern就是一种做事方法的参考，你要清楚知道自己想干什么，
如何干什么，不见得需要这个参考。你要是稀里糊涂，当然是很需要这个参考。
这也是我说很多人不知道design pattern也可以做的很好。
【在 h*****a 的大作中提到】
: 这很正常。也许他们写的程序也恰好fit某个pattern，design pattern本质上就是工程
: 中总结出来的一些行之有效的经验，street smart和school smart的人在这个方面完全
: 可能殊途同归。
|
c*******9
发帖数: 9032 | 30 这要看你做什么事情，像黑客程序不需要多少design pattern。而大型应用程序没
design pattern就一团mess了。
MFC也不适合大程序，编小程序容易，一复杂就不行了。当然，有些人就喜欢在混乱中
找条理（这些人脑子里其实也有些pattern），但不是所有人都这样，没有design
pattern也难以合作。fp编程对传统design pattern依赖也小了，是因为fp本身的逻辑
很清晰，其实已经把
design pattern融汇贯通了，不需要明显提出来。比如haskell的一些monad，就和
decoration pattern，AOP起类似作用。
【在 c****3 的大作中提到】
: design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
: 的理论和他们推崇的做事方法。
: 但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
: 不见得差。
: 这和五线谱是标准化音乐记谱符号，这是两回事。
|
|
|
z****e
发帖数: 54598 | 31 dp是一套规则的总结
嘴巴上不用dp的并不代表他们真的不按照那一套规则去做
比如google的guava的newArrayList
这就是factory模式，只不过不象一般人那样命名成build
代码写多了，每个人都有自己一套编码哲学
当然这个哲学会有所差异，但是并不代表这些哲学互相之间是互斥的
通过了解dp可以明白别人在做什么，有什么经验
通过运用dp可以使自己不再重复前人已经犯过的错误
这就是dp的目的，当然挡不住有人喜欢一而再再而三地把前面的人犯的错误再犯一次
c++ programmers大部分都属于这类，尤其是现在还在这个屎坑里面折腾的
dp只是其中一种选择罢了，就像os一样，不了解os一样可以写出代码来
一再重复的说法，人区别于动物，善假于物
写linux kernel的固然牛，但是如果认为将来五百年
人来还需要一再重写这个kernel的话
或者是认为只有知道kernel怎么写才能够开发的人
那这个就有问题了，是属于不懂得学习
不知道自己在做什么的人
【在 c****3 的大作中提到】
: 这点我同意。design pattern就是一种做事方法的参考，你要清楚知道自己想干什么，
: 如何干什么，不见得需要这个参考。你要是稀里糊涂，当然是很需要这个参考。
: 这也是我说很多人不知道design pattern也可以做的很好。
|
z****e
发帖数: 54598 | 32 显然是一回事
搞各种理论的人都尝试着从某种方式上抽象现有技术并完善所有项目的开发
就像很多人不知道五线谱，一样可以唱歌，一样可以唱卡拉ok
为什么不行？当然因为有人可以不看曲谱就唱歌就否定五线谱的作用
那这个就属于不靠谱的
当然抽象出来的各种理论有对有错，本身也不是绝对正确的
很正常，fp也不过是一种抽象罢了
看不懂dp的人多数都缺乏实际编程经验
很多时候可以明显感觉出来
这个家伙不懂，不懂为什么别人会搞出dp这个东西，思维方式无法抽象出来
也不勉强就是了，很多人iq的确达不到去驾驭项目的地步
说来说去就好比航母指挥官跟一个狙击手在谈
狙击手说，你那一套有什么用？我不知道什么是补给舰一样可以打战
【在 c****3 的大作中提到】
: design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
: 的理论和他们推崇的做事方法。
: 但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
: 不见得差。
: 这和五线谱是标准化音乐记谱符号，这是两回事。
|
z****e
发帖数: 54598 | 33 然
dp其实只是实践的起步
真正的后续是通过发布dp实现的类库
并推广这个类库
最后在大规模流行之后，将这个dp制定成标准发布
强行要求所有人遵守，这才是整个流程的最后一步
aop和fp其实都没有实现最后标准化那一步
群众排斥太强烈，实际上很多人也的确不知道这两个东西
【在 c*******9 的大作中提到】
: 这要看你做什么事情，像黑客程序不需要多少design pattern。而大型应用程序没
: design pattern就一团mess了。
: MFC也不适合大程序，编小程序容易，一复杂就不行了。当然，有些人就喜欢在混乱中
: 找条理（这些人脑子里其实也有些pattern），但不是所有人都这样，没有design
: pattern也难以合作。fp编程对传统design pattern依赖也小了，是因为fp本身的逻辑
: 很清晰，其实已经把
: design pattern融汇贯通了，不需要明显提出来。比如haskell的一些monad，就和
: decoration pattern，AOP起类似作用。
|
b*******s
发帖数: 5216 | 34 基本java就是这个套路，语言本身简单，限制重重，虽然实现点东西很笨拙但是也不容
易出大问题，然后一部分牛人实现一些框架（各种patterns），一群打下手的印度人来
填代码
不过很适合大项目
【在 c****3 的大作中提到】
: design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
: 的理论和他们推崇的做事方法。
: 但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
: 不见得差。
: 这和五线谱是标准化音乐记谱符号，这是两回事。
|
b*******s
发帖数: 5216 | 35 应用场景的抽象
结。
【在 g*****g 的大作中提到】
: 你懂个啥，boost之类类库，同样大量使用design pattern. dp 本来就是个模式的总结。
:
: 计。
|
b*******s
发帖数: 5216 | 36 这个人说得差不多，供您参考：
java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
default value，都能简化至少一半的API。
就因对世界的复杂性而言，任何语言都是一样的。
世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
的根源。
比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
语言会选择通过API来支持，
而java更倾向于弄一套framework，或者design pattern来支持。
你可以说这是作为一个enterprise级语言的考虑，但我想说的是，如果任何时候都需要
这么做，那overhead太大了。
Java语言的基本思路就是，人力是廉价的，所以即使有些overhead，只要这种设计能通
过堆人力来解决，那么就这么做。
这种思路只适合于工人，不适合于像我这样的另一类人。
至于java的生态圈积累，其实java是另一种思路。java为了跨平台，更倾向于从底层开
始构造整个生态圈，所以java的生态圈是封闭的。
经常是一套现有的东西java下不直接用，选择重做一套。比如BLAS/LAPACK，首发1980
年，比java本身还要老很多的库。
java下来个JBLAS，用java重写实现。因为即使用JNI也会因为overhead过大的问题，效
率还未必有purejava写的高。你说这种积累，算是加分还是减分呢？
比如Jython，虽然语法跟Python没区别，但真严肃的用起来，跟Python世界完全是两码
事。
至于teamwork，我是这个观点，只有彼此水平相当的人才具备teamwork的基础，否则只
能形成上下级关系，你做核心他打下手，这种模式本身就没啥沟通成本。
勉强要合作也会变成拖累关系，整个项目被水平最差的人拖累。而同风格同水平的人之
间的沟通本来就是很流畅的，本身合作的重点就在于人，如果有个人跟你有矛盾，然后
两人写的代码还能合作无间，这种事情我不认为是可能的。
Java跟Python在基本思路上就不一样。Java把人作为工业生产的一个组件加以限制和管
理，Python更强调人作为编程这种智力创造的核心地位的重要性。
所以Java随便找个人培训培训也能上岗写出不是那么烂的代码，一个团队上百人是必须
的，每人日产代码>3K行也是压力不大的；Python则完全不可能，所以Python更强调
coding的效率，更需要体现个人的价值。
Java以重量级为荣，以代码写了多少百万/千万行为荣，而Python一般是以代码写的多
为耻的。
所以说穿了就是理念之争，其实我也从来不想去说服Java派的人转向Python，这两类人
从风格上可以说是矛盾的两面。我只有在出现过于低劣的帖子，或者高质量的讨论贴，
或者无聊的时候才会出来冒个泡。
【在 z****e 的大作中提到】
: dp是一套规则的总结
: 嘴巴上不用dp的并不代表他们真的不按照那一套规则去做
: 比如google的guava的newArrayList
: 这就是factory模式，只不过不象一般人那样命名成build
: 代码写多了，每个人都有自己一套编码哲学
: 当然这个哲学会有所差异，但是并不代表这些哲学互相之间是互斥的
: 通过了解dp可以明白别人在做什么，有什么经验
: 通过运用dp可以使自己不再重复前人已经犯过的错误
: 这就是dp的目的，当然挡不住有人喜欢一而再再而三地把前面的人犯的错误再犯一次
: c++ programmers大部分都属于这类，尤其是现在还在这个屎坑里面折腾的
|
m*******l
发帖数: 12782 | 37 java现在不是好像支持default value了么?
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
b*******s
发帖数: 5216 | 38 转载
【在 m*******l 的大作中提到】
: java现在不是好像支持default value了么?
|
z****e
发帖数: 54598 | 39 我这么跟你说
我认为cs没有什么东西是不可以通过堆人力搞定的
如果不可以通过堆人力搞定
那这个问题其实不是cs的问题
是数学或者物理的问题
最差最差也是统计的问题
统计有些模型，不懂就是不会，实际上统计如果抛除数学证明
其实统计也很容易，也是可以通过堆人力搞定的，最典型的就是actuary
拼命做题就可以过actuary的考试
但是cs，所有的东西都是借用其他学科的知识
然后作出一点应用在各行各业
没了
这就是cs的全部，所以如果你跟我说cs有什么是需要思考的
我只能说，你少装了
真想思考，去搞数学，基础数学欢迎你
你会在那边得到真正的思考
实际上大多数cs的难题都被划归到数学题里面去
就像p!=np这种
我不否认这个东西有益，但是如果你在现实中还在讨论这种问题
那我只能说，这个项目可行性分析这一步没有做
麻烦做一下可行性分析
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
z****e
发帖数: 54598 | 40 cs最大的问题就是很多programmers总认为自己比其他programmers要牛叉一些
但其实完全不是那么一回事，我相信人性是有共通点的
三会犯的错误，你一样会犯，你信不信？
就像你数学再怎么深入，百以内的加减有时候还是会算错
数学教授在黑板上算错，那是太正常不过的事了
所以控制犯错，很重要，不要指望人不会犯低级错误
这不现实，其实水母python那个大坑就是google程序员犯错的结果
【在 b*******s 的大作中提到】
: 基本java就是这个套路，语言本身简单，限制重重，虽然实现点东西很笨拙但是也不容
: 易出大问题，然后一部分牛人实现一些框架（各种patterns），一群打下手的印度人来
: 填代码
: 不过很适合大项目
|
|
|
z****e
发帖数: 54598 | 41 我相信的是
一个军队里面，人的素质有高有低
有甲种师团，也有乙级师团
还有航空兵和装甲兵
有开航母的，也有狙击手
所以如何训练这些人，并把这一群人捏合成一个整体
最后形成战斗力，是最重要的
其他一切都给我靠边站
所以当一个狙击手上来说，我一个顶十个的时候
其实我是不在乎的
因为我不是狙击手
如果你是狙击手，你一个顶十个，但是即便拥有了你
我还是不能打胜战，因为队伍里面有新兵，on average而言
不会有太大差异，我在乎的是如何用自己四十万歼灭敌人六十万
所以你跟我算十个还是五个，我只能表示你这个还没入门
这就好比在公司，公司里也是，铁打的营盘，流水的兵
谁知道明天换谁来做，昨天这些东西又是谁在做
这都是不确定的，那这个时候，我如何跟这些良莠不齐的人合作
是一个很重要，甚至可以说是首要考虑的问题
否则项目失败，那项目失败的次数多了，人家还会愿意雇你么？
拿人钱财，替人消灾，赶紧把事情做完是王道
这就是我们作为一个software engineer最基本的professional
就好比你解说足球不能大喊，他不是一个人在战斗一样
足球解说是一分工作，不是说不可以做球迷
但是要做球迷，回家做去，不要带入工作中来
在工作时候，请严肃认真地对待这份工作
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
z****e
发帖数: 54598 | 42 自己用反射写一个也就是分分钟的事
不过这在军队里是属于校官级别的活
【在 m*******l 的大作中提到】
: java现在不是好像支持default value了么?
|
z****e
发帖数: 54598 | 43 另外这个人显然不懂什么是python的哲学啊
python不需要创造力
创造力在python programmers看来，是一种原罪
python只允许一种回字的写法
超过一种并鼓励超过一种写法的那是ruby
用python来装逼真是非常愚蠢
说明这个人压根没写过python也没写过java
既不具备创造力也不具备职业素质
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
z****e
发帖数: 54598 | 44 有基佬说过写java是job
写python是乐趣
这个倒是有可能
但是审美哲学有所差异
我就喜欢这种一板一眼的美
就像军队一样，整齐划一
而不是随意乱搞，搞得跟武林高手一样
其实我本人对于武侠没有什么太多偏好
打心眼不是很看得起武侠小说
所以对我来说，工作和生活还比较完美地结合在了一起
据说蒙哥马利元帅退休以后
把整个花园都弄得横平竖直的
所有的小道都是直的，没有弯的
嗯，我觉得蛮好 |
z****e
发帖数: 54598 | 45 python就是一游击队
没有怎么经过训练
不懂怎么打战
适合小规模骚扰敌人
当然游击队可能演化成人民战争的汪洋大海
但是现代兵器时代
人民战争最后更有可能演化成种族屠杀的好借口
ruby倒是像是一个有点变化的棋手
你跟他下棋，需要费点心思去思考
python就是瞎打，打到哪算到哪
看过那个电影猎杀u-571没？
主角一开始被舰长认为不适合做舰长
为什么？不是他不够好，是他在关键时刻
不懂得取舍，如果不能果断地下命令舍弃小部分利益换取大利益的话
最后会害死所有人
然后猎杀u-571最后一刻，他们用来做诱饵的潜艇被炸沉
主角在被猎捕到的u-571上，看到舰长在水里，还活着，想去救舰长
舰长看到了，却对他喊，dive！
然后舰长就挂了，这就是男性的世界，红果果的利益计算
没有谁是不可或缺的，该干掉你的时候
ceo又怎样？founder又怎样？jobs都能滚出苹果，更何况是其他人
别太把自己当回事 |
z****e
发帖数: 54598 | 46 如果用钢铁雄心里面的师装备来衡量的话
java至少是1936年步兵师，最差也是1934年步兵师
c++则是1918年步兵师，处于一战水准
跟马上即将开打或者说已经开打的二战相比
有代差，j2ee是1939年步兵师，全面开打的主力师团装备
big data时代产物是41年步兵师，高潮了 |
z****e
发帖数: 54598 | 47 打战，写代码做项目就跟下围棋一样
不要太过于在乎一城一地的得失
否则你的主力会围起来被全歼
男性世界里大多数东西都有类似的特点
踢球也差不多，一个人不成事，踢球是十一个人的运动
当年利比里亚有世界足球先生维阿
结果利比里亚还是踢得跟屎一样，因为一个人不成事
所以男性必需很清楚大利益在哪里
搞不清楚这个的，最后吃亏的是自己 |
a****n
发帖数: 1887 | 48 MFC framework的基础就是template methods...
【在 c****3 的大作中提到】
: OOP的也有很多人不用，Windows里面的应用程序在MFC时代，大部分是C++的，有几个用
: 什么design pattern 的。现在用的最多的，不还是网上下载的各种Windows下的程序
|
a****n
发帖数: 1887 | 49 不知道你说的大程序是多大， 金山WPS 是MFC 写的， 虽然现在消失了
【在 c*******9 的大作中提到】
: 这要看你做什么事情，像黑客程序不需要多少design pattern。而大型应用程序没
: design pattern就一团mess了。
: MFC也不适合大程序，编小程序容易，一复杂就不行了。当然，有些人就喜欢在混乱中
: 找条理（这些人脑子里其实也有些pattern），但不是所有人都这样，没有design
: pattern也难以合作。fp编程对传统design pattern依赖也小了，是因为fp本身的逻辑
: 很清晰，其实已经把
: design pattern融汇贯通了，不需要明显提出来。比如haskell的一些monad，就和
: decoration pattern，AOP起类似作用。
|
c*******9
发帖数: 9032 | 50 金山WPS 这个级别的估计多数程序不会用MFC的库，最多大框架用一下。
【在 a****n 的大作中提到】
: 不知道你说的大程序是多大， 金山WPS 是MFC 写的， 虽然现在消失了
|
|
|
x****u
发帖数: 44466 | 51 结构化存储等等过时技术的实现还是很有必要用MFC的。
【在 c*******9 的大作中提到】
: 金山WPS 这个级别的估计多数程序不会用MFC的库，最多大框架用一下。
|
M****z
发帖数: 1058 | 52 中肯，而且没有因为形式而丧失对本质的追求和判断
当然也不是说所述都是对的
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
M****z
发帖数: 1058 | 53 翻了下你在这个帖子里的回帖，其实是表达的时候有些偏差。表达偏差后正好触碰到一
些业内常识概念的所谓底线。然后好多人从这个角度进行争论。其实大家讲的大体都没
错，只不过讲的既不是同一个空间维度，又不是同一个时间维度维度上的问题。
【在 c****3 的大作中提到】
: design pattern和agile一样，是做事和思维的方法，就是有人出了书，同时sell他们
: 的理论和他们推崇的做事方法。
: 但其他人有不同做事和思维的方法，不用design pattern的方法，一样可以做，效果也
: 不见得差。
: 这和五线谱是标准化音乐记谱符号，这是两回事。
|
a*w
发帖数: 4495 | 54 builder pattern不是用来解决default value这个问题的。
【在 b*******s 的大作中提到】
: 这个人说得差不多，供您参考：
: java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
: default value，都能简化至少一半的API。
: 就因对世界的复杂性而言，任何语言都是一样的。
: 世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
: 的根源。
: 比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
: 当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
: 语言会选择通过API来支持，
: 而java更倾向于弄一套framework，或者design pattern来支持。
|
r*******n
发帖数: 3020 | 55 MFC设计的很差；
现在网上各种windows程序，用MFC的不多吧
【在 c****3 的大作中提到】
: OOP的也有很多人不用，Windows里面的应用程序在MFC时代，大部分是C++的，有几个用
: 什么design pattern 的。现在用的最多的，不还是网上下载的各种Windows下的程序
|
a*w
发帖数: 4495 | 56 MFC是老一代的技术。
说它差，它可是把OWL给干掉了。
【在 r*******n 的大作中提到】
: MFC设计的很差；
: 现在网上各种windows程序，用MFC的不多吧
|
g*********e
发帖数: 14401 | 57
你这个观点不对。未来人可以不写linux Kernal，可以只work at highly abstracted
level，但还是要知道kernal该怎么写，需要让他写的时候必须得写得出来。否则知识
就没法传承。
“喜欢一而再再而三地把前面的人犯的错误再犯一次” 就跟写kernal一样，不经历这
些，只是利用别人已有的公式成果的话，有一天估计连电脑都造不出来了。
【在 z****e 的大作中提到】
: dp是一套规则的总结
: 嘴巴上不用dp的并不代表他们真的不按照那一套规则去做
: 比如google的guava的newArrayList
: 这就是factory模式，只不过不象一般人那样命名成build
: 代码写多了，每个人都有自己一套编码哲学
: 当然这个哲学会有所差异，但是并不代表这些哲学互相之间是互斥的
: 通过了解dp可以明白别人在做什么，有什么经验
: 通过运用dp可以使自己不再重复前人已经犯过的错误
: 这就是dp的目的，当然挡不住有人喜欢一而再再而三地把前面的人犯的错误再犯一次
: c++ programmers大部分都属于这类，尤其是现在还在这个屎坑里面折腾的
|
g*****g
发帖数: 34805 | 58 术业有专攻，当然得有人会写os，但大多数程序员不需要会。
abstracted
【在 g*********e 的大作中提到】
:
: 你这个观点不对。未来人可以不写linux Kernal，可以只work at highly abstracted
: level，但还是要知道kernal该怎么写，需要让他写的时候必须得写得出来。否则知识
: 就没法传承。
: “喜欢一而再再而三地把前面的人犯的错误再犯一次” 就跟写kernal一样，不经历这
: 些，只是利用别人已有的公式成果的话，有一天估计连电脑都造不出来了。
|
c*******9
发帖数: 9032 | 59 Owl本来不比mfc差，但因没控制权，导致很多人觉得mfc更可靠。
【在 a*w 的大作中提到】
: MFC是老一代的技术。
: 说它差，它可是把OWL给干掉了。
|
x****u
发帖数: 44466 | 60 差远了，最致命问题是没有搞清楚COM的意义何在。
【在 c*******9 的大作中提到】
: Owl本来不比mfc差，但因没控制权，导致很多人觉得mfc更可靠。
|
|
|
g*******t
发帖数: 7704 | 61 windows的架构是com， 从windows的数据接口看，都是struct数据，所以windows很可
能是c开发的， 和OPP没任何关系，
所以系统架构和design pattern没什么关系， os系统架构是建立在一系列资源管理算
法上，
目前有意思的是android和ios比较， android架构显然没有ios好， |
c*******9
发帖数: 9032 | 62 COM本身就是抄袭CORBA的。那玩意让程序变的很恶心。
【在 x****u 的大作中提到】
: 差远了，最致命问题是没有搞清楚COM的意义何在。
|
F*M
发帖数: 104 | 63 扯淡，我更经常是被迫读恶心的代码。
【在 c****3 的大作中提到】
: 你在大公司呆多了，这个社会上很多人，从来不研究design pattern，照样能写出很好
: 的程序。
|
F*M
发帖数: 104 | 64 还是在谈一些形而上学的东西。
design pattern是程序员经验的总结，其实你的话已经回答的你自己 "好多人似乎都是
根据需要解决的问题去设计程序，需要解决什么问题，就会有相应设计"。。。
如果你还在思考套哪个pattern，说明你的火候还不够。不懂design pattern, 不代表
不在用，用了但是不知道其实那是一种design pattern。
计。
【在 c****3 的大作中提到】
: 我看网上那些independent programmer写的程序，比大公司写的质量还强点。MFC时代
: ，flashget，emule还有好多程序都质量挺好的。人家也不一定非要搞什么MVC才能设计。
: 反而是大公司搞出来的程序，都变成bloatware了，同样功能，速度慢，体积大，在
: 互联网上下载程序，特别明显能看出是个人还是公司写的。
: 搞 design pattern 还有agile 开发之类的流程，是因为参与开发的人太多，很多是大
: 妈转行编程的，水平参差不齐，需要控制。
: 条条大路通罗马，不用 design pattern 就不能编程了？design pattern 里面的设计
: 也不见得合适？
: 好多人似乎都是根据需要解决的问题去设计程序，需要解决什么问题，就会有相应设计
: 。不是非得根据问题，一定要套进某个design pattern才可以。
|
