Emphasis mine. This is the exact mindset I'm referring to, and when applied generally to files in the repo, will bite at some point. Even if you're lucky and it's unimportant/internal enough not to bite users, it will bite contributors. Luckily none of us would be discourteous enough to do this while contributing to another's repo.

> Design Principle #2 [...] shows multiple violating their own mass rule as good examples

While there are some ugly/gaudy houses out there, the gatekeeping behind what is a "McMansion" is subjective and silly.

> Only individual, non-commercial, non-bulk use of the Materials is permitted

Unsure if this falls within. I have written my own scripts against the XML regularly updated there, but am unsure if they allow it to be used on a shared site.

(V)RAM conscious AI inferencer/generator: https://github.com/cretz/thinfer

And now working on an inference engine specifically geared to low mem situations. Both basically vibe coded. Not broadcasting either project widely as they remain unstable, unpolished side projects.

I think all-client-side in-browser AI imagery is becoming very doable and has lots of privacy benefits. However ONNX web leaves a lot to be desired (I had to proto patch many pytorch conversions because things like Conv3D ops had webgpu issues IIRC). I have yet to try Apache TVM webgpu approaches or any others, but I feel if the webgpu space were more invested in, running these models would be even more feasible.

Consent from whom? Consent is already required, why are you discussing this as though consent is not required? Why are you stating it as if people are using other's computers without consent? Right now when I sideload an APK on _my device_, I have to explicitly consent to allowing it to install. And I do not require the author of that APK to have made any deals/interactions with Google. What you mean is Google's consent or a debugger's consent or my consent tomorrow.

So I, as the user, will no longer be able to provide consent alone. I wish that you were right and it was just "no running without consent", but that is today's behavior, and that is being altered.

> I think a good compromise is that they could permit you to sideload. Which they are doing.

They always have, and that was a good compromise. They've now decided you can't sideload until tomorrow unless you break out debugging tools or require the author make special deals with a specific vendor. What exists today is a good compromise, the change is not.

I expect the same from my desktop and mobile devices here.

I am only slightly comforted by the fact that desktop computing had set (some) self-ownership precedence before the current restrictive computing hegemony took control, though even that is eroding.

I can't see where one can opt-out of this new behavior and into the existing behavior, only a description of the new behavior's bypass (which is not the same thing at all)

> easy to bypass the cooling-off period with ADB

I don't think this is a reasonable use of the term "easy". I should be able to give my non-technical friend an apk and they can use it right then, with the one "are you very sure" screen.

More like flying based on your knowledge as a pilot and not by the whims of your passengers.

For many CLIs and developer tooling, principled decisions need to reign. Accepting the unquantifiability of usage in a principled product is often difficult for those that are not the target demographic, but for developer tools specifically (be they programming languages, CLIs, APIs, SDKs, etc), cohesion and common sense are usually enough. It also seems real hard for product teams to accept the value of the status quo with these existing, heavily used tools.

A couple of obvious questions - Is it open source (npmjs side doesn't point to repo)? And in general will it be available as a single binary instead of requiring nodejs tooling to install/use? If so, using recently-acquired Bun or another product/approach?

Admittedly the lang spec doesn't do a great job at the justification side, but the engine spec adjacent to it at https://github.com/cretz/duralade/blob/initial-runtime/docs/... that has sections showing CLI/API commands can help make it clearer where this runtime is unique.

Most of the work as of today is in a branch, can see the language spec at https://github.com/cretz/duralade/blob/initial-runtime/docs/..., and some samples at https://github.com/cretz/duralade/tree/initial-runtime/sampl....

May not amount to anything, but the ideas/concepts of this durable language are quite nice.

At review time.

There are simply too many software industries that can't delegate both authorship _and_ review to non-humans because the maintenance/use of such software, especially in libraries and backwards-compat-concerning environments, cannot justify an "ends justifies the means" approach (yet).

I think skills and other things have shown that a good bit of learning can be done on-demand, assuming good programming fundamentals and no surprise behavior. But agreed, having a large corpus at training time is important.

I have seen, given a solid lang spec to a never-before-seen lang, modern models can do a great job of writing code in it. I've done no research on ability to leverage large stdlib/ecosystem this way though.

> But I'd be interested to see what you come up with.

Under active dev at https://github.com/cretz/duralade, super POC level atm (work continues in a branch)

My reasoning is 1) AIs can comprehend specs easily, especially if simple, 2) it is only valuable to "meet developers where they are" if really needing the developers' history/experience which I'd argue LLMs don't need as much (or only need because lang is so flexible/loose), and 3) human languages were developed to provide extreme human subjectivity which is way too much wiggle-room/flexibility (and is why people have to keep writing projects like these to reduce it).

We should be writing languages that are super-strict by default (e.g. down to the literal ordering/alphabetizing of constructs, exact spacing expectations) and only having opt-in loose modes for humans and tooling to format. I admit I am toying w/ such a lang myself, but in general we can ask more of AI code generations than we can of ourselves.