farid.m...@gmail.com writes:
> It's been several years since @djb's post; curious for opinions /
> guesses on why it hasn't seen more adoption ?
I have personally witnessed all of the following assertions:
• “It is impossible to be better than a standard tool.”
• “This is a niche tool and a huge maintenance issue.”
• “None of the issues redo solves are real issues.”
• “If this was so good, people would be using it.”
I am pretty sure that to an uneducated developer, any claim where a
trick that makes a problem vastly simpler to solve than the generally
accepted “common sense” way suggests is taken not as some kind of useful
insight, but as some shibboleth for quackery, the speaker being a crank.
Nearly every developer I have seen dismiss redo or similar build systems
immediately without trying thinks of themselves as truly competent. IIRC
none of them has ever implemented a build system, yet they have opinions
about what is generally usable, possible, okay to use – and what is not.
It probably does not help that some of the most visible enthusiasm for
redo comes from ppl who love to cheer on anyone who either invents the
wheel several times over or claims to do so in their elevator pitches.
If you look at history, ou can witness such an effect with other simple
insights that take ages to become accepted widely. For example, postel's
principle (be liberal in what you accept) is undoubtedly wrong, but only
the advent of LANGSEC gave coherent enough formal arguments why that is
the case. Some developers probably still believe in that kind of thing.
Meanwhile, actually competent developers have very concrete reasons for
not using redo. The best one I heard came from Mitch Altman: Back in the
80ies, maybe incremental builds could have made sense for him; but he is
doing the kind of embedded stuff that builds in 2 seconds, so he can it
rebuild that every time just fine using a very small shell script.
Greetings,
Nils