I've been ruminating on craft – a.k.a.
craftsmanship. [If I
refer to someone as a
craftsman, please do not imagine I am saying or
assuming anything about their genitalia – or, indeed, about any other
characteristic of them that would be a distraction from the discourse.] It's
a topic I've discussed with my programmer friends and includes generic truths
that yield fruitful discussions with my elder brother (James, antique watch
wright) and my friend Kim, a civil engineer. Along with other
of chaos, I have an avowed intent to
articulate any useful thoughts I can muster on the topic.
I aim to explore the form in which craft appears for me, as a toolwright: I leave it to hackers to identify any commonality between this and hackerdom – and, indeed, to decide whether to call me a hacker. As for hackers, so for practitioners of any kindred craft.
Extant fragments (all, like this page, waiting until I know how to improve them):
helpactually got you something helpful.
Ccode which I have found useful. I describe them, though incompletely, and leave you to care whether they would serve you well. If you want the code of these or of the shepherd (below), drop me a line and I'll package it up for you when I have the time. But they really need re-written (in python, probably).
Your mileage may vary
Straightforward needn't be naïve – it provides facilities which it makes sense to use straightforwardly, allows that these may be used otherwise, but specifies how it will respond in such plain terms as to leave it as clear as even these cases could hope for – just like python, in fact. While keeping things simple is generaly a Good Thing, making something useful needs to allow for non-simple things.
I won't pretend to understand the heated debates about init systems on Unix variants, but Rich Felker's critique of systemd includes a delightful example of straightforward at the end, in his proposed C code for a Unix-style process 1. Even I can make sense of that, and I don't know anything about the low-level machinery of the kernel.
deliberative practice; there are no short-cuts.
Algorithms + Data Structures = Programs(1976) and his later short work (PDF)
Algorithms and Data Structures(1986).