Spec-ulation – Rich Hickey [video]
youtube.com
Spec-ulation – Rich Hickey [video]
1–10 of 74 posts
Re: Spec-ulation – Rich Hickey [video]
#2This is a worthwhile talk, albeit a bit too long. In this talk RH provides a framework to think about libraries, how they change over time and how we should be communicating those changes. He proposes a way forward in which the changes are communicated in a way that can be dealt with programmatically, a much better framework than versioning schemes (semver gets a beating in this talk!).
Re: Spec-ulation – Rich Hickey [video]
#3As I understand it, one of the original problems Go was designed to solve was long compile times at Google.
This talk is fascinating and points out a possible solution space for real world problems in giant codebases and build infrastructures.
What if 80% of your dependency graph can be identified as dead code paths at build time and not require you to actually take dependencies on all that dead code?
Re: Spec-ulation – Rich Hickey [video]
#4This is a worthwhile talk, albeit a bit too long. In this talk RH provides a framework to think about libraries, how they change over time and how we should be communicating those changes. He proposes a way forward in which the changes are communicated in a way that can be dealt with programmatically, a much better framework than versioning schemes (semver gets a beating in this talk!).
Video is a high-bandwidth way of delivering information at a low bandwidth. But try watching tech videos at 1.5 speed, it makes them much more engaging. Also works for ponderous anime.
Re: Spec-ulation – Rich Hickey [video]
#5As I understand it, one of the original problems Go was designed to solve was long compile times at Google. This talk is fascinating and points out a possible solution space for real world problems in giant codebases and build infrastructures. What if 80% of your dependency graph can be identified as dead code paths at build time and not require you to actually take dependencies on all that dead code?
Sadly then Go went and shot themselves in the foot. Originally (I assumed this hasn't changed), you specified dependencies via git URLs. Sounds great, but then they went and said every dependency always used the head of master. So now you're in the horrific situation of your deps suddenly changing whenever your build decides to pull the latest from the git repos.
(Note: I don't use go, but this was the situation about 3 years ago when I last looked).
Re: Spec-ulation – Rich Hickey [video]
#6This is a worthwhile talk, albeit a bit too long. In this talk RH provides a framework to think about libraries, how they change over time and how we should be communicating those changes. He proposes a way forward in which the changes are communicated in a way that can be dealt with programmatically, a much better framework than versioning schemes (semver gets a beating in this talk!).
Video is a high-bandwidth way of delivering information at a low bandwidth. But try watching tech videos at 1.5 speed, it makes them much more engaging. Also works for ponderous anime.
Hah! Ponderous anime. I remember watching some shows at 4x speed. I'm not sure whether it's anime that introduced me to sped up video, but subtitles are a great help when watching videos at faster than 1x speed.
Re: Spec-ulation – Rich Hickey [video]
#7As I understand it, one of the original problems Go was designed to solve was long compile times at Google. This talk is fascinating and points out a possible solution space for real world problems in giant codebases and build infrastructures. What if 80% of your dependency graph can be identified as dead code paths at build time and not require you to actually take dependencies on all that dead code?
Sadly then Go went and shot themselves in the foot. Originally (I assumed this hasn't changed), you specified dependencies via git URLs. Sounds great, but then they went and said every dependency always used the head of master. So now you're in the horrific situation of your deps suddenly changing whenever your build decides to pull the latest from the git repos. (Note: I don't use go, but this was the situation abou…
One of the things Rich talks about in this talk is semantic versioning is fundamentally broken. In fact any versioning scheme that allows removal is broken. In some sense this model encourages Rich's ideas better - since you can't version directly, you either make a new library or maintain backwards compatibility.
Of course the current 'go get' model has a lot of downsides, e.g. Non deterministic builds. I still think it's worth considering building on, rather than trying to fix semver. All that's really missing is a stable monotonic identifier - something as simple as git tree height may be enough.
Re: Spec-ulation – Rich Hickey [video]
#8Earlier quoted context omitted.
Sadly then Go went and shot themselves in the foot. Originally (I assumed this hasn't changed), you specified dependencies via git URLs. Sounds great, but then they went and said every dependency always used the head of master. So now you're in the horrific situation of your deps suddenly changing whenever your build decides to pull the latest from the git repos. (Note: I don't use go, but this was the situation abou…
One of the things Rich talks about in this talk is semantic versioning is fundamentally broken. In fact any versioning scheme that allows removal is broken. In some sense this model encourages Rich's ideas better - since you can't version directly, you either make a new library or maintain backwards compatibility. Of course the current 'go get' model has a lot of downsides, e.g. Non deterministic builds. I still thin…
Absolutely, I think the "perfect world" would be adopting some of the ideas Rich proposes but adding (git url + sha) as the dependency management system.
Of course for that to work well you'd also need to protect yourself from people deleting their git hub repos, or rewriting git history.
Re: Spec-ulation – Rich Hickey [video]
#9The whole section on "just change the name" fits interestingly in with the way that the kernel is developed. They have been rather strict on this for a long time. A function released to the wild stays. Changes to it require a new function.
Re: Spec-ulation – Rich Hickey [video]
#10> Logic systems don't have "And nothing else will ever be true!".
Uuh. Closed world assumption? Everything that is not true is false. Most logic systems do have this. Prologs (not a logic system I know) cut operator even turns this statement into an operation.
I feel like Rich really gets it wrong this time. His request to support all the abominations that you have ever written and keep them compatible with recent changes, might work if you have people pay for using your library and a company behind it. But doesn't fly if you maintain these things out of goodwill in your anyhow limited spare time.
The best example of this style going horribly wrong are the linux kernel file system modules. Different api versions all in use at the same time by the same code with no clear documentation on what to use when.
It's also ironic that the examples he uses to make his point namely, Unix APIs, Java and HTML, are horrible to work with especially because they either never developed good API's (looking at you unix poll), or they, like browsers, have become so bloated that nobody want to touch them with a ten foot pole. One of the reasons why it takes so long for browser standards to be adopted is that they have to be integrated with all the cruft that is accumulating there for almost three decades now.
"Man browsers are so reliable and bug free and it's great that the new standards like flexbox get widespread adoption quickly, but I just wish the website I made for my dog in 1992 was supported better." -no one ever.
Combinatorial complexity is not your friend.
I'd rather have people throw away stuff in a new major release, maybe give me some time to update like sqlite or python do, and then have me migrate to a new system where they have less maintenance cost and I profit from more consistency and reliability.
I think that Joe Armstrong has a better take on this. https://www.youtube.com/watch?v=lKXe3HUG2l4
Also even though I'm a fulltime Clojure dev, I would take Elms semantic versioning that is guaranteed through static type analysis anytime over spec's "we probably grew it in a consistent way" handwaving.