文字优先，小件先行

我从来没有想过你可以以这种方式挂科。当我们说一个东西难用的时候，我们通常指这个东西的学习曲线很高；但还有一种情况，就是这东西是个两头都是拔钉器的锤子。如果我们希望达到高效开发，那么必然是要搞文件，让小工具来做一件事并把它做好。

我一直不用 Keil 而坚持使用 CLion 的原因之一就是 CLion 的工程配置，尤其是和生产相关的配置，是使用脚本控制的。比如 gcc, cmake, openocd, stm32flash 它们都是可以通过脚本进行完全配置的。链接行为、生成行为、烧录行为全部都可以由用户通过文件控制。但是 Keil 就不一样了，它需要通过你在 GUI 里戳来戳去才能调整各种东西；如果你恰好不知道某个选项在 GUI 里是什么位置的话，慢慢找吧，请！

所以这一次吃瘪了。换句话说，我 51 写得也不多，Keil 更是少用，所以我恰好不知道新建工程之后，你需要手动调整编译输出让他输出 .hex 文件。如果不是因为在烧录中可以看到程序的 hexdump 并且我恰好看到了一堆关于 Keil 的字符串，我估计会卡得更久——我一直在烧录一个没有 strip 的二进制文件，所以很自然的，程序不能正确运行。

如果说 51 烧录程序是一个爱好者写的软件，那么当二进制格式错误的时候不给提示情有可原，毕竟只是一个 Proof-of-concept, 所以有很多细节上的内容无法涵盖也是可以理解的，但是这个烧录程序是商业软件。要知道 openocd 这个社区驱动的开源烧录程序可是能识别二进制类型的，而且在尝试烧录错误类型的时候会转换和提示！

我就不再 diss Keil 了。它有它的适用场景，我有我的开发需求。

事实上 IDE 对程序的配置要求使用 GUI 只能增大它的学习成本而不是降低。（所以我也不怎么用 Visual Studio, 因为它作为将配置堆在 GUI 的开山鼻祖，学习成本远大于 *nix 下的工具之总和。不过至少 Visual Studio 开发很活跃，GUI 搜索和强劲的代码提示做得很好；但是 Keil 就完全是另一回事了。）而且会强迫它的用户去学习它的 GUI, 导致工程的透明性降低。

当然也可以说，Keil 的工程文件 (.uvproj) 里也是文字，还是 XML, 人类可读性很好。但注意到，Keil 的工程文件决定了工具链的行为，这导致了要配置单个工具的行为，必须更改整个工程属性。基于小文件配置的工具链则可以保证对于同样的文件生成同样的输出，也可以非常轻松地创建工程模板，也可以对工具链中任意环节进行调试而不影响其他环节。

事实上我对于 IDE 的态度无外乎一个带高亮、补全和调试前端的超强编辑器。如果这个编辑器还能顺带调用一下工具链自然是最好的。某种程度上而言，VS Code 就是这样一个编辑器——它有 IntelliSense, 支持调用各种外部工具，同时还有若干调试器的前端；VS Code 的流行证明了工具链配合编辑器的组态并不是一个小众的配置，而是主流。

总之，现在再写什么也只能算 ranting. 重修预定，Good Game, Good Luck.