作者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