in some sense, the 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 would be no small task to independently discover (and even more direct ways to print âhello worldâ 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, 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â. it's software that gatekeeps itself:
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 ever could.
there's a semi-overlapping cluster of annoying fossbro nonsense over on cat-v.org. some of it is the same boomer nonsense about old software good new software bad, 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, âUNIX Style, or cat -v Considered Harmfulâ. that page also links to a paper 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.