Hacker News Reader

Comment by airstrike | Hacker News Reader

> But Adams makes a powerful point: the general-purpose nature—as well as composability—of a piece of software is just as important as its low floors and its approachability.

This is an interesting take. From this perspective, I suppose Unix got composability right but its approachability to the average person is nearly zero.

In some way "pure" functional programming often feels the same way to me. Extremely composable but am I willing to trade approachability for that? And on second thought maybe that's true of "pure OO" languages too...

Maybe people feel the same way about hardcore text editors like vim or emacs?

The list goes on... I think I read somewhere that innovation is defined as the solution to a trade-off, and this particular battle between approachability and composability seems like a particularly fruitful avenue to explore if looking for "modern problems to solve"

View on HN

"* From this perspective, I suppose Unix got composability right but its approachability to the average person is nearly zero.*"

I strongly agree with the first part of the sentence, but I disagree with the second. Considering the users that the Unix developers had in mind at the time---the late 1970s to late 1980s, say---its approachability was significantly better than the alternatives. (DCL, anyone?)

It wasn't until Unix expanded outside that niche that people began having bad reactions to it. :-)

Of course, now that it has expanded, and it's currently 2023 not 1970, the approachability to the average person is nearly zero.

I'd guess the Node.js and npm got composability w/ approachability formula the most correct. Rust comes close but using rust libraries is where approachability falls apart fast.

As for editors. Right now vscode get that formula the most correct.

As for Unix what do we have to compare it too? Everything more or less is a Unix these days. So it couldn't have got approachability that wrong.

I think the issue with npm is that it makes what should be a relatively important task (adding huge swathes of mostly unknown code) trivial to do, leading to all the bloat and abuse that ecosystem has seen. Sometimes a bit of friction that forces the user to slow down and truly understand what they're doing is a good thing...

The vulnerable part of the npm ecosystem is trust and end-user high-granularity control of trust.

If that problem can be solved, there's nothing inherently problematic with just using large swathes of mostly unknown code. Almost no Debian user knows the innards of every package they've installed, even the dev libraries they're building new applications on top of (to say nothing of every Ubuntu user).

(TBF to the ecosystem, there actually is a mechanism for flagging security issues in old library versions and surfacing those to a package builder. But it is up to the package builder to account for them by changing their dependencies).

I agree. To be more specific I think the problem with npm is that it explicitly trusts names and implicitly trusts their referents, which puts too heavy a burden on the name resolver.

Contrast this with apt, which inspects package signatures and compares them to keys I've trusted. If a package shows up with the same name as before, but different bits, and it's signed by somebody new, I have a reason to scrutinize it more heavily.

Npm does one thing particularly clever that a lot of other library / dependency infrastructures fail at: it supports multiple versions of the same library living in the codebase.

Because npm treats package dependencies recursively, a package depending on v1 of another package and a package depending on v2 of that package can actually live in the same codebase (with proper configuration; it comes as kind of a side-effect of transpilation and tree-shaking requiring the toolchain to rename symbols anyway, so the two different versions of the library just end up either properly hidden via module inclusion or in the same codebase but name-mangled to different things). This isn't foolproof (if one of those libraries leaks details of its dependency, and another piece of code tries to do `instanceof`, it's going to have a bad time), but it makes it easier to work with codebases one doesn't control.

Wondering what more approachable looks like in this case? A GUI embracing Unix metaphors?

"It's a UNIX system! I know this! It shows you what to do!"

You're giving me SMIT flashbacks here. :-)

I wonder if flowcharts could work? Blender’s nodes seems nice, although I guess Blender users are typically fairly technically inclined.

Or spreadsheets. Spreadsheets where the cells run little Python programs. Someone has done this I think, forget the name of the program…

Reply on news.ycombinator.com