A lot of the bitching about react always had the same flavour of the complaints that JavaScript dares to have a NaN

To be fair it is stupid that NaN !== NaN but that is how IEEE and CPUs made floats to be

It's not stupid when you realise that NaN is not "not a number" but rather "not a particular number", this becomes clear from

  hypot(Inf, NaN)

being Inf rather than NaN

I mean to me the whole point of NaN is that it should not equal NaN, so it seems sort of like you are making the complaint in the first sentence in your second sentence, only in a slightly more abstracted way. Unless you are of the opinion there is another better point to NaN?

funny story, I was once interviewing for a job where the tech guy did not know that NaN existed. I guess JavaScript wasn't his language, but not sure what was, and the code was in JavaScript for a Web Dev role.

JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder

Yes, I was talking from a performance/UX standpoint.

Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.

C++ and python are exactly where I would expect this problem to come up

True, but in a sense a single frontier model of today would be of incredible historical significance in the far away future.

Markets and rationality are sometimes just acquaintances

Oracle makes billions selling SQL when you can just use a free version. This is no different. Enterprise has enterprise needs. It's really not that complicated or irrational.

Sure but each of them is being priced as if each one is gonna have 90% marketshare in the future.

For a lot of people writing prose is a chore

> (2) There is nothing actually forcing the open source release.

the anti-cloud-use license would include it, with no need of a separate release

What? How exactly would you make that work in practice?

Are you going to release the source on day one?

Because good luck trying to convince the board to pay for source escrow.

And if you don't do any of those things then you will, in fact, need a separate release of source code.

I cannot answer your main question, but i can give you recommendations wrt what you are gonna try to do.

Very likely there will be a lot of parts of the app you are not going to understand, those will be the main problems so help claude help itself.

Make it add diagnostic/event-logs to every part of the stack and potentially even design implementations around traceability (eg avoid batch background processes that touch many flows if possible). so that claude can check whether runtime behaviour matches expectations. also store historical data to help debug regressions.

Treat implementations as cattle not pets, once a feature is done consider scapping it and turning it into a design doc, then ask claude to reimplement interactively with you step by step explaining to you what is going to do, why it matters, etc. this is a very good way to minimize the black boxes you don't understand in the app.

if the app is web make it work very well with playwright for e2e ux tests.

finally i like the architecture given in https://www.youtube.com/watch?v=4KvbVq3Eg5w (use ui composition to define feature) but this has little to do with claude

An Oxford comma before the or would make it clearer maybe

you are right a stack of printed qr codes is better

No, that's too easily machine-read. Print it in a fancy calligraphy font or one with ambiguous characters.

Reminds me of Lavabit where the US wanted the encryption keys and they printed them out in a 4 point font :D

https://en.wikipedia.org/wiki/Lavabit#Legacy

That's too convenient, cameras can read many qr codes at a time. Encode the binary on some punch cards.

Pretty sure cameras can be used to read punchcards too.

This sounds like a fun project. Somebody already did it, apparently: https://hackaday.com/2012/07/30/reading-punch-cards-with-an-...