gyepi

> The radial arm saw doesn't get enough love, probably because it has space planning requirements that table saws can bypass on account of their portability.

No, the radial arm saw does not get enough love because it is dangerous when used for anything but cross cuts and straight angled cuts, both of which are easily handled by a miter saw, which is safer and more versatile.

I used one for years and was happy when I finally gave it away. A sliding miter saw and a table saw are a safer combination, for sure.

Wholly agree with the dust collection. You can actually get far with a shop vac if you add a cyclone type pre-filter bin to it.

When I was in college, both SICP and Knuth's books were on the recommended reading lists. I didn't buy the former until years later, but did buy Knuth's books (individually and at a time when I could ill afford them) and read them through. They are hard and it was very slow going. There's still a lot I don't understand. But I learned a huge amount, continue to do so and would absolutely recommend them to anyone with enough interest in the field. Similarly, when I finally bought and read SICP, I wondered why I hadn't read it sooner. I still read both books, along with many other "hard" books and enjoy them. I don't think I would be the programmer I am today if I had not read those books.

I disagree with the author. I certainly understand that reading "hard" books takes a lot of effort that may not seem worthwhile, but would not say they are overrated. However, like anything else, they aren't for everyone. Just those who are ready for them.

It's actually quite simple. You write a short shell script to produce the output you need and redo handles the dependencies.

For example, the shell script named "banana.x.do" is expected to produce the content for the file named "banana.x".

When you say

    # redo banana.x

redo invokes banana.x.do with the command:

    sh -x banana.x.do banana.x banana XXX > ZZZ

so banana.x.do is invoked with three arguments and its output is redirected to a file.

   $1 denotes the target file
   $2 denotes the target file without its extension
   $3 is a temp file: XXX, in this case.

banana.x.do is expected to either produce output in $3 or write to stdout, but not both. If there are no failures redo will chose the correct one, rename the output to banana.x and update the dependency database.

If banana.x depends on grape.y, you add the line

    redo-ifchange grape.y

to the banana.x.do, creating a dependency. redo will rebuild grape.y (recursively) when necessary.

The only other commands I haven't mentioned are init and redo-ifcreate, which are obvious and rarely used, respectively.

That's it.

> redo might be simpler and more reliable, but shell isn't.

Not quite sure what you mean here. The scripts don't do anything complicated and redo catches errors that could occur.

As for readability, etc, I suppose it's relative. Simple makefiles do read very nicely. Unfortunately, they aren't always simple and hairy makefiles are just horrible to write, read and maintain. I've had no such problems with do scripts.

> CXX=g++ isn't necessary either; make already knows about $(CXX) and how to link C++ programs.

You're right, of course.

> Also, I think you wanted .o, not o.

I would, yes, but I copied the Makefile ;)

Should have been clearer; I meant that redo is simpler (and more reliable) than make.

For simple projects, redo scripts are a bit longer. However, as the projects grow, the redo scripts reach an asymptote whereas Makefiles don't. The only way to reduce the growth in make is to add functions and implicit rules which get ugly real fast.

I switched to djbdns 14 years ago and have never looked back. I've installed bind a few times for clients who really wanted to stick with it and it seems to have improved but I'm still happy using a set of small, task specific tools that don't require any maintenance once installed.

There's not much in the way of DJB's documentation other than a conceptual sketch so there's much room for interpretation.

There are many differences between the two implementations, some quite fundamental. redux uses sha1 checksums instead of timestamps. Timestamps cause all sorts of problems as we know from make. apenwarr redo has all sorts of extra utilities to ameliorate the problems. redux has the minimum functionality needed for the task (init, redo, redo-ifchange, redo-ifcreate) and I don't think it needs any others.

Redux passes most apenwarr tests. The few it does not pass are apenwarr specific. I've not tried the converse. Might be interesting.

I actually have a task list to add an apenwarr compatibility mode to redux so users can switch easily. At that point, it should pass all the apenwarr tests.

Of course, redux is quite a bit faster too.

> regarding complexity reduction and simplicity it seems to be not better than a plain Makefile.

Makefiles work great most of the time, but become difficult when you need to do things that don't fit well with the make model. I do a lot of multi level code generation, for instance, and make requires a lot of incantations to get right. Whereas redo works exactly the same way regardless of the complexity. I used make for many, many years and got very good at using it before I decided to implement something new.

> Also, I don't think it is a good idea to implement this in Go...

I choose Go because I would not have enjoyed it as much in C. I did not use Perl or Python because redo is used recursively. Perl and Python startup were too slow. I actually wrote a shell implementation that served me well for a while, but it was too slow.

Likely, there are those who won't use it because it's Go and that's fine. I've solved my problem and made the solution available to anyone else to whom it might be useful.

>But honestly, redo don't address any issue that "make clean; make" wouldn't solve.

Fixing make's reliability issue with "make clean; make" is like rebooting Windows when it hangs. Yeah, you can do that, but it doesn't actually solve the underlying problem. With redo, you don't need need to do that.

Nerdsniping reminds me of the Walt Whitman poem:

   There was a child went forth every day;
   And the first object he look’d upon, that object he became;
   And that object became part of him for the day, or a certain part of the day, or for many years, or stretching cycles of years.

It's especially bad if you'd really rather be doing something other than what you're currently doing.

ouch!

Don't forget Thoreau's quote that he could learn from everyone. I think the problem is thinking of people in terms of rankings. Some are better at some things than others but that should not translate into being better than others. It's a hard distinction to make because the the latter is shorter and more convenient to grasp.

Not knowing you, I can only suggest questions to ask your self.

What yardstick are you using to determine your level of suckage? Is it true? How do you know? If it is true, do you care? If you care, in what way do you care? Does it matter? If it matters, is it important? How so? Hopefully, the books you have read will help with the answers. You may not be able to answer all of these questions (and honestly, the answers don't matter too much), but they might serve to orient you.

I have read a fair number of the books on the list (and many more not on the list) and can truly say that I am a better human being for doing so, according to my criteria.