Many examples of decade+ compatibility: - Unix APIs - Java - HTML - Clojure - Emacs I added the notable example of Emacs just because ;-) Such a great talk from Rich! As always. Thank you man and thank you to the Clojure community as a whole! It's such a great pleasure and an honor to be in this community. I owe you so much!
3 years and only 27 comments. Seems like the future will look at this video just like we look at old Lisp ideas that we adopt now (if statements, garbage collection).
1:06:40 What I don't quite understand is that versions of software is a way of letting someone continue to use `foo`. If your on 1.0.0 and I release 2.0.0, you can still enjoy your holiday in Bermuda right? Just update when you see fit.
An instant classic. Rich, always gives well designed (see what i did there) talks tackling big ideas related to things we as an industry aren't questioning and should be.
Changes in packages using Semantic Versioning don't cascade up as far as I can tell. Even when they are breaking they do not. In that case packages that use them _directly_ need to have a new release that specify they are also compatible with the new version if they want their users to be able to use that new version. Packages that depend indirectly do not need to care. (And if they do, they actually depend directly and should define themselves as such.) Hence no cascade. Even in case of breaking changes, which should be rare, the only packages that might want to update (don't need to) are those that directly use it.
One thing I wonder about regarding maven central being immutable is: if a package is found to straight up malware, is it removed, making maven not immutable after all? More commonly a package is found to be insecure, and it seems like we keep providing it for backwards compatibility, maybe with a big warning. Then again nothing is perfectly secure I suppose.
Yep. I ran into the same problem as well. What if I have an app which has multiple REST and WebSocket APIs, and I'd need to change some of them? The only approach that seems to make sense is to give each separate API its own version number even if they operate on the same stuff in the backend. In the end for things to be uniform I'd have to version every thing which serves as a dependency. Perhaps the point is that each module or component that gets reused either via network as a library needs a version of its own even if that versioning doesn't imply what semver implies i.e., the level of risk of breakage when for upgrading. As far as treating a spec change as a completely new thing that's what the Go people are doing. Yes, they use semver but the point here is that a new major version is forced to have a different package name. That allows using multiple major versions in parallel for easier transitions and makes sure that the compile breaks too if you try to use the wrong version's interface.
Postel's law: "TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others."
Wow! An amazing talk. I will be watching it again. Very inspiring. Speaking of versioning,,, didn't Rich some time ago talk about version control at the function level? What happened to that?
What I don't understand is: there's adding, removing but what about altering the behavior within a function? The output becomes different due to the implementation? I feel like that has not been covered, and won't as easily covered by the system he imagines that would check dependencies automagically.
5 років тому+2
Maybe I understand wrong, but I think whats he's saying is that if you need to change a function (foo1), then you create a new funtion (foo2). Because if you change foo1 you break everything linked with it. So in this case there's a bunch of people using foo1 and foo2 at the same time and nothing breaks.
He did mention that Functional programming; and that means pure functions. You will have to understand what that means first. Also, you just have to think about Java libraries and how they don't break. Running java code you wrote 20 years ago will still run today with Java 8. They did not break the old methods; they only introduced new methods; either by new classes or new packages.
Many examples of decade+ compatibility:
- Unix APIs
- Java
- HTML
- Clojure
- Emacs
I added the notable example of Emacs just because ;-)
Such a great talk from Rich! As always.
Thank you man and thank you to the Clojure community as a whole! It's such a great pleasure and an honor to be in this community. I owe you so much!
Add IBM mainframe (and things like JCL, Cobol, CICS, IMS..) to the list.. compatibility for 30, 40, 50 years.
Glad somebody prominent and influential is able to see and say this.
3 years and only 27 comments. Seems like the future will look at this video just like we look at old Lisp ideas that we adopt now (if statements, garbage collection).
1:06:40 What I don't quite understand is that versions of software is a way of letting someone continue to use `foo`. If your on 1.0.0 and I release 2.0.0, you can still enjoy your holiday in Bermuda right? Just update when you see fit.
An instant classic. Rich, always gives well designed (see what i did there) talks tackling big ideas related to things we as an industry aren't questioning and should be.
Changes in packages using Semantic Versioning don't cascade up as far as I can tell. Even when they are breaking they do not. In that case packages that use them _directly_ need to have a new release that specify they are also compatible with the new version if they want their users to be able to use that new version. Packages that depend indirectly do not need to care. (And if they do, they actually depend directly and should define themselves as such.) Hence no cascade. Even in case of breaking changes, which should be rare, the only packages that might want to update (don't need to) are those that directly use it.
Just wow.
1:07:52 - I am afraid of other people. Genius.
One thing I wonder about regarding maven central being immutable is: if a package is found to straight up malware, is it removed, making maven not immutable after all?
More commonly a package is found to be insecure, and it seems like we keep providing it for backwards compatibility, maybe with a big warning. Then again nothing is perfectly secure I suppose.
Is there a name for this Accretion, Relaxation, Fixation paradigm? Like A.R.F. versioning or growth-based development?
Yep. I ran into the same problem as well. What if I have an app which has multiple REST and WebSocket APIs, and I'd need to change some of them? The only approach that seems to make sense is to give each separate API its own version number even if they operate on the same stuff in the backend. In the end for things to be uniform I'd have to version every thing which serves as a dependency.
Perhaps the point is that each module or component that gets reused either via network as a library needs a version of its own even if that versioning doesn't imply what semver implies i.e., the level of risk of breakage when for upgrading.
As far as treating a spec change as a completely new thing that's what the Go people are doing. Yes, they use semver but the point here is that a new major version is forced to have a different package name. That allows using multiple major versions in parallel for easier transitions and makes sure that the compile breaks too if you try to use the wrong version's interface.
Postel's law: "TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others."
Wow! An amazing talk. I will be watching it again. Very inspiring.
Speaking of versioning,,, didn't Rich some time ago talk about version control at the function level? What happened to that?
What I don't understand is: there's adding, removing but what about altering the behavior within a function? The output becomes different due to the implementation? I feel like that has not been covered, and won't as easily covered by the system he imagines that would check dependencies automagically.
Maybe I understand wrong, but I think whats he's saying is that if you need to change a function (foo1), then you create a new funtion (foo2). Because if you change foo1 you break everything linked with it. So in this case there's a bunch of people using foo1 and foo2 at the same time and nothing breaks.
He did mention that Functional programming; and that means pure functions.
You will have to understand what that means first.
Also, you just have to think about Java libraries and how they don't break. Running java code you wrote 20 years ago will still run today with Java 8. They did not break the old methods; they only introduced new methods; either by new classes or new packages.
If you need alter, than you are removing the previous, that means you need a new function
Sorry for the necro, but that's one of the things he talks about, basically calling something different the same name.