GNU 是哪个，GPL LGPL AGPL ？算了，不管哪个哪版都废话多。
Apache 也没好哪去。比传统 permissive copyright 实质无非多了个擦专利屁股条款。然而就这么坨玩意儿，改个代码还得把修改什么地方都老实糊一遍？放在版本库里发布的，能 log 能 diff 的还就得放置不用，非得另外注明？有病。
BSD 光是废话少就吊打了，少了专利授权而已。另外以一些欧洲佬（如 Theo de Raadt ）的看法，copyright notice 就是 notice，捆绑发布者无关目的的恶臭 license 都是坏文明。
这个 Mulan PSL 虽然也挺罗嗦的，但是至少比 Apache 对付修改代码干净点。记得还修了个诉讼授权过头的洞，先不管了。

其实这种情况还是脱裤子放屁。#include 的语义并没有禁止这样的实现，而<>是 implementation-defined。够折腾了。
搞得现在那么复杂，无非是跟 export 有一腿而已。然而看看别家(ML-like)叫 module 的东西，这坨也就是玩具。

“一堆模板元”是什么鬼。

想了想，大概觉察到某些分行阅读党和开火车党的理由了。（严格上来讲这里的单位也不会是正儿八斤的“行”——反正不是 py 的这种 free form 的语言要刻意多拆几行的机会多的是——而是“语句”这样的局部控制结构划分的单元。）
理由是认为这样做更简单而具有“可读性”，这是错觉。
深层一点的原因是误以为字面顺序可以决定操作语义的顺序。
然而现实是这种简化规则能起作用的纯粹 linear IR 等同高级语言的状况，根本就遇不到。不管是怎么样强调所谓语句的语言都没法用它代替表达式。于是能做的无非就是先分析语句，喘口气再分析语句内的表达式而已。
这在使可读性提高上原则上就没什么卵用，因为本来求值的相对顺序就是语义特性，依赖语法顺序在一般语言中根本不靠谱（理论上还有更麻烦的问题，stackoverflow.com/a/57619680/2307646 ）。
在性能上也是弟弟，因为原则上先语句再拆语句的分析方式会阻碍并行，跟一般人视觉的直觉上就对着干的；即便习惯了这套，基本上只能加速特定语言的特定语法的分析效率，换了个稍微不怎么熟悉的语法（直觉上没把握）立刻打回原形。
至于所谓链式调用开火车似乎更好看，大概主要是因为这些用户用的语言的表达能力太弱，强行 map 消除语义冗余，语法上反而会更麻（罗）烦（嗦）而已……

@biossun 这就奇怪了，为什么代码必须要按“句子”来读？代码遵循所谓的语法(syntax) 又不是某些自然语言的所谓“句法”。
照你说的，要是读古汉语这样没标点的文字，你还得非把整个段落加载进脑子里然后整段脑补出标点再分析，而不能边读边增量组句？古人真有这样的吗……现代的标点能让人省事加快分析性能，但现代人的语文本事在没标点下真该有那么差的吗？
后面所谓嵌套写一行里加重来回看的难度就更奇怪了。对一般人来讲，难道不是因为对 cache locality 友好而更容易一次跳个来回而不是跳回来之后还得纠结在不同行里跳？我是真不懂这样的阅读直觉形成方式，是因为 cache 没 tag 导致看得足够近的东西就一团浆糊呢，还是根本就没 cache 硬记代码字符串？

@yippees 语法糖？也就 ALGOL-like 用户能认为“;”不是 applicative order 的语法糖了吧？

以行而不是 AST node 为单位处理代码的习惯也不知道是谁教的。真搞定你用的语言的“语法”了嘛？

开火车的也了断一下好了。
本来直觉上一开始就是 map . f x y z 的逻辑，非得
f
.x
.y
.z
……
不重复.会死？
OutVoGlobal outVoGlobal=new OutVoGlobal(EnumRetCode.SUCCESS);
这种一个标识符近乎重复三次的还能忍着，对视觉的直觉开销和脑子里可用带宽毫无感知，降频 parse 打肿脸充胖子还装作不碍可读性的，只能呵呵……
就自然语言这样没设计的玩意儿的用户习惯大都也懂到处重复不雅的道理，某些 PL 用户咋反而倒回去了呢？

@no1xsyzy 大手子……王根么（原来这坨还删了啊……

@wtdd 在？陪 LZ 实现下超图灵机？

总算不是 Android X ……
各路版本号胜利会师（？）

自己编译的 MdCharm，还凑活。
不过保存 Unicode 非 BMP 字符有 bug，暂时没修。
至于流程图……算了吧，塞进 md 不累么……
这种 DSL 的语法功能是由奢入俭难，用惯 GFM 然后 BitBucket wiki 上连 HTML tag 都是残的（前几年是根本不给用），体验简直呵呵了。用了太多没支持的扩展，兼容就拙计得专有格式也没差多少了，不如直接上专门的格式算了。

@no1xsyzy 确实，把“节目”(programme) 算成程序的话，那也是 programming ……从英语来说这还算是本义。不过中文语境下明显不是这里说的东西了。
关于编程概念的问题我基本同意你说的，另外在 av64199842 的置顶评论的 18 页中提过有点标题党的问题，不过对方好像不买账……
一如你说的知道和不知道的问题，“工程”本质问题确实可以不大，但实际操作往往不如你所愿。比如可能会多出大量局部细节的问题，沟通成本导致涉众可能会不和你沟通他认为你不需要了解的知识，导致你克服这些困难比其它问题难得多。其实这在传统工程中也不是没有，只是标准化操作成熟的传统工程沟通路径明显更固定，不容易那么糟而已。

@youxiachai
首先，ACM 大佬是 ACM 大佬，和 ACM/ICPC 选手正经上不是一个档次的，虽然不排除多年后后者可以凭实力进去。
其次，ACM/ICPC 选手的业务能力和大多数单位的需求不直接匹配（除非就是留校当教练这样的），所以用人单位不太可能省掉资源来磨合业务水平。
第三，ACM/ICPC 和 OI 选手的可塑性强主要体现在工程和业务经验普遍少没有形成思维定势，而算法能力大多数情况下确保够用，编程能力不一定够用但至少平均水平问题不大，所以在大多数相关专业的学生编程和算法能力这样的基础都相对不靠谱的情况下，校招成本和风险都较低；而进行培养也基本只需要注重业务和工程上（我上面说的“自发”发现这方面问题的能力缺失也不成问题，明显可以有人带）的，直接招聘可以减少不少成本。但如果严格限定是吃相关项目经验的社招，或者要求招进来就短时间必须能独当一面，效果就容易大打折扣了。
第四，一个人再聪明，也难保遇到实际上无解（不存在解或者资源限制不可行）的问题。而且，周围的人越聪明，提出无解的问题的效率恐怕就越高。退一步讲，成本一样是坑。
（还有无敌的甲方……

@allenxzz 你对 AI 的理解脱离当前实际。至少从现在来看，最先进的所谓 AGI 在近几十年也几乎不可能胜任获取不会配合 AI 的用户的需求以及表达需求描述的工作。
所谓将来会被取代的程序员，大多是本来就靠堆工作时数“水平扩展”出来的裁员预备队，人力资源角度上把他们“优化”掉本来就是大势所趋，跟 AI 是不是足够成熟没有直接关系——没 AI 取代他们，也有更熟练的人来取代他们，直接缩减 HC。
而假设 AI 确实足够强了，能做的比现在多多了，和 AI 的高效的沟通能力也是广义上的编程能力。因为从成本合理性的角度看，AI 不应该仅靠蹩脚的 HCI 来精确理解用户的需求，有高效专业的接口放着不用那是傻了。
在真正意义的强 AI （某些人所谓的 AGI ）实现之前，我理解的这些判断不太可能失效。（至于成功实现强 AI，运气好点，你大概活个七八辈子可能看到，运气不好人类毁灭也实现不了。）
我也列一张的能力清单吧：
1.基本靠谱的价值判断（影响包括人格健全、站队、优先决策、投资评估等等）。
2.健康的身体。
3.风险承受和规划。
4.表达和自信。
5.快速适应环境（包括语言学习）。
6.某些适龄人群学起来特别占便宜的特定技能（包括某些自然语言和艺术）。
7.社交和社会资源。