@lytofb 当初吹要取代 C ，还不是只能老实当 DSL ……
@lizon 细分领域到最后是项目一有需要就人手撸个新语言实现而不用担心成本。靠 C 糊弄明显是初级阶段的初级阶段。 C 现在除了本来合适的领域，实际项目中主要也就继续靠实现其它语言（以及死皮赖脸装作能霸住互操作接口）刷存在感（虽然 Lisp 和搞所谓 FP 语言的那伙人多数早就对此没兴趣了）。
毕竟现在条件好了能用的选择多了，不需要在此浪费时间。

@ecloud
K&R 当时的确是想发明“更好用的汇编”，但显然不止是汇编，不管是以 B 作为基础和有意无意保持可移植性。
不过我基本同意“低级语言特性”主要是实现的锅。但是提交标准化以后，这些锅最终都尘埃落定了。
在我的印象中伪码是历史上因为编译性能等因素才体现出有意义额外流程。现在并没有这个必要。
与其说 Pascal 是背惯了实现的锅，倒不如说是后续长期疲软才是致命伤。
互操作上的先天不足和其它一些不方便的特性（如 Why Pascal is not my favorite programming language 所说）使市场已经倒向了 C ，在之后没有靠标准化扳回一城于是满盘皆输。

关于强弱类型的问题，实际上和 C 没有直接关系。
按 C 的概念， if(a=5)不管和 typing 还是 type checking 都没关系，所以传统上跟强弱类型的论战也没交集。
当然理论上来说还是可以有的，但按 C 声称的设计，死活不承认 lvalueness 是类型系统的一部分（倒也不像 B 一样直接作为文法元素的性质），那样怎么说都通。

@lizon

> 就计算机知识体系来说， C 是最佳的线索。我对初学者的假设是“想了解计算机体系结构，但是没有人带领”的人。

我之前说过了，就是需要学 C ， C 也不适合放在最前面，因为基本上总是有更合适的路径。似乎你总是无视这个选择。

> 在学习 C 的过程中，会碰到很多问题，一方面是语言造成的，一方面是底层封装不完善造成的，在解决问题的过程中，一方面可以接触了理论知识，一方面可以接触硬件知识，对他自己寻找方向是有好处的。一旦找到了自己的方向，那还用不用继续学 C 就是他自己的兴趣问题了。

这仍然只是说明 C 是可选项，而不一定就是最合适的，也避免不了对于大多数需求事倍功半的事实。

> 不要以为跑数据写代码就是计算机的一切，你说的“普适”的语言对于想玩硬件，从事嵌入式系统内核开发的人有意义吗？

至少就 C 来讲在这里是不得不有意义的，因为 C 的设计自身极端强调这个层次上的“普适”。

要从事嵌入式系统内核开发，也不可能一开始就学嵌入式系统内核开发专用的 C 。何况任何 C 的方言无法绕过 ISO C 这个基础 spec ，否则就不是 C 了。

有些领域入行了提升并不是很困难，困难主要因为不是这个领域的公共基础的难度堆起来的。自担风险。

> 我往坑里带了吗？没有说学 C 就一定要用上 C 。

学了不用和为了不浪费之前没规划好学的东西而去用一样是坑。正确的姿势是为了用而学。

你可能会说学 C 是基础积累，不直接用也可以发挥作用。遗憾的 C 在许多人眼里的“底层”是假象，而对大多数人的目的来说，发挥的作用经常有其它更合适的学习路径替代。

@proudzhu 你要知道 C 这种人为设计的东西，通过对“指针”这个术语的明确的定义和拒绝提及其它义项，就完美地把“指针”在其它领域的本义覆盖掉了。所以光是讨论 C ，你只有一个无歧义的“指针”的概念。如果你需要同时讨论更底层的某些 ISA 中定义的指针，那还不如直接说“地址”更清楚，不需要无谓增加同义词和混乱。（你也不方便随便发明一个新概念代替 C 所谓的“指针”了，加上“智能指针”这类派生，“指针”这个词在一般场合是保留给高级语言的。）

而虚拟地址空间是另外一层抽象，通常比 C 实现的层次更低。不算 WG14 某些扩展提案， C 本身不对地址空间做任何抽象（其实根本就没提什么地址空间）， ISA 和一些硬件 spec 倒是会提到支持，所以提虚拟地址空间实际上已经是 C 以下的底层话题了。排除高级语言这个意义上讨论“指针”的含义反倒比上面明确，虽然我仍然更愿意看到“地址”这样无歧义的表述。（嘛，严格来说上面所有的地址特指 memory byte address ，不过一般人也不会没事倒腾寄存器编址什么的……）

@proudzhu 很遗憾，我还真找不出“不是错误”的借口。这是让实现细节倒置到接口之上的典型 leady abstraction ，怎么看都是设计上的经典反面教材，只是各种不明真相的群众以讹传讹说成了“精华”，也是无语。
改正这个问题最简单的做法就是直接提供底层的指针代替现在的指针，可以实现为整数或者加上一些检查的地址类型（也可以考虑提供地址偏移量类型），于是“（对象）指针就是（可选的）地址”成了真命题，符合一些用户的预期。而现在 C 那种指针应该被废弃，非要兼容也应该弱化为库来提供而不是语言内建。这样语言规范里的废话也能转移出去一大坨，二进制兼容性维护起来也方便得多。
然而很遗憾， C 在参数化类型上的开洞导致这种改动必须另加很基本的核心语言特性而不现实（不像 C++有模板加上一个扩展标识符占位就立刻能凑数）。所以估计接下来几十年将错就错还是主流了。

@proudzhu 你的误解应该综合来源于几个方面。
须知：
1.底层（ ISA 设计提供的）的指针，一般就是有特别含义的地址。
2.C 所谓的指针和上面所谓的指针根本不是一回事。
3.这两者在实现上是有些关系，但不需要倒腾二进制互操作的用户（显然包括绝大多数新手），附会只是添乱。
4.大部分用户没有机会也不必要同时接受把这些东西理解得面面俱到的系统训练。
只有绝对少数领域（像实现 CPU 的、做编译器的、维护系统 ABI 的、在这个层次以下逆向的、因为目前 ISA 抽象混乱做 OS 不得不在这个层次上 hack 的……）的实现者和设计人员中的 architect 才有必要把这些都理解清楚。
相对来讲，只学高级语言，忘记“指针就是地址”符合更一般语言用户的需求。
先钦定指针=地址，根本就是搞错问题领域了。我当作误导，不算冤枉吧？

另外补一句，我来义务诊疗并非因为我闲着没事干或者热衷慈善，而是因为太多被带沟里的厨余发酵着让业界发馊了碍着我了，基于利益考量，我有必要采取减少我潜在工作量的对策罢了。

没搞清楚扯啥的搪塞的还是趁早闭嘴比较能节约双方时间。

@kaneyuki 你先搞清楚答主的问题该答的上一页已经答完了再来水好不好。
现在的焦点明显是给上一页的某些回复擦屁股避免不确定的影响。

嘛，需要小尾巴广告的话——照例专业治疗各种自以为学会 C 的癔病。

@proudzhu ……看来你不仅没学明白 C ，也不懂什么叫“优化”。
对 C 来讲，允许编译器优化而不依赖语言扩展的唯一依据是不违背 observable behavior 和 abstract machine 指定的等价性（ C++倒是在 as-if rule 以外还有 copy elision 和 operator new merging 之类的开洞）。不管 sizeof 还是指针的类型都是在语义规则里直接钦定的被 abstract machine 都支持的东西，编译器必须得正确地生成不同的代码（还有可能报错），什么时候有脸叫“优化”了？

> 一言不合就学傻，按你说的我需要先理解 sum type ，再理解编译器中 sum type 的具体实现，再来理解指针，绕一圈？一个本来相对底层的概念非得用个抽象的东西来理解？

这还真是学傻了。
1.sum type 在 C 的常见实现就是(untagged) union+表示 tag 的整数 /枚举值。这是很常用的惯用法，我不信真学会 C 的连这种做法都理解不了。也许只是不求甚解的时候不太理解计算机科学更通用的术语自己吓唬自己罢了。
2.上面提 sum type 是指代替指针这种错误的偷懒设计应该怎么办。注意 tag 在静态语言中是能编码为静态类型确定的，所以可以实现成某些 C++库中的 compress_pair 。 C 的类型系统太弱没法自定义数据类型来描述，如果用 C++，忽略 tag 以后运行时内部在某些方言中的表示可以大致是这样：
template<typename _Tp>
using __pointer<_Tp> =
union
{
__uintptr_t __address;
__optional<_Tp> __nullable_ref;
// ...
// ...一堆 friend 当 std::is_object<_Tp>()的时候定义 pointer arithmetic ，略。
} __attribute__((__may_be_aliased__));

另外，这里的关键问题你理解错了。正常点的语言设计根本就不应该在实现扩展外出现这种投机取巧的类型，更应提供给用户的是等价于这里内部表示的__uintptr_t 和__optional 等等的（高阶）类型。所以你压根就不需要理解这样的实现。

@proudzhu 看来又是个学傻的…… C 的指针加法跟地址加法一回事？
嗯，我怀疑你根本就不懂 C 。

@lizon 你还是没找到点。

> 你认为一开始就应该给初学者提供比较完善的语言和类型系统，让初学者知道什么是对的，什么是先进的，以最快速度学习享受到现在最先进的理论成果，更多的关注语言本身的描述能力。

如果我认为“一开始就应该给初学者提供比较完善的语言和类型系统”，那么压根就不用提 C 了。
但是考虑实用，这种“比较完善”的东西并不存在，所以并不需要从这个角度考虑先从什么上手。
（不管实用的话，可以考虑 Racket ，但有些知识复用性比较差。）

> 我认为一开始应该提供给初学者最大的自由，暴露合适的硬件细节，让初学者明白计算机到底在做什么。

用 C 显然不是最大的自由，而且很容易让初学者搞不清计算机到底在做什么。
因为 C 暴露的硬件细节其实不多——至少没 C++多。而且经常暴露得很不地道。
例如考虑不相关指针比较是 UB 这点就可以明白实际上 C 自身的设计（强调可移植性）完全是和单一地址空间的简化实现假设相悖的，和 C++11/D 形成鲜明对比。
（其实理论上来讲这里 C 的设计更“正确”，只是实际上几乎并无卵用。）

注意，我猜你想要的“暴露硬件”就是这类语言设计蕴含的抽象假设。
如果是指操作硬件的接口，那么 C 无能为力。必须了解 C 以外的知识才能谈论是否能上手。这对初学者是不必要的负担。

> 我不明白学 C 的低效在哪，风险在哪。

低效有几方面的原因。
首先 C 涵盖的新手急需的知识点太少，学其它语言上手容易收获更多。
其次是教 C 的材料多数比较劣质，光是找到对路的参考资料就需要额外成本。
再次，即便教对了路， C 本身的一些古董劣质设计很容易造成先入为主的错误观念形成误导，阻碍进一步学习——除非有意忘掉一些东西——这就是低效。
核心风险是 C 没学好， C 以外的知识也没学好，另外还会教坏别的小朋友。
因为上面几个原因，拿 C 混搭基础课造成的麻烦比其它语言大得多。

> 面向初学者的教材几乎全是 C ，算法教材也大部分是 C 代码或者类 C 伪码，各大高校开设的计算机课程必定有 C ，已经为初学者尽可能降低了学习曲线。
这是错觉。问题包含几个方面：
不加前提地营造 C “够用”的假象，而不是在使用之前引导学生了解适用范围。
算法实现如果只是伪码描述目的还好，但似是而非的、和现实使用不怎么着边的实现风格就大有问题：这是在误导这类实现是“正常”的或者“不重要”的。
注意即便主题不是实现，作者仍然可以使它们接近实用的做法，而不是普遍地拿半成品搪塞。（当然并不是所有算法书都这么烂，但跟 C 沾边的主流如此。）

使用不容易自然过渡到实用场合的代码教学，使学习者最后至少要学会两套不太相干的写法才能体现出所学知识的用途，这显然不是“降低了学习曲线”，而是人为抬线。

> 初学者需要“学习 C ”，而不是“精通 C ”，不要去研究 C 语言本身的细枝末节，最主要是理解指针概念。

我说过了指针作为实现技巧是个小聪明，而作为语言特性是个烂发明。
如果你是指跟理解指针有助于和了解硬件，很遗憾，这个也是错觉。因为 C 的指针不是描述体系结构时使用的“指针”——有关联，但完全是两回事。
（不信，让这些自以为学会 C 的去看 ISA 手册，看看真正地道的“指针”和 C 的这玩意儿有多大出入，需要浪费多少额外时间才能明白自己想错了。）
另外，即便只是说 C ，我觉得不能理解为什么指针不靠谱的，不该视为理解了指针。具体地，真“搞清楚过指针运作原理”，除去程序语言理论专业知识，下面的一大半应该是能自己独自发现的：
https://github.com/FrankHB/pl-docs/blob/master/zh-CN/why-is-pointer-awful.md

> 有底层知识的支持，很容易就能理解函数指针，回调，委托的关系；从来就没有所谓的引用传递，都是值复制；缓存一致性问题不单单出现在底层，数据库，分布式系统同样出现，在底层同样能接触“速度不够就要加缓存，有缓存就要解决缓存一致性问题”这个朴素道理；类型系统都是纸老虎，是数据就都得放到内存里算。

我很确信依赖实现支持的理解会造成一些典型的错误理解。实例很多。比如被 const folding 坑了的。

你后面一些理解也是典型 yy ，但对大多数用户影响更大的是原则性方法论错误：模糊问题和解的边界。谁来替你保证实际的实现和你想象的一样？出问题谁负责？

顺便，函数指针不管在 C 和 C++中都是大坑，因为甚至连对应的“地址”是什么都扯不清楚。这种 spec 基础问题表明这些语言不适合入门。

> 为什么 C 语言最合适，往上看，高级语言写法风格大都类 C ，要学习其他语言并无太大的不适应。

如果是“都”，那么稍微有点用。然而“大都”是最差的情况——似是而非，想要正确就基本不能合并学习路径复用历史知识，鸡肋。

> 类型系统一个语言一套，但是指针是每个计算机都有的；往下看，完全可以通过逆向 C 程序来往更底层的方向走。

你搞反了，“没有”类型系统是类型论应用的简化特例。这个特例对设计语言的人有点用——因为可以按需定制自己需要的类型系统而不是被渣语言设计恶心；但对多数用户纯属浪费——至少使在具体任务中以不够系统的方式重复造不知所谓的轮子代替缺少的静态契约检查变得有必要了。

C 之所以在 B 上加上了类型系统，主要初衷也就是为了避免这里的不利影响。只不过由于设计者和实现技术的局限性，很不地道罢了。

至于“一定有”指针那还是错觉，你对体系结构设计的见识太少。至少可以确定 ISA native 的 pointer 不保证说的是一回事且可以以一致的方式使用。如果地址操作数直接够用，完全不需要引入 CISC 风格的指针概念。

逆向 C 程序是为了逆向本身的需求，如果说了解底层，比直接学习 ISA 慢不知哪去了……

> 如果是做语言研究，连用 C 入个门都困难，或者跌入个 C 设计上的坑都要大呼小叫，我觉得可能他的能力不适合做语言研究。

如果做语言研究，连 C 那么多明显的窟窿（以至于不适合入门）在哪都找不到，我觉得无论如何都是白费劲。

C 作为样本研究是有价值的，所以可以一学。仅此而已。

现在业界做语言和实现原型主要是 Scheme 这样的 Lisp 系方言。为了让之前学的 C 不浪费而故意复用 C 的知识也基本就是浪费时间，经验不够的还不如死了这条心。

> 在不清楚这个初学者以后到底要干什么的情况下，在初学者连自己都不知道自己到底要干什么的情况下， C 是性价比最高的语言。

我不清楚你有没有看到我指出的不管出于什么实用目的，基本上都有比直接学 C 更高效的路径这点。所以把 C 排在技能列表前面性价比不可能是最高的。

噫……又抽……
int i; int i; int main(void){}
关键字 tentative definition 。
很讽刺的是只看 ISO C 基本是看不懂为什么需要这玩意儿的。倒是 ISO C++的 Annex C 里讲不兼容 C 的部分时会说清楚理由。

@muziki 自己了解，不要人云亦云。
比如说……
@taozhijiangscu ←反面教材。
是不是简单直白就不说了，自己比较 spec 去。
只是需要多澄清一点： C 的潜规则一点都不比对应的 C++少，而且往往更膈应人。
int i; int; int main(void){}呵呵……
至于为啥多数人都没法注意嘛……写书卖钱教你的会拿自己都没把握搞清楚的东西来恶心你劝退？

@lizon 关于反面教材我倒是可以再解释一下。

对于搞语言实现的来讲， C 勉强顶用（但现在也不必要），但对 PLT ，以 C 作为目标是坏榜样。

理由和可计算性没什么关系，而是抽象设计的局促，不仅比起更现代的语言没有优势，功能和设计的一致性上就显著地比同时代的 Lisp 方言劣等。（为什么没有一等函数？）

即便是学习过程中 C 充其量也就是个中间产品，这样还不如直接用 C--或者 LLVM IR 什么的免得什么 decay 之类乱七八糟不务正业扰乱视线。

此外， C 的很多经典的设计，以现在的观点来看，是迁就实现的落后而带有误导性质的设计。这对于几乎所有用户都会产生效果。

比如指针，说穿了就是一堆能共用实现但抽象上本不需要相关的 sum type 。然而先学 C 学岔了不去补习其它语言设计策略或者理论的，基本上就没机会去自己发现 sum type 了，却实实在在“享受”这些设计带来的易错和其它工程上明显低效性质而浑然不自知甚至自以为优越。

（类似指针的东西当然是有用的，但不需要也最好避免在 C 这个层次上提供。）

再如数组的[]，一定意义上导致用户对真实的实现上对应的操作具有错误的复杂度假设——尽管严格来说这不算 C 的问题（ C 也确实没保证）。

@lizon 你的回复有一些比较明显的问题。
1.讲性价比而不顾风险。学茬、低效、一事无成很容易导致性价比一点都发挥不出来。
2.我上面说过不管基本上为了哪种目的学 C ，都有比直接学 C 更有效的策略。
3.你似乎不把 C 当“高级语言”。然而不管 C 的抽象有多不给力，事实上 C 就是彻头彻尾的高级语言。
如果说 C 因为能操作底层实现所以显得低级， C++和 Rust 之流同样也做得到。这和抽象能力的上限没什么关系。
而纯粹的 C （ strictly-conforming ISO C ）甚至严格地比 C++更“高级”。比如说， ISO C++引用的 POSIX 的 errno 错误码在 ISO C 里缩水得没剩几个。
可见仅仅要让 C “底层”到堪用到这点程度，就必须学更多 C 以外的东西。更别提二进制互操作了。
注意，你所谓的“俭”——表达相同层次的抽象时对实现细节依赖少——在日常见到的语言中，恰恰就最符合的就是纯粹的 C 。要说其它的，基本上是个日用的语言都不会那么“俭”，而会偷懒假设更多东西。
（当然， C 也不是都不偷懒，比如和 C++一样假定一个字节至少有 8 位，但不管怎么说比 Java 和 POSIX 这样钦定一个字节=8 位总是明显“俭”的。）
C 正是用这点换来了卓越的源码层次的可移植性（尽管实际上由于限制过于严格多数场合并没有什么卵用……）。
所以你说的学 C 只能认为是学 C 和底层的其它知识，这并不比学其它语言+底层知识优越，还更容易引起混乱，同时得到的技能并不实用。
4.混淆抽象性质和实现的层次。
具体来讲，“高级”和“高层”不是一回事，“低级”和“底层”也不是一回事。（有多少人知道有高级汇编语言……？）
底层实现和强调抽象完全不矛盾；相反，为了了解底层实现，一些（和高级语言类似的）抽象是必要的，否则一些情况会导致理解底层这个任务都不具有可行性。
提一下， volatile 本身恰恰就是非常学术的东西，而且算是 designed by committee （ X3J16 ）而有正面反馈的典型例子。
工程上实践对 volatile 的大大咧咧反而导致了一大票的误用 bug 的笑话。
比如语言设计领域算是比较著名的 double-checked locking 失败例，最终迫使 Java 更改了 memory model ，而现在 Java 和 C#的 volatile 的意思和 C/C++里的截然不同。
直接根源就是多数用户对 volatile 的想当然。
有多少工程派领会到了这些背景知识？有哪些纯粹的工程需求驱动你去了解这些东西？
我不怎么相信你没有足够的抽象会支持你看得下去，因为具体的东西太细碎了。
另外，像 cache coheretece/memory consistency 这样的东西，我也不信你用反抽象的方式能理解得了。
如果说抽象迟早绕不过去，为什么还要用低效的方法？
5.如果要学院派，请严谨地保持含义的准确。
图灵机与λ演算显然不等价，因为“等价”不等价于“可计算性等价”。
对选择学什么语言入门来讲，恰恰需要在乎其中不等价的部分，比如说抽象能力和性能。
6.注意蕴含逻辑。
即便“ C 的程序更符合初学者的思维方式”，也不自然表示这是初学者需要的思维方式。
何况“ C 的程序更符合初学者的思维方式”其实是很有疑问的。
初学者（乃至有几门其它语言经验的老手）基本上不可能理解 C 的抽象机模型和可观察行为等价的要求，所以没几下子就只能拘泥具体实现了，同时还没搞清楚适用范围。
结果就是一些很重要的基础知识（比如什么是 UB ）都缺乏机会掌握，上手做什么就被坑什么，坑了还未必能总结出规律下次避开。
这样还不如直接就来抽象能力强一点的语言呢……好歹能上手把更多的事做对，而不至于找不到方向。

……很遗憾，随便逛了圈，发现 C 学傻的大概的确到处都是。
这里后面回复的大半楼几乎全能挂上： http://www.v2ex.com/t/298012
连 C 的 object 都不知道是什么还好意思装作会……再次表明 C 坑比 C++坑更危险。

@owt5008137 “可以”也并没有什么卵用。
要知道#include <h-char-sequence>这种形式可是整个 implementation-defined ，只要实现高兴都可以允许塞个图灵完备的语言实现进<>中间去。实际呢？

@ssoftlns 好像还有其它棍棍言论啊……可以看看隔壁那位跳大绳是怎么被 B 的： http://www.v2ex.com/t/296233

> 工作那多年 还想负责地告诉你 不只 c++哦 java 、 php 、 python 等语言都是以 c 为基础的 哪怕 golang 都是以 c 为原型的哦

用 C++实现的 PHP （其中 C++自举）以及 Java 和 Golang 自举就先无视算了， PyPy 耳光不要太响亮。

> 对了 顺便再解释一下 无论你使用什么语言 什么指令集 最后都会被解释成机器指令来执行的

区别在于这里我日常工作内容就能直接打脸了：我钦定的语言编译成扔进 CPU 的 ROM 的代码， CPU 里的 decoder 把机器代码转换成类似的格式扔给 backend ，后面电路里执行的根本不存在你以为的什么指令集的机器指令。
到底哪个是“最后”？

这楼简直是卖弄全站 C/C++水平下限……

@ssoftlns 谁教你 C 的“语言特性”没对象的？
理解成面向对象强行扯没的也就算了，还非得颠倒黑白。就这样也好意思学过 C ？

WG14 N1570
3. Terms, definitions, and symbols
3.15
1 object
region of data storage in the execution environment, the contents of which can represent values

还有搞清楚， C++的 object 就是直接抄的 C 的 object ，跟面向对象所谓的对象类似只是顺便。