[w0utert]

That's not how software development works in e.g. companies where multiple people use the software (framework, libraries, API's) at different levels/roles.

For example, if we develop some framework to be used at multiple sites in the company, we can be 100% sure that at some point someone will assume that anything marked 'public' in the API is fair game to use (which IMO is a reasonable perspective). If they start using internal API's or depend on class internals that are only public just because the language did not provide us with a reasonable way to hide them, at some point we will change them and working systems could break elsewhere. In a similar fashion, misuse of private API's by violating preconditions that are completely opaque to users of your (intended) public API can lead to the worst kinds of bugs and unpredictable runtime failures.

Software development always seems so simple and pragmatic if you don't need to care about other people you have no control over.

[eps]

> That's not how software development works ...

... in your setup. All shops are different. To each their own. There's no private/protected scaffolding in the Linux kernel to give the most obvious example.

[w0utert]

Well last time I checked the Linux kernel was C and not C++, so that might explain why ;-).

I don't know anything about kernel programming, but I assume that there's some very, very strict conventions about how the various parts of the Linux kernel interact, and nothing gets accepted for merging unless you follow them. This would be similar to imposing scope/visibility constraints at the language level, but considering C doesn't have anything for that, an extremely strict development process is the best you can do.

[picacho]

emm... All we could say is that, kernel programmers'/reviewers' technical background is much higher/better than average python programmers'/reviewers'. Seen too many times these "Mr/Mrs. More or less" engineers simply modify the internal states as short cuts to compensate real engineering.

[mirsadm]

Equally being too defensive and over-complicating code in case a "bad" developer makes a breaking change often leads to code that is worse in the long term.