Live data from Hacker News

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

medium.com

241–250 of 256 posts

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

#241
post #239

Earlier quoted context omitted.

I mean people still use `ls` everyday so it in fact did win. We have super rich GUIs, REPLs, the start menu, live programming environments and notebooks, web browser file listing capability, the ability to build your own web app to list files visually anyway you want. And yet everyone still uses `ls`.

I think that most people who need ls's functionality (listing files in a directory) use a GUI application.

Depends on how you define "functionality". You could say that ls's functionality is "providing a text listing of files in a directory. You can't get that from a GUI, certainly not without extra steps.

Why would anyone care about that difference? If I'm reading the listing, I don't care. My eyeballs don't care if the photons came from a GUI or text in a shell. But if I'm trying to pipe the results to another program, then I care. GUIs don't pipe well.

And people like me pipe the results of ls all the time.

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

#242
post #65
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.

It's bizarre that this is the case given that ascii contains characters for this very purpose. There's record separator, group separator... Now if your data contains those, that's bad. But that's much rarer than containing ordinary whitespace.

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

#243
post #193

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…

> 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. Well, if you're willing to pay, there's a lot more options. You correctly identify the unix principal only working because the people doing it are computer people. It's designed for a situation where you are the one that has to solve the problem, not one where you can just pay your way out…

May be that is the key to the problem. We should have a programmer os vs a user os, sort of like macOS vs the underlying command interface. Not like dos to windows. The unix or linux is designed by programmers for programmers. User should pay their way out by paying the programmer.

Obviously there is some in-between cases… occasional use is ok.

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

#244
post #168

Earlier quoted context omitted.

> If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues. Of all the reasons microservices are bad this isn't it. Your first point can be handled mostly automatically with half decent SRE tooling. Lock files on any modern language (including Python via poetry) fix dependency weirdness. Contract violations are a problem with your…

Why did you include functional programming in that list? It seems like the odd one out to me.

It's over applied in almost every professional context. I've watched entire codebases go from reasonably tolerable OOP to FP and the subsequent fallout. Usually, it's because some unhinged programmer starts adding stuff they like to a language it doesn't fit with. Then, you bring new developers on and no one wants to wade through the several layers of map/flatten/reduce/etc. Worse, the bolted-on FP is not optimized well by the compiler leading to worse than usual benchmarks. It's almost always a lose-lose except when it's done with a functional-first language.

It has it's purpose. It's almost universally over-applied owing to the cargo cult and holier-than-thou attitude of a lot of functional programmers. I see it happen in Python where comprehensions are often replaced with maps. While it is nice, the comprehension is more idiomatic and far more widely understood.

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

#245

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

[deleted]

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

#246
post #82

Earlier quoted context omitted.

Make an extensible platform through a plug-in facility is hardly new or specifically closed source solutions, doesn't it?

I haven’t made such a claim.

Then there is something I miss in the article maybe. What is the lesson there? What is indeed so special about Obsidian, a platform I'm completely unfamiliar with, that is different from any other platform with a plug-in architecture?

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

#247

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to ha…

A monolith has more engineers working on it though and chances are some of them won't be great.

Those same engineers will still be there in the microservices world. You can argue that the damage they can do is reduced, but I don’t think that’s always true.

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

#249

Taking Obsidian and VsCode as examples of the unix/microservices philosophy is very bizarre. VsCode is in many ways a philosophical successor to Emacs and sits on the opposite end. Yes, it has plugins but it is designed from the top down to work in a particular way, and everything integrates with it. VsCode Extensions don't function on their own, they're not composable tools, they don't expose any agnostic interfaces…

The Atom editor was JavaScript + Electron same as VSCode. You could configure everything a lot more than VSCode IIRC. I was very excited initially.

But I think perf issues did it in from this design choice.

I'm keen to explore Emacs more.

Plugin systems are one of the hardest things in software (but also look the easiest from the outside).

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

#250
post #193

Earlier quoted context omitted.

> 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. Well, if you're willing to pay, there's a lot more options. You correctly identify the unix principal only working because the people doing it are computer people. It's designed for a situation where you are the one that has to solve the problem, not one where you can just pay your way out…

May be that is the key to the problem. We should have a programmer os vs a user os, sort of like macOS vs the underlying command interface. Not like dos to windows. The unix or linux is designed by programmers for programmers. User should pay their way out by paying the programmer. Obviously there is some in-between cases… occasional use is ok.

I think that's just called android at this point.
Post reply on HN