As a Chicagoan... quite often. So many things were introduced there, it's not hard to find a reference with some regularity.

It's disappointing that the two promised movies around the events of Devil in the White City still have not come to pass. One was supposed to feature Tom Cruise in the role of Holmes, and the other Leonardo diCaprio.

People love to tell stories about how stuff is done at Apple, which are often utter bullshit.

Not to mention that Apple has a huge number of teams, and no absolute standards across them. People would be shocked at the things Apple DOESN'T do.

Then again, with the current state of their QA, I think it's becoming clear what Apple doesn't do much of anymore.

Resolve is not any harder to use than any other NLE.

Although... BMD has actually made it harder, by adding bloat like the Cut page. I have attempted to find value in it a couple of times, and didn't. Now I disable it.

BMD needs to stop throwing crap into Resolve and buckle down and do two things:

1. Fix bugs, including UI defects. The Deliver page is a mess. The clip selection between the Edit timeline and the Fusion page makes no sense. And lots more.

2. Unify the node views. Resolve is a bunch of stuff BMD bought and threw together on different pages. The "integration" is janky and can, especially for the beginner, seriously degrade your work. Once example is how Fusion compositions inexplicably downgrade everything to timeline resolution. So you can bring 4K footage into a Fusion comp, but if your output timeline of the moment happens to be merely HD, the entire composition (including keys) will be degraded to work at that resolution. I mean... really? And beyond that, the relationship between Fusion comps and the timeline events they wind up in is extremely fragile and breaks arbitrarily and unrecoverably all the time.

A single nodeview for all operations would be a long-overdue game-changer for editing software.

Have you ever considered that you aren't the target audience for the cut page? It's supposed to be paired with a speed editor and is mostly intended for assembling rough cuts. You probably aren't cutting features or television or multicam so it's usefulness is probably out of your range of use.

That's a lot of assumptions.

"You probably aren't cutting features or television or multicam"

You think THOSE are the target audience of the Cut page? That's not what the marketing has stated.

It's not about the target audience; it's about the target use case. I've tried using the Cut page for quick-&-dirty edits, and it still sucks.

Clearly the penalties for this are not high enough, because the scumbags keep doing it.

Vizio TVs were caught taking screen grabs and phoning those home years ago.

I grew up with Atari computers. I liked digital joysticks and hated the analog sticks Apple computers used. So I decided to spread the gospel to my Apple-owning friend. Yes, only one; the rest of us had Ataris.

So I borrowed said friend's analog joystick and measured the resistance between its extreme deflections, took apart an Atari joystick and then soldered resistors into its circuits to simulate full deflection... then got some multi-conductor wire and laboriously soldered it to the tiny pins on a DIP connector, which was what Apple computers used for joysticks. I don't remember if I had to figure out the pinout or found it in the Apple manual.

This all worked, but the connector was too fussy and fragile to be practical. Funny how much stuff you could learn in a reasonable time with no Internet, no car, no access to an electronics clearinghouse like Mouser...

I must have gotten all of it from Radio Shack on my bike. I wrote the whole procedure up and submitted it to Compute! magazine, but I don't remember what their response was. They probably concluded that not enough people hated analog joysticks enough to go through all that trouble.

Yep, we've seen this sobering reality ignored in previously-hyped "biofuel" aviation stories.

Not to mention another glaring omission here: "By adding acetone to a mixture of alcohol and coconut oil"

How much energy is needed to produce those two ingredients, and the things THEY are made from?

If I were a junior-high teacher, I'd probably give this paper a C.

"@environment is super cool"

Strong disagree on that. @environment is an amateurish hack, basically sugar-coating global variables as a solution to SwiftUI's poor design.

I had a strong background in UIKit; then for a product I'm building for myself, I decided to go all-in on SwiftUI. This was after it had been around for four years or more.

SwiftUI turned development, which I used to enjoy and feel good about, into a tedious trudge. I read everything I could, did the Stanford class, adopted "best practices," and really made an effort to do it right. It blows.

Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is), you wind up thrashing and performing all kinds of state-tweaking gymnastics to herd your application along through whatever tasks the user is supposed to be doing. Heaven forbid you need to walk the user through a series of steps to do or create something.

It's going to be a testing nightmare, and it suffers from every bit as much opportunity for data to get out of sync between the model and the UI as "traditional" app structure. Apple touts the "single source of truth" as gospel in SwiftUI, but you can't have that. First of all, Swift's official position is that you should "prefer structs" over classes. But (and this is one of Swift's hokier characteristics) structs are passed by value (copied) instead of by reference. So your "single source of truth" is broken after the first function call; your data are copied all over the place.

But there's another problem with the single-source mantra: You can't just expose your core model to the UI for direct manipulation, so you have an intermediary (the so-called "viewmodel"). But that intermediary must have temporary data structures to shadow those in the core model, so the UI isn't messing directly with the model, and the user can cancel or fail when changing things without messing up the integrity of the model.

So now, once again, you don't have a "single source of truth."

The problem isn't understanding the paradigm; it's making it do useful work. Some people love to mock OO for its early and obviously cumbersome and pointless idioms, which were quickly abandoned by experienced programmers. What remains of OO is still quite useful. I predict the same for... whatever the this mess is called. You waste so much time trying to follow the gospel of "MVVM" for no actual benefit. As I went through it, re-reading and re-digesting various pundits' viewpoints... I realized that I just had to start from scratch and build something that pays off instead of a bunch of useless ceremony.

I switched everything to classes, built managers (controllers) for the big categories of data and tasks I need to organize, and inject whatever objects I need into each view.

As for the rest of SwiftUI, its state is disgraceful. It excels at scaling UI for different screen resolutions; something that Apple neglected for waayyyyy toooo long. But there was no excuse for Apple to release a UI framework that basically didn't support the most fundamental UI paradigm of phone applications: a stack of progressive views that are programmatically manageable.

How many half-assed attempts has Apple trotted out, to do what UIKit does with ease? The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.

And yes, I know the workaround for this where you create your own struct datatype and then fill it with enums, one for each view. But come on; the fact that Apple even rolled out this ludicrous design tells you that the talented architects have left the building.

I don't want to downplay your lived developer experience, I'm not fully following all your arguments but let me just say @Environment is a great tool. We've all used singletons, even more so in UIKit seeing how unintuitive key value observation was.

It's used a few different ways in the app I'm looking at now. One is to hold a source of truth for my API data models. This way I have a cache of say User that, when it changes for whatever reason - maybe invalidating the cache (read logout) or changing a profile image - is handed around to all my Views that need User info with @Environment(\.user)

Same thing with my analytics. Something like a MixPanel is only going to be created once. It's a singleton. You pass it around in an @Environment.

NavigationStack was a problem pre-iOS 17 and even a bit of a jam in 17 -> 18 and was glad to drop that version. But passing around an enum of values makes deep linking intuitive, yes there's a bunch of boiler plate - setting up an enum I guess - but deep linking was never easy. If you're not doing deep linking then a NavigationPath is really simple to use but I assume that's not what you were talking about.

I used MVVM for about 6 months and ripped it out. There's no reason to use that pattern in SwiftUI. It was popularized by certain iOS evangelists and caught on with the newbies (myself included). Your reaction to MVVM and useless ceremony is exactly the response you should have to a code smell that doesn't belong and it was mine too.

Thanks for your observations. I don't think I've looked at NavigationStack changes since iOS 17, so I will catch up on it. But I do have NavigationPath working well enough with an enum type for each screen, which is admittedly better than the absurd endless binding of "isDisplayed" flags all the way through the stack of views.

And I will have another look at @Environment; I guess I'm thinking of @EnvironmentObject, which is a hack that I'd never choose over a singleton. My only current exposure to @Environment is as a workaround to other missing functions or properties, like this on a custom button:

@Environment(\.isEnabled) private var isEnabled

Or to allow a view to dismiss itself:

@Environment(\.dismiss) private var dismiss

> Unless your app is a trivial master/detail data-viewing app (as pretty much every SwiftUI example is),

And it's pretty much incapable of making anything that is not a master/detail with endless lists within lists within lists.

Just look at the shit that Apple regularly ships now: it's just endless lists of lists.

this is basically the settings app in mac os

> The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype.

You can use a tagged union for the "one datatype", thereby allowing your views to accept any datatype you provide in the enum. Or use NavigationPath.

Thanks. I was referring to NavigationPath. I do have it working with a bunch of custom enums. It took a while for that solution to come along; I just remember looking at NavigationPath initially and thinking it solved the whole problem, but being disappointed about its bizarrely limited design.

> The latest is NavigationStack, which is still pathetic. The only way to navigate more than a level deep is to create an array of one datatype to serve as NavigationStack's "path." But this is designed to be an array of a single datatype. Look at the examples for this thing: They're applications that present a stack of views that each show... an INTEGER. In decades, I have never written an application that needed to stack up a pile of views that all show the same datatype.

You should probably read more of the documentation than looking at examples, "to create an array of one datatype" its far from the truth. NavigationPath can be use to route to more than one type https://developer.apple.com/documentation/swiftui/navigation...

Thanks, but I did read all the doc on this several times. Looking at it again, it reminds me of the fundamental problem conveyed that page: It assumes that you're using a different datatype for every view, and can thus set up NavigationDestinations for them.

But what if you're walking the user through several steps of acting upon the same datatype? Building some kind of message, for example. First add a recipient to the message. Then create and add some content to the message. Then choose delivery options for it. In each case I'm handing the Message object to the view.

Every avenue for using this thing seemed to be crippled by some blundering assumption. Until someone came up with making a special enum for every page, which is just another piece of hokey gymnastics and extra work to "trick" the UI into doing what you want.

Yes, I disagree that the cited behavior is defective. But I respect his pointing-out of the shortcomings and offering other options.

I find myself using the clipboard-erasure "defect" somewhat frequently to cut something to the clipboard, and then undoing the change and using the clipboard contents. And this is specifically useful in a way that merely copying isn't... but at the moment I can't remember why, or whether I use this when programming or working around InDesign's many defects.

It's really natural!

- make a bunch of edits

- decide I don't like all of them

- copy the part I want to keep

- undo a bunch

- paste the good part

This is copy, not cut, but it wouldn't work if the clipboard state was part of the undo system.

If it doesn't change the state how do I cut and paste between programs? And is 'paste' now using the clipboard half the time but not the other half?

Yes exactly, cut (and pasting a cut) is entirely within the same app. If you want to put something in another program you would have to copy.

Not saying I would prefer it, just explaining what the article says.

Exactly, you've nailed it.

That makes no grammatical sense.

A (flaky test) exposed a (Redis client) use-after-free [bug]

Works on my machine. (Even though HN's filters removed the leading "How")

I don't think you're replying to the right comment, since I didn't mention anything working.

The "machine" in question is my brain (or at least, the part of it that parses grammar).