Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

21–30 of 256 posts

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

#21

Post by hresvelgr »

vlovich123 wrote: post #19
hresvelgr wrote: post #17

These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…

Did you read the article? The entire last half is how to apply it to UIs and what that looks like (Obsidian, Canva, etc).

I did. I'm talking about CLI apps, though that wasn't clear I will admit.

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

#22

Post by eternityforest »

hresvelgr wrote: post #17

These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…

We need more standard special purpose interfaces. Not unstructured RPC protocols, but very specific "Every plugin of this type has this function that does exactly this" kinds of things.

Linux people seem to tolerate bash partly because they DO have a special purpose modular system. They algorithmically manipulate text in batch rather than realtime mode to produce an output on a regular basis(I'm not sure for what, besides compiling and building, but they all say they have use cases). Apparently it works great if you process lots of text files.

Perhaps a GitHub awesome list. I've been meaning to start one for very common standards in general(18650 batteries, tripod thread, etc).

We have LADSPA and LV2 for audio, shell commands for text, etc, What else do we have, and what should we have?

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

#23

Post by enriquto »

hresvelgr wrote: post #17

These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…

> invoking them as a separate process from the main application does not count

Why not? What is your worry? That starting a process is too slow? That data transfer is too slow? Something else?

I agree that process startup may be meaningful overhead in the rare cases when the actual computation is very fast. But sharing uncompressed data between programs is essentially zero-cost.

Separate processes look particularly elegant and modular to me. They are much easier to debug and profile than bolted-in dependencies, since the running time and input/output of each process are trivial to isolate. Of course, having both a library and a cli interface for the same computational brick is always better, but the unix-style tool is an essential thing to have.

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

#24

Post by bluetomcat »

hresvelgr wrote: post #17

These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…

On a modern Unix-like OS, these tools aren’t as simple as they used to be in the 1970s. The man page for ls alone lists tens of options, corner cases and historical cruft. If those tools were really composable, they wouldn’t need so many options hidden in their man pages.

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

#26

Post by alkonaut »

As a developer I can sort of see the appeal. I often have tasks where I can compose programs.

But as a user I just want the software that solves my problem from start to finish even if it does a worse job and costs more. Even if there are N pieces of software that solves my problem in N steps, that composition isn’t something I generally can or want to do. I just want someone to make a big ball of mud app that does exactly what I need. It’ll try to do whatever everyone else needs too, which is why it is a buggy ball of mud. But it’s still a lot more attractive than having N separate steps and doing any sort of composition myself. Because that invariably requires knowing about files, data formats compatibility between components .

The Unix principle works well in Unix because the people using it are computer people, perhaps even software developers. In the age of everyone using computers (so 1990 and onwards) this breaks down horribly. The big ball of buggy mud do-it-all Software wins hands down every time.

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

#28

Post by noelwelsh »

doctor_eval wrote: post #15
noelwelsh wrote: post #8

The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusable parts. It's one of the key ideas in functional programming, and it's somewhat core to object-oriented programming. (OO is too big to be able to claim their is a consistent philosophy behind it.) But ... firstly, let's stop with the Unix worship. They didn'…

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…

IMO the problem with the Unix model is not that it's been corrupted over time, but that it was fundamentally flawed from the start. I'm hardly the first to point this out, but sending around unstructured text makes doing some things inordinately hard (imagine writing a separate program to color ls's output, instead of having that as a flag) + going beyond pipes leads to the awful experience of programming in shell.

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

#29

Post by badpun »

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…

I've once worked on a large and old Scala-cats codebase (i.e. Haskel-style, the whole program as an IO monad). I'd say we (the team) hardly introduced any bugs. The language made making whole classes of errors less likely, and the team's disciplined approach handled the rest.

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

#30

Post by hresvelgr »

enriquto wrote: post #23
hresvelgr wrote: post #17

These tools are not composable once you venture outside of a shell, and if I have to write anything beyond 5 lines, I'm not using one. There needs to be a way to make these applications usable as software libraries, and no, invoking them as a separate process from the main application does not count. This is the reason the functionality of these tools have been reinvented many times over and why they get extra cruft…

> invoking them as a separate process from the main application does not count Why not? What is your worry? That starting a process is too slow? That data transfer is too slow? Something else? I agree that process startup may be meaningful overhead in the rare cases when the actual computation is very fast. But sharing uncompressed data between programs is essentially zero-cost. Separate processes look particularly e…

Performance is not what concerns me, it's design. To what end is it useful to have distinctions between libraries and applications? If I have a JSON parsing library, it might be nice to run one-off scripts that grab a certain value and pipe it somewhere else. It's also useful to deserialise in complex manners inside an app of my design. My belief is that programs whether they are intended to or not usually end up being composed with other programs so on that basis, having the distinction of bin/lib doesn't serve a useful end to me at least.
Post reply on HN