5 ms·

The map is not the territory. Similarly, the semantic version number is not the API. Why are we relying on fallible humans to examine an API and encode an asse

by jt2190 8y ago

The map is not the territory. Similarly, the semantic version number is not the API. Why are we relying on fallible humans to examine an API and encode an assertion about its backwards compatibility into a number? Further, why are we then handing this (often dubious) assertion of backwards compatibility to machines to depend on? Can't we create a set of rules/tests that will actually execute the API to determine whether it's backwards compatible? Why aren't we doing that more?

steveklabnik 8y ago
There are tools to do this! Elm has the best-known implementation. However, the real reason is exactly why "compatibility" is not defined in the spec. It is really hard to pin this down, and possibly impossible. Machines can help humans check these kinds of things, but they still need humans in the end.
hluska 8y ago
Figuring out how to make a computer decide that one API is compatible with another would be bloody hard. I hesitate to say 'impossible' because today, I can subscribe to much of what I deemed impossible two decades ago. If you can figure this out, it would be an absolutely amazing feat. Best of luck!
- simplecomplex 8y ago
  Fully typed functional languages (Haskell for example) have this ability.
  - dagenix 8y ago
    I'm not sure that is correct. A function that takes no arguments and returns 2 and a function that takes no arguments and returns 3 both have the same type signature. I'm not super strong on the theoretical side of computer science, but, my understanding is that the only general solution to determining if our function returns 2 or 3 (or some other integer) is equivalent to the halting problem.
    - simplecomplex 8y ago
      Yes, obviously. The API is the same though. The interface.
      - dagenix 8y ago
        The signature of the interface is the same, yes. But, if the behavior changes it can still break users. I'm fully in support of strong typing and SemVer and all that good stuff - I was just responding to your comment which I interpreted to mean that a language like Haskell has a full solution to the problem of breakage, which I don't believe it does. It's certainly in a better position that many other language in the types of breakage it can detect just from the function signatures, however.
- badsectoracula 8y ago
  When it comes to native libraries at least, API laboratory has some tools to help: https://abi-laboratory.pro/ https://abi-laboratory.pro/ It isn't perfect, but it can largely show when things break (or might break). As an example here is the report for curl: https://abi-laboratory.pro/index.php?view=timeline&l=curl https://abi-laboratory.pro/index.php?view=timeline&l=curl
jt2190 8y ago
ruuda pointed out an excellent talk/rant by Rick Hickey about the difficulties with versioning: https://youtu.be/oyLBGkS5ICk?t=1792 https://youtu.be/oyLBGkS5ICk?t=1792 (edit: change video link to start right at the ranty part about Semantic Versioning)
- jt2190 8y ago
  Rich Hickey, creator of Clojure.
Retra 8y ago
For one, "API" isn't a simply definable thing. It can entail any number of performance constraints and tooling idiosyncrasies. That's why the first step of using SemVer is to declare a public API.
fwip 8y ago
Automatically differentiating between bug fixes and backwards-incompatible changes is, I believe, impossible.
- jayshua 8y ago
  In general, yes. But there are still some things you can do. The Elm package repository, for example, looks at the type signatures of all of the public functions. If there are no changes from the last version, it bumps the patch version. If functions have been added to the public API, it forces a minor version bump. If functions have been removed from the public API, or any type signatures have changed, it forces a major version change. I believe it lets the user force a major or minor bump for changes that don't appear in the type signature. It's been my experience that that is pretty rare though.
cbsmith 8y ago
Isn't such a problem at least as difficult a say, the halting problem? There's a lot of implicit contract involved in API's, particularly with languages that aren't theorem proving languages.

by jt2190 8y ago

steveklabnik 8y ago

There are tools to do this! Elm has the best-known implementation. However, the real reason is exactly why "compatibility" is not defined in the spec. It is really hard to pin this down, and possibly impossible. Machines can help humans check these kinds of things, but they still need humans in the end.

hluska 8y ago

Figuring out how to make a computer decide that one API is compatible with another would be bloody hard. I hesitate to say 'impossible' because today, I can subscribe to much of what I deemed impossible two decades ago. If you can figure this out, it would be an absolutely amazing feat. Best of luck!

simplecomplex 8y ago
Fully typed functional languages (Haskell for example) have this ability.
- dagenix 8y ago
  I'm not sure that is correct. A function that takes no arguments and returns 2 and a function that takes no arguments and returns 3 both have the same type signature. I'm not super strong on the theoretical side of computer science, but, my understanding is that the only general solution to determining if our function returns 2 or 3 (or some other integer) is equivalent to the halting problem.
  - simplecomplex 8y ago
    Yes, obviously. The API is the same though. The interface.
    - dagenix 8y ago
      The signature of the interface is the same, yes. But, if the behavior changes it can still break users. I'm fully in support of strong typing and SemVer and all that good stuff - I was just responding to your comment which I interpreted to mean that a language like Haskell has a full solution to the problem of breakage, which I don't believe it does. It's certainly in a better position that many other language in the types of breakage it can detect just from the function signatures, however.
badsectoracula 8y ago
When it comes to native libraries at least, API laboratory has some tools to help: https://abi-laboratory.pro/ https://abi-laboratory.pro/ It isn't perfect, but it can largely show when things break (or might break). As an example here is the report for curl: https://abi-laboratory.pro/index.php?view=timeline&l=curl https://abi-laboratory.pro/index.php?view=timeline&l=curl

jt2190 8y ago

ruuda pointed out an excellent talk/rant by Rick Hickey about the difficulties with versioning: https://youtu.be/oyLBGkS5ICk?t=1792 https://youtu.be/oyLBGkS5ICk?t=1792 (edit: change video link to start right at the ranty part about Semantic Versioning)

jt2190 8y ago
Rich Hickey, creator of Clojure.

Retra 8y ago

For one, "API" isn't a simply definable thing. It can entail any number of performance constraints and tooling idiosyncrasies. That's why the first step of using SemVer is to declare a public API.

fwip 8y ago

Automatically differentiating between bug fixes and backwards-incompatible changes is, I believe, impossible.

jayshua 8y ago
In general, yes. But there are still some things you can do. The Elm package repository, for example, looks at the type signatures of all of the public functions. If there are no changes from the last version, it bumps the patch version. If functions have been added to the public API, it forces a minor version bump. If functions have been removed from the public API, or any type signatures have changed, it forces a major version change. I believe it lets the user force a major or minor bump for changes that don't appear in the type signature. It's been my experience that that is pretty rare though.

cbsmith 8y ago

Isn't such a problem at least as difficult a say, the halting problem? There's a lot of implicit contract involved in API's, particularly with languages that aren't theorem proving languages.