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

61–70 of 256 posts

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

#61

Post by lijok »

qaq wrote: post #59
lijok wrote: post #56

Earlier quoted context omitted.

> If you think that microservices solve the "spaghetti code problem", well, good luck to you, you'll need it. That is a very good point. In fact, good monolithic code layout is a precursor for microservices, as only once you have identified your boundaries and isolated your concerns can you begin splitting them out into their own services. I will say this however - microservices might not solve the "spaghetti code pr…

Have your teams use façade pattern and you no longer need microservices to "isolate it"

Facade doesn't help with poor tests, scripts, new dependencies, cicd workflows, repo settings, etc

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

#62

Post by asddubs »

benj111 wrote: post #31
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…

Suggestions for a term for the phenomena? Emshitifaction?

if you're gonna go that way, you might as well go with shitfactoring

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

#63

Post by asddubs »

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…

Hey! I'll have you know, I don't print improvements for my 3D printer, I mostly don't use my 3d printer at all

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

#64

Post by noelwelsh »

throwaway31381 wrote: post #45
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'…

>But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags GNU is Not Unix. I count 13 flags on both Unix V10 [1] and on Plan 9 [2], its spiritual successor. [1] http://man.cat-v.org/unix_10th/1/ls [2] http://man.cat-v.org/plan_9/1/ls

This is a version of a No True Scotsman argument: the True Unix did not have these flags and therefore these flags are not part of the Unix Way. The extra flags were added over time because the One True Unix did not provide the functionality that people needed in real world use. They couldn't be added in a composable way because of failures in the shell programming model (unstructured text + sh is terrible). The Unix shell model was broken from the start.

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

#65

Post by rakoo »

rcxdude wrote: post #44
benj111 wrote: post #35

Earlier quoted context omitted.

Ls seems like a bad example. Anything that you'd want to colour, the data should already be there. Further I'm not sure the Unix way inherently requires completely unstructured text

Unstructured text is the unix way. You can have pipelines sending other things between your programs (see powershell), but that's definitely not Unix.

I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.

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

#66

Post by morelisp »

ahofmann wrote: post #39
benj111 wrote: post #31

Earlier quoted context omitted.

Suggestions for a term for the phenomena? Emshitifaction?

The article could have used the term technical debt. To me technical debt happens not only when new code gets added in a sloppy way, but also when the developer experience gets worse.

I really like Egon Elbre's definition of technical debt as idealized effort vs. actual effort to make changes - https://www.storj.io/blog/demystifying-technical-debt

It nicely captures a lot of the usually "fuzzier" things of technical debt, like how code even with no changes and no changing requirement somehow accrues technical debt (you get better, your idealized effort reduces).

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

#67

Post by mawadev »

With plugins and extensions we've gotten to the point where "Create New Document" in Photoshop is an extension.

Now that electron apps spawn their own browser process, then act like the central GUI hub and "do that right" - it seems to be quite the opposite from "do one thing and do it well" from my point of view.

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

#68

Post by throwaway31381 »

cpach wrote: post #52
throwaway31381 wrote: post #45

Earlier quoted context omitted.

>But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags GNU is Not Unix. I count 13 flags on both Unix V10 [1] and on Plan 9 [2], its spiritual successor. [1] http://man.cat-v.org/unix_10th/1/ls [2] http://man.cat-v.org/plan_9/1/ls

I think you’re actually making the point for him here. You are correct that GNU is not Unix. And what version of ls has the most installations? I betcha it’s the ls from GNU Coreutils. I do agree that GNU tools are sometimes too maximalist. But they are also more useful than the minimalist alternatives.

I don't believe GNU's triumph over the BSD derivates was for the most part technical, they just happened to be at the right moment at the right time to ride along Linux's success.

A consequence of the proliferation of arguments in the GNU tools is imho that it made the GNU manpages too verbose and information dense to the detriment of their usefulness.

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

#69

Post by dig1 »

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 think of enshitification primarily as an organisational/business phenomenon rather than a technical one.

I will second this. I can't count how many projects were started with a clean design and clean early releases (what worked well), to be later messed up with business changes because the original (business) idea didn't work. And those sudden changes are expected to be implemented usually "yesterday", which adds additional momentum to the project's downward spiral.

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

#70

Post by l0b0 »

eesmith wrote: post #32

To count the number of functions in a rust file you could run: cat main.rs | grep "^\s*fn\s" | wc -l This both promotes the "one thing well" model, while revealing its inherent limitations. How many functions are in this rust file? /* confuse things fn fo fp fn fm fl */ fn main() { println!("Hello, world!"); } The above grep reports two, when there is only one. It can be made to work if everyone agrees to follow conv…

This sort of heuristic bugs me too. We should be able to write language server-adjacent tools which could do this sort of thing as easily as grep. You could do a lot of useful stuff with that, for example to implement custom linting rules:

- Count non-comment tokens within each scope, to look for complex scopes: `foo --tokens --exclude-comments --group-by=scope`

- Count expressions (as opposed to just SLOC) per function: `foo --expressions --group-by=function` piped to `uniq`

- Get the functions and their argument count: `foo --arguments --count --group-by=function`

- Find very short or long names: `foo --names --sort-by=length` piped to `head`/`tail`

Post reply on HN