theSherwood

It's not just about malleability. It's about specificity. A prototype has to specify certain details to run at all. This is not really true of sculpting in clay (former sculptor here). What the article describes of a sculptor working from big forms to smaller forms and so forth is in contrast to what it feels like to code by hand, which always requires some thought for the details even if the details are going to change dramatically as the program goes from prototype to hardened production software. The programmer always had to have their hands on the details even as they thought about architecture, but that's not the case now. Now we really can work from primary masses to increasingly specific details.

Interesting concept. But you might want to ditch the pronunciation audio. At least for Welsh and Spanish, the pronunciation audio is pretty far from the mark. I would guess that is the same for many other languages.

FYI, there appear to be several typos where occurrences of "h" seem to have been replaced with "d", such as in "tde".

This article seems unreasonably optimistic.

If AI can truly replace human labor at a lower price point, then that's more or less the end for your median human. The economy will work by much the same principles as ever: those who can provide value will trade with others who can provide value. If that's not your median human, too bad for them. There may be some initial efforts by government to cushion people's irrelevance with UBI or other welfare schemes, but they won't be stable. Human rights and the political power of the median citizen are historically downstream of the value of the average citizen's labor.

It's great apart from the nested list syntax. It's quite noisy. I'd prefer if it supported indentation.

What stops the llm from writing a malicious program and executing it? No offense meant, but this solution feels a bit like bolting the door and leaving all the windows open.

I don't know about good vs evil. That seems impossible. But I'd be interested in a license that prevented use by any company owned by one of the top 1% most valuable companies in the world. I have no idea if that's enforceable or not. Basically a license that restricts use for companies that are just trying to be acquired.

I'm really skeptical of the idea that the blame for the lack of water infrastructure ought to be put at the feet of the water companies. The UK's planning system has strangled just about every infrastructure project in every domain. There is a general trend of local residents preventing infrastructure being built in the area, whether it be for water, energy, rail, or roads.

This site is an absolute gem. Thank you.

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.

100%. If we could get a DomString8 (8-bit encoded) interface in addition to the existing DomString (16-bit encoded) and a way to wrap a buffer in a DomString8, we could have convenient and reasonably performant interfaces between WASM and the DOM.

I want DOM access from WASM, but I don't want WASM to have to rely on UTF-16 to do it (DOMString is a 16-bit encoding). We already have the js-string-builtins proposal which ties WASM a little closer to 16-bit string encodings and I'd rather not see any more moves in that direction. So I'd prefer to see an additional DOM interface of DOMString8 (8-bit encoding) before providing WASM access to DOM apis. But I suspect the interest in that development is low.

The advantages of Tailwind are:

- the styling is colocated with the markup - sensible defaults - avoids rule hierarchy/inheritance - minimal JS at runtime

Disadvantages:

- build step and configuration - dynamic styling complexity

I don't think that's a bad tradeoff. And we're talking about styling on the web, here. So there are no good solutions. But there is a bad solution and it's CSS-in-JS.

I'm not pretending to any novel insights. Most of us who don't have much use for theology are generally unimpressed by its discourse. Not novel at all. And the "centuries of work" without concrete developments that exist outside of the minds of those invested in the discourse is one reason why many of us are unimpressed. In contrast, AI development is resulting in concrete changes that are easily verified by anyone and on much shorter time scales.

You are, of course, entitled to your religious convictions. But to most people outside of your religious community, the evidence for some specific theological claim (such as predestination) looks an awful lot like "nothing". In contrast, claims about the trajectory of AI (whether you agree with the claims or not) are based on easily-verifiable, public knowledge about the recent history of AI development.