Hacker News Reader

Comment by christophilus | Hacker News Reader

Every time I see these packages mentioned, I’m reminded of an interview with Joe Armstrong. In it, he said, (paraphrasing from memory) “Wouldn’t it be interesting if a language had a global, flat registry of functions that anyone could pull from and contribute to? That way, bugs are fixed in one place, there’s less reinvention of the wheel, things get more correct over time, and programs just become a simple composition of standard functions.”

I may be misremembering his meaning, but I remember thinking it was an interesting idea. It wasn’t obviously a terrible idea. I thought it would be like the Clojure standard library on steroids, especially if it was coordinated and vetted by a decent team.

But alas, NPM has proven it otherwise.

View on HN

I don't think NPM has proven that idea infeasible, just that it may not be a good idea to depend on third-party content that may change under your feet, on such a fine-grained level.

But have a look at the Unison language https://www.unison-lang.org/docs/the-big-idea/ , that has such global registry but addresses each function by a hash of its syntax tree, and thus sidesteps the issue.

How are bugs "fixed in one place" that way?

You either accept updates of third party packages, with little to no vetting of your own, and get fixes "for free" or… you don't.

There's no middle ground: the only way to save effort is to trust others.

NPM is a worse idea than Joe's as Joe was talking about a single community vetted monorepo. Not a free for all of individual repos.

With Joe's idea everything is up front and part of the language and not a bulletin board of packages near the checkout line at the git supermarket. This way simple stuff like isint() can make its way into the languages official standard library. This should eliminate the uncertainty of 3rd party packages maintained by a random number of individuals that can be taken down or tainted at any time.

I wonder if it might be practical to bootstrap such a thing off of Wikifunctions, with a process to vouch for a function as "important enough to merit inclusion" and tooling to ensure that the Wikifunctions implementations actually agree, plus something to synthesize/translate a first-pass implementation in the desired language?

NPM doesn’t capture the full benefit of an open registry of functions because, while anyone can fork and create an alternative @christophilis/is-even or @divbzero/is-even, there is no good way for developers to pick the best version of is-even.

Maybe if NPM required all package maintainers to use a namespace, the global is-even package name could resolve to the most-used fork.

So for an import like:

  import isEven from 'is-even'

You could install a specific fork:

  npm install --save @christophilus/is-even

Or default to the most-used fork:

  npm install --save is-even

In both cases, package.json would only contain namespaced dependencies and npm outdated could flag if a different fork is more commonly used.

This Joe Armstrong quote sums up NPM:

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

(originally on object oriented programming)

To be fair, for all its pitfalls, NPM does provide a limited version of that idea to millions of codebases.

the idea sounds great, but there would have to be something in place to prevent it from degrading into a Wikipedia-style turf war, with people trying to protect "their" code against changes...

Reply on news.ycombinator.com