The response to this piece has been remarkably broad and positive. I have to note, though, that I didn’t write it as a nostalgia trip – I don’t miss underpowered computers, primitive tools, and tiny low-resolution displays.
At least people did notice that it isn’t a you-kids-get-off-my-lawn grumble. I think it’s good for younger hackers to know these things, but it’s no fault of theirs that the technological context has changed so much that they don’t absolutely need to to get work done. In fact it’s a sign of progress.
Yes, you’ll occasionally trip over old tech for which forgotten common knowledge is important – and RS-232, in particular, is still important in niche applications. But the real reason to remember these things is less tangible, and unfortunately difficult for many people to talk about without sliding into sentimentality.
In any kind of craft or profession, I think knowing the way things used to be done, and the issues those who came before you struggled with, is quite properly a source of pride and wisdom. It gives you a useful kind of perspective on today’s challenges.
The real reason I wrote this is to encourage that kind of perspective.
Updated version here. With: more about the persistence of octal, current-loop ASR-33s, 36-bit machines and their lingering influence, ASCII shift, a bit more about ASCII-1963, and some error corrections.
As promised in the comments on my last post, here it is:
Things Every Hacker Once Knew
Comments and corrections welcome.
If I were the kind of person who grumbles about feeling ancient, I’d have been doing it today.
I got reminded that younger hackers don’t know the bit structure of ASCII like their tongues know the back of their teeth. Man, we all grokked that back when I was new at this.
Nowadays not so much. I’ve actually seen younger hackers be confused about, say, how to generate a NUL from the keyboard. And I’m all, like, “How can you not know this?”
I’m bothering to post because I think I’ve figured out why this changed. The kids are OK, it’s conditions around them that have shifted.
In my last blog post I expressed my severe disappointment with the gap between the Rust language in theory (as I had read about it) and the Rust language in practice, as I encountered it when I actually tried to write something in it.
Part of what I hoped for was a constructive response from the Rust community. I think I got that. Amidst the expected volume of flamage from rather clueless Rust fanboys, several people (I’m going to particularly call out Brian Campbell, Eric Kidd, and Scott Lamb) had useful and thoughtful things to say.
I understand now that I tested the language too soon. My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. But I’m somewhat more optimistic about Rust’s odds of maturing into a fully production-quality tool than I was.
Still, I think I see a problem in the assumptions behind Rust’s development model. The Rust community, as I now understand it, seems to me to be organized on a premise that is false, or at least incomplete. I fear I am partly responsible for that false premise, so I feel a responsibility to address it square on and attempt to correct it.
I wanted to like Rust. I really did. I’ve been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec.
I finally cleared my queue enough that I could spend a week learning Rust. I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.
Every once in a while I post something just to have it handy as a reference for the next time I have to deal with a galloping case of some particular kind of sloppy thinking. That way I don’t have to generate an individual explanation, but can simply point at my general standards of evidence.
This one is about accusations of sexism, racism, and other kinds of prejudice in the open-source culture.