This is an enjoyable read. The topic of abstraction needs to be explored more here. I wonder if the author would agree that In practice almost all abstractions

This is an enjoyable read. The topic of abstraction needs to be explored more here. I wonder if the author would agree that In practice almost all abstractions can be made to leak. Given that, then even experienced developers who understand how to avoid mixing different layers of abstraction will seldom succeed in creating abstractions without leaks. If an abstraction leaks, it’s not germane, it’s incidental complexity. This applies to blueprints as equally as it does to implementations. The author notes the caveat in soundness of blueprints - not something a common developer can do much about - but if the developer designs blueprints with unintended behaviours - for example the author’s recursive let example - then they’re being very generous with the helpfulness of blueprints since they are no silver bullet to avoid shooting yourself in the foot. The common case in software development is not a PLT enthusiast. Blueprints are just another way you can shoot yourself in the foot if you hold the tool wrongly. And the common case is not to understand the tool much more than at a fairly superficial level, so mishandling is all but assured. This means pragmatically, there’s no substitute for an acceptable level of testing in a project.