41–50 of 57 posts
Regarding "nothing stopping us from making this versioning system completely automated" it seems like that depends on whether your language's type system supports that, and whether programmers follow the rules. For example, if you're relying on varargs/kwargs too much, it's going to be difficult to tell before runtime whether you've broken something.
Just hash the whole function and be done with it. Joe Armstrong made a proposal for this (I’m pretty sure half tongue in cheek). https://joearms.github.io/published/2015-03-12-The_web_of_na...
Earlier quoted context omitted.
I think churn in NPM might be an effect of how quickly the browsers and language are evolving. There’s always some new interface that will make your existing code faster or cleaner.
My sense it is cultural. If there's no consequence for breaking stuff then stuff gets broken. Other languages have a stronger culture of shame from breaking stuff.
For example:
GET /user/9893
Accept: application/json; charset=utf8; version=1
Now this is a bit different from TFA, because the server supported all the versions at the same time, so the caller could choose whatever mix of versions it wanted. This proposal is about assigning version numbers to individual functions rather than the library as a whole - essentially just a documentation/metadata change, with support from package managers.
Here's why this is relevant: the fact that the API was versioned this way had a big impact on how it evolved over time. At first it was pretty much the same as the usual `v1/user/9893` design. But as new versions of specific resources were added, it forced a decoupling of the underlying data model from the schema that were exposed in the interface. Each endpoint-version became an adaptor layer between the contract it offered to the caller and the more generalized, more abstract functionality offered by the data layer. That had costs as well as benefits. New endpoint versions often required an update to the data layer, which in turn required refactoring of older versions to work with the new data layer while continuing to adhere to their contracts. It worked out well, but it did require a change in implementation strategy.
I think the lesson for this proposal is that changing the way package metadata is handled is just the first step. Adopting it could then create pressure for mix and match packaging of the interface functions - "Hey can I get a version of this library with addFunction 1.2.16 and divFunction 2.0.1? I don't want to change all my addition code just to get ZeroDiv protection." That could be done with the right tooling and library design.
Or maybe it makes DLL hell worse because now you have to solve semantic versioning compatibility for every function in a library and that's slower and more sensitive to semantic versioning mistakes. You could get work-arounds like "only ever change one function when you release a new version of the library" or "just bump all the major versions even if they haven't changed."
Or maybe linkers would get built that can do the logic, like "when package A calls package B, use addFunction 1.2.16, but when package C calls package B, use 1.3.1"
Anyway, I don't think this proposal is sufficient on its own. It would either have ripple effects throughout the language ecosystem, or be ineffective because of developers working around it, or not be adopted at all.
I don’t think the proposal helps as it puts more burden on package maintainers (honourable semvar for the whole package is burden enough!). The problem is in NPM culture, and how much churn there is in packages and especially unnecessary breaking changes. Avoid that and then the problem is reduced from constantly fighting to play API keepup to simply letting security updates flow through. Let your patch version numbe…
> The problem is in NPM culture, and how much churn there is in packages and especially unnecessary breaking changes. This is a human culture problem if anything. Things cannot be left alone and be called "done" anymore, everything has to constantly "improve", breakage be damned. New connectors HAVE to be invented, even though the improvements are marginal, and now everything "old" doesn't work anymore. How many time…
The problem of tracking changes across dependencies exists whether or not this is true. Perhaps the problem is more evident because the feature development and software change processes have become more efficient. eg Detecting the need for changes, new features that are expected to stay competitive, etc. These efficient processes are highlighting this mismatch mitigation, that was easily manageable (or ignored) in the past.
Earlier quoted context omitted.
My sense it is cultural. If there's no consequence for breaking stuff then stuff gets broken. Other languages have a stronger culture of shame from breaking stuff.
Thinking we need to shame our colleagues more is a really bad take. You can like your obscure programming language for all sorts of reasons, but if they go around shaming people I'm not surprised people would rather use a friendlier language.
If a dependency update breaks my code, it reduces my opinion of that dependency. But if it's the least-worse option, and it's free, I can't do much other than think negative thoughts.
It good people are thinking about this problem, but this proposal doesn't address some fundamental issues. E.g, - why developers/maintainers choose the package granularity they currently do. e.g., you can have tiny granular packages today (npm famously has single-simple-function packages, which is widely derided, BTW). Developers break down packages in a way that makes sense to them to best develop, test, maintain, a…
The really, really fundamental issue this proposal doesn't touch at all is that you also need to - either version the data structures/classes/shapes of dictionaries/whatever that a function accepts/returns; - or have converters between different data versions and use them inside your functions. As I said in another topic on HN which was about that project that hoped to bring hot-code reloading in a C REPL or somethin…
Unless these sorts of things are dealt with, any framework like this will just be solving the part of the problem that isn't really a problem.
I don’t think the proposal helps as it puts more burden on package maintainers (honourable semvar for the whole package is burden enough!). The problem is in NPM culture, and how much churn there is in packages and especially unnecessary breaking changes. Avoid that and then the problem is reduced from constantly fighting to play API keepup to simply letting security updates flow through. Let your patch version numbe…
> semvar It's "semver" (with an "e"), short for Semantic Versioning. https://semver.org/
You could have different variable semantics for different namespaces or partitions!
:)
I think this is effectively achieved by the Unison language: https://www.unison-lang.org/learn/the-big-idea/
It would be really great if other languages could adopt this idea in their versioning system.