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 -
Replying to @keleshev
That's what I called maintaining "local forks". But soon, you might be maintaining forks of every library that use the forked library... entire universes of libraries. And if everyone does it, soon there are multiple conflicting such universes. Version hell, squared.
1 reply 0 retweets 1 like
Or then again, you might rely on a single active vendor to curate an entire ecosystem of quality libraries that evolve fast with user needs. Your JaneSt savior. Hopefully though they accept your patches very fast... or now you have to fork their entire ecosystem.
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!