Firewalling your code

Capabilities is, in my opinion, the biggest collective blind spot we have in the programming world right now. Bigger than functional programming, bigger than proofs; those may be useful but there is some general awareness they exist. Capabilities are almost unheard of. If someone was setting out to put their mark on the programming language landscape, finding a way to integrate capabilities into a practical programming language would be something I'd have towards the top of my list. I find it frustrating how many "new" languages are just current languages respelled a different way. It has been a while since I've seen a language try something new.

Or, in this case, new-ish. I'd suggest studying E a bit first: https://en.wikipedia.org/wiki/E_(programming_language) and maybe finding some programmers of it and speaking to them about it. But at this point, a language from 25+ years ago with no live community (I scanned over it quickly, there's a Wiki whose "recent changes" shows no changes and a mailing list with an approximate rate of 1 message a quarter or so) means it's going to be so far behind that you might as well start from scratch.

We keep sort of kind of recreating it a bit but it's really hard to bodge on to a language as a library.

Of course, this may be as pie-in-the-sky as expecting everyone to use proof languages. Here I am pitching this and it's an uphill battle for me just to get people to use a Username type instead of a bare string in the real world. Still, the world has moved on in the last 20 years... perhaps the time is right.

(On the off chance that someone ever does decide to build a capability-based language, I would suggest putting a lot of thought into transparency and diagnostics of the capabilities, because even in a super-mega-alpha-test "function call failed: missing capability" isn't going to be a very useful error message. For instance, I would offer the suggestion of, if some code tries to do something at runtime but it doesn't have the capability, in the process of generating the stack trace tell me the last function call that did have the capability, or if the program never had it in the first place. If one can prove it at compile time so much the better, though I don't know how far you can take this at compile time. Also be careful piling too many trendy other type features on top; along with the fact capabilities can arguably replace some other type features, you're going to have enough work to start out with without also trying to be the language with the super-strongest typing as well.)

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.

They're kind of like contract statements for preconditions/invariants but at the design layer, enforced at compile / run time.

I think this is useful for architect types, though I think this belongs more around the DependencyInjection config area.

A class should not be aware of what uses it.

If you know, you know.