HdS84

Personally, I am comfortable with Pythons "linter warning and we are all adults here" - it works well and I have never seen that somebody cried "I overwrote this private method and after an upgrade it did not work!". .Net allows it via reflection and considering that .Net Frameworks could run untrusted code it was okay that it was forbidden out of the box (since reflection was forbidden for untrusted code). But in the current world, where untrusted code does not really exist anymore? It's just legacy cruft.

There are always corner cases where you might need to do something differently. I had three memorable cases in my career: 1. Python 2.6x had a a stdlib bug where windows event logging did crash the process when the user had some rights set differently. Fix submitted but for the meantime we simply overwrote the private function and could ship. 2. Also python: scikit-learn had a primitive "print everything" strategy, but we need to get it into a logging framework. We overwrote their print wrapper and could ship. 3. In C#, a third party lib insisted on dumping a result to a file. We used reflection to get that as a stream.

All three are not ideal - but I think having escape hatches is important. I also think private/public is overrated. Having it as a signal is ok. Forbidding access to privates is too strong.

Many "developers" think print("OOOPS") is a good way to debug - so I guess it's an education problem.

Probably not... So they will have issues, too.

Yes, halfway decent security runs counter to most people's inclinations. Like osha or medecine rules. So enforcement is important, though it is annoying

Thanks! I am a little disappointed that it seems to be trash :(

We introduced MDM for our Mac boxes early this year. Over half(!) had outdated mac versions and missed multiple major updates. Before that - it was always really obvious that you needed to run the newest version ASAP (asap=All dev tools run on the newest version, which was not a given, so a few weeks delay was ok). We have lots of linux boxes and I suspect their patch state is even worse - but how to check that? There are a dozen distros and a few self build systems...

History shows that to simply not the case. Individuals are bringing down democracies all the time. Especially presidential democracies are super vulnerable to this because the president has outsized power compared to the other branches of the government.

I studied political sciences twenty years ago - even then it was established consensus that presidential democracies are vulnerable to authoritarian takeover. The position has too much power, is easily abused and there are not enough checks on that position. The US escaped that problem for a long time due to strong cultural norms - but you abolished them (i.e. gatekeeping the presidential nominees and replacing that with a televised drama) and working checks (but again, now party in congress and president march in lockstep). FPTP and gerrymandering just exacerbate that problem and entrench a very unhealthy "the winner takes it all without need for compromise" culture.

You need electoral reform post haste - but I do not seed even a start to that discussion, so I think you are hosed. Might not be Dictator Trump, but maybe Vance or some other guy who succeeds in this game.

And all who cry "if the democrats win everything will be ok again!!!!" - not it won't. The democrats are too slow to recognize the problem and even if they eventually do, there are no majorities to change the system. And finally: Democracy needs at least two parties - democrats cannot be expected to keep branches of the government forever. You need a sane and democratic second party. Republicans ain't it - but the current system gives them success, so why change?!

Did you evaluate RavenDB? Just out of interest

Hey, do you think Gitlab should do anything except running after the next trend and develop shitty not-solutions for that? Why, that could improve Gitlab. We cannot have that!

As a simple example : once upon a time a We needed to generate a sort of heat map. Doing it in pure python takes a few seconds at the desired size (few thousand cells where each cell needs a small formula). Dropping to numpy braucht that downs to hundreds of milliseconds. Pushing it to pure c got us to tens of milliseconds.

R with its 4(?) class systems enters the chat.

I don't think Inheritance is always bad - sometimes it's a useful tool. But it was definitely overused and composition, interfaces work much better for most problems.

Inheritance really shines when you want to encapsulate behaviour behind a common interface and also provide a standard implementation. I.e: I once wrote a RN app which talked to ~10 vacuum robots. All of these robots behaved mostly the same, but each was different in a unique way. E.g. 9 robots returned to station when the command "STOP" was send, one would just stop in place. Or some robots would rotate 90 degrees when a "LEFT" command was send, others only 30 degrees. We wrote a base class which exposed all needed commands and each robot had an inherited class which overwrote the parts which needed adjustment (e.g. sending left three times so it's also 90 degrees or send "MOVE TO STATION" instead of "STOP").