LegionMammal978
2 months ago
The author argues that constraints (or a lack of features) are very often imposed in order to provide certain guarantees (even if they aren't immediately obvious), and we should tend to respect them for that reason.
But in my experience, many libraries and systems try to impose constraints on users that are dubious at best, or actively hostile at worst, under the label of "encouraging best practices" or similar: the only resulting guarantee is that "users aren't allowed to do dumb stuff with my library or system", for some value of "dumb". While this can make sense for sensitive things like security, some authors' ideas of "best practices" can be unnecessary and at odds with interoperability.
So in general, I think it makes sense to question the value of constraints, and not blindly trust them to always be beneficial.
marcosdumay
2 months ago
> So in general, I think it makes sense to question the value of constraints, and not blindly trust them to always be beneficial.
Yes. But the constraints are the entire point of something like a library.
So, it's not so much questioning the value of "constraints" in the abstract sense, but questioning the value of the specific constraints you are creating.
As always, good engineering happens on the details and can't be described in a concise way.
LegionMammal978
2 months ago
Perhaps. Still, my biggest gripe with constraints isn't with using them effectively in code under my own control (where they can indeed be quite useful), but having to interact with them in other people's libraries and systems, many of which are seemingly awash in constraints that they don't really need. Some end up in the worst-case combination of having both useless constraints and unrealized guarantees, which is why I think user-facing constraints should always be taken with a skeptical eye, whether you're planning on adding them yourself, or evaluating them in someone else's project.