HN user

90minuteAPI

127 karma
Posts0
Comments40
View on HN
No posts found.

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.

IPv4 vs. IPv6 FAQ 5 years ago

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?

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?

It’s a shame that the reading experience gets worse as you go from book to e-ink to tablet, at least for me. Like many HN readers I’m already staring at screens for many hours per day. Using the library for books seems like the way to go!

I see bookshelves in so many houses and wonder, realistically how many of those will ever be opened again? I have books that will comfort or challenge me for decades to come, but more than a couple of shelves seems like hoarding. Maybe it’s more of a signal to guests that they’re well-read.

Live-but-throttled is a decent compromise between the first two. Maybe something that submits a notification directly to you, as chance to approve/deny/respond, moderate what gets published, and be generally aware of what you’re publishing for that matter.

Server Sent Events and HTTP? With a modern setup it’s going to be sharing an HTTP/2 pipe anyway. Even handles disconnections gracefully/transparently if you’re clever about it.

Can anyone expand on why this technique isn’t more common? I’m so sick of seeing folks reinvent HTTP (poorly) on top of WebSockets. I get if extreme low latency is (allegedly) a requirement.