Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/t

Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/tool. But here's my criticisms: > Instead, ask make to use > as the block character, by adding this at the top of your makefile: Changing this is like replacing java curly braces with square brackets because it's easier to type. A good developer should be able to cope with different stylistic choices to match the existing code without strain IMO Maybe if it was a greenfield project it's ok, but the article doesn't say either way. > The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that. I disagree with using ZSH as it adds another dependency and shell to learn to build your project. This introduces more ramp up in knowledge, but also something build systems will have to pull in. The vast majority of steps end up as simple unix commands and program calling with specific flags in practice. Python is a maybe if that's the only language you're working with. Otherwise anything but simple function calls is better served by an external file. Even a simple module function call becomes clunky on one line. This is an interesting idea worth exploring in general, though. > Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read. See point 1. This is like choosing to not use regex because the symbols are confusing. ~ The rest of the article has good stuff in it though, esp. the file structure and bash flags. The rest is just questionable opinion and has little impact to a good makefile. Can you give some arguments against what I typed above?