Live data from Hacker News

Spec-ulation – Rich Hickey [video]

youtube.com

71–74 of 74 posts

Re: Spec-ulation – Rich Hickey [video]

#71

Earlier quoted context omitted.

Who says you have to maintain old code? We're talking about simply not deleting it and establishing a discrete semantic for the new version as truthfully, a new version is new content which demands a new name to accurately and precisely describe it. If it didn't it would be like saying different content doesn't produce a different hash.

Except that naming things is one of the hard problems. I don't see why a major version bump can't be considered a different library. I guess you can use version numbers in the name instead, since this talk is specifically targeting maven artifacts.

Hickey's other talk says hard is relative, and I happen to agree, especially when it comes to naming. The question is to what degree of exactness you can confirm what exists (in problems). That is a function of your degree of truthfulness. So it's "hard" only in the sense it's hard to approach 100% truthfulness. However, I have observed that one doesn't need 100%, one needs to be beyond a certain threshold of effective sufficiency. And according to human history, special, rare individuals are born who do exceed that threshold.

Re: Spec-ulation – Rich Hickey [video]

#72

Earlier quoted context omitted.

Who says you have to maintain old code? We're talking about simply not deleting it and establishing a discrete semantic for the new version as truthfully, a new version is new content which demands a new name to accurately and precisely describe it. If it didn't it would be like saying different content doesn't produce a different hash.

You're right, there is no obligation to maintain it. I think that misses the point though. The value in keeping the code is to allow the end user to continue to enjoy improvements in parts of the library that don't have breaking changes without upgrading those that do. You could continue to have security patches installed, for example. That value is much less when you don't do basic maintenance implement bug fixes an…

Unless I'm missing something… the answer to that problem is to (a) factor the code sufficiently to then (b) create an abstraction (interface) that backs out the concrete implementation to the specifically desired version/functionality.

Re: Spec-ulation – Rich Hickey [video]

#73
Ever require the services of a hacker with discretion and top servicing, i implore you to try your very best to hire only professionals. It will increase your chances of getting your job completed. i was able to hire the services of an elite, asides the fact that i was provided a permanent solution to the service that was rendered me but gave a very efficient customer experience. gmail- pauleta.steelbreaker. M-+19283233115 (text only)

Re: Spec-ulation – Rich Hickey [video]

#74

This is a very thick talk, one Rich's best ever IMHO. The first point is how we talk about 'change' in software, to center around what things 'provide' and 'require'. Breaking changes are changes that cause code to require more or provide less. Never do that, never need to do that. Good changes are in the realm of providing more or requiring less. There is a detailed discussion about the different 'levels' - from fun…

I found value in dissecting the different levels of change. For the sake of sanity though, we should do breaking changes. Breaking changes exist because we have limited capacity as individuals and an industry to maintain software. This is especially true for infrastructure that is supported by (limited) corporate sponsorship and volunteers. Breaking changes limit our window of focus to two or three snapshots of code,…

Additionally there are safer, usually reasonable, ways to deal with what would otherwise be breaking changes. Give the changed functionality a different name, create a new namespace/module without the removed functionality, or create a new library if you have introduced something fundamentally different (e.g., w.r.t. how you interact with it). That way your users can choose to refactor their code to use the change, rather than discover their expectations no longer match reality when they upgrade.
Post reply on HN