Other forces are to blame as well, though. In the 80s and 90s there were UI research labs in indistry that did structured testing of user interactions, measuring how well untutored users could accomplish assigned tasks with one UI design versus another, and there were UI-design teams that used the quantitative results of such tests to deign UIs that were demonstrably easier to learn and use.
I don't know whether anyone is doing this anymore, for reasons I'll metion below.
Designing for use is one thing. Designing for sales is another. For sales you want a UI to be visually appealing and approachable. You probably also want it to make the brand memorable.
For actual use you want to hit a different set of marks: you want it to be easy to learn. You want it to be easy to gradually discover and adopt more advanced features, and easy to adapt it to your preferred and developing workflow.
None of these qualities is something that you can notice in the first couple of minutes of interacting with a UI. They require extended use and familiarization before you even know whether they exist, much less how well designed they are.
I think that there has been a general movement away from design for use and toward a design for sales. I think that's perfectly understandable, but tragic. Understandable because if something doesn't sell then it doesn't matter what its features are. Tragic because optimizing for sales doesn't necessarily make a product better for use.
But if you're really big, you could also test in production with ab testing. But as you said, the motivation tends to be to get people to click some button that creates revenue for the company. (subscribe, buy, click ad)
Somewhat related to this, the google aistudio interface was really pushing gdrive. I think they reduced it now, but in the beginning if you wanted to just upload a single file, you had to upload it to gdrive first and then use it.
There was also some annoying banner you couldn't remove above the prompt input that tried to get you to connect to gdrive.
On a side note, I'm anthropomorphising too much, gonna have to upgrade and get some top rate therapy...
But what I meant was that the whole response completely disappears. Sometimes the text I wrote previously is pasted back into the text input, but sometimes it's not.
I have this habit of copying my prompt in case it happens.
It randomly fails halfway through a response, sometimes very slow to start, hangs for long periods during a response, and so on.
The Claude chat interface can also slow down with long sessions. I sometimes use Claude code which is better, but I'm not a huge fan of terminal interfaces. I'm aware of third party frontends, but I believe those require api access which I don't like for personal use.
First, that would be Java and Go, not Java and .NET, as .NET offers a separate construct (async/await) for high-throughput concurrency.
Second, while "unfashionable" in some sense, I guess, it's no wonder that Java is many times popular than any "fashionable" language. Also, if "fashionable" means "much discussed on HN", then that has historically been a terrible predictor of language success. There's almost an inverse correlation between how much a language is discussed on HN and its long-term success, and that's not surprising, as it's the less commonplace things that are more interesting to talk about. HN is more Vogue magazine than the New York Times.
Turns out you can't just dd a windows iso onto a usb drive.
You have to format it to fat32, then manually copy all the files. However there is one big installer file which is above 4gb, so you have to get some tool (also provided by Microsoft) to split the file into multiple files less than 4gb. The windows installer will recognize the split files and use those instead.
It's beyond me why the official windows iso just doesn't have this by default...
The current people behind Board might promise to deliver now, but who knows what will happen 5 years down the line.
The way I see it, mathematicians have been trying (and somewhat succeeding every 5~ years) to prove faster ways to do matrix multiplications since the 1970s. But this is only in theory.
If you want to implement the theory, you suddenly have many variables you need to take care of such as memory speed, cpu instructions, bit precision, etc. So in practice, an actual implementation of some theory likely have more room to improve. It is also likely that LLM's can help figure out how to write a more optimal implementation.