I thought I'd revive it, but this time with Vulkan and no third-party dependencies (except for Vulkan)

4.5 Sonet, Opus and Gemini 3.5 flash has helped me write image decoders for dds, png jpg, exr, a wayland window implementation, macOS window implementation, etc.

I find that Gemini 3.5 flash is really good at understanding 3d in general while sonnet might be lacking a little.

All these sota models seem to understand my bespoke Lua framework and the right level of abstraction. For example at the low level you have the generated Vulkan bindings, then after that you have objects around Vulkan types, then finally a high level pipeline builder and whatnot which does not mention Vulkan anywhere.

However with a larger C# codebase at work, they really struggle. My theory is that there are too many files and abstractions so that they cannot understand where to begin looking.

Contrast this with the "os" of my LG oled monitor. It seriously takes 5 seconds to open the settings menu.

I'm not sure what they use these days, but 10-15 years ago the MCU in a monitor was likely to be a ~10MHz 8051.

When you go to the market to buy socks, it's a little difficult not to find socks without logos like nike, addidas, gucci, prada, etc.

If you wear the real deal, everyone will think it's fake, or perhaps "worse", they will think nothing of it.

You can buy high quality fakes, or low quality. Or even the real deal, straight from the factory, just without the final stamp of approval.

I see this argument a lot with Lua. People simply don't like its syntax because we live in a world where C style syntax is more common, and the departure from that seem unnecessary. So going "well actually, in 1992 when Lua was made, C style syntax was more unfamiliar" won't help, because in the current year, C syntax is more familiar.

The first language I learned was Lua, and because of that it seems to have a special place in my heart or something. The reason for this is because in around 2006, the sandbox game "Garry's Mod" was extended with scripting support and chose Lua for seemingly the same reasons as Redis.

The game's author famously didn't like Lua, its unfamiliarity, its syntax, etc. He even modified it to add C style comments and operators. His new sandbox game "s&box" is based on C#, which is the language closest to his heart I think.

The point I'm trying to make is just that Lua is familiar to me and not to you for seemingly no objective reason. Had Garry chosen a different language, I would likely have a different favorite language, and Lua would feel unfamiliar and strange to me.

I haven't read antirez'/redis' opinions about Lua, so I'm just going off of his post.

In contrast I do know more about what Garry's opinion on Lua is as I've read his thoughts on it over many years. It ultimately boils down to what antirez said. He just doesn't like it, it's too unfamiliar for seemingly no intentional reason.

But Lua is very much an intentionally designed language, driven in cathedral-style development by a bunch of professors who seem to obsess about language design. Some people like it, some people don't, but over 15 years of talking about Lua to other developers, "I don't like the syntax" is ultimately the fundamental reason I hear from developers.

So my main point is that it just feels arbitrary. I'm confident the main reason I like Lua is because garry's mod chose to implement it. Had it been "MicroQuickJS", Lua would likely feel unfamiliar to me as well.

I’m not sure it’s still the case but he modified Lua to be zero indexed and some other tweaks because they annoyed him so much, so it’s possible if you learned GMod Lua you learned Garry’s Lua.

Of course his heart has been with C# for many years now.

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.

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.

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.

I love it when they take an offense.

Google & Gemini, that's where I went due to Anthropic's inability to run reliable production workloads

It's just Google own UIs and apps are almost comically bad.

And no, Claude sucks ass. It's like Anthropic does not want to make money. For a company that's targeting enterprise customers, they are totally unprepared. Like forget customer support, they can't even sell properly. They brag about insane capabilities on the Max plan but good luck trying to buy that on a team plan with company billing.

Even if OpenAI doesn't have the best model, at least they know what to do to make money.

What would have improved UI development instead?

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.

Windows 11, iOS7, iOS26 are just some example of non Web UIs, which focused first on optimizing for sales, i.e. making something look good without thinking about usability implications.

Fortunately usability testing is still pretty much a thing. Good articles here: https://www.nngroup.com/search/?q=usability+testing

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...

But instead of the process you describe (which some tools will do for you) I used Rufus to copy the install files onto a USB formatted as a NTFS partition, working around the 4GB limitation.

What you sometimes need is a USB stick having a native "geometry" in terms of HDD emulation ability, that will be recognized properly by the particular series of chipset on the target mainboard.

Then the data bits written to a fully-zeroed drive must conform to what is expected of a bootable device on the target mainboard, for one thing the partition(s) often needs to be well-aligned with the underlying storage hardware to a more particular degree than merely when it is a "perfectly" readable & writeable drive.

Many new USB sticks fail at this fundamental point because the factory partitioning & formatting was accomplished using an image not exactly appropriate after the vendors of the silicon storage or controller chips make hardware revisions.

Analogously, also why writing an IMG or dd from a not-very-identical stick, or with dissimilar partitioning and/or formatting is quite hit or miss.

Sometimes freshly reformatting is enough for problem sticks, other times they can not be made to boot without repartitioning. Either way a fresh reformat or repartition may simply overwrite using (proven nonoptimal) disk structures still remaining in place unless the device is zeroed beforehand. Sometimes a reboot is needed for an OS to forget the structure that was recognized during most recent insertion.

I like Ventoy (and Rufus) but for best results I start with a proven bootable stick which I prepare manually from a zeroed stick and verify bootability beforehand. Similar preparation when getting ready to manually write reliable plain Windows Setup USBs from the mounted ISO.

Rufus puts such a driver in its FAT32 boot partition and loads it before starting the winpe.

It drives me nuts that the UEFI sites never included ExFAT.

The current people behind Board might promise to deliver now, but who knows what will happen 5 years down the line.