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.

There are very clear signs this was mostly built by an LLM. Just an example: https://github.com/Qbix/webserver#%EF%B8%8F-architecture misaligned lines, the commit history, etc.

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

Interesting! I have also implemented a version of TLSF for my (currently single-threaded) programming language. I also found it to be good for my use case (embedded / minimal code size). I'll compare it against yours. One improvement I did is some kind of preallocation for small blocks. https://github.com/thomasmueller/bau-lang/blob/main/src/main...

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.

Great. I'm also writing a new language with the same memory management idea (Perceus-style reference counting / ownership). My language [1] is not functional and currently lacks multi-threading and networking, so there are big differences. But I really like the moto "easy to use memory safety without tracing GC".

[1] https://github.com/thomasmueller/bau-lang/tree/main

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

There are studies that show cancer risk is higher near a nuclear plant. The reason is likely that poorer people live near a nuclear plant; it's _probably_ not because of radiation. My point is: Just having nuclear plants nearby lowers the market price of the property. If there _is_ an accident, the market price of many properties drops to zero. That's why no insurance company will insure the full risk of a nuclear accident: the remaining risk is on the population and land owners. (Property owners may get compensated - paied by taxes.)

In Switzerland there is now again the idea to build nuclear plants, by some (I'm pretty sure the political party that initiated this gets a lot of money from the nuclear lobby - unfortunately the money flow is intransparent in Switzerland.) A recent study in Switzerland [1] has shown nuclear plant are not competitive with solar, wind, hydro, and batteries, not even taking into account that accidents are not fully insured.

[1] https://www.20min.ch/story/akw-debatte-neue-atomkraftwerke-l...

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?

Well... actually, it isn't. I'm also writing my own programming language (named "Bau"). I asked Claude to convert a minesweeper game from C to that language. I only gave some example programs in my language and the grammar. This worked on the first try (Claude didn't even have access to the compiler).

It is not quite as rare. I calculated it to be less common than being hit by a meteorite, and added a section about that and the Birthday Paradox to Wikipedia, to the article about UUIDs. It got removed / replaced a few years ago however. (If my source was correct, there was actually a woman hit by a meteorite, but she survived, with a leg injury.)

If you do have a UUID collision, chances are extremely high that it's either a software bug, or glitch in the computer. It could be a cosmic ray. Cosmic rays messing with the computer memory or CPU are actually relatively common.

Well there is Google Sheets, Microsoft Office, Figma, and some other heavier web apps.

Sure. But it does save you one instruction: "tee", "get" instead of "set", "get", "get".

You could use "local.tee". It is kind of is "store" + "duplicate".

Well that is how it mostly worked until recently... unless if the developer copied and pasted from stackoverflow without understanding much. Which did happen.

I think the main issue with nuclear reactors is the cost, but yes I agree.

It depends on the use case, but do you consider NaN to be equal to NaN? For an assert macro, I would expect so. Also, your code works differently for very large and very small numbers, eg. 1.0000001, 1.0000002 vs 1e-100, 1.0000002e-100.

For my own soft-floating point math library, I expect the value is off by a some percentage, not just off by epsilon. And so I have my own almostSame method [1] which accounts for that and is quite a bit more complex. Actually multiple such methods. But well, that's just my own use case.

[1] https://github.com/thomasmueller/bau-lang/blob/main/src/test...

For the few days without wind, natural gas is cheaper than nuclear. There is also biogas and hydro. Nuclear is not cheap to turn on off. Also, the insurance cost of nuclear power is not accounted for: basically, there is no insurance, and the state (the population) just have to live with the risk.

So if I understand correctly, you are saying the observer doesn't feel like he is in a superposition (multiple states at once). Sure: I agree that observers never experience being in a superposition.

But don't think that necessarily means we are in a Many-Worlds. I rather think that we don't have enough knowledge in this area. Assuming we live in a simulation, an alternative explanation would be, that unlikely branches are not further simulated to save energy. And in this case, superposition is just branch prediction :-)

(This is way beyond my area of expertise so excuse me that this might be a stupid idea.)

I assume the following happens: while a (small) subsystem is in "pure state" (in quantum coherence), no information flows out of this subsystem. Then, when measuring, information flows out and other information flows in, which disturbs the pure state. This collapses of the wave function (quantum decoherence). For all practical purposes, it looks like quantum decoherence is irreversible, but technically this could still be reversible; it's just that the subsystem (that is in coherence) got much, much larger. Sure, for all practical purposes it's then irreversible, but for us most of physics anyway looks irreversible (eg. black holes).

Why do you think so? The code example shows that you can do RLE (run length encoding) without noise / additional space. I'm pretty sure you can do zip as well. It would just be very hard to implement, but it wouldn't necessarily require that the output contains noise.

[1] https://topps.diku.dk/pirc/?id=janusP

Yes you can do compression, if the text is compressible. The playground [1] has a "run length encoding" example.

Maybe you meant sorting. You can implement sorting algorithms, as long as you store the information which entries were swapped. (To "unsort" the entries when running in reverse). So, an array that is already sorted doesn't need much additional information; one that is unsorted will require a lot of "undo" space. I think this is the easiest example to see the relation between reversible computing and thermodynamics: in thermodynamics, to bring "order" to a system requires "unorder" (heat) somewhere else.

There are also examples for encryption / decryption, but I find compression and sorting more interesting.

[1] https://topps.diku.dk/pirc/?id=janusP

There is a programming language that is reversible: Janus [1]. You could write a (lossless) data compression algorithm in this language, and if run in reverse this would uncompress. In theory you could do all types of computation, but the "output" (when run forward) would need to contain the old state. With reversible computing, there is no erased information. Landauer's principle links information theory with thermodynamics: putting order to things necessarily produces heat (ordering something locally requires "disorder" somewhere else). That is why Toffoli gates are so efficient: if the process is inherently reversible, less heat need to be produced. Arguably, heat is not "just" disorder: it is a way to preserve the information in the system. The universe is just one gigantic reversible computation. An so, if we all live in a simulation, maybe the simulation is written in Janus?

[1] https://en.wikipedia.org/wiki/Janus_(time-reversible_computi...

The problem of XPath 3.1 is that it is very complex [1] - this is a long page. Compared to the 1.0 spec, it is just too complex in my view. For the open source project I'm working on, I never felt that the "old" XPath version is painful.

I think simplicity is better. That's why Json is used nowadays, and XML is not.

[1] https://www.w3.org/TR/xpath-31/ [2] https://jackrabbit.apache.org/oak/docs/query/grammar-xpath.h...