Comment by usernametaken29
8 hours ago
I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more real world and it solves maintenance problems pretty much entirely.
Sounds a bit like the idea behind shadcn/ui. You start from the generated components, but the idea is to fork the code.
(Then they seem to also have added their own kind of dependency management thing to update components, which seems to me to kind of defeat the purpose..)
There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.
You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.
The person I was discussing this with was indeed working on lambda calculus and provability of side effects. At least in theory it is possible to account for all classes of side effects and remove any risk. Also, what other people have said here, functions can be immutable artefacts with a fixed hash (just their own content) which mitigates a whole cluster of supply chain issues at once
The missing piece there, that would be a real value-add over normal package repositories, is that functions can be small enough to simply be done. Function gets marked as such, it can no longer be updated, thus eliminating the risk of supply chain attacks and their ilk. IMO, most packages I actually use, with the exception of web frameworks, ought to fall into this category. My JSON parser should never update. My Knapsack-problem solver should never update.
These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.
In what ways do version pining/lockfiles not solve this problem?
I think the function should be anonymous (have no name). Import should name it.
> remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions.
Like leftpad?
Unlike a dependency a function is an immutable artefact. You write it once, done, you get a checksum that matches that exactly. You can even guarantee it’s the function because of it… so not really at all like leftpad or npm, where commit hashes and versions are only loosely correlated to actual code
Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.
I mean in my head it is 'Plugin system', at least in the context of feature bloat.
Where it can get slightly hairy is that to do it well, you need to have a LOT of seams between layers.
> but the idea of providing tests and types without implementation is a pretty interesting one.
I feel like in my head, you need to have -some- baseline/example implementation; e.x. Akka/Pekko/Akka.NET have Plugin specs for Persistence but there's still a Memory-only implementation of Persistence as a reference/baseline; after all you need to make sure the spec is possible at all.
I think the biggest adoption stopper would be that building a dependency chain (like say a JSON parser) could already be quite many functions. As the end user you don’t care about the architecture of JSON, you just want to consume it and get an object. In the end you might virtually end up with libraries again, because in some sense abstractions over functions are libraries. There’d still be a win though because if you store the execution AST in a common database you can provide consistently tested primitives over many languages… However I think outside of functional programming circles no one really actually cares enough about this to tackle it