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

171–180 of 256 posts

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

#171

Post by AnimalMuppet »

noelwelsh wrote: post #28
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…

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.

The Unix command line tools were designed to be usable in a lot of ad hoc situations. In an ad hoc situation, unstructured text is often what you have. So, to be usable for that, the command line tools had to be able to operate on unstructured text as input. That left two options - either also accept something structured as input, or accept only unstructured text as input.

"Usable in an ad hoc situation" gets us back to composability. If you can compose existing parts to meet a novel situation, that's better than having to carefully architect a solution. And the key to being able to do that is common interfaces. Unix did exactly that. And, for all the criticism, it works pretty well.

Can a well-designed interface do better? Sure. Can a well-designed interface deal with something outside the design parameters as well? Probably not.

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

#172

Post by Lio »

> cat just outputs file contents

Well it does but... its actual purpose is to concatenate multiple files.

All Unix commands can read files so you don't need any special tools for that.

E.g.

  grep "^\s*fn\s"
or in grep's specific case just

  grep "^\s*fn\s" main.rs | wc -l

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

#173

Post by cpach »

jmclnx wrote: post #159
cpach wrote: post #74

Earlier quoted context omitted.

Good point. However: The users could have revolted and gone to *BSD land instead. But for some reason, most users didn’t.

That is because of the "lawsuite", unless you are referring to the 80s. Back then, Companies and Colleges were the ones who got UNIX. Companies went with AT&T, and IIRC Colleges when with BSD. So AT&T won out due to better financial backing and maybe a possible threat of AT&T going after BSD.

Well, Linux is 30 now. The lawsuite was settled quite long ago, wasn’t it?

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

#174

Post by AnimalMuppet »

cowsandmilk wrote: post #88

But then Kernigan contributed to awk which does regexes, count lines, and enough other things that there are 500 page books on how to use the tool. Maybe stringing together grep and wc wasn’t always enough.

Of course it wasn't always enough. It was enough to be useful in many situations, and not enough to be useful in all situations. So there's awk. And it's useful in some situations, but not in all. So there's C. (And some will say it's not useful in all situations...)

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

#175

Post by eesmith »

l0b0 wrote: post #70
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 funct…

While I have not tried them out, I know there are tools along these lines.

See Tree-sitter at https://tree-sitter.github.io/tree-sitter/ , and as an example project which uses it to parse different languages in a line-oriented manipulable way, see https://pypi.org/project/code-ast/ .

At the very least, the hard part - parsing the different languages - is done.

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

#176

Post by BirAdam »

rakoo wrote: post #65
rcxdude wrote: post #44

Earlier quoted context omitted.

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.

But, you can always override IFS, so this isn’t as much of an issue.

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

#177

Post by BirAdam »

Honestly, every paradigm and tool the industry has come up with has been great at identifying and attempting to solve either or one or many issues with software development and maintenance. The UNIX guys did this for C, where when UNIX systems are viewed as a C dev environment, the tools and paradigm are fine. The issue, IMHO, is that people tend to get… religious in their dedication to a paradigm and/toolset. I think the functional and OOP communities have done well too. The issue today is, I think, speed. People move very quickly now and there’s not adequate time for teams to document, bug fix, and grok a code base. If they took enough time for this, they’d be late to market and miss a giant amount of revenue. There’s also just the problem of accretion. All human organizational and informational systems suffer this, and software is no exception. At some point, the size of the code base and the number of developers eclipses any attempt and understanding and control. The extremes of the UNIX paradigm are neither sufficient nor necessary to arrest this, personal discipline is more the requirement.

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

#178

Post by Kamq »

renegade-otter wrote: post #126
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…

That is a very strategic and appropriate use of this pattern, and it's not even "microservices" - it's just goddamned "services"!

It also seems like an intentional wielding of Conway's Law.

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

#179

Post by hinkley »

francasso wrote: post #48

You don't need a damn network between two pieces of code just to "do one thing and do it well", for God's sake, I'm so sick of this rampant cluelessness in the industry. Do you saturate the resources of one machine and need to split things off? Do you have multiple teams each taking care of their own stuff? Do multiple services, it's fine in those cases. For almost any other reason you are just adding complexity, boi…

I can’t even get people to make new web pages in a web app past year 1. Everyone wants to just cram new features into whichever page makes the most sense, and so average page load time just gets worse and worse because we still want ### milliseconds but now the page is doing twice as much.

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

#180

Post by photochemsyn »

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…

Yes, the bug accumulation problem is better described as 'degradation'. 'Enshittification' implies deliberately introducing features that make user experience worse while benefitting only the owners of the platform.

Is someone keeping a list of features that qualify for the label? For example browsers like Safari make it very difficult to export bookmarks to another browser like Firefox, even though a simple json file would suffice.

Post reply on HN