And here is the mandatory AvE Hole Hawg tear-down: https://www.youtube.com/watch?v=qoR59rzqlxw

Though he sang the praises of the Hole Hawg, it's worth noting that he later switched to OS X. Usability still matters.

"You guessed right: I embraced OS X as soon as it was available and have never looked back. So a lot of "In the beginning was the command line" is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."

From question #8 of an interview with him in 2004 at https://slashdot.org/story/04/10/20/1518217/neal-stephenson-... His responses to the other questions are entertaining and worth a read as well.

That can describe Unix command-line tools. No "are you sure y/n?" except if explicitly asked for via a flag, unlike DOS.

This is true, but the concept was taken further in the Oberon operating system, which has a design goal of never asking the user questions at any point.

Interesting. Another thing I vaguely remember reading about Oberon was that any subroutine in the OS could be used from any program, or something like that, for high code reuse. I'm sketchy on the details. Read it quite a while ago, maybe in a BYTE article about Oberon. Not sure if that implies if all programs were in one address space, or what.

I think they are, but OTOH I think that's acceptably safe when it's a single-user, client-side-only OS written in a rigorously bounds-checked, type-safe language.

I suspect that the obsession with process isolation in xNix reflects its origins: as a terminal-based multi-user OS written in perhaps the least-safe high-level language ever developed, one in which it is necessary to deploy terrible techniques such as pointer arithmetic just to get anything done at all.

Mostly agree. Didn't know Oberon was a single user OS, though I did read that Wirth was also involved with creating the Lilith workstation (he missed the chance to call it a Wirthstation :), so it could make sense that Oberon was single-user too.

What's so wrong with C pointer arithmetic, per se? I know about the issues with pointers in general, having used C a lot, earlier. But the arithmetic?

There are multiple issues with pointer arithmetic and it is widely regarded as one of the weakest, most failure-prone points in the C language.

Some discussion: https://www.cs.swarthmore.edu/~richardw/classes/cs31/s18/off...

http://web.cse.ohio-state.edu/~reeves.92/CSE2421au12/SlidesD...

Thanks, will look at those.

hehe this has become my favorite saying lately for computers 'do what I want, not what I told you to do!' computers have a lovely way of merrily going along and breaking things at a fairly fast pace.

Lately I find myself saying “do what I told you to do, not what you think I want to do”

Mainly this is due to the autocorrect, autocomplete on most devices nowawadys. I’m sure it’s very helpful, but I seem to notice the mistakes more than the successes. (Eg, trying to type “nowadays,” I had to break out of typing on my iPhone 3 times to backspace and stop it from changing it to other words and expressions)

hehe that is awesome it is opposite of mine but also so true! I turned off autocorrect on my phone. Suggest is fine, but just changing it... not so much.

Many CLI tools have a dry run option for expensive (time/resource wise) or risky commands (one way, irreversible or reversible only with a lot of effort). It would be interesting to see this become the default for some of them, with a separate flag `--now-i-mean-it` to actually execute.

I wish more tools had the option of dry run. Been using it with ansible quite bit in the past few weeks. Look ma I can mess up 50 computers all at once!

Yes, like

make -n

https://man7.org/linux/man-pages/man1/make.1.html

In fact, the above man page shows that one long form of the -n option is named --dry-run :)

I’ve spent so much time with rsync’s -n (I think it supports —-dry-run as well).

Shouldn't dry run be the default and the "prod" run be requiring adding the switch