thomasmg

Well the first is a discussion without an analysis of existing code, the second is about smart contracts. I'm not convinced that _cyclomatic_ complexity of a function plays a role in security at all. Why:

(a) We have plenty of evidence that buffer overflows etc play a role (caused by using manual memory management), but not so for cyclomatic complexity.

(b) Trying to reduce cyclomatic complexity in one function typically increases the complexity somewhere else, and so is not helping. Often this is just moving stuff around, and sometimes makes things more complex.

Is there research that show if and how much a low complexity improves security?

Usually the air is exchanged

For me (having written my own tiny 400 line chess engine, that now I'm not able to beat - sure I'm not a good player, but still), the reason to have Stockfish is not really to play against it, and then inevitably lose, but to use it to show which moves are best. I assume that's how most (hobby and professional) chess players use Stockfish nowadays.

Right, but for a fan, it would work. Cars heat up mostly in direct sunlight. The solar panel could be wired directly to a fan. This would also prevent heat death of dogs and forgotten children.

Lacking a large study, we can't know. Of course the CO2 meter companies benefit if people believe it is true.

Solar, wind and hydro are all much cheaper, far safer and more efficient these days.

I don't have a strong opinion what is better in this case, but my view is:

> document and express intent clearly

Arguably, the void* does that as well?

> Any seasoned C++ developer seeing this knows what this reinterpret_cast means.

Same for void*?

> it's a bit more text to read

If you have to call it many times, this adds up.

> Some might also say it complexifies and uglifies the code

I think the point is that it adds security, which the other options don't. And, it doesn't add complexity on the caller, but only at one place: the implementation.

> makes it non-portable on top of that.

This can be solved.

> I choose to use Python because I am productive with it.

That, I fully understand. I think many developers are productive in one language: in the one that they know best. Which is probably the one they use most. It might happen that this is is a "fast" language by accident (like Java or Go), or a language like Python. And then there is never enough reason to switch.

> "Most engineers would kill for a 5% speedup"

I think this is very rare - maybe a heavily used app in Facebook or Google, where 5% could mean a lot of money. But a factor of 10 speedup is much more common (and possible sometimes).

> there is an allure to performance optimization due to the fact that it can be so easily quantified.

That's true. I also think simplicity is quantifiable, and so my personal hobby is to write something impressive in few lines. Like a chess engine, QR code reader, editor, data compression tool, compiler, in 500 lines. But this is mostly for hobbies I guess. For work, it's mostly about features, and then performance, I guess.

I'm not trying to criticize, but Python is known to be much slower than eg. Java or Go etc. So for performance-critcal code, why use Python? I find Python to be very good because it is concise and simple, but I have not used it for production so far.

I understand what you mean; Claude is a tool and does not have feelings, thats clear to me. But how else can I describe what I did? "Wrote to Claude" has the same issue. Posted, typed, inputed?