Life & Research Notes

Contract programming would require something akin to continuations, which are a good way of approaching persistent program state. We are talking here about programs that sit and hold a state for days or months or even years while they wait for participants to fulfill each piece of the contract. Take, for example, several of the methods I called in the pseudo code:

comfirm(client, designer, self)
verify(client, deliverables)

As with the Amazon’s mechanical turk API, certain simple calls actually abstract extremely complex transactions and interactions. The confirm method, for example, requires both parties to examine and agree to participate in the contract. The verify method similarly requires a person to examine and verify the created document.

By providing this sort of functionality as atomic building blocks, users could easily construct their own contracts. A market for contracts and contract programmers could even arise.

I left off last time without fully fleshing out some of these contract programming ideas, and I haven’t yet touched on why this approach is fresh and worth pursuing. I hope to outline my premises and justify my proposal in this post.

Provided as a trusted, third party service akin to PayPal, a contract program and execution service would lower costs and risks of creating and managing complex contracts and transactions. The contract code is viewable to both parties, the logic is clear and easy to learn, and the underlying mechanics of how the code runs would be documented and potentially even open for review. With contracts created and executed deterministically, room for creative, litigious human interpretation is minimized.

In the near future, such a service will substantially lower or eliminate costs of complex digital transactions and collaborations, enhancing fluidity in the market, and thereby helping small businesses and individual contractors to more easily do business. Even more intriguing are the long term possibilities. Increasingly complex and sophisticated contracts could be constructed out of predictable existing contracts, similar to importing existing libraries into a program. Full blown contract systems will emerge.