HdS84 · HackerTrans

4 माह पहलेdiscuss

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.

HdS84

4 माह पहलेdiscuss

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.

HdS84

7 माह पहलेdiscuss

The germans tried that in the 60s see https://en.wikipedia.org/wiki/Otto_Hahn_(ship). It was uneconomical. You need specialized engineers for that, you need special permissions for ports and the important canals are off limits due to risk.

HdS84

पिछला वर्षdiscuss

I am often shocked how poor language support for paralelism is. Sorbets asnc/await make writing that kind of code a breeze. Python and Java are much less ergonomic for this. Might have improved with the newest Java versions, but I did not try that yet.

HdS84

पिछला वर्षdiscuss

We maintain a few number of projects for clients - the apps are feature complete and will not change much in the next years. The goal here is to spend not much money on the apps but to keep them functional in the appstore. RN is somewhat cheaper up fron than native development or say flutter. Unfortunately, maintenance cost is high and difficult to predict. Why? Appstores are adding new requirements and increase API-level all the time. Support for that is often baked into new RN versions. Unfortunately, new RN versions often break things, which break libraries in turn. So you need to upgrade this morass and if you are unlucky, you need to redevelop huge swaths of your app because the lib now is deprecated /works differently / will never be updated to the new RN version.

comments