Seems to me this is proof that you can lose an idea by telling someone about it. I hear a lot here that you shouldn't worry about telling people your ideas because ideas are worthless. I've never agreed with that.
Here we have someone who had a really great idea, did part of the work, and then told people about it. Then he sat on it and didn't release. Someone else came along, loved the idea, and wrote it from scratch in a month.
Does the original author care? Probably not. He's probably happy to see it be used. But if it had been a money-making idea, he'd be a lot less happy.
Software development is a very fast-moving field, and if you sit on your ideas at all, someone will do them instead. That's worth remembering.
The original author is Daniel J. Bernstein, a mathematics professor at UIC, who wrote an entire Sendmail replacement and an entire BIND replacement and released them both to the public domain. Monetizing ideas is not what he does.
Does anyone actually know of a commercial build system that's had any success? I know commercial support is available for CMake and I expect some of the Java build systems, but they're still all under a free software license.
Even this description doesn't really do him justice; the man is surely approaching genius status. If he wanted to get rich, he'd hardly be writing cutting-edge cryptography papers. :-)
Isn't the core problem here "he sat on it and didn't release"? Money-making idea or not, if you don't release it doesn't matter whether you've told people about your idea or not.
I completely agree with your last statement, "if you sit on your ideas at all, someone will do them instead." - But, I think that's true even if you haven't told people about your idea. Someone else will have the same idea, sooner or later.
Yes, it is awesome; I remember reading about redo years ago and thinking "this IS going to be awesome when released". I was trying to think of things that make, with all its legacy, does better.
The only thing I could come up with so far is when one input has multiple outputs (e.g. yacc; not quite dead, unfortunately). In gmake at least, you can do:
%.h %.c: %.y
yacc ....
In redo, you'd have to have to have specific blah.h.do and blah.c.do for each blah.y file you have
The other thing is multiple ways to generate the same file; as far as I know, make can do that but then the result is ambiguous - it's actually better than redo doesn't try.
There are relatively painless workarounds for both situations.
For multiple outputs, you can just make sure that anybody who depends on %.c also depends on %.h. This is pretty easy in the case of yacc. Then the rule can just be one for creating the %.h and you'll still never be missing a build rule.
For the problem of multiple ways to generate the same file (eg. generating a .o from either a .c or a .cpp), you can solve that by simply putting the decision logic into the .do file. This is actually better than making it implicit, because you explicitly get to say exactly which priority order to use in case both .c and .cpp exist. Make would silently pick one or the other (after also wasting time evaluating a bunch of other irrelevant rules, like ones for .pas files), which is no fun when you're debugging.
Thanks (both for the reply and for redo! oh, and for bup and sshuttle!)
The multiple-output solution is not very painful, but is kind of error prone, which stands out as redo is otherwise extremely clean, simple and robust. Perhaps something like "yytab.h_and_yytab.c.do" in the filename could work?
Quoting myself:
> it's actually better than redo doesn't try.
This was a type. I mean tot say "actually better that redo doesn't try", which is what you were saying too.
