There's an entire semi-formal language on promises, called promise theory. This includes promises autonomous agents (humans, back when this was conceived) make for other autonomous agents. Promise Theory was the basis for CFEngine, which spawned Puppet and Chef, but it's applicability is much broader. The kind of promises examined within this article can be described and analyzed by promise theory.
The central insight is understanding that promises are not obligations, and why and how that matters. From there, interesting things can be analyzed -- using types and contracts in a development team, unit tests, integration tests, specs, user interface and user experience, compliance, signaling, APIs, etc.
I think it is particularly useful now in the age of LLMs, agenic AIs, and autonomous robots that have to navigate spaces shared with humans.
Right. The work that Mark has done for more than three decades is amazing.
Unfortunately I think it has been unappreciated and largely unknown, leading to people either re-inventing things already known, or, even worse, trying to create something that essentially contradicts the theory and results and therefore failing.
While I can apply promise theory to call-by-future, call-by-future by itself does not really bring out the richness of promise theory.
Promise theory isn't really about computation. It is about voluntary cooperation among agents. Agents, for the purpose of this semi-formal language, is defined as something that can make its own promises -- that is, communicate intent to a set of observers, some of whom might also be agents.
Promises are not obligations, and as such, the intent to do something is not the obligation to do something. There is no guarantee that the intent will be executed at all. Maybe other agents are actually doing this by best-effort. Sometimes external circumstances can trigger a failure. Sometimes the agent is not able to execute the promise well. Sometimes, the agent may deceive, and deliberately communicate an intent when it is intend to do something else.
How well an agent kept is promises is an assessment -- crucially, assessments are not global determination of an agent's ability to keep a promise. Each agent makes its own subjective assessment on how well another agent keeps its promises. Understood in this way, this can model both centralized and decentralized systems of voluntary cooperation.
agumonkey · 30d ago
Yeah I didn't skim enough through the article and since I just found out about call-by-future .. I premacommented.
kqr · 30d ago
Huh, interesting. I recognised the name from my time working with CFEngine – a very impressive piece of software in a space full of crap – but did not know there were books on it. Colour me intrigued.
Is the Thinking in Promises book too shallow or is it a good start?
hosh · 30d ago
I am not familiar with that book and that sounds interesting. I have not read that book so I won't make a recommendation on where to start.
I was working through "Promise Theory: Principles and Applications" and read through the first handful of chapters. For me at least, it was more accessible than math-heavy books. Yet, I can tell that it helped sharpened my reasoning ability about promises. I only made it through the first handful of chapters and yet it set a foundation that I was able to use over the years. Reading through some of the comments and reviews again, I see there are even more ideas that I could understand if I make my way through the book.
vrnvu · 30d ago
> When publishing software, you make a promise to your users.
Just to add on to that. Beyond a promise, it's a contract, and someone has to be responsible and accountable for it.
Like when you're walking or driving and see a traffic light... you don't stop to wonder if there's a race condition or if another signal is out of sync. You trust it and act.
Unfortunately, it feels like in software today, promises are made... but rarely kept. And worse, most people just seem to accept that. If traffic lights were broken, we'd just need to upgrade to the next version right?
arccy · 30d ago
actually, you're usually taught to look both ways at a traffic light...
Verdex · 30d ago
Second this. My dad always called it being "dead right" if you go through a green light without checking.
MichaelZuo · 30d ago
By definition the vast majority of software publishers are not that virtuous or credible.
Hence why large businesses pay a lot of money to get guarantees in writing from reputable firms, even though the nominally same software may be available for free.
behnamoh · 30d ago
I disagree. A lot of open source software literally come with "it's what it is" clause in the license, meaning that the maintainer has ZERO responsibility towards you, the user. No promises were made, you take it as is or leave it. Just because the dev generously decided to open source the code doesn't give you, the user, any "rights" to inundate the dev with issues.
motorest · 30d ago
> A lot of open source software literally come with "it's what it is" clause in the license, meaning that the maintainer has ZERO responsibility towards you, the user.
There's a loophole in that scenario, which is created by the fact that in FLOSS there is no clear distinction between users and mantainers. Meaning, the whole concept of FLOSS is based on community modifying and redistributing their own contributions, as a form of giving back to the community.
The same principle applies to wikis. You can take it or leave it, but the whole notion of a wiki lies on your ability to make it your own.
badlibrarian · 30d ago
WARNING: Putting some code on the internet may yield curiosity and contact from other like-minded humans. The more potentially useful it is, the more people you may hear from. Gasp!
A simple "I put this up but please do not contact me" solves the problem.
A software license is not a social contract but that doesn't mean you can't bring some kindness and common sense to the situation.
bmitc · 30d ago
Yes, exactly. Especially when a lot of open source projects seem to be resume padders. They're presented as if they're the most useful library in the world with implied support, and then when your first issue is closed immediately with "yea, we don't care about that", you realize the reality.
It goes a long way if a "maintainer" simply states upfront about their mode of operation and sets expectations accordingly.
stronglikedan · 30d ago
> that doesn't mean you can't bring some kindness and common sense to the situation
It doesn't mean you have to either. There's no social contract either way, so there's nothing to debate. Doing whatever you want is the correct thing to do regardless.
badlibrarian · 30d ago
Setting expectations is basic human decency.
Verdex · 30d ago
Setting expectations is decent. However I suspect it to be advanced human decency.
Basic human decency is probably something more along the lines of 'live and let live'.
niekiepriekie · 31d ago
`software can be anything in imagination, but must be something in reality.` - I like that. I should stick it on my wall.
handfuloflight · 30d ago
This truism can be applied to any object that exists in physical reality.
The central insight is understanding that promises are not obligations, and why and how that matters. From there, interesting things can be analyzed -- using types and contracts in a development team, unit tests, integration tests, specs, user interface and user experience, compliance, signaling, APIs, etc.
I think it is particularly useful now in the age of LLMs, agenic AIs, and autonomous robots that have to navigate spaces shared with humans.
https://markburgess.org/promises.html
Unfortunately I think it has been unappreciated and largely unknown, leading to people either re-inventing things already known, or, even worse, trying to create something that essentially contradicts the theory and results and therefore failing.
Promise theory isn't really about computation. It is about voluntary cooperation among agents. Agents, for the purpose of this semi-formal language, is defined as something that can make its own promises -- that is, communicate intent to a set of observers, some of whom might also be agents.
Promises are not obligations, and as such, the intent to do something is not the obligation to do something. There is no guarantee that the intent will be executed at all. Maybe other agents are actually doing this by best-effort. Sometimes external circumstances can trigger a failure. Sometimes the agent is not able to execute the promise well. Sometimes, the agent may deceive, and deliberately communicate an intent when it is intend to do something else.
How well an agent kept is promises is an assessment -- crucially, assessments are not global determination of an agent's ability to keep a promise. Each agent makes its own subjective assessment on how well another agent keeps its promises. Understood in this way, this can model both centralized and decentralized systems of voluntary cooperation.
Is the Thinking in Promises book too shallow or is it a good start?
I was working through "Promise Theory: Principles and Applications" and read through the first handful of chapters. For me at least, it was more accessible than math-heavy books. Yet, I can tell that it helped sharpened my reasoning ability about promises. I only made it through the first handful of chapters and yet it set a foundation that I was able to use over the years. Reading through some of the comments and reviews again, I see there are even more ideas that I could understand if I make my way through the book.
Just to add on to that. Beyond a promise, it's a contract, and someone has to be responsible and accountable for it.
Like when you're walking or driving and see a traffic light... you don't stop to wonder if there's a race condition or if another signal is out of sync. You trust it and act.
Unfortunately, it feels like in software today, promises are made... but rarely kept. And worse, most people just seem to accept that. If traffic lights were broken, we'd just need to upgrade to the next version right?
Hence why large businesses pay a lot of money to get guarantees in writing from reputable firms, even though the nominally same software may be available for free.
There's a loophole in that scenario, which is created by the fact that in FLOSS there is no clear distinction between users and mantainers. Meaning, the whole concept of FLOSS is based on community modifying and redistributing their own contributions, as a form of giving back to the community.
The same principle applies to wikis. You can take it or leave it, but the whole notion of a wiki lies on your ability to make it your own.
A simple "I put this up but please do not contact me" solves the problem.
A software license is not a social contract but that doesn't mean you can't bring some kindness and common sense to the situation.
It goes a long way if a "maintainer" simply states upfront about their mode of operation and sets expectations accordingly.
It doesn't mean you have to either. There's no social contract either way, so there's nothing to debate. Doing whatever you want is the correct thing to do regardless.
Basic human decency is probably something more along the lines of 'live and let live'.