Either bifunctor | Hacker News Reader

Either bifunctor

blog.ploeh.dk

27 pointsghuntley8 comments

George Wilson and some other Aussies in the Haskell/Scala community give some excellent talks on this kind of stuff, here's one on some more members of the Functor family that are cool:

https://www.youtube.com/watch?v=JZPXzJ5tp9w

And if you just want to relearn the BiFunctor stuff in that post in a language with cleaner, conciser syntax (it's Haskell):

https://www.youtube.com/watch?v=JZPXzJ5tp9w&t=304

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.

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.

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.

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.

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

That still seems like a breaking change to me, as kdwxg already observed https://news.ycombinator.com/item?id=18855734

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.

Reply on news.ycombinator.com