90minuteAPI

Maybe with some kind of plugin for more deterministic output from those languages?

Supposedly a major justification for the continued separation of Mac and the others (especially iPad) was differing UI interaction patterns.

So what are they doing now? Using tools that evolved to serve touch-first interfaces to build desktop applications.

The Mac/iPad split grows more confounding with every iteration. Now it feels like familiar desktop features are being reimplemented poorly in both iPadOS _and_ macOS.

I knew something had to be up with them. It’s bad when I come across a round-up or comparison that fails to even mention my top options, and that seems to be the norm over there.

If those instances are only for tests/validation it could simplify some overall pipelines quite a bit.

This was a great read, thank you. I’m just now removing my application-focused blinders, but I already see the same technical, organizational, and financial issues.

> I do not own any HiDPI monitors

This is a major factor. macOS has aggressively optimized for these in recent years, often at the expense of classic 1x display experience. I use 5K 27" and 4K 24" monitors at 2x scaling (this is the default), and the result is excellent.

> The applications broken in v4 are so niche that most people won't notice.

Except when you’re building these applications. Then it’s infuriating! Maybe more often a feeling of hopelessness than anger.

This is a pretty grim outlook. It’s at best a false dichotomy between “code lovers” who write beautiful code and “money lovers” who write ugly code. An engineer who can adapt their output based on constraints and requirements deserves to be well compensated for that flexibility.

No apparently that means you don’t know what you’re doing, and you’ll corrupt the repo, and you’re not a real software developer so we’ll come to your desk and rip up your I’m A Very Serious Professional card.

Swift is multi-paradigm. Improved support (over ObjC) for functional style, protocol-oriented design, and value types has led many to overuse them.

Multi-paradigm isn’t a cop-out, it’s a pretty specific goal of the language. Being overly “faithful” to particular patterns will conflict with this, as you’ve likely experienced. I appreciate the ability to break out and use different styles where appropriate. That pesky “last 10%” is now far less painful. It also allows for varying styles per module based on functionality required and libraries in use.

I was so tempted to jump on this with my anecdata of successfully running ZFS without ECC for a time, but that was in the context of a dirt cheap home tinker box.

If you care about data integrity enough to use ZFS, just bite the bullet and use ECC. If you care about data integrity at all, use ECC. If you don’t, what are we even doing here?

Answering “Does this skirt make my butt look too big?” with something that “depends intimately on the true size of the set of real numbers” seems to be among the worst strategies.

Hence the “some/all” in the quoted text, yes?

I guess it still makes sense for higher abstraction levels though, right? Like a filesystem or other shared access to a storage resource. So these asynchronous APIs aren’t writing as directly to storage, they’re placing something in the queue and notifying when that batch is committed.

> Append-only log structures are what NVMe/flash devices live for.

I would think this is also good for filesystems like ZFS, APFS, and BTRFS, yes? I had an inkling but never really looked into it. Aren’t these filesystems somewhat similar to append-only logs of changes, which serialize operations as a single writer?