ClojureTV
10 HN recommenders · recommended in 15 months, 2016–2024
1:16:14 · 136K views · Dec 2, 2016
Rich Hickey's keynote on software versioning, arguing that breaking changes are the real problem and that libraries should only grow by providing more and requiring less. It critiques semantic versioning and ties into Clojure spec.
HN returns to it in every versioning and API stability debate as a challenging, contrarian talk worth watching.
20 comments from Hacker News
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. this video
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 ( this video )
Whenever an idea about API versioning springs into mind it is always worthwhile to watch Rich Hickey's Spec-ulation talk, this video for an alternative view of the world.
This is all excellent, and I'll add one more sub point to "Avoid becoming a bottleneck at all costs": - Be backwards compatible. If you need to break backwards compatibility, advertise it widely and put your people towards the migration. Otherwise, only expand the abilities of components, never remove them and only require 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: 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).
> I have a hard time being too impressed because more modern languages are doing this out of the gates The problem with Java is that it's an already established and very popular platform and it's been so for the past decade at least. When starting from scratch, it's easy to just throw it all away and start fresh, it's easy to fix mistakes that were made in the past. The irony though is that we still have a hard time learning from history. Just look at Go. Sometimes this industry feels like Groundhog Day, 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: this video