5.4 编程语言的“爱恨情仇”
把 C、VB、C++、Java 与 Ruby 的语言取舍放回同一任务、版本、实现和维护约束中比较，避免用个人经历替代可验证证据。
学习目标
- 能用同一任务、语言版本、实现、输入和验收标准比较 C、VB、C++、Java 与 Ruby
- 能解释类型检查、内存管理、运行时、抽象机制和生态如何改变正确性、交付速度与运维成本
- 能在正常、边界和故障场景中定位把个人经历或单一基准外推成语言本质的首个比较偏差
5.4 编程语言的“爱恨情仇”
本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 5.4 编程语言的“爱恨情仇”。正文、图示、实验和练习是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。
语言没有脱离任务的永久排名。C 让内存和布局更接近机器，VB 与 Visual FoxPro 曾以快速业务开发降低入门门槛，C++ 在控制力与抽象之间取舍，Java 以虚拟机与生态换取可移植性，Ruby 以表达力和约定改善开发体验。比较前必须固定任务、版本、实现、输入、资源预算和维护窗口。
三个会让语言比较失真的陷阱
六个目录节点到比较证据
5.4 编程语言的“爱恨情仇”
总合同是：先固定任务，再声明语言版本与实现，使用等价输入实现同一行为，分别测量正确性与资源，最后记录维护和运维约束。任何“更好”的结论都必须说明适用任务和代价。
让人怀疑的C 语言
让人怀疑的C 语言 不是给 C 贴上好坏标签，而是观察显式内存与数据布局怎样影响控制力、错误风险和调试证据。一个需要稳定 ABI 或极限资源控制的任务，可能需要这种可见性；同样的可见性也会增加边界检查责任。
↡以 C 语言的显式内存、布局和编译模型为比较样本，既观察控制力，也观察越界、生命周期与工具链责任。被忘却的 VB & Visual FoxPro
被忘却的 VB & Visual FoxPro 代表面向业务快速交付的历史工具。它们的价值要放在当时的团队、数据库、部署环境和交付期限中判断；工具生态变化后，维护和迁移风险也必须成为证据。
↡以 VB 与 Visual FoxPro 的历史业务开发体验为比较样本，关注快速交付、数据工具、生态寿命和迁移成本的组合。蹂躏我的C
蹂躏我的C 对应把语言限制与项目压力放在一起观察：手工内存管理、编译错误、调试工具和团队规范会共同决定痛苦来自哪里。若只把一次项目事故归因于语法，就无法找到可修复的工程边界。
↡把 C 语言在真实项目中的内存、编译、调试与团队规范压力作为比较样本，而不是把一次事故简化成语言本质。赖以谋生的Java
赖以谋生的Java 体现虚拟机、垃圾回收、类型系统和成熟生态对交付的帮助，同时带来运行时调优、启动成本和依赖管理等新约束。比较 Java 时要固定 JDK、垃圾回收器、库版本和部署资源。
↡以 Java 虚拟机、类型系统、自动内存管理和生态为比较样本，衡量可移植交付与运行时、依赖和资源成本。优雅的Ruby
优雅的Ruby 体现动态语言、元编程和约定对表达力与迭代速度的帮助，也要求运行时、依赖、性能和团队诊断能力匹配任务。优雅是可读性和约定的结果，不是无需测量的赞美词。
↡以 Ruby 的动态特性、表达力和约定为比较样本，观察快速迭代与运行时、依赖和团队诊断成本之间的取舍。Lab
编程语言公平比较实验
只改变输入、预算或版本上下文，观察比较结论怎样收窄或失效。
五种语言对同一输入实现同一输出，结果均通过
fixed task → versions → equivalent output → measure → maintain
判定
accept：结论带上下文，可比较成本维度
当前样本：同例比较；保存任务、版本、实现、输入、测量和维护记录。
五步重放一次语言比较
1. 固定任务与验收合同
写出输入、输出、错误处理、延迟预算和资源上限。正常样本做一项小型数据处理，边界样本增加输入规模，故障样本故意违反资源预算。
正常、边界与故障证据矩阵
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 同一任务与等价输入 | 结果正确，成本维度可横向解释 | 版本、代码、测试、测量 |
| 边界 | 输入规模或资源预算 | 明确哪项成本先越界，并说明适用范围 | 输入、预算、重复测量 |
| 故障 | 版本、库或运行时不匹配 | 拒绝跨上下文结论，保留首个偏离 | 环境、错误、复位轨迹 |
故障诊断：先找比较基线
- 任务与正确性：查输入、输出、错误语义和验收测试；结果不等价时，性能数字没有比较意义。
- 版本与实现：查编译器、解释器、运行时、库、平台和优化开关；同名语言在不同版本的能力与成本可能不同。
- 资源与测量：查启动、运行、内存、并发、缓存预热和重复次数；把编译时间、运行时间和交付时间分开。
- 维护与生态：查调试工具、升级、部署、团队熟悉度和库寿命；短代码不能替代长期运维证据。
如果一个基准让 C 看起来更快，先核对是否比较了相同优化和输入；如果 Java 或 Ruby 启动较慢，分离启动和稳态运行；如果历史工具迁移困难，记录生态与人员成本而不是只批评语法。每次只改变一个比较约束。
术语与边界
本页五个术语都绑定到实验中的语言卡片、版本字段和测量表：
- 让人怀疑的C 语言：显式控制力与内存责任的比较样本。
- 被忘却的 VB & Visual FoxPro：历史业务快速交付与迁移成本的样本。
- 蹂躏我的C：项目压力下的内存、编译和调试边界。
- 赖以谋生的Java：虚拟机、自动内存和生态换取可移植交付的样本。
- 优雅的Ruby：动态表达力与运行时、依赖成本的样本。
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 让人怀疑的C 语言
以显式内存、布局和编译模型观察控制力与错误责任。
- 被忘却的 VB & Visual FoxPro
以历史业务工具观察快速交付、生态寿命和迁移成本。
- 蹂躏我的C
以真实项目压力观察 C 的内存、编译、调试和团队规范边界。
- 赖以谋生的Java
以 JVM、类型、自动内存和生态观察可移植交付与运行时成本。
- 优雅的Ruby
以动态特性和约定观察迭代速度与运行时、依赖和诊断成本。
练习
练习
问题 1： 为什么不能用“代码行数更少”直接证明一种语言更适合生产？
问题 2： 同一算法在 C 与 Java 的运行时间不同，比较前应补齐哪些上下文？
问题 3： 修改实验，让一门语言在小输入更快、另一门在维护评分更高；应如何写结论？
本页小结
- C、VB、C++、Java 与 Ruby 的取舍必须绑定任务、版本、实现、输入和团队约束。
- 先验收等价行为，再测量运行和交付，最后纳入维护、生态与运维成本。
- 语言结论应带适用范围；单次经历、单个基准或代码行数都不足以证明永恒优劣。
读完后的自测问题是：面对“某语言太慢”或“某语言最优雅”的断言，你能否补齐比较基线，找到首个缺失证据，并重放一个可审查结论？