看你定义什么叫裸，或者说想裸到什么程度。
比如我还没有见到会（无聊到）能逆向出源码中的 ASCII art 的反编译工具。

切换到 iOS 不见得会解决问题，如果不是更糟。
正如这个 issue 下的回复一样，实际情况是逼迫用户在 social death 和放弃使用选择一项。还没有人能正面反驳这个问题。这自然说不上你圈所谓“生态”的多光荣的现状，所以要拒绝也自然只能曲线救国了。
换 Apple 的产品其实有个类似的问题：不管你自己想不想用，周围人或多或少会逼你用——甚至从来不用也一样。（而且因为定制起来对开发者都更麻烦，问题可能更大。）你长辈要你安装个 app ，你是十动然拒，还是厚脸皮说“不会”然后被婊“白养了你个×的”？或者直接因为这种破事撕破脸？
真要这样就太二了。无论哪种情形，明显鞭策便于接受用户需求变更的厂商是跟低头不见抬头见的周围人闹翻相比更具有现实性的捏软柿子的手段。
当然这里已经排除了个更硬的选项——自己撸个替代品。不过就 Android 这么一坨坨的玩意儿， fork 的成本和全部重新造轮子都快相差无几了。看了一下，回复里还真有个“ make a fork of Android since it is open source ”的，该说是套路么？
一定意义上这应该就是 RMS 不用这俩货的理由。不过对于其他大部分用户而言，用一坨破烂更省事，问题还是不会解决。

@patx 你的话柄比原问题报告者落得更明显。
首先，如何定义“正常工作”，什么叫“合理”？在没有和客户约定死支持范围的情况下拒绝因为预期行为不一致而产生的请求是合理的？（当然，有没有义务是另一回事。）
如果想说这种用户理解的 force 不是项目成员理解的 force ，或者想说不是项目范围内应该解决的问题，那么 ok ，先澄清支持特性集的边界。直接劈脸 intended 是什么鬼？怎么不说 by design ？
第二，“不是 bug ，当然是 won't fix ”是一种什么精神？你正好搞反了，正因为 issue tracker 跟踪的是 issue 而不仅是 bug ，所以处理时更不应该不是 bug 就 won't fix 。（人家 bugzilla 还处理 feture request 呢。）
回复的估计都没敢这样想。

当然这里处理的具体做法（直接的回复）有个明显的槽点，就是报告者都没明确咬定这个 issue 是 bug 的时候（虽然报告者在方案里用了 fix 这个词——其实对实质问题来讲是错的，撑死叫 workaround ），直接就一坨更次等的 fallback workaround 覆盖需求变更了，包括传话的回复在内，显得十足的不专业。
更合理的反映是先明确定性，回复这个 feature enhancement request （或者随便什么别的，总之也不会自认就是 bug ）的 issue 因为 blah blah blah 原因不能修复，然后就不用多废话了。现在呢？被 switch to iPhone 噎回去吐不出象牙很好玩？

……某些小区门口大白天就蹲着若干中介。

虽然可能不是主要问题，不过 grep 的实现性能经常不够用。可以试一下 ag(the silver searcher)和 ripgrep 之类，用法和 grep 大同小异。
不过如果模式简单（只是找关键字 XXX ），可能自己直接实现个 native 程序（在各种意义上）还更快点……

@wwqgtxx 用 reflection 实现 type introspection 编码的可不是 typechecking rules 。

@htfy96 不要看上去 duck 就 duck 了。 Duck typing 是把类型检查推迟到运行时，而 C++这里明显不是。这叫 structural typing ，对立的是 nominal typing 。
@wwqgtxx golang 那也是 structural typing ，而且用户无法自主编码类型检查规则。
@starvedcat 火焰猫燐是一只火车然而不是汽车……（

C++所谓的 pointer 可以有多种含义。
一类是从 C 照搬的 pointer ，是一类内建类型。
另一类是库中约定的泛化的 pointer ，如满足标准 NullablePointer requirements 的类型（例如 unique_ptr 的实例）。这些类型往往也被直接称为 pointer ，如 smart pointer 。严格来说这些类型只是 pointer-like ，限制比内建 pointer 小，除了 CopyConstructible 之类的语义约定外，通常只要求特定的*或->操作之一（连这些操作都没有的一般称为 handler ）。
iterator 是指库（如 SGI 或标准库）约定的概念，一般指满足标准 Iterator requirements 的类型。这对右值 r 只要求*r 和++r ，限制同样比无论哪种 pointer 都小得多。
在标准库的框架中，内建的 pointer 是 random access iterator ，然后可以很容易推出 pointer 是 iterator ：
random access iterator 是 bidirectional iterator ；
bidirectional iterator 是 forward iterator ；
forward iterator 是 input iterator ；
input iterator 是 iterator 。
Q.E.D.
反过来不成立。
至于其它意义上的 pointer ，连++都不保证有，就自然不是 iterator 了。

@pagict 看清楚标题。
C++的 iterator 哪来的 next()。
@sagaxu 关虚拟地址毛线？
unique_ptr 跟地址有一腿？
逻辑地址和物理地址就不能跟 pointer 有一腿？
@nicevar 哪个语言的指针是所谓的内存地址？

这么多年了 HR 也该学精知道这种能刷的玩意儿不靠谱了吧……

@nbndco 问题在于 0.999...未必表示一个实数。
受到良好数学训练的童鞋应能立刻了解问题的关键——这个问题恰好在不同的分析学中可以有不同的结论。
如果 0.999...保证表示一个标准实数，那么很容易证明 0.999=1 成立。但是，实际上 0.999...不保证蕴含一个实数的表示（具体来讲，最终取决于使用何种对无穷小量的态度，这是个数学哲学问题），它代表的数不一定具有阿基米德性质；部分不同意=成立的意见实际上也隐晦地指出了这一点，但大部分没有经过充分训练的童鞋没法理解而视为诡辩，却不知道其实是自己因为无知而使用了没有充分论证过的假设，就结论上来讲，错得更离谱。
这里构建超实数的做法可以参照 https://en.wikipedia.org/wiki/0.999...#Infinitesimals 的讨论。

@DinoStray Java 语言一开始使用 UCS-2 ， J2SE 5 开始使用 UTF-16 ，现在由 JLS 规范。 Java 的一些 API 支持 UTF-8 和 MUTF-8(modefied UTF-8)。 JVMS 规定 JVM 的实现需要用到 MUTF-8 表示特定的字符串。一些其它实现如 Dalvik dex 也使用 MUTF-8 。

@zhidian 不巧，历史上 Unicode 和 ISO 10646 钦定的一些重要的方案如一开始的 16 位直接索引的编码和之后的 UTF-32/UCS-4 就是这样“浪费”的；退一步说，至少 UTF-8 发明之前就是这种状况。你的槽点又有几何呢……

既然务求严谨，顺便纠正 LZ 的几个表述不清晰的地方（包括错误）：
“其实 Unicode 是一个囊括了世界上所有字符的字符集，其中每一个字符都对应有唯一的编码值（ code point ），然而它并不是一种什么编码格式，仅仅是字符集而已。 ”
—— Unicode 的本义大概是如此，不过现在早就跑飞了。现在的 Unicode 很难单独抠出“字符”的概念和日常的字符讲清楚（这是我认为 Unicode 辣鸡的地方，且按下不表）。例如， emoji 姑且可以认为是“字符”，但带颜色和不带颜色的 emoji 指派不同的 code point 是什么鬼？
“ UCS-2 是使用两个定长的字节来表示一个字符”
——编码 UCS-2 的是两个八元组(octet)，不能和字节(byte)任意互换。
“而 UTF-16 是使用两个变长的字节”
——读起来难以言喻……
“之所以在 Windows 下有 Unicode 编码这样一种说法，其实是 Windows 的一种错误表示方法，它真正的编码类型是 UTF-16LE 编码。”
——因为历史原因，当年所谓的 Unicode 编码=UCS-2 ，因此也不全然是错误。反倒直接说 UTF-16 是有问题的。事实上， UTF-16 的普遍支持是 Windows 2000 加上去的（部分超出 BMP 字符的用户层机制如 WM_UNICHAR 在 Windows 7 之后才全面支持）。
“ Unicode 只规定了每个字符对应到唯一的代码值（ code point ），代码值 从 0000 ~ 10FFFF 共 1114112 个值 ”
——历史上除了最开始的 16 位编码空间外，之后曾扩展到 32 位。限制 U+10FFFF 是 RFC 3629 时候的事。（顺便注意一下 UTF-8 的版本。）

@vultr 首先找错误未必“花大量的时间”，内行可能一眼就注意了；而花时间告诉别人这里存在问题和“写几篇正确”作用类似，成本不同。同时没法要求有技术专长的人人都能高产赛母猪……
@DeutschXP 我有些好奇你如何揣测出“新人”“向上爬”。我在这里完全看不出这一点。
@ersic 太多人没注意到“个人笔记”的性质了。
@linxu 谓词（虽然也叫 predicate ）看来不是你要说的意思……
@21grams 我觉得让人找不清楚门在哪里往哪边开是很不够意思的。
@stranbird 我经验的和你认为的正相反，大部分真·小白对这类内容来源是抱着跪舔的心思拜读的（其中的多数还不会说出来这种不长脸的事）。

@coderzheng 作为读者，希望内容质量能和名气正相关，节约点时间。
作为懂行的那部分相关领域的读者，希望能正经科普少添乱。

@FrankFang128 然而错误也不限于单一的专业领域。
比如我记得之前有著作权的理解上的低级错误，总算评论里有人指出了。
考虑到相关的坑不少还不总是那么容易被读者发现，提醒提防一下还是有必要的。

@xieranmaya 看来我们在不同的次元上。

先说共识吧。顺便补充一点说明。
做 Web 前端，选 js 入门问题不大。作为跑不掉的浏览器端语言，在这个领域确实没有什么成气候的好替代的东西。
这个学校里一般的编程用 C 入门完全不同——大部分情况下都有更好的替代，现在只适合极少领域的应用。
另外， js 的设计好歹比 C 高级点，支持的范型多一点，就算只学 js 也不至于像只学 C 那么有误导性。
虽然 js 作为一般的程序设计入门仍然不合适，但考虑培训的需求，可以忍耐。

“我想你说的应该也包含计算机专业的吧”—— bingo 。“深入下去都是单独的领域了”——正解。
“常规软件开发，对该了解的问题了解到足够的程度就可以了”——没错，但这不表示根本性误解是可以容忍的。
或者说，被误导还不如继续无知。因为这类过于基础普遍的问题潜移默化导致的错误很难控制风险，比如鸡同鸭讲的额外沟通成本——总不能把这部分全扔到理解正确的一方吧？
“就算是有导师指导，自己啃论文肯定是少不了的”——不对。这不是学术研究，不讲究材料的来源，只关心内容的准确。
“了解到基础的层次，我想信数学基础不差的人绝对不会有问题”——这也不对。这里硬要说有基础，在于怀疑主义和搜索能力两方面。我之前刻意拿数学基础举例，就是为了说明通常意义下的一般人理解的数学基础也不靠谱。
“至于你提到的 concurrency 跟 parallel 这么细节的问题”——仍然一般性地不对。这是对于不少相关行业从业人员来说都很“宏观”的普遍而又基础的问题。（嘛，很适合用来面人，成本低效果好——只要面试官自己不缺斤少两。）虽然培训的目的不是为了教会这个，但既然打算巩固基础，至少避免流行的误会还是有必要注意的。
“事实上你永远都可以抛出一个偏门的概念来说很多人都不懂”——没错，不过上面显然不是“偏门的概念”，而且确实有培训会讲到（对 Web 前端来说也是有必要了解的）。

“毕竟这几个概念每个都能在宏观角度观察到它们的行为”——这就是主要分歧。
仅仅是提醒一个人注意行为和某些概念相关，可能确实用不了多少时间，你说“最多也就是多花点时间”一定意义上没差。
但既然做培训又不坑人，那得顺便帮助把基础的坑绕过吧？这就不是一回事了。
特别地，行为和抽象的目的是两回事。只通过观察行为了解问题，可能是方法论上错误的，或者干脆就是有害的（形成错误的刻板印象）。
拿你认为没在重灾区的例子举例，你需要怎么应对 C 的未定义行为？（另一方面，你自己当年是怎么绕过这个坑的，还是说压根没注意到就直接飞过去了？）
这种情况下学员越是只看行为分析问题就错得越离谱。在他们缺乏能力找到正确的方向时，找人带“基础”的意义才尤为重要。

还是引用一下原文吧。我评论针对的是这里的认识：“我不相信他理解不了二进制、网络、多线程、异步，理解不了能够活生生的在他眼前运行，并且能够单步跟踪调试的编程语言。最多也就是多花点时间。”
实际上我还真不信这里能有几个人把这几个论题的*外延*都搞清了——且不论接受过教育的背景和花时间的多少。（至少对照 SO 上到处都分不清 concurrency 和 parrallel 区别的回复来看真不能奢望。）“最多也就是多花点时间”是不是乐观过头了？

@robsong 不坑人是基本不可能的；没有特别的姿势，越速成基础课越坑人。
坑是谁都没法回避的，所以不需要太在意有或者没有的问题；但是不在意风险或者拿不出应对方法，明知山有虎偏向虎山行，就不地道了。