The "replace the tab with magic character" thing particularly baffling. I agree that it was probably a dumb idea in the beginning for make to force you to use a literal tab character, but using these kinds of hacks is a terrible idea. It will just make it harder to read makefiles for normal people and it will make them less portable. Every sensible programming editor knows that make is particular about spaces and tabs and will make sure that it uses tabs to indent the recipes, so it's not an issue any more. If anything, using some other character will make it more confusing, because I'm guessing most editors will indent/syntax highlight it incorrectly.
It's not dissimilar from early C programmers who wanted C to be more like Pascal and put things like this in headers:
#define BEGIN {
#define END }
and then never used curly braces. NO! DON'T DO IT!
I really don't understand his justification for such a significant modification:
> Make leans heavily on the shell, and in the shell spaces matter. Hence, the default behavior in Make of using tabs forces you to mix tabs and spaces, and that leads to readability issues.
I agree with you in that replacing TAB with > makes things much less readable.
1) The original creator of Make plainly said that his original choice of tabs over spaces was accidental, and honestly a mistake. He just learned about (at the time) new tools lex and yacc for writing parsers and chose TAB as a line prefix for shell commands. Not much thought given really.
2) Tab in the very beginning of the line determines that the rest of the line is a command. However, the rest of that line goes into shell pretty much verbatim (modulo a few substitutions). Because of that, you may have tabs in the middle of that line, no problem, and they will be passed into the shell to execute!
3) To my knowledge, shells treat '\t' and ' ' the same way as whitespace. If anyone knows such differences, please let me know tho, I will correct myself. On the other hand, ">" is an important shell operator.
The shell performs field splitting according to the characters in the IFS environment variable; if unset it splits on <space>, <tab>, and <newline>.
There are many other places in Unix where tabs are special. The "<<-" heredoc operator will strip leading <tab> characters, so if you want to nest embedded content neatly in your script you have to use tabs. Similarly, programs like cut(1) default to using <tab> as the delimiter.
The fact of the matter is that until very recently the vast majority of programs and programmers on Unix used tab indentation, and to a lesser extent tabs for intra-line alignment. So while the requirement of leading tabs in Make may have been a mistake, it was a benign mistake that would have gone mostly unnoticed. And the alternative surely would been a more permissive syntax allowing both <tab> and <space>.
It's not dissimilar from early C programmers who wanted C to be more like Pascal and put things like this in headers:
and then never used curly braces. NO! DON'T DO IT!