Hacker News Reader

Comment by janpot | Hacker News Reader

> A minimal viable program is the smallest program that solves a particular problem. It is small and beautiful. It has no additional features.

Yet, when a node developer creates left-pad...

View on HN

There's two problems with leftpad:

(1) Dependencies always add certain minimal level of complexity, so a too-trivial dependency can add more-than-warranted complexity as a dependency even when the implementation itself would not do so as an integrally-maintained component of the larger system.

(2) the nature of the npm distribution ecosystem (and this is by no means unique to npm) means that the complexity and risk added by dependencies managed through that ecosystem is more than it otherwise could be with immutable, append-only repositories of dependencies.

What's an example of an immutable, append-only repository of dependencies? That _sounds_ intriguing but I don't follow.

Maybe like C's `include`s? Where (I think) the code is in-lined without modification?

The include is immutable (unless there are macros).

Append only sounds like the included code should be evaluated after other code in a given file (so main defs would take precedent over included defs? Or main defs would be over-written by included defs... I guess it depends on compiler/evaluator implementation.

The more I type here, the more I realize how much I don't know about this stuff...

I don't know of any perfect examples, but the idea is one where once a version of a library is posted, that version can no longer be deleted or modified, only later versions added.

Legal and practical constraints would probably mean any real system would be at best an approximation of this ideal, but a big part of he leftpad problem is that NPM at the time didn't even try to approximate it (the response also underlined an NPM policy existing at the time that was useful in that context but dangerous in general, in that NPM generally allowed others to claim the name of abandoned projects.)

So like the first use of a shared ledger ever for binary packages?

nixpkgs works like this when you pin to a specific git commit. It's effectively like vendoring all of your dependencies into your source control system, but without the overhead of storing everything locally (instead just storing hashes of dependencies).

Joe Armstrong agrued vociferously for mny years for breaking up all packages into one universal database of importable functions.

http://erlang.org/pipermail/erlang-questions/2011-May/058768...

> - contribution to open source can be as simple as contributing a single function > - there are no "open source projects" - only "the open source > Key-Value database of all functions"

Look at the examples he gives:

    is_blank_line
    is_prefix
    remove_leading_whitespace
    remove_trailing_whitespace
    remove_leading_and_trailing_whitespace
    skip_blanks
    trim

and many more

https://news.ycombinator.com/item?id=8342755

https://joearms.github.io/published/2015-03-12-The_web_of_na...

There is creating left-pad, and there is packaging it alone in a library distribution infrastructure to be manually managed as a dependency.

There is absolutely no problem with the first one. Nobody is complaining about the author writing left-pad, only about it not being available in the standard library or some larger package. Changing the entire infrastructure so code becomes immutable and requires no trust would work too.

The OP Joe Armstrong was certainly advocating for it NOT available in the standard library or some larger package.

http://erlang.org/pipermail/erlang-questions/2011-May/058768...

I don’t think this extends to libraries, which are units of composition and each unit comes with a more-or-less fixed amount of overhead for managing the trust relationship with the maintainer (as well as other things, like managing the version to pin against, etc).

Reply on news.ycombinator.com