编程与软件工程bell-labs.com编辑精选
C 语言的发展（2003）
The Development of the C Language (2003)
2015 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Dennis Ritchie 撰写的 C 语言发展史，回顾了从 Thompson 在资源极其有限的 PDP-7 上用汇编写出 Unix，到 B 语言再到 C 语言成型的全过程，并讨论了语言设计中的诸多取舍。文章由 C 之父亲笔所写，兼具史料价值与设计洞见。
为什么经久不衰：出自 C 语言创造者本人之手，是理解 Unix 与 C 起源的第一手史料，几十年后仍是语言设计讨论的经典参照。
HN 评论精选
摘录原文：Unix 诞生于极其简陋的 PDP-7 上，a.out 等细节展现了早期系统的极简与自举过程。
Thompson 面对的硬件环境即便在当时也极为寒酸：他 1968 年起步用的 DEC PDP-7 只有 8K 个 18 位字长的内存，没有任何可用的软件。虽然想用高级语言，他还是先用 PDP-7 汇编写出了最初的 Unix 系统。起初他甚至不在 PDP-7 上编程，而是在 GE-635 上用 GEMAP 汇编器的宏，后处理器生成 PDP-7 可读的纸带。这些纸带被拿到 PDP-7 上测试，直到原始的 Unix 内核、编辑器、汇编器、简单 shell 和一些工具（如 rm、cat、cp）完成。此后系统便可自举，开发得以在 PDP-7 上继续。他的汇编器比 DEC 的还简单：求值表达式并输出对应比特，没有库、没有加载器或链接器——整个源程序交给汇编器，输出一个固定名字的文件即可直接执行。这个名字 a.out 也解释了一点 Unix 词源：它是汇编器的输出，即使后来有了链接器并可以指定其他名字，它仍被保留为编译结果的默认名。
peter_d_sherman查看英文原文
Excerpt: "Thompson was faced with a hardware environment cramped and spartan even for the time: the DEC PDP-7 on which he started in 1968 was a machine with 8K 18-bit words of memory and no software useful to him. While wanting to use a higher-level language, he wrote the original Unix system in PDP-7 assembler. At the start, he did not even program on the PDP-7 itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine. A postprocessor generated a paper tape readable by the PDP-7. These tapes were carried from the GE machine to the PDP-7 for testing until a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few utilities (like the Unix rm, cat, cp commands) were completed. After this point, the operating system was self-supporting: programs could be written and tested without resort to paper tape, and development continued on the PDP-7 itself. Thompson's PDP-7 assembler outdid even DEC's in simplicity; it evaluated expressions and emitted the corresponding bits. There were no libraries, no loader or link editor: the entire source of a program was presented to the assembler, and the output file—with a fixed name—that emerged was directly executable. (This name, a.out, explains a bit of Unix etymology; it is the output of the assembler. Even after the system gained a linker and a means of specifying another name explicitly, it was retained as the default executable result of a compilation.)"
感叹 Thompson 发明 ++/-- 运算符的深远影响。
Thompson 更进一步发明了 ++ 和 -- 运算符，前缀或后缀位置决定自增自减发生在取值之前还是之后。这个人给编程界贡献了太多。
ruffrey查看英文原文
> Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. This man has given programming so much.
认为 C 语义上接近汇编，其设计取舍是合理且经竞争检验的。
值得注意的是，C 的特殊之处在于它语义上非常底层，几乎与汇编同级，因此留给自动优化的空间比大多数语言都小。所以就像汇编一样，语言设计（包括对数组的处理）谈不上什么'不幸'，C 长期流行正是良性竞争的结果。有些小地方我希望不同（比如 '->' 太吵，用 '.' 就够了；还有'分号癌症'），但整体上这门语言相当可用。
Koshkin查看英文原文
I think it is worth noting that C is special in the sense that compared to other programming languages it is semantically low-level, pretty much on par with assembly. Which is why it offers less opportunity for automatic optimization than most of other languages do. Therefore, just like with assembly, there is nothing too "unfortunate" about the language's design (including its "treatment of arrays"), and the fact that C has been, and still remains, highly popular is just the result of healthy competition, IMO. There are a few little things that I wish were different (for example, I see the arrow symbol '->' as noisy and unnecessary - the simple period '.' would work with pointers just as well; also, the "semicolon cancer"...), but the language seems to be pretty usable the way it is.
指出 C 的数组与指针设计给编译器优化和语言扩展带来的长期难题。
另一方面，C 对数组（不只是字符串）的处理对优化和未来扩展都有不利影响。指针的普遍存在意味着优化器必须谨慎，需要精细的数据流分析才能有好的结果。例如从数组派生的指针参数在向量机上很难编译出高效代码，因为几乎无法确定一个指针参数不与另一个参数或外部可访问的数据重叠。更根本的是，C 的定义把数组语义描述得太具体，想把数组当作更原始的对象、允许整体操作的改动或扩展都很难融入现有语言。
benlorenzetti查看英文原文
On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can possibly change, but some important usages remain difficult to analyze. For example, functions with pointer arguments derived from arrays are hard to compile into efficient code on vector machines, because it is seldom possible to determine that one argument pointer does not overlap data also referred to by another argument, or accessible externally. More fundamentally, the definition of C so specifically describes the semantics of arrays that changes or extensions treating arrays as more primitive objects, and permitting operations on them as wholes, become hard to fit into the existing language. Ritchie notes the difficulty with optimization and aliasing and as far as I know the only portable C89/99 convention for this is using the appropriate function if what you want to do is memcpy() or memmove(). I love C and programming is mostly a hobby for me. But my language experience does not really extend beyond C and C++, other than reading about D, Lisp, Rust, etc. I also think the STL is the beautiful thing C++ gave us, and having it as a library is better than building these structures into the language. The STL relies heavily on iterators of course. My question to HN is: do any languages that really emphasize pointers and iterators over arrays and indices have a non-cumbersome way of telling the compiler when no aliasing is expected? As a hobbyist, I am more interested in something like slices from D or parameter type restrictions than trivially obvious global guarantees like ``if you mutably borrow it then there is no aliasing''. Do D programmers find the slices helpful and easy? Is the syntax and/or semantics such that the programmer can provide the compiler with aliasing info? Are there a small number of type concepts for this or does it explode with the number of different data structures. I know there is the restrict keyword, but I have always been too lazy to use it in C and even in C++ it seems (quadratically?) unlikely you would be energetic enough to properly declare which pairs of entities could not alias.
读史纠正误解：C 并非源于强类型，可移植性也不是最初目标。
我喜欢这类故事，一门年轻而丰富的科学背后的历史。比如我一直以为 C 出自强类型传统、其初衷就是可移植性——其实两者都不是。
cntlzw查看英文原文
I love stories like this. All the history behind a very young but rich science. For example I always assumed C came from a strong typing background and its premises was always about being portable. Neither of them are true.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选