Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.

Cocoa is excellent but who knows when Apple will deprecate it for SwiftUI (which is not very good yet, if it ever will be)?

Windows is a disaster of half-finished APIs. Win32 doesn't even support dark mode. Windows Forms was on life support for ages and only now is getting some love, but it doesn't have a native look despite being built on Win32. WPF is stuck on DirectX 9 and was also on life support for a long time. UWP is dead, effectively. WinUI3 requires bundling 38MB worth of DLLs (many DLLs), is a pain to install and setup a project with and somehow performs worse than electron apps (don't look at the callstack when you click a button, it is scarier than RE9).

And Linux... well there's Qt which really wants you to drop QtWidgets and use QtQuick instead that nobody likes, and GTK is actively developer hostile with a severe disdain for backwards compatibility.

I thought they had solved the worst problem with WinUI2, a bit like the compatibility library in Android, so you only had to bundle the more "volatile" bits while still delegating most things to the OS.

But then they went and threw all that out the windows (pun intended) with WinUI3 which even has its own separate implementation of DirectWrite for some god forsaken reason.

Unlike the DirectX redistributables of old it's not even backwards compatible so you can't tell people "just download the WinAppSDK runtime", they have to install the specific version you used when developing your app.

You get that download "for free" if you use a .appx, but with a regular installer you're on your own. Even the way apps link to the WindowsAppSDK is a mess with a weird bootstrapping process.

Not worth the headache.

Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.

As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.

A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?

As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.

There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.

The company does highly complex simulation software used by movie studios for explosions and other effects.

He got hired by word of mouth recommendation from someone at the company that had met him.

It takes as much luck as it takes skill to get these sorts of jobs, sadly.

Checked exceptions only make sense for errors that are relatively common (i.e., they aren't really exceptional), which calls for a different implementation entirely where both the happy path and the error path have around the same cost.

This is what modern languages like Rust and Go do as well (and I think Swift as well though don't quote me on that) where only actually exceptional situations (like accessing an array out of bounds) trigger stack unwinding. Rust and Go call these panics but they are implemented like exceptions.

Other errors are just values. They have no special treatment besides syntax sugar. They are a return value like any other and have the same cost. As they aren't exceptional (you need to check them for a reason), it makes no sense to use the exception handling mechanism for them which has massively skewed costs.

Make a commit.

Give Claude a task that's not particularly open ended, the closer to pure "monkey work" boilerplate nonsense the task is, the better (which is also the sort of code I don't want do deal with myself).

Preferably it should be something that only touches a file or two in the codebase unless it is a trivial refactor (like changing the same method call all over the place)

Make sure it is set to planning mode and let it come up with a plan.

Review the plan.

Let it implement the plan.

If it works, great, move on to review. I've seen it one-shot some pretty annoying tasks like porting code from one platform to another.

If there are obvious mistakes (program doesn't build, tests don't pass, etc.) then a few more iterations usually fix the issue.

If there are subtle mistakes, make a branch and have it try again. If it fails, then this is beyond what it can do, abort the branch and solve the issue myself.

Review and cleanup the code it wrote, it's usually a lot messier than it needs to be. This also allows me to take ownership of the code. I now know what it does and how it works.

I don't bother giving it guidelines or guardrails or anything of the sort, it can't follow them reliably. Even something as simple as "This project uses CMake, build it like this" was repeatedly ignored as it kept trying to invoke the makefile directly and in the wrong folder.

This doesn't save me all that much time since the review and cleanup can take long, but it serves a great unblocker.

I also use it as a rubber duck that can talk back and documentation source. It's pretty good for that.

This idea of having an army of agents all working together on the codebase is hilarious to me. Replace "agents" with "juniors I hired on fiverr with anterograde amnesia" and it's about how well it goes.

Turns out spending some time understanding what your CPU and GPU are actually doing when running your app, and how to make them do less work, leads to pretty speedy software.

Then it also turns out that this does not seem to impede most of the features of the software it is competing with, meaning that software is by definition wasteful.

It can't even be argued that the other software made better use of human resources since it's a large team vs one guy who is often not even getting paid, and the guy is the one with the fast software.

I don't want yet another subscription.

I see that they can still be bought (for now) but I wonder how long that will last.

I'm happy they're at least maintaining (to a limited extent) Windows Forms and WPF and updating their styles to fit with their fancy Fluent design.

But even that is a pretty sad state of affairs, since Windows Forms should be able to get that info from uxtheme (which Microsoft fumbled) and WPF should be able to get that info from the style distributed with the system-installed .NET framework (which Microsoft fumbled and now only exists for backcompat).

For the company with the best track record for backwards compatibility (with Windows), they sure suck at developing and evolving the same API for long.

For an app platform already a distant third place and struggling to attract developers, pissing off the few devs you do have TWICE was not a smart move.

Not being sarcastic, genuinely curious.

Even Apple's own marketing material had screenshots where text was near impossible to read, even for someone with good eyesight: grey text on top of highly transparent glass... what were they thinking!?

If you're a designer at a top 10 S&P 500 company making 6 figures, you owe it to yourself to have some love for your craft. If a PM tells you to shove a UI style meant for an unsuccessful VR device onto desktop and mobile platforms, say no. Get your colleagues to say no. Make that PM read everything the Nielsen Norman group has ever written. Read it too.