@yagamil 明明命名困难是两大计算机科学难题之一，你不在乎就无所谓了？
你这首先用复用不复用来判断命名的方式是病，得治。

使用符号命名是有明确的目的性的，就是塞入语义上无关紧要（操作语义上就是某种 alpha renaming ；虽然遇到反射会失效）但有确切含义的元数据来辅助人类阅读者改善推理，同时语言实现不影响语义等价翻译（比如编译优化）的可行性。后者可以在语义上约定自己的假设而同时能被机器改善推理（比如 devirtualization ）。
其实这就是所谓的封装性(encapsulating)的确切内涵。因为教学质量的普遍垃圾，很少有人理解，不管是 access control 这样在 name resolution 上加 hook 还是 inclusion polymorphism 这样在 call 上加 hook ，都只是 encapsulation 的实现细节而已。

你若只是因为要让看得清楚，而不管这里的原始目的，这是胡搅蛮缠。因为只是为了看清楚，而不是区分“这个不是那个”这种依赖元数据内容的场合，完全可以用编辑器辅助的纯语法方式（例如高亮边界）解决。

一般地，在一个合理的设计中要求实体具名，充分必要条件是这个命名属于用户关心的 API 的一部分——只有这种场合人理解命名的冗余含义才能确保可能帮助准确地正确使用（当然前提是命名对了）而不是干扰人类读者的冗余噪声。否则，都是耍流氓。

有一种常见的误解是关于人为在源代码（而非实现内部变换）中引入“中间变量”的必要性。
实际上如果不考虑一等状态（比如 C++的那种 RAII ），任意的显式声明引入的中间变量在逻辑上是冗余的，只不过因为考虑读者的脑容量有限，避免发生 register spill 之类的问题，所以有的作者才试图这样做。
但是，这种中间变量完全可以 canonicalize 成 let form 。（学 ALGOL-like 语言学傻的不容易理解这一点，因为不知道 block 实际上是 lambda 的 derivation——用 JS 的话来说就是 IIFE 。）
这种情况下，到底什么变量才是真正有资格当中间变量的问题才会显著——只有能被复用时，才配被提升到 let 的变量名的位置上。
那么不被复用的复杂表达式可读性差怎么办？很简单，拆成具名函数的调用。引入的函数名就不是这种中间变量了，它可以是内部 API ，即便只被用到了一次。
之所以函数名和普通的变量名区别对待，是因为具名函数的实现默认是封装的（函数体不可见），因此它有资格单独占据名称。
当然，如果考虑一等状态，比如 lifetime 这种依赖对象自身存在的情况，那就有复杂多了的例外——因为存在隐含的资源释放，实际上有类似函数调用的作用。不过，遵循约定的代码反而会更清晰可读：如果严格遵循“不复用的对象不在 let form 中出现为变量名”，人很容易推理出为什么需要有孤零零（甚至一次都没用到）的对象；反之就麻烦多了，读者要自行验证这里到底复用了几次才放心。结果，在这个上下文中尽量排除没有复用的具名对象，反倒更合理了。

题外话，显式类型(explicit typing)和命名的必要性同等，也就是在 API 上才配用。所以 bb 什么 auto 啊 var 啊看不清楚类型的，那也是耍流氓。

@Al0rid4l 其实和为什么没多大关系，虽然允许遵循链式命名解析的变量（名）算是 lambda 演算的主要贡献，lambda 演算的命名就只有约束变量（函数参数）这个地方能用。而现代语言更常见的命名依赖的环境这种抽象是在 Lisp 用动态作用域实现 lambda 演算变体时提出的副产品（相比纯 lambda 演算依赖 capture 和 capture avoidance substitution ），并且环境的实现方式（ alist ）因为保存了状态恰好还同时更加兼容词法作用域和非纯函数式的用法（ impure λv calculus ），能够直接平替没作用域的符号表而已。
所以也不是学 C 学傻，基本上不清楚一些历史的，默认只能当作都是傻的。

@user667788 要现代岂不是先得把 py 干掉？
没什么现代语言能抄个 1930 年就有的 lambda 还有脸限制一行的吧。

@L4Linux 什么叫不追求 memory safety ，你写的玩意儿有几个是可以随便 crash 无所谓的？
（就是挂在导弹上漏尿的都不算 Rust 所谓的 memory safety 。）
你要说用 Rust 是懒得 review 这种低端问题，让人跟 rustc 斗法节约时间，然而并不是所有项目都能节约出多少，这还差不多。

@chesha1 1. 市场是大但是分层且不互通，得看水平在什么程度上。
不限预算是无所谓的，反正什么语言都得会。
卡死预算也是无所谓的，反正这俩都不会。
中间层次就比较迷，得看从事的领域是不是恰好有很多已经造过的轮子。众所周知，C++和 Rust 用户造（烂）轮子的水平和品位半斤八两，如果一个领域流毒 C++烂轮子多、好轮子少，那么 C++就有超额成本；反过来就是 Rust 占便宜。但恰好这里 Rust 基本就没轮子……
至于跟 rustc 斗的更低层次的初级用户，比 CRUD boy 贵不了多少了。
2. 非技术问题。会折腾的没什么人有兴趣自己造更没资源推广。
3. “挺好的”，说明比较初级。

@uni spec ，请。

@talkischeap567 那坨前后一致性都有问题的 shit 伪码就见过写 cmodel 的翻译成 C/C++，没见过其他抖 M 来整活的。

@reallynyn 都 23 ？你给我在主流实现里找个 23 的 flat_map 给我抄抄？

（当然熟悉 C++11 特性嘛，要我来面的话……比如实现个 C++11 能用的 uses_allocator_construction_args 试试？ https://github.com/FrankHB/YSLib/blob/master/YBase/include/ystdex/allocator.hpp#L203 ）

这没啥，这年头诈骗的答车万题都知道百度……

@BeforeTooLate 我的是 80027F8F ，商店应用也没法在线安装，折腾了几年最后终于重装了……github.com/FrankHB/pl-docs/issues/6 （继续坑
损失了 qBittorrent 的记录没备份，别的还好。

@dk7952638 没说没有啊，只不过钱堆起来的罢了。
你看 C/C++ 的维护者和用户在乎你堆壁垒不？用的到的地方，别的不成气候，不在乎你什么平台堆不堆，这个平台不行换个平台一样有，一个平台有另一个平台没有的默认都是给选型添堵的扣分项。
Web 也是，但显然比较菜。嫌弃 Web 的一脚踢开也不少，就算开发成本会上升。
至于 app 开发市场就更不成熟了，所以才有得讨价还价。

@dk7952638 C 打脸 ISA 啪啪啪。
POSIX 打脸 C 啪啪啪啪。
然后 C++再打脸回去啪啪啪啪。
……
特定不可移植的技术永远需要依赖可移植的技术，否则自然会受到经济规律制裁。任何的对全局不可移植的容忍无非都体现在两个方面：用得不够多；用得不够久。
平台壁垒？给钱谢谢。一旦资源烧不动就没什么资格假装屎山继续动力学稳定。
（当然，不是说 Flutter 算是方向。它不够格。）

进来前就在想怕又是个 allocator 拎不清楚的，结果对比一个直接把 allocator 写脸上了……药店碧莲行么？
且不提 COW 的 std::basic_string （ C++11 已经寄了……那年头会折腾的都知道 vstring 和 rope 罢）同样的操作可能反过来吊打，你依赖 SIMD 就已经是可移植性上投降了。
std::string （还不是 std::basic_string ）原则上不可能被干掉的最大槽点是污染 stdexcept 外加 ABI （但除了 Itanium 的 mangling 开洞之类的琐碎问题外，根本上这是用户对 ABI 假设普遍自己作死，不是 string 的问题），看不出这个的还真没资格写玩具碰瓷。

@pocarisweat string 本来就是纯数学概念，虽然定义依赖 alphabet 却没所谓字符的意思，你还是先叫 C++的 vector 滚粗吧。
本来叫 vector 的东西 C++的叫 array ，本来叫 string 的东西 C++叫 vector （还硬塞了个 valarray ），然后扯了坨 char_traits ，就这笑话了。
虽然始作俑者应该是 C 硬把 B 的 vector 叫 array ，然后本来叫 array 的东西（ C 表达不了） C++里叫[unordered_]map （严格来说是实现了 operator[]的 concept ，vector/basic_string 也算），本来叫 map 的东西叫 transform……乱成一锅粥。
ALGOL 厨二数学学渣祸害了不知道多少人。

@nullptr 比如屑 LLVM 。还不只是 std::string 。
开个_GLIBCXX_DEBUG 不重新编译都能炸了。

一眼看成 14 岁初中生开发身体……

这种属性要宣传也别放标题，主次不分。

你这些开不开源没直接关系吧。
给你补个强相关的：
0. 瞎写 copyright notice/瞎用许可证。

也就圣代泼到屏幕上的时候……

@yjim 没找到。有没有脚本关键字？

“个人使用对其他任何人都是没有影响的”作用在交互功能上就是不可能的，理由说了，批量 block 会对别人讨论的话题造成影响。实际上只要是 block 就可能有影响，但是手动 block 影响扩散很小，所以近似可以认为不影响别人。

你忽略了几个现实：对不同人来讲什么东西算包含政治立场的问题不见得是一样的；对大多数人而言，用有和没有政治成分划分话题就是在表达一种政治立场；对几乎所有人而言，强调什么技术中有多少政治成分以及接受的界限都是政治行为。
我不认为你能逃避你不想要的政治的同时能让人清楚这个界限。你想要的功能也就是帮你逃避说清楚这点罢了。逃避本身并无不可，你没义务说清楚（说清楚了别人都没义务理解你）；但是你用来逃避的逻辑是基于话题参与的贴标签给人划分三六九等（虽然你可能自始至终只是认为是个人偏好），那么自然就没有只准你贴别人而别人不能贴你的道理——注意这个功能并不能让别人针对性反过来给你贴标签，因为你怎么操作别人不知道。于是暴露操作的云黑名单就是最大化贴标签对等的措施，顺便也减少对话题非预期影响的成本。
另外，即便这个界限客观稳定，也不能保证 block 的标准是稳定的——无所谓你有所谓的政治的用户的比例可能比你想象的多得多，一时间成了漏网之鱼，但是不断可能出现某天偶然犯禁被你 block 了，然后最后剩下的就没什么人了。所以这个功能即便实现，对用户意义也有限。

@yjim
> 上来就政 Z 正确的屁话。请先好好学习“自由”的含义再出来叫，谢谢。
> 请问哪里涉及政治了？

很不巧的是，你希望钦点的“自由”是有法条涵盖的下限的，也逃脱不了政治。

比如说，参考《中华人民共和国刑法》第五十四条第二款。

或者你可以表演一下不涉及行使这些合法权利发表你的意见的方法。

给 OP @we21x 提个需求：我需要一键 [显著标记] 类似 @yjim 可以证明明确表达（过）不问内容滥用 block 需求的用户的功能，最好可以跨用户共享，允许全站用户一起维护。如果觉得不便也可以向站方转达需求，不过如果你不满足这些用户的需求，也许就不那么急迫。
理由是 block 审查内容是道德义务，就算审查用户名可以接受，针对非特定用户用话题连坐的地图炮是过大的权利，不能放任不管。客观上，不可能所有用户都跟风这些用户一样要 block 而保持共识，放任迟早会导致楼层内容断裂——没勤快跟上这些用户 block 的其他用户以为在双向交流，其实根本没有——导致任何非确定用户的阅读体验变差。因为不管是不是被内容恶心到了都可能发生，这比任何依赖具体内容引起的差异原则上都恶劣得多，尤其是这样的用户自认为具有可以不顾他人阅读体验的超人一等的局部审查权，在不尽分楼层鉴别内容的社区义务就应该能享受到不对等的眼不见为净却同时能够继续参与其它话题的权利的时候。增加标记至少可以发现以后不主动挑事，又不影响愿意和这些用户交流的其他用户回复之间的逻辑连续性。

@aloxaf 如果是设计 ABC 那时候的 GvR ，那么是可以宽容一点。但设计 Python 的 lambda 的 GvR ，已经不太能那么让人宽容得起来了。说得严厉一点，就是德不配位。
我举的有洞察的对照例子，也都是年代明显更早的论述。
真心要称赞的话，大概 GvR 就一点做得比较突出：没有直接乱缝合别家设计。虽然很多设计拉胯，来源基本上是他自己（比如大多数 PEP 的质量相对无理的原始设计，质量看上去都算好的），那么就不至于稀里糊涂搞得大多数人最终都不清楚为什么要有 i++之类的情况，纠正起来也容易得多。

@aloxaf len 这种东西说不上多巧妙，但是现实中几个值得一提展开的点（还是普遍到跟 Python 不需要直接关系）。
我确信 GvR 始终没摸到这方面的坑的主要边界，以至于解释中很大程度都是 ABC 的历史包袱。

1.关于混合所谓自由函数和方法的问题。
其实大多数语言都还没有复杂到要你纠结坑的地步，但也存在进退失据的例子。搜索 C++ UFCS 有真相。
因为，认为 len(x)和 x.len()不是一种含义会造成明显的不一致，以至于有不少人认为这两种语法的含义干脆合并得了，定义一个就能两用。但这样就有个灵魂拷问：既然允许 len(x)，为啥还要发明 x.len()，浪费一个不同的语法？然后什么 customization point 之类的妖魔鬼怪上来凑一脚，不忍直视……
所谓“前缀符号更可读，简单胜过复杂”其实倒并非没有道理。
仔细还原这类语言的语义规则，*this 被作为隐藏的参数，但这其实还有个更一般的形式——静态环境（在静态语言中通常被处理成不可见的符号表）。
隐藏显式名称查找的语法，都写成前缀，比如 Lisp 语法：(len x)——就能发现完全是一回事。是不是要依赖 this/self ，只不过 len 到底是从哪里来的罢了，这完全可以作为实现细节，而实现这里的简单。

2.这玩意儿是个普遍的问题，和 OOP 本没多大关系。
扯上 OOP 的关系，大约是某 PL 大手子的功劳。
这样的理解原则上就是歪的，应当予以纠正： https://stackoverflow.com/a/74375048 。

无论是误会的形成还是传播，去除脏话以后，拍案叫绝的成分都是够多的。

顺便，至于 0 索引，那倒是有点洞察世界的味道，但是只字不提 EWD831 （ https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html ）这种常识性文献，多少有点过分。
原文评论区有人指出了这点。GvR 只是提供了关于 slice 的新发明，然而除了提了一点避免 off-by-one 错误问题外并没有涵盖 EWD831 的内容。
EWD831 距离所谓的世界的洞察也是有一段距离的，因为它只是很隐晦地顺带提到了根本原因：基数(cardinals)和序数(ordinals)的区别。
这种洞察，对有点数学（哲学）系统训练的用户来说，实在过于基础了，也许不值一提。不过放在这种文献中解释，从一般情形（而非举例）证明为什么索引应该从 0 开始，本应当是有必要的。不过作者并没那么做。

@aloxaf 口味问题严重到一定地步，还真可以说明对世界的本质缺乏洞察力。比如看看这里 GvR 是怎么认怂的：
http://neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html
作为对比，这方面什么叫有洞察力的：
https://www.researchgate.net/profile/William_Clinger/publication/2728133_Proper_Tail_Recursion_and_Space_Efficiency/links/02e7e53624927461c8000000/Proper-Tail-Recursion-and-Space-Efficiency.pdf
注意考察这里的分析对具体（任何允许递归函数调用的）高级语言的具体设计基本中立。
设计通用语言的有义务理解计算模型和理论 CS 教育的影响。MIT 的某课程改用 Py 在这方面就是一种消极的影响，尽管这锅不是 GvR 背的，但没有 GvR 瞎搞，这个世界恐怕会好很多。
倒不是说 GvR 多大奸大恶，但是一个平庸的选手占据了过于显著的地位浪费资源引领菜鸡互啄，这是业界的不幸。

当然这文章里提到的东西普遍比较水（作者的洞察力相当可疑）。
比如什么 i++，根本就是 artifact ，该问的是本应当是为什么 C 之流使用这种设计，而不是 Python 不使用这种设计。Ken Thompson 搞出这货的时候还有节约代码长度的技术作用（类似的一个更著名的语法是 C 的声明符），现在剩啥？ Python 没有稀里糊涂照抄这种设计，反而是正常人的思路。
这里唯一跟“本质”洞察力能扯上关系的是 lambda 的设计（其它大都是比较菜的历史和工程 tradeoff 问题）。这个例子中，社区里脑子正常的更多点，比 GvR 更加分得清限制的工程复杂度后果；不过半吊子妥协搞得不伦不类也许是更差的结局。当然，这点也说明“由个人主导的语言”早就寄了。不过如果让这 BDFL 一路作死，说不定现在就没那么多不求甚解的口味奇怪的用户了。

@doyel VPN 算是，RDP 还真不一定。
虽然原则上用到了应该由企业提供解决方案。