I wrote a logistics optimization program (think travelling-salesman++) in Python and it gradually took over from the v1 version written in Java.
People generally compare "speed of execution" to "speed of coding".
I'll add "speed of troubleshooting". When something goes wrong and the clock is ticking, you need tools to identify quickly if the data is inconsistent, a config set wrongly or the algorithm stuck at a local optimum. And then decide if things can be mitigated with a patch or we should we grovel and buy time from the client... All of this is much easier in Python (bar the grovelling).
LLMs are changing things though. I recently ported a complex part of the kernel to C++. 90% of it was creating the scaffolding before the actual algorithms were ported. Very tedious work but Claude can just chug through. Wouldn't like to maintain it just yet.
I did not. Post-conditioning by your comment and the other one,I can see some signs such attempting to be unusually comprehensive. The 'atoms in your liver' could be an awkward human trying to be poetic about scales.
I still don't see idiomatic markers of AI so that's scary if your claim is correct.
I wonder how many completely u related applications have that interval check logic coded up somewhere. I'm pretty sure I wrote one for my work codebase. Would I bet my life that the < and <=s are correct? Nope.
Yes that's a brilliant article. I do not think it is in the book yet?
I used a poor man's version to solve a puzzle where one arranges polymino pieces on a grid spelling out the date [1]. No pointers, just keeping track of deleted rows and columns in the recursion.
It is not at all obvious that all 366 days can be solved. To my dismay all of them can be solved in multiple ways - as a human I find some days quite tricky.
I am drowning in gating propagating semantic mismatches...