So where are all the successful AI slop products?

It's not so much about AI slop being successful, it's about non-slop being drowned in slop so much its voice can't be heard.

I don't like that argument either.

However, the continued existence of society requires other people's children, so maybe it's a pretty important investment?

> society requires other people's children

Does it really require knee-capping the internet and privacy though?

Is this really the pressing issue for society?

Very neat. I'm not sure if I missed it, but is there any way to get n equidistant points on the curve?

E.g. for moving an object at constant speed along the curve.

There is indeed: Bezier::compute_lookup_table[1]. You'll want to use a `TValueType` of `Euclidean` to get equidistant points.

[1]: https://docs.rs/bezier-rs/latest/bezier_rs/struct.Bezier.htm...

Easy to mitigate by only allowing the device that requested the 6-digit code to use the code.

Edit: See first reply, this is not a mitigation at all!

but the device is under the control of BAD. They fake a signin on their backend to GOOD. Your computer never touches GOOD at all, except from seeing the email from GOOD (which you're told about by BAD, and lied to about being a partner signin thing).

The problem being exploited by BAD is that your login account identifier (email in this case) is used in both GOOD (and BAD - accidentally or deliberately orchestrated), and 2-factor does not prevent this type of phishing.

The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another.

The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.

It's not irrational; quite the contrary.

Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.

State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.

What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.

Reactivity is just one pattern to help manage state. We have observable (which is just reactivity in another cloth), Entity-Component, View-Model (also Presenter), etc,…

Ever use knockout.js?

I think it had/has the perfect balance of utility without being overly opinionated. State was also much easier to deal with.

I haven't used it in a while, but still look back on that project fondly.

React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM.

Storing the diffs to local storage is an interesting idea though.

Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.

> Do you have some issue that in Denmark its deemed solvable only through that?

No. On the contrary, our crime rates are some of the lowest in the world.

Like what?

Domestic violence, crimes involving minors, without explicit mention of the crime

The extra DOM complexity that would entail seems like a loss for the existing web.

The current situation is that we have limited uptake of WASM. This is due, in part, to lack of DOM access. We could solve that but we would have to complicate WASM or complicate the DOM. Complicating WASM would seem to undermine its purpose, burdening it forever with the complexity of the browser. The DOM, on the other hand, is already quite complex. But providing a fresh interface to the DOM would make it possible to bypass some of the accretions of time and complexity. The majority of the cost would be to browser implementors as opposed to web developers.

At least some of the implementation complexity is already there under the hood. WebKit/Blink have an optimization to use 8-bit characters for strings that consist only of latin1 characters.

Programming languages are different. They usually can't be "repaired" once broken, because they need to maintain backwards compatibility.

This is only true if people stick to a version of a language and don't upgrade.

If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.

Same goes for other languages like C# or Python

They don't "need" to maintain backwards compatibility. Several major languages have broken it by now.

Programming languages deprecate features in standard libraries all the time. As PHP did, causing many PHP 5.3 applications to fail catastrophically once the warnings added to PHP 5.4, 5.5, and 5.6 were turned into errors. Of course, maintained software rarely ever runs into this issue.

The standard libraries were the lacking part in PHP. The language itself was never a serious problem.

They are software products like anything else.

Yeah, Super Mario Bros is 40+ years old by now. Runs just fine in an emulator, even if you can't find the original hardware.

Modern SaaS apps can't be run once the company shuts it down. You don't have the code, not even the executable.