如果不使用 printf，你会如何打印 Hello World？

Source: Dev.to

The Problem

如果没有 printf，你该如何在屏幕上打印 “hello world”？
你会直接写入 stdout。在此之前，是一次系统调用。再之前，是向内存映射的显示缓冲区写入字节。再之前，是在前面板上翻动开关并观察灯光闪烁。

每向下一层，都是有人已经构建好某些东西，让下一个人不必再重复。这其实就是整个领域——我们没有设计的语言、我们没有编写的编译器、我们没有发明的协议。我们一直站在别人的工作堆上，然后把输出称为自己的。没有人因此有过问题。

printf 并非一直存在。有人写了它，而我们在使用时并未加以说明、愧疚或解释——我们本可以用更艰难的方式实现。同样的情况也适用于框架、包管理器以及随后出现的一切。

Progression of Abstractions

front panel switches → machine code → assembly → C → printf
    ↓
    syscalls → write() → stdio → high‑level languages → frameworks

在每一步，都有人说：“你不需要再做这一步了”。而在每一步，又有人问：“那你到底如何真正理解正在发生的事情？”

每个之前的层次仍然要求你用该层次的问题语言来思考：

• C 让你思考内存。
• 并发 让你思考状态。
• HTTP 让你思考失败模式。

抽象压缩了工作量，但它们并没有跳过理解。即使你不必自己构建实现的东西，你仍然必须知道自己在请求什么。

Implications

更新的层次之所以不同，并不是因为它们更高，而是因为你第一次可以在没有经历产生它的思考过程的情况下得到输出。你可以——但这并不意味着你应该。很多人仍然会先思考。跳过低层推理的选项是新的，而这部分确实是全新的。

所以也许问题不在于工具是否算数——它可能一直都算数。
一个更好的问题可能是：当输出看起来正确但实际上不对时，你会知道吗？你能找到问题吗？你能修复它吗？

这并不是陷阱；它只是那部分没有改变的事实。