I don't actually know what the original paper describing what algebraic effects are supposed to do is, I just know them informally from Koka, Effekt, etc.

For example, Koka compiles handlers differently depending if they do multi-shot continuations or not. It can do this because all that matters is "perform is supposed to do this, resume is supposed to do this", not what they turn into (same as "if" turning into "cmov" in certain cases). I think it uses a continuation-passing style sort of implementation, but I can't quite remember.

Daan's libhandler implements effects for C in an entirely different manner. It captures the stack much like my example or a stackful coroutine library would.

I'm sure there a formal definitions in both the koka papers and the libhandler paper, but I just skim that stuff ;)

For example, let us say I don't allow "multi-shot" continuations like in your library, and I'm implementing Algebraic Effects in my own interpreted language.

One way I can implement effects and handlers is to have a handlers get registered in a stack, then when an effect is triggered, save the IP and current stackframe, search for the right handler and jump to it. "resume" then just resets the stackframe, pushes a value into the stack, and sets the saved IP.

(Only saw your edit after posting, sorry, but yes)

The latter is very important because in your example it would not really be hidden. If your function does not have the "exn" effect, it cannot call functions that throw exceptions, full stop. Same with any other effect including IO if you want.

Basically function coloring taken to the extreme. In a statically typed language with statically typed effects you actually cannot get surprised, which was your major complaint.

Type systems that support algebraic effects also typically support row polymorphic effects (fancy generics) so you can make a function generic over "color", avoiding the "function coloring" problem.

Now, having said that, why did I say I agree with you? Well because algebraic effects are a lousy user-facing feature. You almost never want to implement your own handlers, at best you'll plug in a custom handler for the IO effect and that's about it. (And for exceptions of course, but that's just exceptions with extra steps)

Where they shine is for the language implementer. They provide a framework on which exceptions, generators, async/await and even prolog-like backtracking can be implemented, while (very importantly) defining how they compose. That's really the bit that makes them so interesting from a research point of view and why they might make it into the mainstream languages, even if the language doesn't actually ever expose them for you to use.

The only mystique around algebraic effects is the same mystique there is around monads. I don't know if people have started equating algebraic effects to burritos yet but that's a pretty good way to take something simple and turn it into something confusing.

You can still use native controls for the rest of the UI and have 0 Javascript running. I'm not sure I understand what the problem with NSTextView was though. It's pretty performant as far as I can tell?

I have ADHD and for whatever reason telling the LLM what to do instead of doing it myself bypasses the task avoidance patterns and/or focus problems I tend to suffer from. I do not find it fun, but I am thankful for it.

If you pick red you survive.

If you pick blue and at least 50% of people picked blue, you survive, otherwise you die.

There's 0 advantage to picking blue, none what so ever, the only reason you'd pick blue is because you assume there's some subset of people that is so unbelievably stupid that they'll pick blue. You're sacrificing yourself in the hope of saving them.

IMO, the reality is that everyone you think would pick blue would actually pick red. Very few people are that stupid, and even if they are they probably also have access to someone not as stupid who will tell them to press red.

The only people you'd be saving are other suicidal white knights that pick blue to save those imaginary "blue pressers", and the outcome of that, since that blue pressing base doesn't actually exist, is that you're all just committing collective suicide for absolutely no reason.

What "blue pressers vs red pressers" says about our society is best left to philosophers.

NT Kernel, Direct3D, .NET Runtime. Also a lot of stuff that came out of Microsoft Research like Z3.

Which also happen to be the sort of projects older devs would normally be working on.

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.