Kernighan and Pike were right: Do one thing, and do it well

Post by beebeepka » Sat, Aug 19, 2023, 5:50 PM UTC

renegade-otter wrote: post #133

marcosdumay wrote: post #120

Earlier quoted context omitted.

> Do you saturate the resources of one machine and need to split things off? No, of course not. We divide a single machine in an uncountable number of virtual ones; write some code to make sure they don't talk to each other; write some code to make them able to talk to each other; write some code make more or fewer divisions on the run, automatically; and write some code so we can set them up automatically too every…

And what if a certain permutation of these hundreds of services goes down or slows down ? What if one service starts generating tons of data and floods another service? Do you have backpressure figured out? Distributed systems introduce a whole new level of complexity and edge cases, but most companies never even hit the scale at which it matters. It's just a pointless, wasteful exercise in "how they do it over at Go…

Post by jcelerier » Sat, Aug 19, 2023, 5:53 PM UTC

tsimionescu wrote: post #33

doctor_eval wrote: post #15

Earlier quoted context omitted.

Let's just be careful what we call Unix though. In SVR4, I don't think "ls" had that many options. It didn't even have colour (not that I would know; my Wyse 60 could only have Green, Orange or White text... and the colour was set in the factory). It's the same for many programs that started small but grew loads of knobs with age. You can't claim that this was the Unix vision, because what we call Unix today isn't ev…

It's still a failing of the Unix philosophy that people found it easier to add all these flags to ls than to string together a few "simple&composable" commands.

Post by RetroTechie » Sat, Aug 19, 2023, 6:02 PM UTC

Narishma wrote: post #212

RetroTechie wrote: post #205

Earlier quoted context omitted.

This is why I tend to go for the "open" option (eg. open source software) wherever possible. Not necessarily because it's better. But because the incentive to enshittify it is lacking. Closed / proprietary ecosystems tend to be nice for a while. And then disappear without warning. Or turn into crap, like a big sinking ship taking all its users down with it. FOSS / open platforms tend to fork and/or evolve. And (if th…

It happens in OSS too, though maybe the reasons there are different. See Gnome for example.

Post by matheusiacono » Sat, Aug 19, 2023, 6:17 PM UTC

saghm wrote: post #154

tailspin2019 wrote: post #6

Good article, but to me it seems to be co-opting the term enshitification in a strange way: > Large codebases will eventually reach an “enshittification point” — the point at which bugs are introduced faster than they can reasonably be fixed. I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. It doesn’t necessarily emerge “bottom up” as the result of technical d…

Am I the only one who thinks that the term sounds far too general given the apparently narrow interpretation that's intended by it? When first seeing the word, it literally just sounded like it meant "the process of becoming shitty", and I never would have guessed that it was intended to be so specific. It seems unfortunate that the term was picked primarily for how evocative it is rather than for its clarity.

Post by giantrobot » Sat, Aug 19, 2023, 6:29 PM UTC

deng wrote: post #37

I wish people would stop applying the "only do one thing and do it well" to all software. Kernighan/Pike were explicitly talking about software tools in the Unix environment, not about all software in general. It is an idealist, you might even say elitist view of how software should work, which they then realized in Plan9. And as impressive as Plan9 is, there's a reason it never got widespread adoption, and that is n…