作者StubbornLin (Victor)
看板i-enterprise
标题Re: [请益] 网路创业大部分的网站规划都是用PHP吗?
时间Fri Jan 15 15:26:23 2010
※ 引述《gpmm (银色)》之铭言：
: http://blog.ez2learn.com/2010/01/08/how-to-compare-languages/
: 让我们从头开始：
: 0. 但是大多数人不知道程式语言该比较些什麽，而我今天所要说的，
: 就是程式语言该拿什麽来比较
: 1.1 一个程式的可读性，关系到维护的人能否轻易的了解程式语言所表达程式的意图，
: 如果维护的人难以理解某段程式所要表达的事情，那麽这些程式就难以被维护
: 可读性的开头说明了，你的可读性评比目的在此，难以被维护。
: 如果你站在语言规范这样抽象的角度看，同意。
: 如果你站在一个实用的角度看，降低可读性是为了其他目的，
: 例如多元开发，那麽这里所讲的能当成「评定优劣」的方式吗？
我不知道你有没有从一个很重要的角度来看一款语言，
那就是从商业的角度来看，我所提到的都是在实务上的经验
也就是包含了商业的考量
你知道当我看到
$$ $% $^ $&
你知道我看到了什麽吗?
我看到都是钱钱钱钱钱钱钱阿!!!
如果我主导的专案都用Perl来开发
这麽一来我的code浪费在很多时间在我上面文章提到的问题上
包括一直查手册，google搜寻不到语法等问题上
$/那类肮脏的写法让程式一直在debug的回圈中
我专案的成本一直在增加...
生产力因此而下降
因为语言的天性
做为一个好的工程师不只是看见自己喜欢看见的东西
你有看过Discovery之类的工程奇观之类的节目吗?
你有看见工程师在设计选用建材等等
是靠喜好决定的吗?
成本影响设计也是很重要的
要在设计、成本等等方面要能达到平衡的状态
才是好的决择
当然，反对我的人说，那是写程式的人烂
他写不出好的Perl，好的Perl一样可以维护
但我会说...
"喔.. Perl的语法这麽自由，你要去哪里找来这一堆写出良好Perl的程式设计师?"
"还有你找这些高手Perl设计师来作什麽? 我们专案的经费付担得起吗?"
"我们需要的是一般的程式设计师"
嗯哼，那你又会说
"嘿，我们可以定语法的风格，严格规定每个程式设计师都这样写"
好吧，这样是可以规定，但是能落实多少? 规定讨论怎样才是好的Perl程式是不是成本?
落实检查好的Perl写法是不是成本?
再者，请问规定风格语法是在做什麽? 答案很清楚
"限制"
欧，那Perl不是一款
"There's more than one way to do it"
的语言? 有人这样说，我们在现实生活中，可以有很多手段完成同一件事
所以Perl自然这样做也有道理，如果只是随意个人撰写，我认同这样的说法
但是像我们在实务上看到的，都是
"限制"
对，语法风格有限制，档案命名有限制，文件怎麽写有限制，这一切都是在限制
你有没有看过一家大型企业没有SOP的?
他们在做什麽? 做的就是限制
为什麽要限制? 为什麽不自由?
为的是能让企业的运作一致
为了让运作有案可循
那，既然我们在实务开发，为什麽需要一款那麽自由的语言
花费额外的成本来增加限制在其上面?
我之所以选择和喜爱Python
就是因为它是一款限制性强的语言，所以使用Python
他本身限制性就强，写出烂程式的机会也是有
但是比较少，而且还有其它很多理由
都让我选择Python
因为我看到的不只是语言
而是成本
为什麽拿Python跟Perl比?
我的文章里写的很清楚
因为他们的哲学刚好相反
: 1.2 可读性很明显地 Python 优於 Perl，我在这里说明为什麽，
: 原因其实很简单，因为Perl加太多语法和用太多特殊符号在他的语言中
: Perl对於这些琐碎的功能加了太多的语法，
: 使得用Perl写出来的程式难以被简单的理解
: 很好，Perl 相较於其他语言的确是较难阅读，因为他有特殊的设计，
: 从语言规范的抽象角度看，语言要尽可能容易被人理解，
: 但是从实用的角度看，有目的的降低可读性，是可以在别处获得回报。
: 当你不阐明，你的论点就会落在更大的立场上
两害相衡取其轻，只为了一点点好写就牺牲可读性
这没什麽好谈的
"程式被读比被写还多次"
一个成本可能是80%，一个是20%，你是老板，你要节省哪个成本?
: - 也就是你的可读性既涵盖了语言本身的概念，也包括了动机和目的
: 1.3 因为用语法来实现太多功能，某种程度上算是不良的设计，
: 因为他们都能够用函式或函式库来取代，而函式库的取代虽然要写多一点字，
: 但是可读性大大提升…
: 我不明白既然你现在告诉大家你的标准在於语言规范，
: 此处提出的以「函式」取代语法是指什麽？
: Perl 也可以用函式来取代语法，
: 你并不能说大家会被符号宠坏所以就扔掉这一点。
请问这两个哪个好记?
好从字意上猜到答案?
www.sex.com
123.111.222.1
你会把你的公司网址就只用ip当名字吗?
没有扔掉它阿，只是基於成本和各方面的考量
可读性差使他不在我选择的名单之内
: 1.4 可读性的差别就是这些语言的天性，也是判断程式语言优劣的关键之一
: 又一个很好，请问你从可读性连结到「判断程式语言优劣的关键之一」
: 之间到底是透过什麽？
: 你如果写「是从语言规范来判断程式语言优劣的关键之一」，
: ok，我接受。
: 这就是我们对於可读性基准的不同，
: 你的基准只在於语言规范，我则涵盖了背後「降低可读性」的原因和动机。
: 如果硬是要拿现在的设备进步，来无视当年（或现在仍是）语言本身追求的东西，
: 那会不会也太没 sense 了？
世界上没落的语言何奇多
我指的缺点就是他们没落的原因
一款语言本身很多特性使得他不受喜爱
那他就没落了，就是这麽简单
Python也是15年前或更早之前开始的
Ruby其实也差不多是在那附近开始发展的
也没多晚，而Perl一直听说在改版
但是都只闻楼梯声，当一款语言不改版
太多问题让人嫌弃，那语言就会没落
你有看见现在多少人还在用Perl写CGI?
我那个年代一堆网页程式不是Perl就是C写的
有更好的选择，自然他们就没落了
基於成本和工程上的各种考量
为什麽要用旧的东西?
你会不会跟你老板说
"嘿，用现在的技术比十年前的技术太不公平了啦
在那个年代之下用C写CGI也很情合理阿
我们用C写CGI吧"
欧喔... 那我只能说你会被开除
商业市场、实务应用是残酷的
哪边好用就倒向哪边
不知改进者就将被淘汰
在以前被淘汰的你没听过的语言多不可数
没什麽好大惊小怪的
: 所以我说，请好好想想，你探讨这个程式语言优劣的基准和标的是什麽，
: 如果你只是纯就「语言规范」上检讨，不考虑其前後，
: 那就好好标明这是从「语言规范」下的「可读性」来评断程式语言，
: 当你没有阐明你站在「语言规范」的基准，却又以一种宏观的立场告诉大家，
: 可读性的差别就是这些语言的天性，也是判断程式语言优劣的关键之一。
: 这样恰当吗？
我说过是从各方面，当然也包含实务
请你想像一下你自己是老板
你要决定用哪一款工具
或是你要说服你老板用哪一款工具
你会怎样解释
我想这样你就能更了解我所说的那些观点
--
Now.in 网路广播平台
http://now.in
哇咧咧 创意投票系统
http://walele.com
易记学 程式设计教学
http://ez2learn.com/
VICTOR's 个人Blog
http://blog.ez2learn.com/
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 111.252.68.181
1F：推 reflynet:现在一堆人用C#写网页啊XXD 01/15 17:28
2F：→ crazybad:给1F，用C#写的是ASP.NET，清醒一点～..............路过 01/15 18:09
3F：推 bobju:一系列看下来,StubbornLin 的确很有说服力.如果我是老板,我 01/15 19:45
4F：→ bobju:也要采用python了. XD 01/15 19:45
5F：→ bobju:其实程式语言也是要面临'物竞天择'的考验,每一种语言都有其 01/15 19:47
6F：→ bobju:设计精神,也反映出时空背景的某些需求.只是时空会变化,当它 01/15 19:49
7F：→ bobju:不再适用於新的时代需求时,自然就被淘汰了. 01/15 19:49
8F：→ bobju:以前awk还蛮popular的,现在大概已找不到有人在用了.搞不好连 01/15 19:51
9F：→ bobju:听都没听过. 01/15 19:51
10F：→ minstrelsy:这个说法跟可读性还有程式语言的优劣有关吗? 01/15 19:57
11F：→ minstrelsy:这只是说明了随着时代变迁某些语言会受到不同的重视 01/15 19:58
12F：→ minstrelsy:拿这样来判断说某个语言比另一个语言好 也不是不行 01/15 19:59
13F：→ minstrelsy:但这是政治考量跟商业考量 跟可读性什麽的有很大关系吗 01/15 19:59
14F：→ minstrelsy:顶多只能说明python比起perl来说 现在的人比较马上看懂 01/15 20:02
15F：→ minstrelsy:而商业考量跟可读性也不必然有关 C有很多不好懂的部份 01/15 20:04
16F：→ minstrelsy:但实际应用上还是一大堆地方在用 顶多是边用边骂而已 01/15 20:05
17F：→ minstrelsy:C的商业应用之广泛跟许多C难以理解的怪写法就不用举例 01/15 20:07
18F：→ StubbornLin:可读性只是一小部份，还有太多要考量了 01/15 22:24
19F：→ StubbornLin:可用现成的函式库、资源有多少 01/15 22:24
20F：→ StubbornLin:顾不顾得到人、团队能不能接受、学习成本 01/15 22:25
21F：→ StubbornLin:和现有的系统的整合问题 01/15 22:25
22F：→ StubbornLin:商业的支援、社群的支援 01/15 22:26
23F：→ StubbornLin:未来的发展等等 像很多人会担心某个支持该工具的公司 01/15 22:27
24F：→ StubbornLin:倒掉，一瞬间自己用的工具就会失去支援 01/15 22:27
25F：→ StubbornLin:像是PowerBuilder如果Sybase倒掉 工具大概就完了 01/15 22:28
26F：→ StubbornLin:所以工具未来的发展性、风险等等也要考虑进去 01/15 22:28
27F：→ StubbornLin:社群发展的语言虽然不会倒，但会没落 01/15 22:29
28F：→ StubbornLin:当使用者其它社群吸走，这社群大概也没戏唱了 01/15 22:30
29F：→ minstrelsy:既然可读性只是一小部份 既然还有其他很多要考量 01/15 23:10
30F：→ minstrelsy:像是现成的函式库 资源 团队 成本 整合等等 01/15 23:11
31F：→ minstrelsy:光以python跟perl在这几方面 有很大的差别吗? 01/15 23:12
32F：→ minstrelsy:perl的资源社群函式库相对於python来说应该是更丰富吧 01/15 23:12
33F：→ minstrelsy:以你自己的标准来判断的话 看不出为什麽perl不如python 01/15 23:14
34F：→ StubbornLin:perl因为他语言的天性，学习曲线高 01/15 23:18
35F：→ StubbornLin:应该说陡才正确，所以较难找真正开发大型软体的人才 01/15 23:19
36F：→ StubbornLin:而且我也说过，使用全域变数来达成某些工作 01/15 23:19
37F：→ StubbornLin:使perl写出来的程式容易很脏，很不利团队开发 01/15 23:20
38F：→ StubbornLin:如果是写小型的程式，Perl可以很快解决 01/15 23:22
39F：→ StubbornLin:但是当专案变得很大，perl的天性使它很难胜任 01/15 23:23
40F：→ StubbornLin:当然有人做得到，但如我说的: 成本问题 01/15 23:23
41F：→ minstrelsy:学习曲线陡不陡跟好不好找开发大型软体的人才没关系吧 01/15 23:24
42F：→ minstrelsy:C学习曲线陡但开发大型软体的人一堆 01/15 23:24
43F：→ StubbornLin:Python有很多成功的大型专案的例子 01/15 23:25
44F：→ minstrelsy:VB类的学起来简单 但真要找大型软体的人似乎没那麽多 01/15 23:25
45F：→ minstrelsy:而且 perl成功的大型专案难道就少了吗? 国外一堆 01/15 23:26
46F：→ StubbornLin:当然有关系，你自己一个人写程式怎麽写都无所谓 01/15 23:26
47F：→ minstrelsy:欧洲有许多大型跨国的金融系统都是建在perl之上的 01/15 23:26
48F：→ StubbornLin:团队写得考虑到设计层面的问题 01/15 23:26
49F：→ minstrelsy:另外 全域变数是会让程式变脏 但跟利不利团体开发无关 01/15 23:27
50F：→ minstrelsy:linux kernel中全域变数多到爆 但协同开发者也多到爆 01/15 23:27
51F：→ StubbornLin:为何无关? 今天张三在他的程式里改了$/ 01/15 23:28
52F：→ StubbornLin:就会影响整个程式的行为 哪里无关了? 01/15 23:28
53F：→ StubbornLin:李四不知道张三改了$/，跑出来的结果不同 01/15 23:28
54F：→ StubbornLin:这不是团队合作上的问题是什麽? 01/15 23:29
55F：→ minstrelsy:因为你认为绝对有关 所以我只要随便找个反例就可以反驳 01/15 23:29
56F：→ StubbornLin:你开发专案要去哪里找一堆linux kernel那种geek? 01/15 23:29
57F：→ minstrelsy:而且这种例子太多了 开源的大型专案 爱用全域的一堆 01/15 23:29
58F：→ StubbornLin:如果你觉得你可以找到那堆geek都加入你团队 01/15 23:30
59F：→ StubbornLin:那你要用什麽开发都可以，说真的 01/15 23:31
60F：→ StubbornLin:我今天说的是一般情况，你只有一般的工程式 01/15 23:31
61F：→ minstrelsy:所以扯回来又扯成是开发者能力的问题 跟团体开发又无关 01/15 23:31
62F：→ StubbornLin:你要拿玩linux kernel的一堆geek打一般工程师 01/15 23:31
63F：→ StubbornLin:能比吗? 01/15 23:31
64F：→ StubbornLin:我问你，开发者能力是不是成本? 需不需要成本? 01/15 23:32
65F：→ StubbornLin:linux kernel能玩到那种地步的人你要多少钱请他? 01/15 23:32
66F：→ StubbornLin:还有你要请多少个那种人才够你专案的开发? 01/15 23:32
67F：→ StubbornLin:你要不要说请linus本人帮你开发专案算了 01/15 23:33
68F：→ minstrelsy:所以你是认为玩perl的要够强才能发挥 玩python的则不用 01/15 23:33
69F：→ StubbornLin:软体工程师要在台湾找到好的更难 因为都被硬体吸走 01/15 23:34
70F：→ minstrelsy:所以以开发者成本来说 python会比perl来得省? 01/15 23:34
71F：→ minstrelsy:一般的programmer 一个强的至少可以打2-3个一般的 01/15 23:34
72F：→ StubbornLin:学习曲线较平缓，要知道的pitfalls比较少 01/15 23:35
73F：→ minstrelsy:我找一个perl够强的来抵2-3个python一般的好像还是省 01/15 23:35
74F：→ StubbornLin:自然在能力上可以不需要额外的知识来避开那些问题 01/15 23:35
75F：→ StubbornLin:嗯，如果你的专案只需要一人开发，我觉得很OK 01/15 23:36
76F：→ minstrelsy:要学习曲线平缓 我找10个会php的不是更好 这种人更多 01/15 23:36
77F：→ StubbornLin:但是说真的，一个人能写得出来的程式 01/15 23:36
78F：→ StubbornLin:你随便找都可以 01/15 23:36
79F：→ minstrelsy:可以找1个perl来抵2-3个python 就也可以同理扩大十倍 01/15 23:36
80F：→ StubbornLin:php初期的学习曲线很缓，但後面呢? 01/15 23:37
81F：→ minstrelsy:你觉得找二三十个工程师来沟通有比找十个来得轻松? 01/15 23:37
82F：→ StubbornLin:哈哈，那你就错了... 软体开发不是收割小麦 01/15 23:37
83F：→ minstrelsy:同理 perl前期的学习曲线很陡 但後面呢 01/15 23:38
84F：→ StubbornLin:你找10个强者来不会就扩张十倍的效率 01/15 23:38
85F：→ StubbornLin:你可以参考一本书 "人月神话" 01/15 23:38
86F：→ minstrelsy:同理 你找二三十个来做 大概还不如找十个 01/15 23:38
87F：→ olctw:我还是觉得看推文很累，但我还是继续看好了 (...板凳) 01/15 23:39
88F：→ StubbornLin:里面有提到那个问题，就是人数扩张需要的沟通更多 01/15 23:39
89F：→ StubbornLin:还有，如果你能找十个perl强者，为何不找python的? 01/15 23:39
90F：→ minstrelsy:所以我觉得你讲的python利於团队开发的优点有问题 01/15 23:40
91F：→ minstrelsy:如果可以1个抵10个 就成本考量 我为什麽要找10个 01/15 23:40
92F：→ StubbornLin:就语言可读性上，还有可靠性都比perl佳 01/15 23:40
93F：→ StubbornLin:那选择perl的理由在哪里? 01/15 23:41
94F：→ StubbornLin:我们谈的是现实的状况，你找得到一个抵十个的吗? 01/15 23:41
95F：→ StubbornLin:好，你找到了，恭喜你，然後呢? 01/15 23:42
96F：→ StubbornLin:你要花多少钱留住这个人才? 01/15 23:42
97F：→ StubbornLin:要是这个高手离职了，你要怎麽办? 01/15 23:42
98F：→ StubbornLin:Perl的可读性较差，你之後请的人读不懂怎办? 01/15 23:42
99F：→ minstrelsy:等等 你所指的可读性如果是说自然语言的可读 这没问题 01/15 23:42
100F：→ minstrelsy:但 这跟perl可靠性好不好有什麽关系? 01/15 23:43
101F：→ StubbornLin:perl因为使用全域变数来改变行为，使它的可靠性较差 01/15 23:43
102F：→ StubbornLin:所谓的可靠性是什麽，我不想再贴 你自己搜寻 01/15 23:44
103F：→ minstrelsy:可靠性的问题 只跟专案本身的执行与开发者有关吧 01/15 23:44
104F：→ minstrelsy:跟语言有什麽关系? 01/15 23:44
105F：→ minstrelsy:你讲的那一堆我看过了 照你的标准来看 C的可靠性更差 01/15 23:44
106F：→ StubbornLin:错 可靠性好的语言，应该要尽量避免容易写出错误 01/15 23:44
107F：→ StubbornLin:对，你说对了 C语言可靠性真的很差 01/15 23:45
108F：→ minstrelsy:但不好意思 你我现在的电脑世界 绝大部份都建在C之上 01/15 23:45
109F：→ StubbornLin:但是他有个优点 就是他比低阶高一点 01/15 23:45
110F：→ minstrelsy:包含你所说的python. python compiler也是c写的 01/15 23:45
111F：→ minstrelsy:所以python可靠性也很差 推论完毕 01/15 23:45
112F：→ StubbornLin:我从来都没有说过任何语言可以应用在任何场合阿 01/15 23:46
113F：→ minstrelsy:所以如以上所言 python也不是万能的 完毕 01/15 23:47
114F：→ StubbornLin:我真的觉得很困扰，又一个不查资料要战的 01/15 23:47
115F：→ StubbornLin:我从来没有说过python是万能的= = 01/15 23:47
116F：→ minstrelsy:我是个以c/python/外加一点perl/偶尔再来点php维生的人 01/15 23:48
117F：→ minstrelsy:请问我要查什麽资料? 你所说的这些都是我每天的工作 01/15 23:48
118F：→ StubbornLin:我从来都不知道语言直译器用什麽实作 01/15 23:49
119F：→ StubbornLin:语言特性会有递移性 还挺好笑的= = 01/15 23:49
120F：→ StubbornLin:Python的直译器版本有 Jython Java版 01/15 23:49
121F：→ minstrelsy:所以语言的可靠性会递移到专案执行的好坏也很可笑 01/15 23:50
122F：→ StubbornLin:IronPython .Net平台的版本 01/15 23:50
123F：→ minstrelsy:这些我都很清楚 01/15 23:50
124F：→ StubbornLin:没有绝对的好坏，但是有差别 01/15 23:50
125F：→ minstrelsy:有差别是语言本身的差别 跟专案有啥关系? 01/15 23:51
126F：→ StubbornLin:我们今天讨论的是程式语言 你说的那些我都有写过 01/15 23:51
127F：→ StubbornLin:当然有，语言本身容易写出未预期结果的情况 01/15 23:52
128F：→ StubbornLin:你的专案成本不是因此增加吗? 01/15 23:52
129F：→ StubbornLin:就像我说的$/问题，还有很多类似的情况 01/15 23:52
130F：→ StubbornLin:关於语言的可靠性，有一款语言叫Ada 01/15 23:53
131F：→ StubbornLin:他就是以可靠性为重点所发展的语言 01/15 23:54
133F：→ StubbornLin:你可以去看看到底什麽是可靠性 01/15 23:54
134F：→ StubbornLin:如果一款语言天生就容易写出错误 01/15 23:54
135F：→ StubbornLin:另一款较不容易，那是不是有差别? 01/15 23:55
136F：→ minstrelsy:这是专案本身执行的问题 跟语言的关系不大 01/15 23:55
137F：→ minstrelsy:专案执行不力 文件不完整 沟通乱来 就算用python照死 01/15 23:55
138F：→ minstrelsy:专案执行得当 文件清楚 沟通良好 用什麽语言都没差 01/15 23:56
139F：→ StubbornLin:你当然可以说就算怎样就算怎样 但是比较下就有差异阿 01/15 23:56
140F：→ StubbornLin:我说过perl过度自由，你在定风格，是不是很细节都得定 01/15 23:56
141F：→ StubbornLin:你可能得连$/那类全域变数都得规定要怎样用 01/15 23:57
142F：→ minstrelsy:难道我非要说这些专案我都做过带过执行过? 01/15 23:57
143F：→ StubbornLin:你的程式设计师得严格遵守 01/15 23:57
144F：→ StubbornLin:接着还得要检查风格是否符合 01/15 23:57
145F：→ minstrelsy:用python或许在coding style上会比perl来得占优势 01/15 23:57
146F：→ StubbornLin:这些不都是"额外"的成本吗? 01/15 23:57
147F：→ minstrelsy:因python的coding style先天就定好了 perl太自由 01/15 23:58
148F：→ StubbornLin:一款这麽自由的语言，在开发时要花额外的心力限制 01/15 23:58
149F：→ minstrelsy:但这跟专案做得好不好成不成功没关 01/15 23:58
150F：→ StubbornLin:这不是多余的浪费成本吗= = 01/15 23:58
151F：→ StubbornLin:我没说用了perl就会失败，用了python就会成功 01/15 23:59
152F：→ minstrelsy:就算是python 也是一样要订好沟通方式 界面命名的方法 01/15 23:59
153F：→ StubbornLin:我只是很在意能不能做到更好、更省成本 01/15 23:59
154F：→ StubbornLin:对，但是就不用花心力在$/那些过度自由的东西上 01/15 23:59
155F：→ minstrelsy:用perl也一样 在多人专案中 沟通界面的一致才是最重要 01/15 23:59
156F：→ StubbornLin:因为给太多自由倒头来在合作还是得限制 01/15 23:59
157F：→ StubbornLin:你的程式设计师得心理一直想，这个是否合规则 01/16 00:00
158F：→ minstrelsy:而这些沟通界面的订定等等 跟coding方式自不自由 01/16 00:00
159F：→ StubbornLin:查看看发下来的风格表，在里面搜索关於$/的规定 01/16 00:00
160F：→ StubbornLin:我请问你这不是浪费成本是什麽? 01/16 00:00
161F：→ minstrelsy:没多大关系 反而是跟专案执行沟通时 执行是否良好有关 01/16 00:00
162F：→ StubbornLin:你的设计师一直花心力在之前给的过度自由变成限制 01/16 00:01
163F：→ StubbornLin:所造成的落差上 01/16 00:01
164F：→ minstrelsy:你讲的情形 代表的是 你找错工程师了 01/16 00:01
165F：→ minstrelsy:而这在perl或python或c或php上都会发生 01/16 00:01
166F：→ StubbornLin:所以你所谓的好工程师是什麽? 01/16 00:01
167F：→ StubbornLin:当然都会发生阿，但是程度上有差别= = 01/16 00:02
168F：→ minstrelsy:专案会有这种情形 代表一开始工程师的筛选就出了问题 01/16 00:02
169F：→ StubbornLin:好，那我问你，工程师不看风格的规定 01/16 00:02
170F：→ minstrelsy:找个python很弱的工程师一样会有这种问题 01/16 00:02
171F：→ StubbornLin:他要怎样知道写出来是否合风格? 01/16 00:03
172F：→ minstrelsy:工程师不看风格 代表1.你找错人2.执行不力 01/16 00:03
173F：→ StubbornLin:我们讨论的都是一般情况，你一直要跳针到很弱、超强 01/16 00:03
174F：→ minstrelsy:这跟语言无关 每种语言都有这种人 也都有守规矩的人 01/16 00:04
175F：→ StubbornLin:我指的是 "工程师为写合风格的程式，要花的心力" 01/16 00:04
176F：→ StubbornLin:我什麽时候说过工程师不看风格? 01/16 00:04
177F：→ minstrelsy:并不是python的工程师就一定守规矩 01/16 00:04
178F：→ StubbornLin:你一直在跳针，我一直在说要写出合风格要花的成本 01/16 00:05
179F：→ StubbornLin:perl那麽自由，你开出来的风格规定不会琐碎吗? 01/16 00:05
180F：→ StubbornLin:一来你得开得非常详细，二来工程师也得仔细才能遵守 01/16 00:06
181F：→ StubbornLin:这不就是额外的成本= =? 01/16 00:06
182F：→ StubbornLin:python当然也要风格规定，但是因为他限制性强 01/16 00:06
183F：→ StubbornLin:所以风格规定自然就较少，花的心力少，成本自然低 01/16 00:07
184F：→ minstrelsy:你所说的 并不会 01/16 00:07
186F：→ StubbornLin:Python的风格甚至有官方的版本可以参照 01/16 00:07
187F：→ minstrelsy:像我所提的 python/perl的案子 我都做过也都带过 01/16 00:07
188F：→ minstrelsy:语言风格本身对专案执行的差异 小到看不出来 01/16 00:08
189F：→ minstrelsy:不同的语言对专案来说 只是不同的工具 看用的人怎麽用 01/16 00:08
190F：→ StubbornLin:当然风格有差别，可读性可写性可靠性也都有差 01/16 00:09
191F：→ minstrelsy:请问你本身有执行过python与perl的案子吗? 01/16 00:10
192F：→ minstrelsy:自己做过与带过大型团队 01/16 00:10
193F：→ StubbornLin:有Python，没有Perl 01/16 00:10
194F：→ minstrelsy:如果没有 你所说的都只是你个人的想像 那些并不存在 01/16 00:11
195F：→ StubbornLin:喔，那你认为别人的说法也都是想像吗? 01/16 00:11
196F：→ StubbornLin:我说的说法当然不全然是我说的，可读性可写性可靠性等 01/16 00:12
197F：→ minstrelsy:专案执行时 语言并不是重要的考量也不是成败的主因 01/16 00:12
198F：→ minstrelsy:所以你认为我的说法都是想像? 01/16 00:13
199F：→ minstrelsy:我个人对python/perl/c/php等专案得到的经验都是假的? 01/16 00:13
200F：→ StubbornLin:我没说那些都是假的，我也从没说过那些是成败的原因 01/16 00:14
201F：→ StubbornLin:只是我很在意工具对专案的影响 01/16 00:14
202F：→ StubbornLin:当然你可以以你的经验说没有影响 01/16 00:14
203F：→ StubbornLin:但你能不能说出在什麽样的评比条件下没影响? 01/16 00:15
204F：→ minstrelsy:既然不是成败的主因 选什麽语言都没差只有适不适合而已 01/16 00:15
205F：→ StubbornLin:软体开发的效率本来较很难评估 01/16 00:15
206F：→ minstrelsy:会说没差的原因是 语言风格等会有一定影响 但不很重要 01/16 00:16
207F：→ StubbornLin:成败没差，但是成本上有差别 01/16 00:16
208F：→ StubbornLin:你怎样下出不重要的断定? 你依什麽评估效能 01/16 00:17
209F：→ minstrelsy:重要的往往是沟通 界面 文件 而跟这些比起来 你在意的 01/16 00:17
210F：→ minstrelsy:小到不行 01/16 00:17
211F：→ minstrelsy:以复杂程度来评估 01/16 00:17
212F：→ StubbornLin:小到不行的结论是怎麽下出来的? 01/16 00:18
213F：→ minstrelsy:一个可以搞定沟通界面文件的团队 就算用了搞怪的语言 01/16 00:18
214F：→ minstrelsy:也可以很容易搞定那个语言 语言本身的差异比这些都小 01/16 00:19
215F：→ StubbornLin:你从头到尾也都只是主观的说小到不行 01/16 00:19
216F：→ minstrelsy:用c或perl的团队成功的不少 用python的团队失败的也有 01/16 00:20
217F：→ minstrelsy:那我是不是可以说你从头到尾只主观说可靠性很差? 01/16 00:20
218F：→ StubbornLin:你能不能拿出什麽来证明可读性可写性可靠性的影响小 01/16 00:20
219F：→ StubbornLin:我有提出实例，$/就是一个 01/16 00:21
220F：→ minstrelsy:我举了一堆反例还不算? 我过成做成的专案算不算? 01/16 00:21
221F：→ StubbornLin:还有很多个，我没办法在短时间内全想起来 01/16 00:21
222F：→ minstrelsy:而且 目前我失败的专案 没有一个跟选择的语言有关 01/16 00:22
223F：→ StubbornLin:你举了什麽反例? 就算组语能写出同样的案子又如何? 01/16 00:22
224F：→ minstrelsy:这样算不算? 01/16 00:22
225F：→ minstrelsy:你要我举例 我讲了实例你又不信 反正你也只是主观认定 01/16 00:22
226F：→ minstrelsy:算了 懒得讲 你就活在你自己的世界吧 01/16 00:23
227F：→ StubbornLin:我指的一直都是语言特性在成本上的差异 01/16 00:23
228F：→ StubbornLin:你一直讲专案的成败 01/16 00:23
229F：→ minstrelsy:我随便可以讲一堆我的案子的成本与语言特性无关 01/16 00:24
230F：→ StubbornLin:我也懒得讲，结果语言的特性本来就会造成开发上的差异 01/16 00:24
231F：→ minstrelsy:反正那只发生在你想像的世界 真实世界没这回事 01/16 00:25
232F：→ minstrelsy:反正世界上这些真实发生的案子都是假的 01/16 00:25
233F：→ StubbornLin:喔，那我也会说，反正学术研究讨论什麽可读性可靠性 01/16 00:26
234F：→ minstrelsy:反正什麽语言特性跟开发差异有关系也只是主观的 01/16 00:26
235F：→ StubbornLin:都是个屁，你的专案开发就是全世界 01/16 00:26
236F：→ minstrelsy:板主 有人骂脏话 我懒得回了 你就慢慢幻想吧 01/16 00:27
237F：→ olctw:(敲碗)老板，提到屁的那个犯规 (...回板凳) 01/16 00:27
238F：→ StubbornLin:我骂的是学术研究讨论是个屁，关你什麽事= =? 01/16 00:29