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

41–50 of 256 posts

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

#41

Post by [deleted] »

dist-epoch wrote: post #18
noelwelsh wrote: post #10

Earlier quoted context omitted.

Wow, I didn't realise. I haven't paid attention to Windows APIs for a long time. I really thought it would have died a long time ago.

The core of COM is about allowing binary code to be used from any language through a standardized interface. As pjmlp mentioned, this part was very successful and all new Windows APIs are based on it. The COM which failed and which you are thinking about was related to OLE and the idea of embedding Excel sheets inside Photoshop drawings, ...

[deleted]

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

#42

Post by i_don_t_know »

To me, Wirth’s Oberon system has the same philosophy of having small composable tools and being extensible. There’s no distinction between system language and scripting language. Text is also a common way of passing data, but you can use whatever data structure you want. I think of it less as an OS than as an application shell that you shape to your needs.

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

#43

Post by nologic01 »

lelanthran wrote: post #12
nologic01 wrote: post #3

Its an insightful read and the final graph analogy seems very apposite. But here is the rub: if microservices is a general graph pattern, it includes all the other patterns (likear, hub and spoke etc) as these are all just particular graphs. In other words, you could implememt unix pipe like or plugin like microservices by applying certain constraints.

Is that relevant, though? An undirected cyclic graph is a superset of all other data structures[1], yet we still differentiate between them and choose the most suitable. [1] And can be used to build all other data structures. A tree is a directed acyclic graph, a list is a tree with no more than one child per node, etc

The proof would be in eating the pudding, but the thrust of the argument would be to indeed recognize that "microservices" is too general a pattern and one might benefit and make them more usable by developing tailored patterns (imposing constraints adapted to the data exchanges that dominate the application).

Its just a thought sparked by that interesting diagram at the end of the post and motivated by the fact that the REST architecture is also specified as a set of constraints...

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

#44

Post by rcxdude »

benj111 wrote: post #35
noelwelsh wrote: post #28

Earlier quoted context omitted.

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.

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.

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

#45

Post by throwaway31381 »

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

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

#46

Post by SuchAnonMuchWow »

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?

crushed by technical debt

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

#48

Post by francasso »

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, boilerplate and additional failure conditions.

If you think that microservices solve the "spaghetti code problem", well, good luck to you, you'll need it.

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

#49

Post by oneshtein »

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?

In my native language, we widely use therm "Information explosion".

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

#50

Post by troupo »

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…

> Separate processes look particularly elegant and modular to me. They are much easier to debug and profile than bolted-in dependencies

Debugging async rocesses is definitely not an easy task. As is managing them in systems that have no management and supervision capabilities (aka nearly all of them).

What happens when your process errors out? Gets kille dby OS? Gets stuck? Fork bombs?

They are also quite expensive to start in OS terms.

Post reply on HN