Be Nice and Write Stable Code • Hacker News Board

Re: Be Nice and Write Stable Code

#11

Post by pvorb » Mon, Jul 23, 2018, 11:41 PM UTC

nemothekid wrote: post #10

laurence-myers wrote: post #5

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/r…

> SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.

A problem with SemVer I often see is that it's unclear whether a project adheres to it. You just can't assume every project having x.y.z version numbers uses semantic versioning.

Re: Be Nice and Write Stable Code

#12

Post by timwis » Tue, Jul 24, 2018, 12:08 AM UTC

It would be helpful to mention that these guidelines -- and semver generally -- don't really apply to applications from what I've read. Versioning applications still feels like a gut feeling.

Re: Be Nice and Write Stable Code

#13

Post by sramam » Tue, Jul 24, 2018, 12:11 AM UTC

laurence-myers wrote: post #5

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/r…

While the distinction of construct vs contract is subtle, improved tooling will eventually elevate the "construct" to a contract.

semver needs to be combined with a package manager and strong version locking semantics for it to be useful.

Both npm and yarn in the node eco-system certainly provide this - with any remaining kinks are being ironed out fast.

Using micro-modules as dependencies is a rather pleasant experience in node/js - especially when the dependencies follow semver. This is even more true of popular modules, where authors take their versioning responsibility seriously.

I regularly use automated version updates (npm-check -u [1]/ npm audit --fix [2]). Coupled with good test coverage of my code, I've been really happy.

[1] https://www.npmjs.com/package/npm-check [2] https://docs.npmjs.com/getting-started/running-a-security-au...

Re: Be Nice and Write Stable Code

#14

Post by Swizec » Tue, Jul 24, 2018, 12:19 AM UTC

gregmac wrote: post #9

CoryG89 wrote: post #4

Earlier quoted context omitted.

While it is a good example, you could also use the same example and conclude that the problem was inadequate tests. SemVer is great, but you can't count on dependencies that you do not control actually adhering to it, either intentionally or unintentionally. The only thing that could have prevented something like this for sure was mentioned: > And while nothing in our early testing sent messages larger than 256k, the…

While it's easy to say, how far do you go? Do you test every bit of every upstream library you use? The ideal is probably yes, but the reality is this rarely happens. Even with a test, you may not find this. In the IOException example, the author calls out why: > When we upgraded, all our tests passed (because our test fixtures emulated the old behavior and our network was not unstable enough to trigger bad condition…

> While it's easy to say, how far do you go? Do you test every bit of every upstream library you use? The ideal is probably yes, but the reality is this rarely happens.

It depends. I have a friend who used to work on banking systems. They had full test coverage of every dependency. Even standard lib functions and language features.

One time they found a bug in the md5 implementation in a minor version of a popular database.

Re: Be Nice and Write Stable Code

#15

Post by h8liu » Tue, Jul 24, 2018, 12:25 AM UTC

fwiw, I maintain a website called smallrepo (https://smallrepo.com). It builds go language code together, and maintains an always buildable commit set as a "super repo". If you sync to smallrepo (rather than using go get), it can shield you from many unexpected build breakages.

Re: Be Nice and Write Stable Code

#16

Post by hackernoon » Tue, Jul 24, 2018, 12:25 AM UTC

Argh! I love the deprecation example! How elegant! How did I never think of this (or why did I never think to ask)!

edit: pasted here –

  func ListItems(query Query) Items {
    ListItemsWithLimit(query, 0, 0)
  }

  func ListItemsWithLimit(query Query, limit int, offset int) Items {
  // ...
  }

Re: Be Nice and Write Stable Code

#17

Post by hinkley » Tue, Jul 24, 2018, 12:28 AM UTC

nemothekid wrote: post #10

laurence-myers wrote: post #5

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/r…

> SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.

I haven’t figured out how to implement this, but the key observation is that Semver is trying to delineate degrees of substitutability (LSP).

I think the right solution here is to build version numbers off of your black box tests.

The devil is in the details though. What’s a change to the tests mean exactly? Adding new tests is probably a patch release. Modifying tests demands at least a minor version number, but what makes it a major version number? Deleting tests probably qualifies. Removing assertions probably does too.

But now what if the author is bad at tests too? Can I substitute my own? (I could do that right now for regression testing, and in fact I do occasionally for interdepartmental issues).

Re: Be Nice and Write Stable Code

#18

Post by hinkley » Tue, Jul 24, 2018, 12:30 AM UTC

pvorb wrote: post #11

nemothekid wrote: post #10

Earlier quoted context omitted.

> SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.

A problem with SemVer I often see is that it's unclear whether a project adheres to it. You just can't assume every project having x.y.z version numbers uses semantic versioning.

If the version number is less than 3.1, odds are very good they don’t.

And I just described 80% of the node module ecosystem...

Re: Be Nice and Write Stable Code

#19

Post by azernik » Tue, Jul 24, 2018, 12:35 AM UTC

laurence-myers wrote: post #5

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it. One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/r…

Contracts are social constructs too.

Re: Be Nice and Write Stable Code

#20

Post by denkmoon » Tue, Jul 24, 2018, 12:44 AM UTC

That headline is a summary of all the things I try to do but fail.