@noli

这里的“工具”，如果指的是抽象的“手段”，那么几乎就是废话——差不多什么东西都能当工具。
如果是具体的“器具”，那也不合适，这个之前已经提过。
于是“语言就是工具”论，我就当是民科理论。从建设性来说鼓吹这种论调的还不如李煌老湿，后者好歹能有些娱乐价值。

破事有很多，再提些影响较大的。

首当其冲，想当然和惯性。
绝大多数人学习语言的目的往往是“会用”。这没问题。问题在于，不知不觉有些人就不考虑前提以为处处“存在就是合理”了，而不是联系实际需求，想想到底其中能有多少是有意为之的，哪些又是对现实的妥协。
比如说，越接近自然语言的设计就一定更“易用”吗？
比如说，越接近底层的，抽象特性越贫乏的语言，实现起来性能就一定能更好吗？
比如说，写出来的代码看起来干净，把类型都写清楚，没那么多乱七八糟的符号，就一定是更“清晰”吗？
只是不求甚解也罢了，然而这些问题实在太容易自以为是了。
这种思路这带来了严重的副作用，例如，阻碍现有语言的一些改进。
举个Java的例子。
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4459053
十多年前就有人提议过，结果呢……呵呵呵。
有些时候，语言的设计者自己就不够清楚，导致犯下的低级错误影响更坏——特别地，被无知者捧臭脚。
不过好在大多数语言设计者还是相对理性一些……于是结果就是蠢主意扎堆在少数的语言上了，这种语言的用户就是冤大头（虽然也有部分是活该）。
仍然是Java的例子。前无古人后无来者的checked exception，别的语言有好意思抄的么。
（嘛，据说James Gosling还想取消extends呢。林林总总加起来，说是偏执狂也不算冤枉吧。）

然后，如果一句“那么多的共同思想”就能轻描淡写把某些人打发走，那也太便宜了。
这方面仍然缺乏一些系统化的理论。有很多东西就是因为各种原因鸡同鸭讲，因此有时被逼不得不讨论清楚以免误会。
比如，“强类型”和“弱类型”这种普遍没有清晰边界的东西，不围绕具体例子是几乎没法保证知道别人说的是啥的。
再如，都说面向对象，那么是不是都怀疑过为什么“对象”里非要窜出个“类”呢？
其实照OO之父的观点，根本就不是那么回事——重点是对象和消息传递，方法乃至类都是实现方式，顶多这种只能算一种风格(class-based OO)。具体点说，应该是Simula→C with Classes→中古C++→Java等等这样传承下来的。
现实却是似乎有不少见识拙计的，就拿这个偷换概念了，却不知道所谓的prototyping也能毫不含糊地实现OO，反过来鼓吹卖弄什么pure OO，甚至还有什么“继承”“封装”“多态”都好意思拿来当OO的定义了……笑死人。（……敢区分OOP和OOAD么？）
这种可笑的误会如果非要说客观因素的话，恐怕就是缺乏交流导致的——严格意义上的“面向对象”这个概念因为这般鸡同鸭讲，和被废了差不多。
扯到这里倒是正好发现还能发散一些东西（虽然可能在c2.com之类的地方都已经吐槽腻的常识）来黑：无论是继承封装多态，还是SOLID这些所谓OO五原则，其实就没一个是OO的专利。
只挑其中和PLT最相关的两个来讲。
一是继承，在这些实现方式里面都是作为类型之间的关系，说白了就是一种subtyping，是一种类型之间的严格偏序关系的特例。摊上五原则里表面上最依赖“OO思想”的LSP，在System F里早就玩的溜了： http://typeof.net/2014/m/formation-of-modern-magic--why-functions-are-contravariant-in-the-input-type.html
二是多态。OO所谓的多态也就是inclusion polymorphism或者subtyping polymorphism，只是真正的多态中出现较晚的一种而已。出现早的呢？比如重载就是一种ad-hoc polymorpism。泛型则是parametric polymorphism。
大概那些OO语言的设计者对历史也不甚了然，不知道那么些别人早就玩滥的道道，所以就偷懒没明确（这里得承认C++当初也做得不好）。
于是只会照搬语言教科书以及盲目崇拜的无能者/纯OO厨就只能念歪经了。没法指望他们会创造更方便的能解决问题的设计，反而还得负担科普成本，这凭什么要我干呢？

嗯，要搞这坨又没特定目标用户（脑残粉也算），做好我不入地狱谁入地狱的思想准备。

@ryan10107 “远离了v2”……你现在是打算重新接近么。那么建议还是请继续远离好了。这样对谁都好一点。
我当然也不曾指望过v2的多数用户在这类问题上有LtU之类的地方专业，然而某些版面就事论事的氛围都赶不上reddit之类的地方甚至一些有活人管的贴吧……只能说不曾接近v2也不亏。

@ryan10107 ……能抓重点么。
我不用Java写操作系统，是因为：
1.对我或者对写操作系统这个任务来说，Java不好用。即便非要用类似的设计，我也宁可用CLR+C#而不是JVM+Java。（当然，并不是说前者就够好用到让我付诸实践了。）
2.更重要的是，写操作系统对我来说没意义——我现在没这个需求。所以要是你也不写，只能参照别人。

为什么不作为工具就要作为其它什么的呢。你会拿汉语当爱人么？如果是，那么类似地，这里也请自便。我是没那种心情。
非要说的话，某人（嗯，早于王垠，那个也是拾人牙慧）早就说过，比起工具，更像是“材料”——它或多或少地嵌入到产出之中，影响成品的质量。

@ryan10107 我觉得很有意义。

语言作为“工具”，和API或者其它开发环境用到的依赖一样，并没有什么特殊的，有很大改善的空间。即便你自己没法发明语言，没法实现语言，仍然可以改进现有语言。这种改进的初步共识就是在这类讨论取得的——首先先要确认足够的动机——用户需求，具体点说就是多数用户对现状的不满。退一步讲，你没法改变一个语言，那么在一个语言不够合适的场合，换一个语言也很正常。这样，就有必要交流什么场合适用。

反过来，我倒是奇怪，强行“没有意义”党的底气是基于什么理论什么事实得到的？是已经修改过语言发现徒劳无功了？还是仅仅不愿意承认自己没有行动力？或者干脆就是斯德哥尔摩综合症？

恐怕其中的大部分，就是自己没有能力改进语言或者看不懂在说啥，干瞪眼不爽，于是就把对现状无力的反感迁怒到讨论这种形式上了吧。

我不同意“无所谓好与坏，只有合不合适”这个观点。一种解决方案合不合适的理由显然不可能全因为用户的选择。有一种情况是设计者自身不够料到变化的需求（没设计“好”），却错误地使用户相信这种解决方案合适。或者说，直接的问题就是“锄头去锤钉子”还不自知的用户太多了，反而还要为这种行为的合理性辩护。

语言这种大多数用户没有尝试去设计过的东西是这种误解的重灾区。正是因为这样才更有必要澄清。正面讨论语言的优劣是有效手段之一。

Java写操作系统有什么好奇怪的，又不是没人试过。

http://en.wikipedia.org/wiki/JavaOS

http://en.wikipedia.org/wiki/JX_(operating_system)

你硬说作为“操作系统”绝对不合适？还真的未必——至少系统级别的GC没进程隔离阻碍回收资源那么坑（就这种设计而言，如果不适合造操作系统，就更不能指望适合开发用户空间程序）。只是造出来短期也不可能和现有的东西合拍就是了。

还有用Java造CPU的呢。

“C++这么好，为什么还需要Lua？C++这么厉害，为啥不写前端，需要JS。”——这是谁说的？我没在这个主题里见过支持因为C++可能可以用，所以就不需要其它语言的论据。而且，这看起来不正是因为你没法说出具体语言“好”“坏”在哪（如果要说语言自身就不可能只是合不合适）才有的疑问么。

题外话，语言可以作为工具，但绝不只是工具。大多数时候也不应该作为工具。从一个语言的话题就能影响这里那么多人的心智搞成宗教战争的架势来看，当作工具就已经上当了。

@all
“请尽量让自己的回复能够对别人有帮助”——回复框下面的这句话我不希望是摆设。

要支持“无所谓好与坏”或者“这个问题讨论没有意义”请像楼上一样展开论述，一句“无聊”“负分滚粗”和一厢情愿的“毫无意义”只是浪费所有人的时间的损人不利己。

@ryan10107 不敢讨论的不如shit么。
发明语言的十有八九倒是愉悦地中枪了。

@zjengjie 不特别针对谁，只是说一下现状。
不管是什么语言，不管是语言自身的演进、实现语言还是使用语言，本来一些事情，是可以和真正要解决的问题联系得更好的，不必要担心浪费多少时间，学了用得上还是用不上。
百分之七八十时间浪费在设计模式啊重构啊封装啊调优啊，不管实际上是不是真用得上或者是不是真得花这么多时间去做——这不是个别现象。
其实包括C++自身的设计其实很多也就是拾人牙慧罢了。只不过，表面上两者的合理性看起来近似，都有一坨历史包袱；骨子里呢？一小部分情况是对客观现实必要的妥协，另一部分则是给之前的愚蠢选择买单而已。
从Java的设计者到主流用户来看，后者的概率明显更大。而其它“复杂”语言的一些恶心之处反倒淘汰了一些不合适的用户，剩下的相对就不敢那么浮躁——如果不想一事无成的话。

@noli 如果原生支持一些语言构造的直接变换，不引入新关键字当然是可能的。但是，C++天生欠缺对这种扩展语言的方式的支持，在这种问题上会付出太大的代价。搞成像LISP方言那样就得扔掉一大半现有的特性，引入一大坨现在不存在的特性，这可不是“可持续发展”——不说语言规范维护的困难和用户切换的成本，就是可实现性都成问题。现在的提议可能仍然不是最好的，但明显是更可操作的。

@miao1007
我看了三次确认你没有回错人。
（？？？？）→廉价？看不懂你的逻辑。
不就是这种造成实际损失之前被指出没有漏注意的低级错误的情况么……你所在的星球难道没有对此叩首答谢的礼仪么。
“晒我的项目”貌似和这个主题没什么关系吧。
非要附会，那就勉为其难贴个参加过的： https://github.com/cplusplus/draft

@noli
这个提案的一个动机就是减少新的关键字：如果直接加yield/async这样的，恐怕没法就这样收场。
考虑到没法指望syntax-rules之类的东西，只加一个关键字能满足这些需求，也算是比较现实的、可以忍的妥协了。

@shuiniushushu
能介绍一下Linus自己用C++特别多的项目么。

有前途，混WG21么。

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf
http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-functions-in-c.aspx

说句公道话——asm降智商功效怎么能和Java比。谁敢让手下撸Java的通通去折腾asm呢。


@miao1007
1.平衡？Android？那个传说中坑害显卡驱动的MC算不？
2.真以为越OO越能SRP是嘛……
3.顶用的又有多少呢。

@zhea55
考虑“用的人”就行了？
好吧，checked exception看起来也是前无古人后无来者。

@riaqn
优雅？Haskell？
（虽然某种意义上倒的确比C艹还C艹。）
syntax……呵呵呵……
grammar……呵呵呵呵呵……

@zjengjie
花点时间折腾百分之七八十用不到的玩意儿和花百分之七八十时间折腾本来就没意义的玩意儿的成本，要哪个，自己掂量吧。

@GtDzx C++11没有支持VLA。
@icenan2 不考虑扩展，最快也许两年后。
@gongpeione 题主明显没有用C。C++没有这项特性。
@ffffwh 不要拿实现偷换语义。即便典型实现如此，C和C++都本身不管所谓的栈和堆。顺便，重定义operator new[]还就是能保证new不分配在堆上（如果找得到替代的自由存储）。
@WKPlus 你记错了，C99是支持VLA(variable length array)，但改成optional的是C11而不是C++11。
ISO C++从来都没考虑完整支持VLA，一个主要原因是运行时计算sizeof不可接受。
C++1y曾经考虑支持不包括这项特性的VLA的简化版本ARB(array of runtime bound)，但是考虑进度问题以及为了并行，2012年一大堆标准化工作分离为TS(Technicle Specification)直接从working draft里移除，结果C++14也没有包括这些特性。
最早的话也许C++17能正式支持。
顺便，GNU C++扩展是支持VLA的，g++默认-std=gnu++98能过。作为扩展，gcc默认的-std=gnu89也支持。

标题的说法正确。
@zkd8907 有两个重要的明显错误。
1.把具体语言指定的程序的语义和语言的实现的操作语义混为一谈。
这里说的Win32 code和C没有必然联系。一个C编译器需要遵守什么样的ABI生成代码，本质上就不是C语言管得了的。
ISO C和ISO C++都以抽象机模型规范程序的行为。基于可观察行为的等价规则（C++专门称为as-if rule），一个C或C++实现（一般就是优化编译器）有权变换底层实现中的子例程调用来体现函数的语义（C++还有另外一条例外规则，和这里问题没什么关系，略）。显然，这不表示两者是一回事。这里的C编译器生成的代码是汇编或者其它语言，不再是C语言程序。
2.把C和C++混为一谈。
事实上，C的函数参数就只能CBV，也就是“传值”。而C++的引用类型参数是被CBR的，并非“传值”（虽然所谓“传址”的说法也不确切，引用是否占用存储是unspecified，在具体实现以上根本就无所谓“引用的地址”）。

@yanyuechuixue 社区……呵呵，不提userland的破事也罢，Grsecurity/PaX为什么要单独维护？Linus对这些“安全”问题一贯又是什么态度呢。
Linux安全这种事。。就抱个别发行版大腿还有点现实性。

Imperative (i.e. TODO/FIXME)/subjunctive("suggest"): base form, i.e. "do sth".

Noun phrase (not a sentence, i.e. titles, some logs): non-finite forms. To be simple, roughly use "did sth" or "sth done" for past or perfect tense, "to do sth" for future tense, "doing sth" for others.

General documentation: simple present/third person singular/past tense as needed.

@bugeye Informative stative meaning (esp. as a title): non canonical/false passives (without explicit verb phrase to avoid ambiguity between passive auxiliary and copula) should come first, i.e. preferred "file not found" rather than "the file is not found".

@raincious
1.和这里说的有关系么。
2.Open source code is NOT Open Source. 何况我不认为你说的林林总总就都能算得上Source Code Open。
3.也许我知道关键问题了。我看到一般讨论（包括#36）的以及我默认的“开源”必须是合法行为，但你不承认这个前提。（基于上面的法律原因，#36引用到的lisenced实质上就是为了保证合法。）于是我仍然不同意你#37的观点，并且据此认定你是误导。顺便，误导也包括所谓的“不影响作为“口头授权”的效力”——仍然作为法律常识：要约不是授权（姑且认为题主是有明确要约过了）。
4.是否花费点数是各人的自由。PS.要节约点数，可以压缩一下行文。

@raincious 所以说你想什么样的回复呢。
总之我还是更认真一点把意思说清楚吧。不过仍然还是从你的回复开始。

> 根据哪怕是基本的法律原则，也有“谁主张谁举证”的准则。而这贴没有任何例外情况，所以你需要举证。
1.法律原则适用范围？
2.为什么“没有例外”情况是要求举证的原因？

闲话少叙。关于找到论据来支持我的看法这点我很能理解，所以并不反对。但是请注意我之前说的是不打算指明“具体段落”；进一步地，我已经表示原文通篇能自然地支持我的理解（因此其实没有纠结具体段落这个必要）。

你似乎没有注意到，“无法举证”和无法指明具体段落显然是两回事。于是你下面的几点的前提就不成立了，也就没有澄清的必要。不过，我可以暂且搁置这个问题——即便如此你要求我承认的东西仍然有些问题，我无法清楚地理解。

> 我上述回复的表达只是你脑中形成的观念，而不是事实；且（/或）：
主语先不论——和问题没多大关系。我不否认区分清楚讨论内容中的“观念”和“事实”在是自然的，也有一定的必要性，但没有预设条件（比如说，回复内有明确指出）下默认某些回复必须只能是观念或者是事实，就有些奇怪了。

> 你在没有清楚认知问题的情况下进行了非常不严谨的归类和回复，并造成了后续问题。
先不论清楚认知的是哪几个具体问题以及如何来确定是否认知得足够充分而能使回复不造成后续问题——不严谨的“归类”在哪？你指的被“归类”的是什么？

> 如果你发现我有问题，指出问题，我们可以继续讨论，然后修正我的观点；
我理解的问题是你看到我先前的回复“摸不着头脑”，所以我补充了理由。这应该足够明确了。
或者说，你仍然认为我（实际上，在我之前先是36楼）指出的“误导”（“源代码开放就是开源软件。你说的那是自由软件”）的依据至此仍然不充分？
至于修正观点与否对我相对无关紧要，我更关心“讨论者是否已经确认关于某个主题/概念有共识”，或者“在说同一回事”而不是鸡同鸭讲这件事。

> 如果你确认是你看错了，作为非原则问题，只要说明就可以。
我暂时没有确认我看错了什么。如果你认为我可能看错了什么，请提示具体内容。

接下来紧接的一些内容，我基本同意你的观点。更确切地，我同意不存在公认的唯一定义“开源软件”的许可。也因为这样，关于开源指的是什么的问题，之前我说的是“可以参照”（这并没有法律在管辖中的权威性），而不是“规定”之类。
不过，基于一般的法律（应该适用于题主和这里几乎所有人）的原因，没有给出明确许可的情况下，不符合这里列明的条件，据此我也不认为符合通常所说的“开源”的含义。这一点虽然细碎，但我认为和理解什么是“开源”至少同等重要（实际上根本不限于“开源”）。若对此你有异议请指出，欢迎继续讨论。

@qbeenslee 性能需求有明说的话，还是要关心的，否则嘛就随意了。
如果你想减少罪恶感，或者减少一些考虑这些问题浪费的时间，可以加上TODO之类（当然，风险自担）。

看你怎么偷懒。
如果符合spec和convention，不要故意往添乱的方向写就行。否则，不小心过了就是premature optimization。QoI到什么程度大多是设计问题，不用拖到代码实现耍小聪明。
如果不符合spec，要是找不到专门替你擦屁股的，还不如不写。如果不符合convention，除非你有权限改掉代码以外的部分，否则还是得准备好擦屁股（通常也只能自己擦）。