The smallest type change make entire APIs incompatible, hence a lot of pain in OCaml: forced upgrades, forced downgrades, crazy version update schedules, extra forks, reluctance to fix bad early choices that would break compatibility, etc. Types DIRECTLY cause library badness.
-
Show this thread
-
Worse: the opacity of modules and parametricity mean that you can't use reflection to hot patch a module until it's been fixed upstream. You have to go through a whole lot extra pain, including local or global forks and/or cajoling maintainers, to get a real fix in.
2 replies 0 retweets 4 likesShow this thread -
And you can't use introspection to access unpublished interfaces while you lobby the author to publish them or offer primitives you need even though he "doesn't see why" it matters. You could use copy/paste + obj.magic, but it's even less safe or maintainable than introspection.
3 replies 0 retweets 7 likesShow this thread -
Replying to @Ngnghm
One thing that helps, in this case, is vendoring dependencies. You can make a small local patch to unblock you from progress, then try to resolve upstream at a different pace. Though, vendoring has its own trade-offs.
2 replies 0 retweets 1 like -
Otherwise, I agree. It's also quite a special hell that adding a function to a module is a breaking change because of `include`.
1 reply 0 retweets 2 likes
Here's to Functional Programmers pissing on "Object Oriented" programming. Their modules aren't classes, can't inherit methods, have default methods, or otherwise allow for incremental programming that would make it not a breaking change to add a function to an interface.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Read my blog!