Re: [請益] 網路創業大部分的網站規劃都是用PHP嗎?

看板toberich (創業)作者olctw (olc.tw)時間16年前 (2010/01/16 02:08)推噓5(5推 0噓 28→)

留言33則, 7人參與討論串20/23 (看更多)

整理一下 Python v.s. Perl ... ;) → minstrelsy: 這個說法跟可讀性還有程式語言的優劣有關嗎？這只是說明了隨著時代變遷某些語言會受到不同的重視。拿這樣來判斷說某個語言比另一個語言好，也不是不行，但這是政治考量跟商業考量，跟可讀性什麼的有很大關係嗎？頂多只能說明 python 比起 perl 來說，現在的人比較馬上看懂，而商業考量跟可讀性也不必然有關， C 有很多不好懂的部份，但實際應用上還是一大堆地方在用，頂多是邊用邊罵而已。C的商業應用之廣泛跟許多C難以理解的怪寫法就不用舉例。 → StubbornLin: 可讀性只是一小部份，還有太多要考量了，可用現成的函式庫、資源有多少、顧不顧得到人、團隊能不能接受、學習成本和現有的系統的整合問題，商業的支援、社群的支援、未來的發展等等，像很多人會擔心某個支持該工具的公司倒掉，一瞬間自己用的工具就會失去支援。像是PowerBuilder，如果Sybase倒掉，工具大概就完了，所以工具未來的發展性、風險等等也要考慮進去。社群發展的語言雖然不會倒，但會沒落，當使用者其它社群吸走，這社群大概也沒戲唱了 → minstrelsy: 既然可讀性只是一小部份，既然還有其他很多要考量，像是現成的函式庫、資源、團隊、成本、整合等等，光以 python 跟 perl 在這幾方面，有很大的差別嗎？ perl 的資源社群函式庫相對於 python 來說應該是更豐富吧？以你自己的標準來判斷的話，看不出為什麼 perl 不如python → StubbornLin: perl 因為他語言的天性，學習曲線高，應該說陡才正確，所以較難找真正開發大型軟體的人才。而且我也說過，使用全域變數來達成某些工作，使perl寫出來的程式容易很髒，很不利團隊開發。如果是寫小型的程式，Perl可以很快解決，但是當專案變得很大，perl的天性使它很難勝任。當然有人做得到，但如我說的: 成本問題，Python有很多成功的大型專案的例子 → minstrelsy: 學習曲線陡不陡跟好不好找開發大型軟體的人才沒關係吧，C學習曲線陡但開發大型軟體的人一堆，VB類的學起來簡單，但真要找大型軟體的人似乎沒那麼多，而且 perl成功的大型專案難道就少了嗎？國外一堆，歐洲有許多大型跨國的金融系統都是建在perl之上的。 → StubbornLin: 當然有關係，你自己一個人寫程式怎麼寫都無所謂，團隊寫得考慮到設計層面的問題 → minstrelsy: 另外，全域變數是會讓程式變髒，但跟利不利團體開發無關，linux kernel中全域變數多到爆，但協同開發者也多到爆。 → StubbornLin: 為何無關？今天張三在他的程式裡改了$/，就會影響整個程式的行為，哪裡無關了？李四不知道張三改了$/，跑出來的結果不同，這不是團隊合作上的問題是什麼？ → minstrelsy: 因為你認為絕對有關，所以我只要隨便找個反例就可以反駁，而且這種例子太多了，開源的大型專案，愛用全域的一堆 → StubbornLin: 你開發專案要去哪裡找一堆linux kernel那種geek？如果你覺得你可以找到那堆geek都加入你團隊，那你要用什麼開發都可以，說真的。我今天說的是一般情況，你只有一般的工程式。 → minstrelsy:所以扯回來又扯成是開發者能力的問題，跟團體開發又無關 → StubbornLin: 你要拿玩linux kernel的一堆geek打一般工程師，能比嗎？我問你，開發者能力是不是成本？需不需要成本？ linux kernel 能玩到那種地步的人你要多少錢請他？還有你要請多少個那種人才夠你專案的開發？你要不要說請linus本人幫你開發專案算了。 → minstrelsy:所以你是認為玩perl的要夠強才能發揮，玩python的則不用？ → StubbornLin:軟體工程師要在台灣找到好的更難，因為都被硬體吸走 → minstrelsy:所以以開發者成本來說，python會比perl來得省？一般的programmer，一個強的至少可以打2-3個一般的。我找一個perl夠強的來抵2-3個python一般的好像還是省。 → StubbornLin:學習曲線較平緩，要知道的pitfalls比較少，自然在能力上可以不需要額外的知識來避開那些問題。嗯，如果你的專案只需要一人開發，我覺得很OK → minstrelsy:要學習曲線平緩，我找10個會php的不是更好，這種人更多，可以找1個 perl來抵2-3個 python，就也可以同理擴大十倍 → StubbornLin:但是說真的，一個人能寫得出來的程式，你隨便找都可以。php初期的學習曲線很緩，但後面呢？ → minstrelsy:你覺得找二三十個工程師來溝通有比找十個來得輕鬆？ → StubbornLin:哈哈，那你就錯了... 軟體開發不是收割小麥 → minstrelsy:同理 perl前期的學習曲線很陡，但後面呢？ → StubbornLin:你找10個強者來不會就擴張十倍的效率，你可以參考一本書 "人月神話" → minstrelsy:同理，你找二三十個來做，大概還不如找十個 → StubbornLin: 裡面有提到那個問題，就是人數擴張需要的溝通更多，還有，如果你能找十個perl強者，為何不找python的？ → minstrelsy:所以我覺得你講的python利於團隊開發的優點有問題，如果可以1個抵10個，就成本考量，我為什麼要找10個？ → StubbornLin: 就語言可讀性上，還有可靠性都比 perl 佳，那選擇perl的理由在哪裡？我們談的是現實的狀況，你找得到一個抵十個的嗎？好，你找到了，恭喜你，然後呢？你要花多少錢留住這個人才？要是這個高手離職了，你要怎麼辦？Perl的可讀性較差，你之後請的人讀不懂怎辦？ → minstrelsy: 等等，你所指的可讀性如果是說自然語言的可讀，這沒問題；但，這跟 perl 可靠性好不好有什麼關係？ → StubbornLin: perl因為使用全域變數來改變行為，使它的可靠性較差，所謂的可靠性是什麼，我不想再貼，你自己搜尋 → minstrelsy: 可靠性的問題，只跟專案本身的執行與開發者有關吧，跟語言有什麼關係？你講的那一堆我看過了，照你的標準來看，C的可靠性更差 → StubbornLin: 錯，可靠性好的語言，應該要盡量避免容易寫出錯誤。對，你說對了，C 語言可靠性真的很差，但是他有個優點，就是他比低階高一點 → minstrelsy: 但不好意思，你我現在的電腦世界，絕大部份都建在C之上，包含你所說的python.python compiler也是c寫的，所以python可靠性也很差，推論完畢 → StubbornLin:我從來都沒有說過任何語言可以應用在任何場合阿 → minstrelsy:所以如以上所言，python也不是萬能的，完畢 → StubbornLin: 我真的覺得很困擾，又一個不查資料要戰的，我從來沒有說過python是萬能的= = → minstrelsy: 我是個以c/python/外加一點perl/偶爾再來點php維生的人，請問我要查什麼資料？你所說的這些都是我每天的工作 → StubbornLin: 我從來都不知道語言直譯器用什麼實作，語言特性會有遞移性，還挺好笑的= =。Python的直譯器版本有 Jython Java版、IronPython .Net平台的版本 → minstrelsy: 所以語言的可靠性會遞移到專案執行的好壞也很可笑，這些我都很清楚 → StubbornLin:沒有絕對的好壞，但是有差別 → minstrelsy:有差別是語言本身的差別，跟專案有啥關係？ → StubbornLin: 我們今天討論的是程式語言，你說的那些我都有寫過。當然有，語言本身容易寫出未預期結果的情況，你的專案成本不是因此增加嗎？就像我說的$/問題，還有很多類似的情況，關於語言的可靠性，有一款語言叫Ada，他就是以可靠性為重點所發展的語言 http://0rz.tw/ZXanN ，你可以去看看到底什麼是可靠性。如果一款語言天生就容易寫出錯誤，另一款較不容易，那是不是有差別？ → minstrelsy: 這是專案本身執行的問題，跟語言的關係不大，專案執行不力、文件不完整、溝通亂來，就算用python照死；專案執行得當、文件清楚、溝通良好，用什麼語言都沒差 → StubbornLin: 你當然可以說就算怎樣就算怎樣，但是比較下就有差異阿。我說過perl過度自由，你在定風格，是不是很細節都得定，你可能得連$/那類全域變數都得規定要怎樣用，你的程式設計師得嚴格遵守，接著還得要檢查風格是否符合，這些不都是"額外"的成本嗎？ → minstrelsy: 難道我非要說這些專案我都做過帶過執行過？用python或許在coding style上會比perl來得佔優勢，因python的coding style先天就定好了，perl太自由，但這跟專案做得好不好成不成功沒關 → StubbornLin: 一款這麼自由的語言，在開發時要花額外的心力限制，這不是多餘的浪費成本嗎= =。我沒說用了perl就會失敗，用了python就會成功，我只是很在意能不能做到更好、更省成本 → minstrelsy:就算是python 也是一樣要訂好溝通方式，界面命名的方法，用perl也一樣，在多人專案中，溝通界面的一致才是最重要 → StubbornLin:對，但是就不用花心力在$/那些過度自由的東西上，因為給太多自由倒頭來在合作還是得限制，你的程式設計師得心理一直想，這個是否合規則 → minstrelsy:而這些溝通界面的訂定等等，跟coding方式自不自由，沒多大關係，反而是跟專案執行溝通時，執行是否良好有關 → StubbornLin: 查看看發下來的風格表，在裡面搜索關於$/的規定，我請問你這不是浪費成本是什麼？，你的設計師一直花心力在之前給的過度自由變成限制所造成的落差上 → minstrelsy: 你講的情形，代表的是，你找錯工程師了，而這在perl或python或c或php上都會發生 → StubbornLin: 所以你所謂的好工程師是什麼？當然都會發生阿，但是程度上有差別= = → minstrelsy:專案會有這種情形代表一開始工程師的篩選就出了問題，找個python很弱的工程師一樣會有這種問題 → StubbornLin:好，那我問你，工程師不看風格的規定，他要怎樣知道寫出來是否合風格? → minstrelsy:工程師不看風格，代表1.你找錯人2.執行不力 → StubbornLin:我們討論的都是一般情況，你一直要跳針到很弱、超強 → minstrelsy:這跟語言無關，每種語言都有這種人，也都有守規矩的人 → StubbornLin: 我指的是 "工程師為寫合風格的程式，要花的心力"，我什麼時候說過工程師不看風格？ → minstrelsy:並不是python的工程師就一定守規矩 → StubbornLin: 你一直在跳針，我一直在說要寫出合風格要花的成本， perl 那麼自由，你開出來的風格規定不會瑣碎嗎？一來你得開得非常詳細，二來工程師也得仔細才能遵守，這不就是額外的成本= =?python當然也要風格規定，但是因為他限制性強，所以風格規定自然就較少，花的心力少，成本自然低 http://www.python.org/dev/peps/pep-0008/ ，Python的風格甚至有官方的版本可以參照 → minstrelsy: 你所說的，並不會。像我所提的 python/perl的案子，我都做過也都帶過，語言風格本身對專案執行的差異，小到看不出來，不同的語言對專案來說，只是不同的工具，看用的人怎麼用 → StubbornLin:當然風格有差別，可讀性可寫性可靠性也都有差 → minstrelsy:請問你本身有執行過python與perl的案子嗎？自己做過與帶過大型團隊，如果沒有，你所說的都只是你個人的想像，那些並不存在 → StubbornLin:有Python，沒有Perl。喔，那你認為別人的說法也都是想像嗎？我說的說法當然不全然是我說的，可讀性可寫性可靠性等 → minstrelsy: 專案執行時，語言並不是重要的考量也不是成敗的主因，所以你認為我的說法都是想像？我個人對python/perl/c/php等專案得到的經驗都是假的? → StubbornLin: 我沒說那些都是假的，我也從沒說過那些是成敗的原因，只是我很在意工具對專案的影響。當然你可以以你的經驗說沒有影響，但你能不能說出在什麼樣的評比條件下沒影響？軟體開發的效率本來較很難評估 → minstrelsy: 既然不是成敗的主因，選什麼語言都沒差只有適不適合而已，會說沒差的原因是，語言風格等會有一定影響，但不很重要 → StubbornLin: 成敗沒差，但是成本上有差別。你怎樣下出不重要的斷定？你依什麼評估效能 → minstrelsy: 重要的往往是溝通、界面、文件，而跟這些比起來，你在意的小到不行。以複雜程度來評估，一個可以搞定溝通界面文件的團隊，就算用了搞怪的語言，也可以很容易搞定那個語言，語言本身的差異比這些都小 → StubbornLin: 小到不行的結論是怎麼下出來的？你從頭到尾也都只是主觀的說小到不行，你從頭到尾也都只是主觀的說小到不行 → minstrelsy: 用c或perl的團隊成功的不少，用python的團隊失敗的也有，那我是不是可以說你從頭到尾只主觀說可靠性很差？ → StubbornLin: 你能不能拿出什麼來證明可讀性可寫性可靠性的影響小，我有提出實例，$/就是一個，還有很多個，我沒辦法在短時間內全想起來 → minstrelsy: 我舉了一堆反例還不算？我過成做成的專案算不算？而且，目前我失敗的專案，沒有一個跟選擇的語言有關 → StubbornLin:你舉了什麼反例? 就算組語能寫出同樣的案子又如何? → minstrelsy: 這樣算不算？你要我舉例，我講了實例你又不信，反正你也只是主觀認定。算了，懶得講，你就活在你自己的世界吧 → StubbornLin: 我指的一直都是語言特性在成本上的差異，你一直講專案的成敗，我也懶得講，結果語言的特性本來就會造成開發上的差異 → minstrelsy: 我隨便可以講一堆我的案子的成本與語言特性無關，反正那只發生在你想像的世界，真實世界沒這回事，反正世界上這些真實發生的案子都是假的，反正什麼語言特性跟開發差異有關係也只是主觀的 → StubbornLin: 喔，那我也會說，反正學術研究討論什麼可讀性可靠性都是個屁，你的專案開發就是全世界 ---個人想法或摘要--- 1. 可讀性也許對個人學習所投入的成本有差異，但對專案影響不大 PHP > Python > Perl 2. 專案的可靠性跟語言的可讀性不會有顯著的關聯，關鍵在執行者或團隊 3. 只要是熱門語言就不乏大型專案的例子 4. 團隊開發的例子，文字描述與實際體驗有顯著的差異，因為團隊開發有太多不能說的秘密 ;) 5. 眼前應該沒有人會因為太過自由而放棄民主吧？所以自由也許不是什麼批評的好理由 6. 真有心要得到結論，不妨就拿來當你接下來的論文吧，用科學的方法去證明 7. 如果多花一百萬可以讓公司成功生存，為什麼要省這個成本看公司消失？所以專案的成敗在重要性遠高過工具或僱用操作工具者的成本，而專案的成敗取決於執行者或團隊，此時工具的成本有什麼好探討的？ --- kiang -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.103.49

推

SMUGEN

01/16 02:22, , 1^F

01/16 02:22, 1^F

→

mlwmlw

01/16 05:56, , 2^F

01/16 05:56, 2^F

推

crazybad

01/16 10:01, , 3^F

01/16 10:01, 3^F

推

bobju

01/16 10:22, , 4^F

01/16 10:22, 4^F

→

bobju

01/16 10:22, , 5^F

01/16 10:22, 5^F

→

bobju

01/16 10:23, , 6^F

01/16 10:23, 6^F

→

bobju

01/16 10:24, , 7^F

01/16 10:24, 7^F

→

bobju

01/16 10:24, , 8^F

01/16 10:24, 8^F

→

bobju

01/16 10:27, , 9^F

01/16 10:27, 9^F

→

bobju

01/16 10:28, , 10^F

01/16 10:28, 10^F

→

bobju

01/16 10:29, , 11^F

01/16 10:29, 11^F

→

bobju

01/16 10:29, , 12^F

01/16 10:29, 12^F

所以才需要科學的方法去證明，因為數字會說話，文字只會引發更多的誤解，不可能要每個業主都去學各種程式語言來理解上述艱澀的討論內容，難道就因此一直說懷才不遇？別鬧了，物競天擇，人需要去配合環境做改變，而不是環境配合人。如果人能夠說服業主，讓業主專心在自己原本擅長的事務上，透過任何工具為業主達成預期目的都可以，這才有辦法創造最大效益。企業是為了追求最大利益，而不是世人所認同的真理 ※ 編輯: olctw 來自: 114.32.103.49 (01/16 10:46)

→

bobju

01/16 10:35, , 13^F

01/16 10:35, 13^F

→

bobju

01/16 10:36, , 14^F

01/16 10:36, 14^F

→

bobju

01/16 10:37, , 15^F

01/16 10:37, 15^F