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.
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?
> 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?
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.
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.
> 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.
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.
hosh|8 months ago
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
zvr|8 months ago
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.
agumonkey|8 months ago
kqr|8 months ago
Is the Thinking in Promises book too shallow or is it a good start?
vrnvu|8 months ago
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|8 months ago
MichaelZuo|8 months ago
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|8 months ago
motorest|8 months ago
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|8 months ago
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.
niekiepriekie|8 months ago
handfuloflight|8 months ago
meindnoch|8 months ago
sirlantis|8 months ago
lkjla43|8 months ago
[deleted]