The Property type is a datatype for which the definition is private. So we look at functions that creates Property objects. We find

    class Testable prop where
      property :: prop -> Property

    instance Testable Bool

    instance (Arbitrary a, Show a, Testable prop) => Testable (a -> prop) 

This basically covers the first half of the article.

We continue to find other functions that returns Property objects. We find

    forAll :: (Show a, Testable prop) => Gen a -> (a -> prop) -> Property

We also find the implication operator:

    (==>) :: Testable prop => Bool -> prop -> Property 

You see, the beauty of Haskell and similar languages is that you don't need to first gain an intuitive understanding of those vocabularies of a library. The library designer has built up an abstraction of those vocabularies and Nouns and the compiler is tasked to enforce it. You can get things wrong, and the compiler just yells at you. Or you can just mechanically find things to fill in the blanks ("hole-driven development") without understanding the vocabularies. It's your choice.

And this is for sandboxed apps. You correctly point out that non-sandboxed apps have even more access. So a user’s mental model should be that all open dialogs grant permanent access.

And specifically they could show some code snippet to reveal what exactly the Insent app was doing. Was it calling startAccessingSecurityScopedResource of the NSURL class?

As for cached and downloadable data, I have long ago turned off backups for many apps where the data is stored on a server anyways. Backing up these apps never makes any sense.

You can just look at examples like Knuth Claude’s cycles that solved the problem. I have no doubt that if Claude didn’t exist perhaps Knuth would come up with a solution anyways, but given a limited amount of time/patience Claude came up with a solution while Knuth did not. That’s what I meant here.

Similarly the problems I give to Claude are also in that category where I myself did not come up with a solution within a set amount of time, and instead of keep working on it manually I decided to give them to Claude.

Buying stocks hoping that it would appreciate doesn’t work when there is no economic growth. So we are back to square one.

And for hundreds of years we didn’t have the same kind of international trade, or the same financial markets. One must wonder whether a new kind of currency must accompany a new era of economy and trade.

Currency losing almost all its value is by design. Modern economists target a 2% inflation rate. This means currency is supposed to lose value. It’s another mechanism to encourage spending to increase economic growth.

I had hundreds of unit tests that did not trigger an assertion I added for idempotency. Claude wrote one that triggered an assertion failure. Simple as that. A counterexample suffices.

Recently I wrote a data transformation pipeline and I added a note that the whole pipeline should be idempotent. I asked Claude to prove it or find a counterexample. It found one after 25 minutes of thinking; I reasonably estimate that it would take me far longer, perhaps one whole day. I couldn’t care less about using Claude to type code I already knew.

The system was conceived with the primary goal of maintaining balance of payments equilibrium for all countries at the expense of economic growth and liquidity. It had become clear that if a country wanted its currency to be the world reserve currency it had to run a balance of payment deficit. And the United States clearly wanted its dollar to be the reserve currency unbridled by any balance of payment constraints.

If the United States had balance of payment surpluses as it had in the early years, the system lost liquidity (other countries wanted to buy U.S. exports but had neither gold nor dollars to do so), reducing the surplus. And if the United States had balance of payment deficits, well, gold would flow out of the United States, and the United States could not meaningfully increase public debt or spending.