Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Nice and Write Stable Code

technosophos.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: Be Nice and Write Stable Code

#31

Post by lbm »

hinkley wrote: post #18
pvorb wrote: post #11

Earlier quoted context omitted.

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...

Not necessarily. There are plenty of projects in their infancy that follow semver correctly. I'd argue that a project with a high major number is more likely to be indicative of improper usage.

Re: Be Nice and Write Stable Code

#32

Post by ShaneWilton »

User23 wrote: post #30
QuinnWilton wrote: post #21

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's be…

Is API compatibility computable in general? My instinct is that it is, but I’ve never seen a theorem.

I'd imagine it isn't, at least depending on how you define API compatibility, and whether you're only looking at the API interfaces. Imagine two versions of a library that implement the function "add".

  Version 1:
  add Int -> Int -> Int
  add x y = x + y

  Version 2:
  add Int -> Int -> Int
  add x y = x * y
Both versions expose the same API interface, but the functions that conform to that interface are semantically different. A stronger type system could probably differentiate between the two functions, but I doubt you could generally compute whether both functions implement the same behavior.

Perhaps with some sort of functional extensionality you'd be able to compute compatibility perfectly, but I can't imagine that ever being feasible in practice.

That being said, what Elm does offer is still a huge improvement over humans trying to guess whether they made any breaking changes :)

Re: Be Nice and Write Stable Code

#33

Post by int_19h »

> Stop trying to justify your refactoring with the "public but internal" argument. If the language spec says it's public, it's public. Your intentions have nothing to do with it.

This is so wrong. APIs are for people, not tools, so intent is primary. When tools are not expressive enough to capture and enforce intent, you document it, but it's still primary. Someone using a "public" API that clearly says "for internal use only" is no different from a person that uses workarounds like reflection or direct memory access, and there is no obligation to keep things working for the.

Re: Be Nice and Write Stable Code

#34

Post by jniedrauer »

SamuelAdams wrote: post #29
hackernoon wrote: post #16

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 { // ... }

Wouldn't it be easier to write optional variables, allowing you to keep the same method name? This results in cleaner code that doesn't break existing usage. For example: func ListItems(query Query, limit int = 0, offset int = 0) Items { // .... }

This only works in languages that support optional variables or overloading.

Re: Be Nice and Write Stable Code

#35

Post by toast0 »

ShaneWilton wrote: post #32
User23 wrote: post #30

Earlier quoted context omitted.

Is API compatibility computable in general? My instinct is that it is, but I’ve never seen a theorem.

I'd imagine it isn't, at least depending on how you define API compatibility, and whether you're only looking at the API interfaces. Imagine two versions of a library that implement the function "add". Version 1: add Int -> Int -> Int add x y = x + y Version 2: add Int -> Int -> Int add x y = x * y Both versions expose the same API interface, but the functions that conform to that interface are semantically different…

I don't think 'does it work exactly the same' isn't necessarily the right question, given there are expected to be bug fixes which may change the behavior in some functions.

Re: Be Nice and Write Stable Code

#36

Post by flukus »

QuinnWilton wrote: post #21

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's be…

This seems like something solved decades ago with c header files, they're easy to do a diff on and the only false negative is from adding a function. Even that would be fine if you weren't export raw structs.

It seems like we gave up simple ways to do stuff like this because we hated header files and moved to tools like java and c# that eschewed them. Then they got reinvented and renamed to interfaces and we've come up with all sorts of other complicated tools (elm-package, mocking, IoC) just to recreate the functionality we lost in header files.

Re: Be Nice and Write Stable Code

#37

Post by bgorman »

int_19h wrote: post #33

> Stop trying to justify your refactoring with the "public but internal" argument. If the language spec says it's public, it's public. Your intentions have nothing to do with it. This is so wrong. APIs are for people, not tools, so intent is primary. When tools are not expressive enough to capture and enforce intent, you document it, but it's still primary. Someone using a "public" API that clearly says "for internal…

Making an API public means that people can do whatever they want with it. If you are not sure if you want to allow the API in the future it should not be public. People will always look to do the laziest thing possible which might mean hooking into your "public internal API". Then you will never be able to change it and you will have to maintain it forever.

Re: Be Nice and Write Stable Code

#38

Post by beefsack »

User23 wrote: post #30
QuinnWilton wrote: post #21

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's be…

Is API compatibility computable in general? My instinct is that it is, but I’ve never seen a theorem.

Only as far as the type system supports, but I feel like constraining the minimum version unit to increment is far better than doing nothing. Disallowing incrementing the patch version when the types of existing API changes is great.

Re: Be Nice and Write Stable Code

#39

Post by p1necone »

int_19h wrote: post #33

> Stop trying to justify your refactoring with the "public but internal" argument. If the language spec says it's public, it's public. Your intentions have nothing to do with it. This is so wrong. APIs are for people, not tools, so intent is primary. When tools are not expressive enough to capture and enforce intent, you document it, but it's still primary. Someone using a "public" API that clearly says "for internal…

What reason would you have for publishing something in a public API if it actually is for "internal use only".

Re: Be Nice and Write Stable Code

#40

Post by peterwwillis »

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've found that the golden rule of "everyone is lying to you" works well enough. Assume that every change will be a breaking change. Test everything, verify everything, and then continue to test and verify when it's in production.

I've never found standards to be all that standard.

Post reply on HN