salvage two percent of my chostsHEADmain

1 files changed, 25 insertions, 0 deletions

diff --git a/_posts/2024-09-08-abdication-is-not-simplicity.md b/_posts/2024-09-08-abdication-is-not-simplicity.md
new file mode 100644
index 0000000..05d1979
--- /dev/null
+++ b/_posts/2024-09-08-abdication-is-not-simplicity.md
@@ -0,0 +1,25 @@
+---
+title: Abdication Is Not Simplicity, or cat -v Considered Harmless
+---
+
+in some sense, the [Brainfuck](https://en.wikipedia.org/wiki/Brainfuck) programming language is extremely simple. it only has eight instructions! an intermediate programmer could write an interpreter in an afternoon! that's so simple it borders on trivial! specifically, Brainfuck is simple to *implement*.
+
+*using* Brainfuck, on the other hand, is so self-evidently a bad idea that it's the entire point. even [the Wikipedia “hello world” snippet](https://en.wikipedia.org/wiki/Brainfuck#Hello_World!) would be no small task to independently discover (and even [more direct ways to print “hello world”](https://github.com/ZakiPedio/HelloWorld-in-Brainfuck/blob/main/HelloWorldBrainFuck.bf) are a bit of a mess). there is still a lot of complexity, it’s just been moved downstream, out of the implementer's hands and into the user's.
+
+it'd be absurd to claim that Brainfuck is simple, because the only real way to get any nontrivial work done in Brainfuck would be to find or create a programming language that compiles into Brainfuck, at which point Brainfuck adds nothing. there are things we reasonably expect programming languages to do, and a simple language might do them simply but Brainfuck simply doesn’t do them. i think it'd be unhelpful and misleading to call that “simplicity” when it's just not fulfilling the responsibilities that we generally expect programming languages to fulfill.
+
+fortunately, nobody actually says Brainfuck is simple. unfortunately, however, the idea that “simple” means “simple to implement, regardless of how complicated it is to use” is a long-lived meme among certain kinds of programmers. one cluster of such programmers is called [suckless](https://suckless.org/), and their backwards understanding of simplicity leads to fascinating decisions like “[the way you change the settings in this software is by editing `config.h` and recompiling it](https://dwm.suckless.org/customisation/)”. it's [software that gatekeeps itself](https://dwm.suckless.org/):
+
+> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
+
+this sucks more than [systemd or cmake or any of the software they’re butthurt about](https://suckless.org/sucks/) ever could.
+
+there's a semi-overlapping cluster of annoying fossbro nonsense over on [cat-v.org](https://cat-v.org/). some of it is [the same boomer nonsense about old software good new software bad](https://harmful.cat-v.org/software/), and some of it is more directly venerating Rob Pike and The UNIX Philosophy™. the website is named after [a talk Rob Pike gave in 1983](https://harmful.cat-v.org/cat-v/), “UNIX Style, or cat -v Considered Harmful”. that page also links to [a paper](https://harmful.cat-v.org/cat-v/unix_prog_design.pdf) by Rob Pike and Brian Kernighan, which is a really interesting case study in The UNIX Philosophy™.
+
+what is `cat`? if you ask someone who knows a bit about the command line on macOS or Linux, they’ll tell you it displays the contents of a file, but if you ask a proper UNIX dweeb they’ll tell you it *concatenates* files (hence the name) and it’s a happy accident that it’ll display the contents of a single file. as Pike and Kernighan put it,
+
+> The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program.
+
+and right away we have encountered a flaw in the UNIX Philosophy™ tenet that a program should do one thing well. `cat` does two things well: concatenating files and displaying them. a program that displays files well would very reasonably benefit from options to add line numbers or display non-printing characters (in BSD, `cat -s` and the titular `cat -v`), but Pike and Kernighan are right that a program that concatenates files well would need no such options.
+
+but if displaying a file is the main use of `cat`, then it is absurd to argue that displaying a file is not the one thing it should do well. Pike and Kernighan suggest adding line numbers with `awk` and displaying non-printing characters with a new program `vis`, to maintain the purity of `cat` for concatenating files, but that sucks. `cat` is responsible for displaying files, and as such if it can’t meet reasonable requests about displaying files, that’s not simplicity, that’s an abdication of that responsibility. `cat -v` is good, and 1983 Rob Pike was wrong, and The UNIX Philosophy™ is bogus.