C/C++ 牵扯面广，改起来更麻烦。
很多语言其实都有一个事实上的实现标准，然后别人都得兼容它，如此这般，标准方的话语权地位就十分的高。比如 Python 有一个 CPython 作为事实标准，作者想改那就改了，然后在文档里边体现一句，其它的 python 实现基本都得考虑与它兼容。比如 Java 无论怎么改，都还是要以 sun 的那个为兼容性基础，不与它兼容的都是异端。那么只要它改了就大家都跟着改就行。C#也是，基本只有微软的那一份实现，那么，微软想怎么改怎么改，就算有其它的开源实现什么的，肯定只能是跟它兼容。
C/C++就不一样，有非常多的厂商，独立做出了非常多的不同的实现， 究竟听谁的呢？谁也不服谁，那么结果就只能是，这些厂商的技术代表，以及C/C++作者等人，联合起来谈判，哪些特性要加，哪些特性不加。而这样不可避免的就要吵架，错过了项目的最佳修改时间。
当C/C++在代码界的地位和体量逐渐变大，以其为基础的项目逐渐变多时，已然成为庞然大物。作为目前运用最广的底层语言，牵一发而动全身。
从编写程序员的角度来看，这确实是一个问题。其他程序员代码只写一份实现，而C/C++的程序员不仅需要实现函数功能，还要进行相应声明，确实非常繁琐。
但是，如果项目换一个人接手，或者是向他人提供接口，那么C/C++的头文件就存在优势，它就好比一本目录，一个书签，不需要查阅动辄上万的代码看懂前作者写了什么变量，实现了什么函数，而是一种拿来主义，只需要阅读的相应的头文件就能快速地了解这个文件的内容。对于编写程序员而言，写两次相同的函数和变量名，更能加深他对项目的印象。
可是目录这种东西，由编译器自动推导出或许更合适，也有人认为，它是C/C++的一个特色，不应该删去。头文件这种事，究竟算是一个bug还是一个优势，目前已经各有各的说法，莫衷一是。
在可以遇见的未来里，头文件的删除问题是不会做出较大的让步的，不仅仅是作者和标准方，而且是全世界的以C/C++为基础的，已经建立或完成的项目。