[syntheweave]

Not necessarily. Speed is actually very easy to come by if we push down quality to the level of "wrong answers infinitely fast", which trivially allows you to achieve as much computational performance as a broken clock. As well, if you write code solo or in a small team, you will almost always get a more consistent, higher quality result than if it's written at corporate scale because that eliminates incidental communication overheads that get reflected in the software dependencies(e.g. Windows Terminal's low performance is mostly an artifact of Microsoft's processes).

Jon and the authors of uxn commit a common fallacy in that they're chasing a brass ring of in-the-small performance metrics, getting it in the form of particular demonstrations, and then gradually accreting features to it until, most likely, they end up in a similar position to the old tech. Many software projects start off as the "light and simple alternative" and then develop into something not light and simple. This isn't necessarily an issue for any particular project, because if you know the goal of your tech, you don't need all the features and so can omit some things to claim a definite advantage for the application; but it's not in and of itself a solution to the general issue of making computing better, because it entails bespoken effort from expert practitioners, while the general trend in computing tech is the same as most industrial automation - it's quality-first. Quality comes first when you automate, because a superhuman level of quality can redefine what's possible, and it can compensate for the downsides of not being a bespoke, artisanal result.

The actual problem faced by language authors is that they face difficulty in defining quality while also generalizing the problem space. New languages are mostly "old concepts, new syntax and libraries" - still giving improvements in UX and therefore quality, but with most of the features carried over from previous languages.

[Karrot_Kream]

> Jon and the authors of uxn commit a common fallacy in that they're chasing a brass ring of in-the-small performance metrics, getting it in the form of particular demonstrations, and then gradually accreting features to it until, most likely, they end up in a similar position to the old tech.

The authors of this post note the same tendency with Gemini [1] and demonstrate that the clients are actually quite fat, much fatter than their rationale documents claim they should be.

[1]: https://applied-langua.ge/posts/terminal-boredom.html

[dmitriid]

> Jon and the authors of uxn commit a common fallacy in that they're chasing a brass ring of in-the-small performance metrics, getting it in the form of particular demonstrations, and then gradually accreting features to it until, most likely, they end up in a similar position to the old tech

If creating full games is an in-the-small performance for a particular demonstration, I can't even imagine what an in-the-big is.

> The actual problem faced by language authors is that they face difficulty in defining quality while also generalizing the problem space

As far as I can tell, jai is exactly that. It's already dropped a few features that looked fine in theory but didn't work for actual development.