3 ms·
Always feels like you're in a dysfunctional place when you have to program this defensively. I had an acquaintance who was writing library code for a few dozen
by _cenw 2y ago
Always feels like you're in a dysfunctional place when you have to program this defensively.
I had an acquaintance who was writing library code for a few dozen data engineers in python, and she had to resort to locking down private methods by checking the call stack after engineers repeatedly got hold of private objects, or objects that are only there sometimes (e.g. when not running clustered).
I adopted a similar stance of "you can't abuse what you can't access" in platform engineering too, but I am not the greatest fan of having to do this in the first place. But the alternative always seems to be that someone will change the scope of what's supported by you for you, as soon as someone builds a dependency.
- JonChesterfield 2y ago"I monkey patched your code and now it doesn't work" would be a deeply irritating bug report. It's directly equivalent to "I forked your codebase, changed the text files, and now it doesn't work".
- pjc50 2y agoFor some reason, recipe bloggers get "I substituted this ingredient with <completely different thing> and got something bad" a lot.
- bluGill 2y agoAt least there it is useful sharing - it warns others from the substitution. There is also "I substituted this ingredient with <completely different thing> and got something great" which I see happen a lot more often. In cooking it is common to be missing some ingredient and so you want some substitution if it will turn out.
- _cenw 2y agoThis was the kind of place where data engineers would ask an LLM for config options (for the framework that was built internally) and then complain they didn't work. No idea how these people got by and even made more than the person writing the framework.
- dangsux 2y ago[dead]
- breckenedge 2y agoWere these leaky abstractions built on top of other libs?
- _cenw 2y agoDatabricks, so it's hard to avoid.
- bluGill 2y agoThere are multiple reasons to want this, some are dysfunction, but others are useful. Every time you use a function from elsewhere you become coupled to that function and how it works. That means that if however maintains that function wants to make a change someone must be responsible for keeping your code working with the change. (this can be handled many ways - all too often this customers get mad because a feature doesn't work right and they can't complain to anyone). If you put control over who can use what you can prevent a lot of issues. In a compiled system changing an interface means more code to recompile, so control over who can use what reduces build times. If you know some function is for internal use in one place you won't spend time designing a good interface. If the function is for use by everyone you should spend more time making it a nice interface that is easy to use correctly. Every once in a while I design something for internal use like that, but someone external discovers it is useful and they are using a bad interface that meets my needs but isn't quite right for them.