u/alexdmillerin r/Clojure • Recommends
Spec-ulation - Rich Hickey keynote at Conj link to this video
0:00 / 0:00
#clojure#clojure.spec#semanticversioning
Spec-ulation Keynote - Rich Hickey
ClojureTV
111K subscribers • 136 videos on Hallway
- Recommended by 14 people: 10 on Hacker News, 2 on Lobsters, 1 in engineering communities and 1 curated list.
- A classic. People kept recommending it from 2016 to 2024.
- Presented by Rich Hickey, creator of Clojure
- An opinion. It argues one side of a question engineers disagree on.
Advanced. Deep dive for people who know the field.
135K views9 years ago14 recommendations
Software designProgramming languagesSoftware architectureDesign patternsAPI design
Rich Hickey critiques semantic versioning and argues that software libraries should grow compatibly by requiring less and providing more.
The uploader added no description.Why it's here
14 people recommend thisWhat people say. Highly recommended as a thought-provoking critique of semantic versioning and a masterclass on API compatibility design.
Moments people linked to
sooheonon Hacker News • Recommends
On “Ok, let me explain: it’s going to be Angular 4.0”
This talk 1 by Rich Hickey seems more pertinent than ever. It's a contrarian stance on semver (which, almost as much as vc itself, is lauded as "the Right way" among developers). He definitely challenged my beliefs, it's likely to be worth your time too. link to this video
smackayon Hacker News • Recommends
On “APIs as infrastructure: future-proofing Stripe with versioning”
Whenever an idea about API versioning springs into mind it is always worthwhile to watch Rich Hickey's Spec-ulation talk, link to this video for an alternative view of the world.
finalfantasiaon Hacker News • Recommends
On “Thank You, Guido”
To anyone who's interested in this topic, I strongly recommend this talk from Rich Hickey about "giving something to somebody that they can use and making a commitment ": Spec-ulation ( link to this video )
programming-talkscurated list on GitHubRecommends
Under “Clojure”
Spec-ulation 01:16:23 by **Rich Hickey** (2016)
opvasgeron Hacker News • Recommends
On “Is Semantic Versioning an Anti-Pattern?”
This seems inspired and perhaps even duplicated from what Rich Hickey recently said about Semantic Versioning (found here: link to this video ) I really enjoy how the package-manager for the Elm programming language automates semantic versioning by diffing your apis based on the type system. I think a bit part of the real criticism of SEMVER stems from this inability to either automate it or use it correctly. Hickey's discussion of the subject obviously has a lot more great points to it, and even when I don't agree, I can't help to enjoy listening :)
gavinpcon Hacker News • Recommends
On “Software Engineering ≠ Computer Science (2009)”
…tive is to support comparisons between the signatures of a function at two different points and say, are these compatible? Is this a breaking change? You have to design for growth: make no assumptions about unspecified keys and always assume that later versions may return more than they used to. And so on. If you're a fan of semver, be warned. 0 link to this video link 1 link…
bad_useron Hacker News • Recommends
On “Project Jigsaw: Complete”
…, the movie. Also, no platform or language that I know of has gotten " modules " right, with Java being one of the platforms that has gotten closest to fixing the problem actually (by means of OSGi). To see why modules are still a big problem and why we won't have a fix for the foreseeable future, I invite you to watch this keynote by Rich Hickey: link to this video…
_54qbon Hacker News • Recommends
On “Be Nice and Write Stable Code”
A very interesting talk by Rich Hikey (creator of Clojure) on the topic: link to this video To summarize, any change that offers more (as in, more fields in the output) and/or requires less (more of the original parameters made optional) is non-breaking. Edit: Of course, this is all under the assumption that the semantics of methods should never change. Instead of changing semantics, he proposes to just create a new method with a new name.
ruudaon Hacker News • Recommends
On “What's next for SemVer”
For an interesting take on versioning, see the Spec-ulation keynote by Rich Hickey 1. It specifically touches upon SemVer being itself versioned. 1: link to this video
lvhon Hacker News • Recommends
On “Six Years of Professional Clojure”
…rantees nobody stomps on anyone else's feet. Spec/malli and friends tell you what to expect at those keys. You can sort of do the same thing in some other programming languages, but generally you're missing one of 1) typechecking 2) namespacing 3) convenience. 0: spec-ulation keynote from a few years ago does a good job explaining the tradeoffs; link to this video…
svieiraon Hacker News • Recommends
On “Ask HN: How to roll out an internal UI component library”
…quire less, never require more. If you want to remove from what you give or ask for more than you currently require then make a new version of the component (e. g. `components/Button/v2`). Plan for this (e. g. don't ship `components/Button`, ship `components/Button/v1`). Rich Hickey's Spec-ulation talk goes into the principles in some more detail: link to this video The reason for this is because your goal is to empower other teams to move faster. The minute that "keeping up to date with the UI library" requires any significant amount of attention you are draining any velocity you added. People will stop (either by not updating or by moving off the library).…
u/SOberhoffin r/Clojure • Mentions
What's the vision of Clojure Spec?
So when I first heard about Spec it sounded to me like a tool to verify data, presumably aimed at generating better error messages - a long standing complaint about Clojure.
However, when watching Rich Hickey's keynote error messages went almost unmentioned. Instead the focus was primarily on dependency hell. I've played with Spec for a few hours and I think I have a good idea regarding its capabilities. But I have no clue how Hickey plans on bringing this to bear on dependency management. Surely nobody will blindly trust a couple of property tests to tell when breaking changes occur in a new version?
u/oilshellin r/ProgrammingLanguages • Mentions
On “Following the Unix philosophy without getting left-pad - Daniel Sockwell”
…into the ideas of "relax a requirement" and "strengthen a promise", which is a much better way of thinking about compatibility and evolution than "I'm going to just break this thing in middle of my Jenga stack, and leave it a flaky versioning scheme and the package manager's version solver to tell people about it"
There's some of it in this talk: link to this video
Also some of it in the "Maybe Not" talk I believe…