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

91–100 of 256 posts

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

#91

Post by csydas »

bluetomcat wrote: post #24
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.

I don't agree with this conclusion on the number of flags for the GNU core utils relating to it's composability; the flags are natural advanced extensions of what the tool is meant to do, and even without the flags the tools are straight forward enough that the default execution likely will meet the requirements of even new users.

From my own experience teaching newbies about bash, the only hard part about all the flags was getting newbies comfortable with ignoring them at first and just trusting that `ls` lists files in the current directory, `sed` let's you manipulate text in a smart way, `grep` finds things, and so on. Once they got that in their head and understood that the flags just allow very specific operations that you previously needed to write a lot more code for, most people got it pretty fast and could punch out quick shell scripts to help with their work. But the base commands without a slew of flags was still quite useful for these newbies.

Again though, that's just my experience and it was fairly narrow in scope for accomplishing specific troubleshooting tasks, so that may factor into why I saw success here; I don't know if the people I taught further evolved their scripting skills past basic troubleshooting, though I am fairly confident these persons understand the "kitchen tools" nature of the GNU core utils as many ended up writing scripts on their own for situations we never discussed, and the scripts were pretty okay.

Edit: Typo, changed Exceptions to Extensions in the first paragraph

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

#92

Post by baz00 »

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…

This. So much this. We are 5 years into a microservices wank-fest. So far the net ROI is negative, the user experience sucks more than ever, the complexity is so high that people can't get things done, nothing works properly any more and no one owns anything because they have washed their hands of it all. But this is still promoted as a success because no one wants to be accountable for the fuck up.

Our team spend most of the time designing fucked up messes that run over poorly designed APIs, slowly, that impact customers. If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues.

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

#93

Post by MyAccountYo »

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 think you are misunderstanding the whole topic. Obviously it's about software at scale. Picking the right solution for a problem is kind of the whole job of software development.

I have gone through the migration of monoliths to microservices (yes, at scale with multiple teams and requirements to scale individual components etc.) and it solved a lot of problems.

The benefits outweigh the costs in my opinion (and drastically so).

When people say "you can write well separated components in a monolith..." I can only say: of course you could, but you are not going to (and certainly not everybody at your giant ass company is going to).

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

#94

Post by _shantaram »

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…

"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

seem very confusing to grug"

-- https://grugbrain.dev

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

#95

Post by jacquesm »

throwaway31381 wrote: post #68
cpach wrote: post #52

Earlier quoted context omitted.

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.

That's exactly why RMS is so pissed at Linux being mentioned without GNU. The funny thing is that it is the license he shipped his code under that allowed them to do this, he could have made the license say 'if you use this code you are required to prefix the name of any project with 'GNU/'' and that would have been that. If you give people rights and freedom they will use them.

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

#96

Post by rcxdude »

Kinrany wrote: post #85
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: text is the minimum structure. It's often enough sufficient too, but using something higher level like JSON is also perfectly UNIX.

I don't think so, this idea of JSON is a more modern interpretation and I'd say is counter to the UNIX philosophy, not an extension to it (it just so happens to squeeze into existing primitives a little better than e.g. a binary serialisation protocol).

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

#97

Post by prakhar897 »

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"

Can your "facade" "isolate" interns making change in your service as well so that the whole service which powers the system doesn't go down. Microservices can.

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

#98

Post by oneshtein »

alkonaut wrote: post #26

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 e…

> I just want someone to make a big ball of mud app

Just hire someone to make a big ball of mud app.

> it does a worse job and costs more

Yep. Just pay for it.

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

#99

Post by 37174330 »

theorem: Total system complexity in software is constant; architecture determines where the complexity is exposed.

doctrine: Effective architecture shifts complexity to the core competency of the development and operational resources.

observation: software engineering suffers from the disconnect between the competencies in development and operation resources.

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

#100

Post by bregma »

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.

The Unix way is streams of bytes.

How those bytes are interpreted is up to the endpoints of the streams. Sure, a lot of endpoints interpret byte streams as text. That's not Unix, that's a particular endpoint.

You will notice that Unix does not even offer 'text' files (like Windows does). Or ISAM files, or random access files. or Fortran carriage control. Just binary files. Because the Unix way is streams of bytes, and nothing more.

Post reply on HN