oliviac

head line? sure hope it does!

  • she/they

last.fm listening

DO NOT FOLD, SPINDLE, OR MUTILATE.

post-mature optimizer, texas yeehaw in Austin, former linux distro witch at

🏳️‍🌈🏳️‍⚧️

cat pics, shitposting, a bit of software eng



cactus
@cactus

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.


You must log in to comment.

in reply to @cactus's post:

Recognizing that people are using something you created in unexpected ways should be cause for, first, joy, and second, considering what new needs and goals this introduces. Not pushing back and saying “no you’re doing it wrong”.

What's "great" is that my career has involved watching the industry collectively kind of figure this out and try to solve the problem by giving simplicity another name if you mean simple for somebody I don't care about. So, you call in the User Experience(TM) person to give advice for ten minutes, then never speak to them again for the rest of the project, because you're behind schedule and "nobody" cares about button sizes or explanatory text...

hmm, i feel like you're conflating simplicity of a thing with simplicity of using a thing

as i understand it, simple means fewer parts. brainfuck is simple because it has like 12 parts. suckless is simple (compared to other software) because its cuts out the "configuration" part

however, this means using the thing takes more parts. brainfuck is best used with a compiler (a separate part), and suckless software cannot be interfaced with through a config file (few parts) but instead requires the user to know C (many, many parts)

separately,

my perception is that suckless-style simplicity genuinely does have benefit; using C as your "config language" means configuration has all the power of C, and using your source code as your "config file" means configuration can change whatever it wants. lots of software claims to be flexible but this is practically the only way to achieve complete flexibility

it comes at the cost of accessibility, as you've noted, and it would probably be a bad idea for suckless-style software to be the default. i just don't think it's all bad, and i don't think its claims to "simplicity" are entirely without merit

separately,

cat does two things well: concatenating files and displaying them

cat is great at concatenation and okay at display

it supports line numbers and non-printable characters, but what about syntax highlighting, embedded binary, embedded images (with a compatible terminal), or any other reasonable feature i haven't thought of?

these features are of use when displaying a file but not when concatenating. for this reason i actually think the impulse to decouple "concatenate" from "display" is fine, although, yes, in practice cat is very often all you need for display as well

if displaying a file is the main use of cat

i mean, it happens to be, but isn't that a historical mistake? we could have had a dis command (display) and a concatenate command (cat). i bet dis would have won out in popularity as the canonical command to display a file


for what it's worth, i'm not a Unix fanatic either. i like the Unix Philosophy but think that the original Unix guys did kind of a mediocre job with it (bytestreams as the single datatype? really?). so i don't feel like i'm disagreeing with you on the grounds of wanting to Defend My Lord And Savior Ken Thompson or anything like that

oh, yeah, also, dwm practically listing elitism as a goal in its homepage is pretty yikes. before i clicked the link you provided i assumed that quote was from some third-party article 😬

perhaps many of these philosophy problems stem from the fact that these unix people weren't thinking of other people when they wrote their little things, at least not people outside of their lab or company.

And then when their utility ended up on millions of machines, people rushed to the source to speak to the creators to receive wisdom but they aren't wise, their just locally-competent people, no more talented or wise than any other locally-competent person.

And, surprise, they don't often have anything useful to say about the general "user" experience or insight into how their little tool fits into a massive globe-spanning ecosystem of tools and workflows.

I wish we could stop trying to seek wisdom from them. They don't have much to offer.

i'm reminded of a certain tendency among ostensible communists who take retrograde social opinions to justify their bigotry with cherrypicked quotes about marx considering sex workers lumpenproletariat or lenin calling female promiscuity bourgeois. it's funny how certain atheist ideologies still end up with adherents who desire dogmatism.

While I understand the point you're making, I don't really think suckless as an example supports that point.

The core thesis of suckless and the adjacent projects is that it is impossible to present a simple interface over complex software. Instead, suckless strives for simple, extensible software with the simplest configuration format of them all: direct access to the source code. (That's the way I understand it at least; I'm not actually that deeply involved in the project). I'd take C over the usual mishmash of half-baked DSLs any day of the week!

The reason you are editing config.h instead of /etc/dwm.conf is because you may realize that you need to introduce some code to dwm.c. The line between changing configuration and changing implementation is much thinner and that's a good thing. The software is simple enough that you can make changes to the source instead of wrangling configuration files to achieve a subpar result using much more complicated software.

I really believe that suckless' approach is a much more fulfilling and fun way to interact with one's computer. That being said, I don't care much for the weird elitist attitude and the sometimes pedantic interpretation of the Unix Philosophy:tm: