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

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

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

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

    redo-ifchange grape.y

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.

Some of these requirements should be built into any build tool. However, most can be added easily enough:

For instance, redux [https://github.com/gyepisam/redux] is written in Go (not compiled for binary distribution, but I could add that), is cross platform, supports any mix of languages and tasks, is very easy to learn.

It uses shell scripts to create targets so everything is scriptable. Stuff like recognizing standard folder hierarchies and auto-discovery can be added with small scripts or tools. It can be as simple as you want or as complex as you need.

1. Since make has builtin suffix rules, the Makefile could be simplified to:

    CXX=g++

    hello: main.o factorial.o hello.o

    clean:
        rm -rf *o hello

    cat <<EOF > @all.do
    redo hello
    EOF

    cat <<EOF > hello.do
    o='main.o factorial.o hello.o'
    redo-ifchange $o
    g++ $o -o $3
    EOF

    cat <<EOF > default.o.do
    redo-ifchange $2.cpp
    g++ -c $1 -o $3
    EOF

    cat <<EOF > @clean.do
    rm -rf *o hello
    EOF

These are just shell scripts and can be extended as much as necesary. For instance, one can create a dependency on the compiler flags with these changes:

    cat <<EOF | install -m 0755 /dev/stdin cc
    #!/bin/sh
    g++ -c "\$@"
    EOF

    # sed -i 's/^\(redo-ifchange.\+\)/\1 cc/' *.do
    # sed -i 's}g++ -c}./cc}' *.do

[1] https://github.com/gyepisam/redux

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.

As of today, there is no build system which is 1) simple and easily comprehensible, 2) reliable and rock stable and 3) still able to build complex applications with all their (seemingly) quirky needs.

See https://github.com/gyepisam/redux

It's an implementation of DJB's redo concept.

I wrote it because I needed a build tool with exactly the features you describe and none of the alternatives had them.

I encourage you to try it out and provide feedback if necessary.

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.

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.

I read The Inner Game of Tennis based on Alan Kay's description in a youtube video. It is an excellent book.

I am glad to see Csikszenmihalyi on the list as well. Flow is a very powerful concept; we all know it, but understanding it and using it effectively is a different matter entirely.

After reading The Miracle of Mindfulness by Thich Nhat Hanh, I realized that all three books are actually talking about the same subject from different perspectives.

To this list, I would add:

anything by Robert Grudin, but especially:

Time and the Art of Living and The Grace of Great Things

How to solve it by G. Polya

Conceptual Blockbusting by James Adams

Nice to see the Mortimer Adler recommendation as well, but I think his How to Read a Book should be a prerequisite for serious reading.

As I've gotten older, I've come to the conclusion that true understanding requires the kind of depth that comes from knowing one's self intimately. It's a lot harder than it sounds, especially for a technologist.

Yes, you're right. However, in redo, you don't have a Makefile equivalent and, instead, specify the dependencies in the shell script that generates your target. Basically, the configuration language is shell (or any other program that can be invoked from a shell script).

The advantage of make, or any other decent build tool, is the dependency management; what depends on what, what's changed, what needs to be (re)built, what order to do all this. In the absence of all that, everything gets rebuilt all the time. Not a big deal for small projects but an absolute killer as projects get larger.

Page caching: it's been around for a while. At least on unix systems. I imagine Windows, etc have it too.

I completely agree with the sentiment of the article. Makefiles are a form of documentation. However, I no longer use make in new projects and instead use redux [1]: my implementation of djb redo. It manages the dependencies and you write your scripts in shell. Simple, straightforward and easy. No more 'make -B', no more make contortions.

[1] https://github.com/gyepisam/redux

FWIW, I implemented redo in Go and released it a couple of months back.

https://github.com/gyepisam/redux

I once spent a summer writing software in a room full of telephone order takers. My requests for a quieter office were rebuffed and only granted when I offered to quit.

I took the office, finished the software, and quit.

They are cool. A bunch of them were stationed at an Air National Guard base near my house and they would frequently fly overhead. Eventually they moved elsewhere; which is just as well. They are noisy too.

A lot of this depends on the organization, its perceived needs and the personalities involved. No doubt some of the answers you get here will be helpful, but I would focus on the particulars. The first question is whether the organization actually needs a new language or whether you just want to use a new language.

Depending on the environment, the change will bring its own set of difficulties and those will need to be addressed. Sometimes, it's a matter of the people involved. For instance, you are the only one passionate about a new language and others are not or is willing to learn and others are not, etc, then you suddenly have a new problem that may not have existed before, including having to support your colleagues through the transition.

As for arguments, etc, those should arise from your situation. If the current system is not working, make that clear. You may have to repeat yourself to get the point across. But do your homework first. Know what's broken and how your suggestion will fix it. Know the advantages of the current system and the distadvantages of the new one. "Trying something new" does not seem like a good reason; surely there's a reason why you use language X?

I think you are referring to Hotel Rwanda. No, I didn't. I am hopeful that this is a joke and not an attempt to disprove my point or a demonstration of your range of knowledge on the subject.

As a one time wealthy, educated black person, I take offence at this characterization.

I live in mostly white neighborhoods because that's where I and my family wanted to live.

It was not to show that we had "made" it or to give the neighbors the opportunity to demonstrate their lack of racism. I think, far too often, people focus on race and don't realize that class distinctions are frequently better indicators.

On that basis, it seems quite reasonable to choose to live amongst people who are similar to me and not amongst those who aren't.

As it turns out, I'm now in South Africa and it's easier to see my point. Most of my neighbors are black or "colored" but I live near them because it's a nice neighborhood and not becuase of their race.

I think it's important to remember a fact of humanity: you're generally safer on familiar ground, around people who are similar to yourself. It can be very interesting, exciting, and rewarding to be "the foreigner", but at the same time you should never forget when you're in that position.

This is generally true. However, the United States is a multi ethnic country. So the question is, does this statement apply to all ethnicities, everywhere? The fact is, for a large number of Americans, they are "the foreigner" exactly in that position most of the time.

I am afraid you don't know what you're talking about. Genocide is not common in Africa. It's happened, but it's not common.

I hate to be that guy, but this software (with a patent, natch) is definitely not the first or best solution to the potential problem of the /dev/log buffer filling up.

If the standard syslogd is inadequate, how about using a different logger? Gerritt Pape's svlogd, an implementation of DJB's daemontools loggers, solves this problem very nicely, is very reliable, can log over UDP and write to disk if desired. Heck, it can even replace syslog and run more reliably.

Not to say that this software is not useful. It is a great solution if the client software insists on using syslog and cannot be modified or reconfigured and syslogd cannot be modified or replaced. However, these are quite specific and generally unusual cases. For more prosaic circumstances, there are simpler and better solutions.

I have noticed that there are generally three kinds of software releases.

1. No code, just vaporware.

2. Some code, no to few tests, very little documentation.

3. Well written code, lots of tests, lots of documentation.

The first is annoying. The second sometimes contains interesting snippets if you're willing to dig. I read the code but am unlikely to use it. The last kind, when I find it, is gold. I use it, read the code, and refer back to it.

I have a theory that these kinds of code correspond to intent. Some people want to get something out (sometimes just words) and others want to provide something useful.

My zen koan is: if it were not for the chaff, you might not have wheat.