6 ms·

These language features build using the type system are useful, except when you're using them in your API. In that case, they break down as changing the API bec

These language features build using the type system are useful, except when you're using them in your API. In that case, they break down as changing the API becomes problematic. A simple example is to change a `void derp(Nullable<SomeType> parameter)` into `void derp(SomeType parameter)`. This is a breaking change, while on the consumer side it is not a breaking change.

mixedCase 8y ago
Those changes can be automated. That's one good idea for tooling right there. I know Elm's package manager already detects breaking changes that can be caught through the type system, so it sounds like it wouldn't be hard to handle an automated migration that keeps things compiling (by just wrapping inside of a Maybe on call) until you have time to simplify the code.
- sharpercoder 8y ago
  True, but the current state of tooling does not allow for these kind of changes in most published public API's. Even now where e.g. the .NET Roslyn API allows for this, I don;t see it happen often.
tome 8y ago
I'm not sure what you mean. derp presumably used to check for null. This implies that 1. outside derp the callers need to change, and 2. inside derp there's a redundant null-check that needs to be deleted.
- gowld 8y ago
  In a more dynamic less-statically-typed language, when you change the semantics of a method, it doesn't break any clients or call patterns who are fortunate enough to be compatible with both versions of the semantics, so changing those clients (to update types) is useless work. Assuming you have 100% test coverage (which isn't any harder in static-vs-less-static languages, if all your tests are functional tests per YAGNI), your test suite is sufficent to tell you that you have callers that are broken by the change and need to be updated. Then it's a simple matter of finding and updatig the broken callers, which is easy because dynamic language programs are short and it is easy to know the whole program, and dynamic languages are flexible so it's quick and easy to run experiments to find the bug. Poe'd? Maybe. I tried to represent the dynamic-language side as charitably as possible. It is a different "ethical" system than static languages
  - tome 8y ago
    That still seems like a breaking change to me, as kdwxg already observed https://news.ycombinator.com/item?id=18855734 https://news.ycombinator.com/item?id=18855734
kgwxd 8y ago
If the semantics of the API change to no longer expect null, it's a breaking change weather a type system is there to catch it or not.

mixedCase 8y ago

Those changes can be automated. That's one good idea for tooling right there. I know Elm's package manager already detects breaking changes that can be caught through the type system, so it sounds like it wouldn't be hard to handle an automated migration that keeps things compiling (by just wrapping inside of a Maybe on call) until you have time to simplify the code.

sharpercoder 8y ago
True, but the current state of tooling does not allow for these kind of changes in most published public API's. Even now where e.g. the .NET Roslyn API allows for this, I don;t see it happen often.

tome 8y ago

I'm not sure what you mean. derp presumably used to check for null. This implies that 1. outside derp the callers need to change, and 2. inside derp there's a redundant null-check that needs to be deleted.

gowld 8y ago
In a more dynamic less-statically-typed language, when you change the semantics of a method, it doesn't break any clients or call patterns who are fortunate enough to be compatible with both versions of the semantics, so changing those clients (to update types) is useless work. Assuming you have 100% test coverage (which isn't any harder in static-vs-less-static languages, if all your tests are functional tests per YAGNI), your test suite is sufficent to tell you that you have callers that are broken by the change and need to be updated. Then it's a simple matter of finding and updatig the broken callers, which is easy because dynamic language programs are short and it is easy to know the whole program, and dynamic languages are flexible so it's quick and easy to run experiments to find the bug. Poe'd? Maybe. I tried to represent the dynamic-language side as charitably as possible. It is a different "ethical" system than static languages
- tome 8y ago
  That still seems like a breaking change to me, as kdwxg already observed https://news.ycombinator.com/item?id=18855734 https://news.ycombinator.com/item?id=18855734

kgwxd 8y ago

If the semantics of the API change to no longer expect null, it's a breaking change weather a type system is there to catch it or not.