编程与软件工程bost.ocks.org
为什么用 Make：Mike Bostock 的构建工具入门
Why Use Make
2013 — 2014，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Mike Bostock（D3.js 作者）的经典短文，主张即使不构建大型软件，也应该用 Make 来自动化围绕少量文件的日常数据处理流程。文章展示了 Make 如何把零散的命令行步骤变成可重复、可维护的工作流。
为什么经久不衰：它把 Make 从“老旧构建工具”重新定义为轻量级流程自动化利器，多年来反复引发“用 Make 还是自己写脚本”的讨论，至今仍是理解构建系统取舍的好入口。
HN 评论精选
反对在新项目中使用 Make，认为它已被更好的现代构建工具取代
绝对不要在新项目里用 make。如果你爱 make，那说明你对工具的要求太低、没有跟上生态的变化。有太多更好的替代品，其中大多数还免费提供自动依赖管理。我知道文章的本意是“用构建系统”，这点我完全同意——把一切脚本化，再重构你的脚本。但别给新手留下“make 是今天可接受的默认选择”的印象。
mseebach查看英文原文
Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem. There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free. Yes, I know that the essence of the post is "use a build system". I agree completely. In fact, script everything. Then script your scripts. Then refactor your scripts because they are getting messy. But don't give impressionable souls the idea that "make" is anywhere near an acceptable (generalised, default) choice today.
指出文章场景是小型文件工作流，Make 在此场景下最合适
大家似乎都忽略了一点：他说的不是构建大型软件项目，而是围绕几个文件编写简单的工作流脚本。在这种情况下 Make 可能比任何工具都好，因为足够简单，很难出错。当你需要真正“编程”构建过程时，Rake 之类的显然更合适。
jcromartie查看英文原文
Everybody seems to be missing the fact that he's not talking about building a big software project. He's talking about scripting a simple workflow around a few files. Make is probably better than anything else for this, because under these circumstances it's so simple it's hard to get it wrong. Something like Rake is obviously better when you need to really program your builds.
列举 Make 在依赖管理、速度和语言设计上的具体缺陷
如果项目有自动生成的代码，或构建目标依赖生成后才可知的输入，Make 根本处理不了，只有难看的变通方案。Make 很慢（比如和 tup 相比）、很容易写错依赖导致隐蔽 bug、脚本语言很糟糕、还缺少其他构建系统（如 tup、shake）的分析报告等功能。它是个过时的劣质工具，应尽可能被已有的更好工具取代。
Peaker查看英文原文
If your project sports auto-generated code, or any sort of build targets that depend on inputs only known after generation -- Make simply cannot handle this. There are ugly workarounds but they don't work well. Make is: * Slow (e.g: when compared with tup[1]) * Very easy to get it wrong (under-specify dependencies), with cryptic bugs (or over-building) as a result. Pretty difficult to get it right (e.g: doing proper #include scanning, especially with the above-mentioned generated code). * Terrible scripting language (mentioned by many others) * Lacks useful features of other build systems (e.g: tup, or shake) of useful profile reports and queries about the build process. It is just an antiquated, poor tool that ought to be replaced by betters that already exist, whenever possible. [1]: http://gittup.org/tup/
反驳“自己写脚本”派：自造工具会重蹈 Make 已解决几十年的覆辙
读读这里的评论你会发现：很多人对 Make 的某方面不满，就说“我可以用 [某语言] 自己写得更好”，然后用自己惯用的方式实现了 Make 的 30%。写自己的工具感觉更容易，但那实际上意味着你要重新学习 Make 维护者们近 40 年来学到的一切——或者干脆不学，重复几十年前就已解决的错误。
rout39574查看英文原文
If you read down the comment threads here, you'll notice something. Many many folks get frustrated with some aspect of Make, and then turn around and say "I can do better myself in [language]". And then they go off and do 30% of Make in their favorite idiom. Sorry, but as an old fart, these all read as "Wah, make is haaard, and inconvenient". This isn't to say that I think Make hung the moon in radiant perfection, but I haven't seen any tool that has a clearly superior set of compromises and tradeoffs. Gorgeous example: automatic dependency generation. Does anyone really think the identical dep generation codebase will work on 20 year old C and node? It's not hard to glom whatever dependency mapping you want into your make workflow and drop it into separate included makefiles. It feels easier to write your own. But what that really leads to is re-learning all the shit the make maintainers have learned in the last (look it up.. DAMN.) nearly 40 years. Or maybe _not_ learning it, and duplicating mistakes which have been solved for decades.
历次讨论
同类还值得读
开源应用架构
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编辑精选