@
yangff 來說說爲什麼有些地方你說得不大對。
送你一句我師兄送給我的話：「軟件工程裏面最重要的是權衡。」
你的思路體現了你其實對着點沒多少體會。
----
对于成熟的现代流行的编程语言，只要能熟练运用，开发相同程序的效率都一样。而与所使用的语言类型没有太大关系
既然是成熟的流行的编程语言，当然是这样的。这里的效率说的是开发效率，做不到这点说明不够熟练。
語言的成熟是各方面權衡，達到一個相對穩定的情況後的境界，不同的語言有不同的哲學，也就有不同的側重點。在無限的情況下當然各方面都是好的，又正確，又高效，又開發效率高，問題是這樣的語言從來沒有過。於是乎，語言只能有選擇。
於是乎，你看到成熟的C，開發效率很低很低，但是有限的時間內還是各種語言裏面運行性能數一數二的。於是乎，你看到成熟的python，開發效率很高，但是性能很差。他們都已經說的上「成熟」了，「熟練」只能說充分發揮語言的特性，而「成熟」並不代表開發效率高。
----
如果把语言看成命令式的语言（比如js）以及描述式的语言（比如css）。那么这两种类型在使用方式上可以互换，比如可把命令式改为描述式的，也能把描述式改为命令式的
您改一个试试？css要体现一部分命令的效果需要伪类，不过哪怕这样，也不可能实现js能实现的所有功能。IE6除外。LESS != CSS！他的看起来的特性特性是在编译期实现的，本质还是描述式的，没有动态的效果。
這句話我也覺的有爭議，但是大致上，如果是圖靈完備的語言，都是可以互換的。我們把命令式的看成how，描述式的看成what，那麼how的確可以是what的答案。
你在混淆題目的意思，題目沒有說任何一個how都可以變成what或者已經有成型的what了。
----
大多数编程语言的核心功能都差不多，基本由循环、条件判断、数据类型等组成，只是语法与库的不同。因此学习多种编程语言对提高个人能力没有太大帮助，开发者应该把时间花在学习数据结构、算法、以及解决具体问题等方向上
程序=算法+数据结构
少年你真的覺的上面這條公式是對的麼？是完備的麼？我只能呵呵了。。。。
btw，算法和數據結構最後也會投影到編程語言上。好吧長期國內的教育就是不重視「編程語言」這門學問，樓主顯然在故意戳害你們弱小的心，但是很遺憾樓主在這件事情是的確是對的。另外，數據解構和算法在不同的編程語言裏面，用於工程上也有很大的差別。
----
“专用语言”与“通用语言”相比使用范围较窄，因为它们无法实现“通用语言”的强大功能
请用CSS访问Cookie，并把它发到xss平台上。
JavaScripts是脚本语言，具体请看：
http://en.wikipedia.org/wiki/ECMAScript#Implementations你連專用語言和通用語言都沒搞明白吧。另外，又跟腳本語言什麼事情。
另外你的邏輯也錯了啊。你實際上是說「存在一個專用語言，無法實現通用語言的功能。」這跟「專用語言無法實現通用語言的功能」是兩回事啊。這裏的謂詞，根據語義，只能取全部啊……也即是「全部的專用語言都無法實現通用語言的功能」。
其實還是編程語言的圖靈完備性啊。其實題目想表達的是「專用語言也可以是圖靈完備的。」估計您一直沒意識到吧？
----
相比Python这种通用语言Shell是一门语法比较复杂的语言，以至于有些人希望能够不用Shell实现的就不用Shell，而用其它语言代替Shell来编写脚本
Shell语法还复杂，看到Python不是要哭了？
shell的確複雜，你去看看bash的ref你不哭？我現在都不會寫shell。你知道shell可以寫子程序，而且傳參有多蛋疼麼？shell長大以後，維護的確十分困難，「用其它语言代替Shell来编写脚本」的確是可行的作法啊。
----
Shell是一门跨平台的语言，使用Shell编写的脚本不用修改，便能很好的在各种Linux发行版上运行
http://en.wikipedia.org/wiki/Bash_(Unix_shell)首先shell的主语指带不明，甚至Windows的控制台你都可以叫他Shell。其次，类UNIX系统所共同支持的shell语法。最后，绝大多数linux系统都会带上bash，就算你硬要说没有，也至少会带一个兼容http://
en.wikipedia.org/wiki/Bourne_shell 语法的shell。
请不要把用户自行安装的其他shell考虑在内。
看不到你回答的邏輯啊。最後一句「请不要把用户自行安装的其他shell考虑在内。」跟上下文完全沒有聯繫的感覺 = =
原命題的錯誤，應該是「使用Shell编写的脚本不用修改，便能很好的在各种Linux发行版上运行」，真正寫過跨發行版的shell程序看到這句話估計就哭了。如果一開始沒有考慮跨發行版，在複雜的環境中，基本不可能很好地在各種發行版上運行。原因不在於shell，而在於linux破碎的發行版帶來的破碎的環境不一致。所以才有了各種猜測系統環境的工具……
----
使用设计模式，有时可让程序代码变得更清晰易懂，也更容易和其它懂模式的人沟通。但模式也可能会增加程序的复杂度
更多情况下，设计模式会让代码变得更加冗长复杂，增加他人阅读的难度，沟通请使用文字。同样的目的，你是愿意面对1000行的代码还是400行的。阅读代码的成本，比重新完成的成本高10倍以上，看方法名知内容的阅读不算。
你的設計模式是老師教的吧？漂亮的設計模式根本不會讓代碼冗長，增加閱讀難度，增加溝通成本。（如果不是漂亮的設計模式，就相當於你在用工具做一件錯誤的事情，這時候請不要埋怨工具）。不要拿你在課堂上學到的那種設計模式過來說啊 = = 有多少老師懂設計模式的，亂用而已。
----
协议往往比实现此协议的程序活的更久，因此我们不但应该学会使用程序，也应该学习程序所使用的协议
私有协议死得比程序还快，比如，QQ2000使用的登录协议。
人家說的是往往 = = 根據我的經驗，「协议往往比实现此协议的程序活的更久」是說得過去的。當然可能你見過很多垃圾協議，覺的垃圾協議比正確的協議還多，那只能說這道題出得不好了。你的例子在邏輯上不能作爲反例駁倒原命題，比較有說服力的例子，應該是統計數據來說明是不是「往往」。
其實原命題的意思是「因此我们不但应该学会使用程序，也应该学习程序所使用的协议」。估計出題人是載了很多教科書的坑，想用這道題來表達他「程序使用的協議是很有學習價值的材料（然而這卻常常被忽視了）」。
----
版本管理工具在合并两个分支的代码时，此两个分支可能分别来至不同的程序项目
干出这种事情的拖出去揍。
你邏輯又出錯了。「可能」不是「應該」，講可能是講「可行性」，而不是「正確性」。
不同的程序項目完全是可能的。雖然有點牽強，不過你可以考慮一個項目在github上被多次fork，最後他們實際上是「不同的程序項目」（repo），但是的確可能合併，而且也是git的feature之一）
----
测试驱动方法可以提高开发程序的效率，特别是在不增加新功能重构现有程序代码时
带来更多的限制，减慢开发速度。
傾向於認爲出題者這句話是不嚴密的，是錯誤的。原因還是在表達，應該加上「往往」，「一般」，不然就只能當「测试驱动方法一定可以提高开发程序的效率」。出現這種錯誤，是因爲英文到中午的翻譯會丟掉一些東西。
TDD can help more dev effect. // 沒有「一定」的意思
测试驱动方法可以提高开发程序的效率. // 有「一定」
不過一般人都覺得「可以」就是「可以」，「测试驱动方法可以」==》的確有時候可以。
然後無論如何，你的反駁都是錯的。「带来更多的限制，减慢开发速度。」更多是在錯誤的使用的情況下。好吧我從來不用TDD，因爲我總覺得我還不需要 = = 但這不是TDD的問題。
然後出題人後面半句是非常正確的。在不增加新功能重构现有程序代码时，TDD非常幸福。
----
管道为两个程序之间建立起了互相通信的方式，程序在运行过程中可以通过管道互相传输数据
不能吗？LZ多想想
原題明顯表述，是shell裏面的pipe，你丟掉了上下文。以下的你對管道的觀念都不是shell裏面的pipe，而是*inux提供的程序間通訊的方法，是用API來做的，是論非所論。
shell的pipe是單向的，「相互」是錯誤的。
----
管道可以让程序与程序之间分工更为明确，从而减少了整个程序代码的复杂度
带来额外的协议维护费用。
錯誤在於你論非所論。這裏的協議就是「標準輸入和標準輸出」，任何unix風格的程序，都是直接操作標準輸入，標準輸出，使得程序之间分工更为明确，从而减少了整个程序代码的复杂度。沒有帶來額外的協議維護費用。
此外，恰恰是這種方法，使得unix下的程序不需要這麼多「協議」，因爲每個程序都直接處理標準輸入輸出裏面的字符串流。
----
管道可让一个程序在未来发挥出程序作者自身没有预料到的作用
http://zh.wikipedia.org/wiki/%E7%A1%AE%E5%AE%9A%E6%9C%89%E9%99%90%E7%8A%B6%E6%80%81%E8%87%AA%E5%8A%A8%E6%9C%BA你壞掉了，沒見過「管道可让一个程序在未来发挥出程序作者自身没有预料到的作用」的例子吧？好吧你沒見過，但是神奇地搭配管道真的是可以很神奇的，多多積累吧 = =
這裏跟DFA沒什麼關係。。。一個程序可以近似DFA，而shell是一個膠水，把這些DFA拼裝起來，有什麼問題？
----
使用管道可以避免两个程序之间必须互相了解对方的实现细节才能彼此合作
协议还不是细节？我用json，你用urlencode，我们来交流一下吧。
理由見上。我都不想說你的邏輯 = = 人家說可以，你舉個不可以的例子，來說明可以是錯的？
----
当一个网站的数据量越来越大时，为了存储更多的数据，必须使用支持可存储量更大的数据库，或者使用空间更大的磁盘
……到更多的服务器上就不要增加硬盘啦！！！LZ真是太TM机智了！！！！太神了！！！！！快去拿图灵奖，还和我等傻逼瞎哔哔个毛啊！！！！！！！还有物理学的诺奖也可以拿了吧！！！！信息熵都被你吃到黑洞里去了吧！！！！！！
这个答案真的是找喷
lz沒說不用增加硬盤吧？
----
数据结构也可视为算法的一部分，优秀的数据就够能够引出优秀的算法。因此有时可以把编程的重心从算法的角度移步到关注数据结构，从而降低整个算法的复杂度
程序=算法+数据结构
顺便说一句，SplayTree是数据结构，Splay是算法
。。。啊。。。
**只會做點點算法，沒有做過實際的項目，是遠遠不夠的**
----
在开发程序初期，若能为未来程序中可能会遇到的性能问题设计好算法代码，便能优化程序的性能。因此在项目初期应该多提前考虑算法优化问题
……在您眼里只要能跑出结果，跑1W年也无所谓是吧，反正跑着跑着CPU性能就上升了，然后时间就会越缩越短，不用考虑优化是吧，您在微软工作是吧？还是在开发Android？不考虑优化算法效率，其它的优化都是搞笑。CPU累个半死帮你争取回来的常数，都被您败光了。
PS：还是说古剑2是您开发的，我要求退货！！！
過早的優化是萬惡之源。人家沒說性能不重要，是在討論關注性能的時機。軟件不是寫個幾百行幾十行的東西交給評測機AC了就是好項目了……性能越來越不是項目最重要的東西了。學會權衡啊少年。
Select Language