One thing I'm curious about, which I couldn't figure out from a skim of your post, is whether the generated test inputs are random, sequential, or adversarial.

IIRC there are fuzz testers that will analyze the branches of the code to look for edge cases that might break it -- that seems like something that would be wonderful to have in a property tester, but it also seems very difficult to do, especially in a language agnostic way.

How long does it take to find breaking cases like "0/0" or "ß"? Do they pop up immediately, or does it only happen after hundreds or thousands of runs?

They're random but with a lot of tweaks to the distribution that makes weird edge cases pop up with fairly high probability, and with some degree of internal mutation, followed by shrinking to turn them into nice tidy test cases. In Python we do a little bit of code analysis to find interesting constants, but Hegel doesn't do that, it's just tuned to common edge cases.

I think all the examples I had in the post are typically found in the first 100 test cases and reliably found in the first 1000, but I wouldn't swear that that's the case without double checking.

We don't do any coverage-guidance in Hegel or Hypothesis, because for unit testing style workflows it's rarely worth it - it's very hard to do good coverage guidance in under like... 10k test runs at a minimum, 100k is more likely. You don't have enough time to get really good at exploring the state space, and you haven't hit the point where pure random testing has exhausted itself enough that you have to do something smarter to win.

It's been a long-standing desire of mine to figure out a way to use coverage to do better even on short runs, and there are some kinda neat things you can do with it, but we've not found anything really compelling.

It's not quite as simple as that because the chunks should be self-contained; they need to start with an IDR keyframe, which fully resets the decoder. That allows the player to seek to the start of any chunk.

That means when you're encoding the downscaled variants, the encoder wants to know the size of the file segments so it can insert those IDR frames. Therefore it's common to do the encoding and segmentation in a single step (e.g. with ffmpeg's "dash" formatter).

You can have variable-duration or fixed-duration segments. Supposedly some decoders are happier with fixed-duration segments, but it can be fiddly to get the ffmpeg settings just right, especially if you want the audio and video to have exactly the same segment size (here's a useful little calculator for that: https://anton.lindstrom.io/gop-size-calculator/)

For hosting, a typical setup would be to start with a single high-quality video file, have an encoder/segmenter pipeline that generates a bunch of video and audio chunks and DASH (.mpd) and/or HLS (.m3u8) manifests, and put all the chunks and manifests on S3 or similar. As long as all the internal links are relative they can be placed anywhere. The video player will start with the top-level manifest URL and locate everything else it needs from there.

Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean?

I don't think that's actually out yet, and more importantly, it doesn't change anything at runtime -- your code still runs in a JS engine (V8, JSC etc).

npm i -D @typescript/native-preview

You can use it today.

You get a gold star.

Why would you want a language enhancement for that, rather than just writing it in JS code? (or perhaps WASM)

There are two main options, put your docs in the repo, or throw them all over the floor. Many companies opt for the floor.

Sorry if this comes across as overly facetious — I’m sure you have a reason for doing it that way! — but would it not be easier just to bow to convention and rename your .js files to .jsx?

Probably. It's just that I've always used .js for my projects (decades). Such a rename would likely result in configuration changes to the other tools I use, but indeed they are better documented. When faced with a multiplicity of conventions I pick one and stick to it; the tools are flexible enough to work with it I'm sure, the real issue is of discoverability.

But it’s not just convention… JSX files are not valid JS files. Also, as a programmer, I would be annoyed to open a JS file and find out it’s actually something else.

I'm seeing a lot of comments here about macOS/iOS unification, but I think people are getting worked up about nothing.

What do macOS window styles have to do with iOS? iOS (mostly) doesn't have windows!

What does the MacBook Neo have to do with iOS, other than coincidentally using some of the same components? Maybe Apple decided to make a cheaper Mac because they thought people might want to buy a cheaper Mac.

They are trying to use a common design language across all their devices, sure. But you would hardly expect them to do the opposite! They might try to make a hybrid tablet/laptop or something at some point, sure, but none of their current moves point inevitably in that direction. Except maybe for software notarization, but that has nothing to do with window corners or cheaper laptops.

> this particular thing is not new.

Article author here. I think the quoted claim is somewhat misleading. There are at least two different ways to interpret a UI feature as "not new":

1) The feature has been in the operating system all along.

2) Something analogous existed 40 years ago and then disappeared long ago.

You're referring to 2, not 1.

The only reason I chose Calculator app for my screenshot is that its window is very small, which allowed me to make a small screenshot, because people may be reading the blog post on small phone screens. In other ways, admittedly, Calculator is not a great example, because its window is not actually resizable, and thus it's not the type of window that you would normally place in the corners of your screen, like a resizable document window.

Rounded corners on a "widget" type of app are not as objectionable. As other commenters have noted, the calculator in "classic" Mac was a special Desk Accessory. In contrast, on Tahoe, the varying corner radii affect ordinary document-based apps.

Consider Mac OS X 10.0 Cheetah. The top of the windows had rounded corners, but the bottom did not! https://512pixels.net/wp-content/uploads/2018/08/10-0-Cheeta...

TextEdit, for example, did not start to have rounded bottom corners until Mac OS X 10.7 Lion, which was itself much maligned for bringing the iPhone UI to Mac.

Thanks for the thoughtful and detailed response!

You're right, what I had in mind was 2, although a bit more general; I think there have been similar kinds of inconsistency in the Mac UI since the beginning, in various forms, almost always intentional.

So I think it would be wrong simply to say "the UI has gone a cliff, they've just thrown away their own HMI guidelines." You can certainly dislike what they've done (and I do dislike it!) but they at least have a somewhat logical goal in mind -- in this case, making the corners neatly fit various different kinds of window content.

Having said all that, there are also some real bugs and unintentional glitches, like scroll bars and other widgets not fitting correctly. I'd agree that seems to be happening more often in recent years, so their quality control has gone downhill.

> So I think it would be wrong simply to say "the UI has gone a cliff, they've just thrown away their own HMI guidelines."

My own view is that Mac OS X 10.5 Leopard was the beginning of the end, and it's gone downhill ever since.

> they at least have a somewhat logical goal in mind -- in this case, making the corners neatly fit various different kinds of window content.

I would emphasize "somewhat", because as noted, the corners do not neatly fit the window content at the bottom, which is ironic, because Apple claims that their intention is to emphasize the content, but their implementation actually clips the content!

Puzzle and Calculator were Desk Accessories (DAs), a special kind of app.

Some cool details here: https://en.wikipedia.org/wiki/Desk_accessory

Like Tahoe, it was deliberate and there's an explanation for the difference.

But I do wonder if people at the time felt the same way.

That led me to https://www.folklore.org/Desk_Ornaments.html which is a very fun read. Interesting to note that the UI style of the DAs is actually not consistent at all, some have round corners and some don't.

I particularly like this Bill Atkinson tidbit at the end:

Bill Atkinson complained to me that it was a mistake to allow users to specify their own desktop patterns, because it was harder to make a nice one than it looked, and led directly to ugly desktops. [...] So he made MacPaint allocate a window that was the size of the screen when it started up, and filled it with the standard 50% gray pattern, making his own desktop covering up the real one, thus protecting the poor users from their rash esthetic blunders, at least within the friendly confines of MacPaint.

(He was totally right, making your own desktop patterns was fun but the standard checkerbard was far and away the best choice.)

“Well actually” in System 1 and later Classic macOS the puzzle and the calculator are ”Desk Accessories” that is applications that can run simultaneously as other apps, even though the operating system does not support multitasking. The rounded corners are there to distinguish them from the current running application.

Yep, I'm aware. Just like Tahoe, it's intentional and there's a rationale behind it. It may or may not be immediately obvious depending on the user, and people may or may not like the way it looks.

Clarke’s book The Lost Worlds of 2001 goes into a lot of detail about the process (and is a great read in its own right). His take was that the book should say “a novel by Arthur C Clarke, based on the screenplay by Stanley Kubrick” and the movie should say “screenplay by Stanley Kubrick, based on the novel by Arthur C Clarke”.

I think Kubrick was very much the dominant force in the partnership, but they did work quite closely together.

I’d like to recommend Kate Beaton’s book Ducks to get a vivid feel for what these “man camps” are like. That book is about camps attached to oil fields in Alberta, but the “AI camps” described here sound very similar.

The existence of temporary accommodation for workers in construction projects should not be the issue. It seems like this is a necessary and sensible thing.

The problem is with the quality of that accommodation.

It is also worth noting that there should not be an issue due to the fact that the accommodation provider also supplies accommodation for asylum seekers, because they should be providing acceptable accommodation to those people too.

You can probably add prisons to that list too.

Workers, immigrants, and prisoners all deserve reasonable living conditions. Why people are being housed in a place is irrelevant.

The AI link in this story seems to be simply because there are construction projects involving AI, that seems rather spurious. They wont be the first or last construction projects. Those workers deserve (and probably don't get) the support they need whether they are building a data center, a Casino, or a hospital.

Or you could click the link in the article where they talk about the temporary housing for data centers, including the perks they’re including like “free steaks” and golf.

Oil fields in Alberta are a very different situation than high budget AI data centers in the US.

What makes it very different? It sounds quite similar to me. Each is a lucrative business that requires lots of physical infrastructure to be built out, and therefore needs a large but temporary influx of construction workers and engineers.

Well, hang on, the brief TechCrunch article we're discussing here links to two different Bloomberg articles. The first is from 2018 about "housing for men working in remote oil fields", the second from 2026 about a data center in Dickens Country, Texas.

I think you're getting overly fixated on "remote Canadian" here. West Texas is plenty remote. Those temporary workers in Dickens County must far outnumber the local population. If people wanted to commute, where are they going to commute from? The closest big city is Dallas, four hours away. (Edit: I tell a lie, Lubbock is closer if that counts.)

It sounds like you're maybe envisaging a Googleplex, a cool campus where young college hires will want to come and hang out with like-minded peers (and work for long hours as a convenient side-effect). I definitely think it's going to be much more like an oil rig -- people will be paid well, and a decent amount of money will be thrown at entertainment and benefits, but fundamentally it's a place to house hundreds of men who have no reason to be there except that the work has to happen at that specific site.

This article and the linked ones specifically talk about "man camps", not even something like "company towns" where they're maybe trying to establish an actual long-term community.

> It sounds like you're maybe envisaging a Googleplex

No I’m envisioning what the article is describing combined with my experience with construction projects. You’re the one injecting other stories about Canadian oil fields to the story about something completely different.

I'm confused about how we can be interpreting the same short article so differently. It says: "This style of camp was popularized as housing for men working in remote oil fields." So the living conditions in Canadian oil fields seem perfectly relevant.

Did not expect to see that excellent book mentioned here, but I co-sign.