@
dblue 对于成熟的现代流行的编程语言，只要能熟练运用，开发相同程序的效率都一样。而与所使用的语言类型没有太大关系
既然是成熟的流行的编程语言，当然是这样的。这里的效率说的是开发效率，做不到这点说明不够熟练。
语言的成熟是各方面权衡，达到一个相对稳定的情况后的境界，不同的语言有不同的哲学，也就有不同的侧重点。在无限的情况下当然各方面都是好的，又正确，又高效，又开发效率高，问题是这样的语言从来没有过。于是乎，语言只能有选择。
于是乎，你看到成熟的C，开发效率很低很低，但是有限的时间内还是各种语言里面运行性能数一数二的。于是乎，你看到成熟的python，开发效率很高，但是性能很差。他们都已经说的上「成熟」了，「熟练」只能说充分发挥语言的特性，而「成熟」并不代表开发效率高。
####
所以说是熟练度的问题，C用的熟练，开发效率不会比Python差。
这里的熟练不仅仅是对语言的熟练，Coding从来不是瓶颈啊……
####
----
如果把语言看成命令式的语言（比如js）以及描述式的语言（比如css）。那么这两种类型在使用方式上可以互换，比如可把命令式改为描述式的，也能把描述式改为命令式的
您改一个试试？css要体现一部分命令的效果需要伪类，不过哪怕这样，也不可能实现js能实现的所有功能。IE6除外。LESS != CSS！他的看起来的特性特性是在编译期实现的，本质还是描述式的，没有动态的效果。
这句话我也觉的有争议，但是大致上，如果是图灵完备的语言，都是可以互换的。我们把命令式的看成how，描述式的看成what，那么how的确可以是what的答案。
你在混淆题目的意思，题目没有说任何一个how都可以变成what或者已经有成型的what了。
----
####
如果把语言看成命令式的语言（比如js）以及描述式的语言（比如css）。那么这两种类型在使用方式上可以互换
命令式的语言 => Js
描述式的语言 => css
使用方式 互换 => use css as Js
说完了。
####
大多数编程语言的核心功能都差不多，基本由循环、条件判断、数据类型等组成，只是语法与库的不同。因此学习多种编程语言对提高个人能力没有太大帮助，开发者应该把时间花在学习数据结构、算法、以及解决具体问题等方向上
程序=算法+数据结构
少年你真的觉的上面这条公式是对的么？是完备的么？我只能呵呵了。。。。
btw，算法和数据结构最后也会投影到编程语言上。好吧长期国内的教育就是不重视「编程语言」这门学问，楼主显然在故意戳害你们弱小的心，但是很遗憾楼主在这件事情是的确是对的。另外，数据解构和算法在不同的编程语言里面，用于工程上也有很大的差别。
----
####
如果你做的比较多，你就会严重的同意上面这句话是对的。
其他的东西都是几分钟可以解决的事情，但是算法和数据结构可能是几年、几十年甚至都不可能解决的问题。
算法和数据结构最后也会投影到编程语言上 => 哪个人这么告诉你的……算了不多说。
不重视算法和数据结构是中国的开发者超级严重的一个问题……没办法，大学教出来的很多就这尿性。
####
“专用语言”与“通用语言”相比使用范围较窄，因为它们无法实现“通用语言”的强大功能
请用CSS访问Cookie，并把它发到xss平台上。
JavaScripts是脚本语言，具体请看：
http://en.wikipedia.org/wiki/ECMAScript#Implementations你连专用语言和通用语言都没搞明白吧。另外，又跟脚本语言什么事情。
另外你的逻辑也错了啊。你实际上是说「存在一个专用语言，无法实现通用语言的功能。」这跟「专用语言无法实现通用语言的功能」是两回事啊。这里的谓词，根据语义，只能取全部啊……也即是「全部的专用语言都无法实现通用语言的功能」。
其实还是编程语言的图灵完备性啊。其实题目想表达的是「专用语言也可以是图灵完备的。」估计您一直没意识到吧？
####
F 专用语言通常更擅长解决一些特定领域的问题，但它们也能摇身一变成为通用语言，看看JavaScript和Node.js
他自己说的哦。
PS：……所谓领域专用语言（Domain Specific Language/DSL），其基本思想是“求专不求全”……
通用语言可以作为专用语言来使用，但他本质上还是通用语言，而专用语言在设计时就不是为了实现通用的目的的。
「专用语言也可以是图灵完备的。」
如果他完备了，那为什么它还是专用语言呢？仅因为是他只被在该场合使用吗？多想想？
####
----
相比Python这种通用语言Shell是一门语法比较复杂的语言，以至于有些人希望能够不用Shell实现的就不用Shell，而用其它语言代替Shell来编写脚本
Shell语法还复杂，看到Python不是要哭了？
shell的确复杂，你去看看bash的ref你不哭？我现在都不会写shell。你知道shell可以写子程序，而且传参有多蛋疼么？shell长大以后，维护的确十分困难，「用其它语言代替Shell来编写脚本」的确是可行的作法啊。
----
####
不蛋疼，shell比python好调多了，但是这个看个人吧，出成题目实在不合适，我只是吐槽下。
不过至少Shell写成什么混蛋样子还能看得懂，python可以写到没学过这个语言的人看都看不懂。
####
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破碎的发行版带来的破碎的环境不一致。所以才有了各种猜测系统环境的工具……
####
使用Shell编写的脚本不用修改，便能很好的在各种Linux发行版上运行
我的意思是在语法上的。各个Linux平台有自己的差异，但是这与shell无关。
####
----
使用设计模式，有时可让程序代码变得更清晰易懂，也更容易和其它懂模式的人沟通。但模式也可能会增加程序的复杂度
更多情况下，设计模式会让代码变得更加冗长复杂，增加他人阅读的难度，沟通请使用文字。同样的目的，你是愿意面对1000行的代码还是400行的。阅读代码的成本，比重新完成的成本高10倍以上，看方法名知内容的阅读不算。
你的设计模式是老师教的吧？漂亮的设计模式根本不会让代码冗长，增加阅读难度，增加沟通成本。（如果不是漂亮的设计模式，就相当于你在用工具做一件错误的事情，这时候请不要埋怨工具）。不要拿你在课堂上学到的那种设计模式过来说啊 = = 有多少老师懂设计模式的，乱用而已。
####
不妨来个栗子？这个主观上的原因是我比较排斥设计模式。客观上是能用的好设计模式的实践实在是少的可怜。当然确实也有不错的就是了……不过看多了垃圾代码这东西真心会吐。
能不能，当然可能，不过实在没什么意义。
还有我是自学的。
增加阅读难度，我的意思是，不管什么代码，反正一眼一行，我是受不了带一大堆修饰的……我宁可复制到编辑器里面手动去掉……
####
----
协议往往比实现此协议的程序活的更久，因此我们不但应该学会使用程序，也应该学习程序所使用的协议
私有协议死得比程序还快，比如，QQ2000使用的登录协议。
人家说的是往往 = = 根据我的经验，「协议往往比实现此协议的程序活的更久」是说得过去的。当然可能你见过很多垃圾协议，觉的垃圾协议比正确的协议还多，那只能说这道题出得不好了。你的例子在逻辑上不能作为反例驳倒原命题，比较有说服力的例子，应该是统计数据来说明是不是「往往」。
其实原命题的意思是「因此我们不但应该学会使用程序，也应该学习程序所使用的协议」。估计出题人是载了很多教科书的坑，想用这道题来表达他「程序使用的协议是很有学习价值的材料（然而这却常常被忽视了）」。
####
作者没有举出任何可以证明他的观点的证据。
但是，除了成为标准的协议，绝大多数的私有协议在程序死后还能存活？这个没什么可质疑的吧。
####
----
版本管理工具在合并两个分支的代码时，此两个分支可能分别来至不同的程序项目
干出这种事情的拖出去揍。
你逻辑又出错了。「可能」不是「应该」，讲可能是讲「可行性」，而不是「正确性」。
不同的程序项目完全是可能的。虽然有点牵强，不过你可以考虑一个项目在github上被多次fork，最后他们实际上是「不同的程序项目」（repo），但是的确可能合并，而且也是git的feature之一）
####
这个我只是纯粹吐槽他举的栗子，干这种事不是没事闲着么= =、
####
----
测试驱动方法可以提高开发程序的效率，特别是在不增加新功能重构现有程序代码时
带来更多的限制，减慢开发速度。
倾向于认为出题者这句话是不严密的，是错误的。原因还是在表达，应该加上「往往」，「一般」，不然就只能当「测试驱动方法一定可以提高开发程序的效率」。出现这种错误，是因为英文到中午的翻译会丢掉一些东西。
TDD can help more dev effect. // 没有「一定」的意思
测试驱动方法可以提高开发程序的效率. // 有「一定」
不过一般人都觉得「可以」就是「可以」，「测试驱动方法可以」==》的确有时候可以。
然后无论如何，你的反驳都是错的。「带来更多的限制，减慢开发速度。」更多是在错误的使用的情况下。好吧我从来不用TDD，因为我总觉得我还不需要 = = 但这不是TDD的问题。
然后出题人后面半句是非常正确的。在不增加新功能重构现有程序代码时，TDD非常幸福。
####
后半句是正确的同意。
但是要证反这个命题太同意了，我们来举个极端的栗子，比如A+B。要推翻一个命题只需要找到一个特例使他不成立就行了。
“测试驱动方法可以提高 **（中）大型** 开发程序的效率，特别是在不增加新功能重构现有程序代码时”
我同意。
####
----
管道为两个程序之间建立起了互相通信的方式，程序在运行过程中可以通过管道互相传输数据
不能吗？LZ多想想
原题明显表述，是shell里面的pipe，你丢掉了上下文。以下的你对管道的观念都不是shell里面的pipe，而是*inux提供的程序间通讯的方法，是用API来做的，是论非所论。
shell的pipe是单向的，「相互」是错误的。
####
同意。没看到“|”抱歉。
####
----
管道可以让程序与程序之间分工更为明确，从而减少了整个程序代码的复杂度
带来额外的协议维护费用。
错误在于你论非所论。这里的协议就是「标准输入和标准输出」，任何unix风格的程序，都是直接操作标准输入，标准输出，使得程序之间分工更为明确，从而减少了整个程序代码的复杂度。没有带来额外的协议维护费用。
此外，恰恰是这种方法，使得unix下的程序不需要这么多「协议」，因为每个程序都直接处理标准输入输出里面的字符串流。
####
你得定义流之间要怎么传递数据吧！！
本来我只要考虑dlopen之后，从某个函数把参数丢过去。
用管道，无非就是把这个过程放到了流里面。
相反，dlopen的话函数定位系统还能代劳，用流的话这还得你自己处理。
####
----
管道可让一个程序在未来发挥出程序作者自身没有预料到的作用
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，我们来交流一下吧。
理由见上。我都不想说你的逻辑 = = 人家说可以，你举个不可以的例子，来说明可以是错的？
####
理由同上上，比如我要请求你一个方法OpenFile，我得知道你怎么处理我输入的流吧，比如，你要接受一个
Funcall <- header[\n]
Name:[ ]<- 一个空格，必需的 Funcname[\n]
Argc:[ ]<- 一个空格，必需的 Number(<100)[\n]
Args:[\n]
base64(arg1)
base64(arg2)
base64(arg3)
还有我得知道你返回的是什么吧。
如果我只丢过去：
FCall OpenFile("
xxx.md")
你也能处理？就算这个你也考虑到了，你也处理了.
^_OF("
xxx.md")
我这样传递你还受得了？
不了解怎么通讯？
就像如果上面这段内容我写成：
qdw2r3r2^qw34rf4f34g.fgf34rrr3r3,**OpenFile^^&&,r3232fe43f4.
……
你知道我在说什么？这是我花了5分钟想出来的一个语言规则。
如果你说题目说的细节不是这个，那我要质疑，难道不用管道就不能避免了吗？用管道避免有什么特殊性？难道我用libopenssl我真的把libopenssl的代码都读了一遍，才开始编译它？
####
----
当一个网站的数据量越来越大时，为了存储更多的数据，必须使用支持可存储量更大的数据库，或者使用空间更大的磁盘
……到更多的服务器上就不要增加硬盘啦！！！LZ真是太TM机智了！！！！太神了！！！！！快去拿图灵奖，还和我等傻逼瞎哔哔个毛啊！！！！！！！还有物理学的诺奖也可以拿了吧！！！！信息熵都被你吃到黑洞里去了吧！！！！！！
这个答案真的是找喷
lz没说不用增加硬盘吧？
####
说了。LZ认为这是错的。
####
----
数据结构也可视为算法的一部分，优秀的数据就够能够引出优秀的算法。因此有时可以把编程的重心从算法的角度移步到关注数据结构，从而降低整个算法的复杂度
程序=算法+数据结构
顺便说一句，SplayTree是数据结构，Splay是算法
。。。啊。。。
**只会做点点算法，没有做过实际的项目，是远远不够的**
####
做过，不好意思。
对算法的理解只限于教科书，真的很可怕。
另外，我们很多时候会说，我用线段树优化Dp之类的，你以为这里的线段树只是数据结构？你每次不需要Query？你只考虑了线段树的区间性质，不需要处理线段树的查询？只是因为这些算法基本是和数据结构配套而生的，但，你和你弟弟是双胞胎，你能说你弟弟就是你吗？
####
----
在开发程序初期，若能为未来程序中可能会遇到的性能问题设计好算法代码，便能优化程序的性能。因此在项目初期应该多提前考虑算法优化问题
……在您眼里只要能跑出结果，跑1W年也无所谓是吧，反正跑着跑着CPU性能就上升了，然后时间就会越缩越短，不用考虑优化是吧，您在微软工作是吧？还是在开发Android？不考虑优化算法效率，其它的优化都是搞笑。CPU累个半死帮你争取回来的常数，都被您败光了。
PS：还是说古剑2是您开发的，我要求退货！！！
过早的优化是万恶之源。人家没说性能不重要，是在讨论关注性能的时机。软件不是写个几百行几十行的东西交给评测机AC了就是好项目了……性能越来越不是项目最重要的东西了。学会权衡啊少年。
####
还是那句话，连性能都不考虑就开始写代码，写出来的都是垃圾，都要推倒，最后剩下的只有框架。
“性能不是最重要的东西”，
这种思想特别可怕，以次充好啦，打一炮就走了，能用就行管他什么垃圾，把这些看成正统的人，呵呵。
权衡？权衡什么？能问一句吗？
能AC的代码才是好代码，你可以把这里的AC理解成单元测试。
同样AC的代码，效率越高越好。
效率同样的代码，越短越好。
长短相同的代码，再和我说可读性。
没错CPU会越跑越快，GPU会越来越强大，这不是不重视算法的理由。就算CPU快到，你的代码
0.0000000000001s
我的代码
0.0000000000000000000000001s
跑10000000000000遍，高下立判。
为什么会要这样呢……多想想？N^3可以过就不去做N^2logN的事我不是没做过，也不是没吃过亏哦。
####
……长的我都只能用记事本写了……