整理一下 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 所以才需要科学的方法去证明，因为数字会说话，文字只会引发更多的误解，不可能要每 个业主都去学各种程式语言来理解上述艰涩的讨论内容，难道就因此一直说怀才不遇？别 闹了，物竞天择，人需要去配合环境做改变，而不是环境配合人。如果人能够说服业主， 让业主专心在自己原本擅长的事务上，透过任何工具为业主达成预期目的都可以，这才有 办法创造最大效益。企业是为了追求最大利益，而不是世人所认同的真理 ※ 编辑: olctw 来自: 114.32.103.49 (01/16 10:46)