Ouch, for something as sensitive, I don’t trust code reviews to catch vulnerabilities. They probably won’t happen overnight, but I don’t want to risk being a victim to the gradual laziness that comes with backseating programming over time.

Time to jump ship.

At that scale, contracts are multiple interfaces, not just one. And C#/Java /whathaveyou interfaces are largely irrelevant, we’re talking way broader than this. Think protocol, like REST, RPC…

Wholeheartedly agree. OOP was supposed to offer guardrails that make it harder to write irremediably bad code. When you measure the outcomes in the wild, the opposite is true. Traditional OOP code with inheritance makes it hard to adapt code and to reuse it, as far I’ve been able to measure.

It works in huge teams where teams aren’t closely integrated, for development velocity.

Defining a contract that a service upholds, and that dependents can write code against, with teams moving at will as long as the contract is fulfilled is valuable.

I’ll grant you it is true that troubleshooting those systems is harder as a result. In the huge organization I was in, it was the job of a non-coder specialist even.

But given the scope, it made a ton of sense.

When a system uses words of a specific size, you need to use the same size for wraparound behaviour to work as expected. Incrementing 0xffff by one needs to return 0. It’s easy if you use a uint16_t. Not so much if you use an unsigned of unspecified length.

Those are very powerful abstractions for sure, but did you notice how far their implementation is from standard Java OOP?

That’s because polymorphism at a macro-level is a functional concern, not something programmers speak in conferences about.

One of my biggest gripe with Y2K-style OOP is that its proponents make lots of promises that don’t track in practice when you measure the outcomes. One such promise is that writing rigid class hierarchies lead to the potent abstractions you describe.

I’ve had to do that too, for tests specifically as well, and making clocks an interface on the spot was trivial. I did it when I needed it though, and not ahead of time.

A Time interface is waaaay too broad. Turns out, I only needed something something to give me programmable ticks for my tests, which is much narrower in scope than abstracting something as general as time.

I’d say abstractions designed to support tests need to be very narrow in scope, and focused on solving the problem at hand.

Emulation code where you expect unsigned integers to wrap around instead of being UB is a good example, because it was guaranteed for programmers working on the emulated systems.