[HN Gopher] Software is about promises
___________________________________________________________________
Software is about promises
Author : _bramses
Score : 81 points
Date : 2025-06-09 00:04 UTC (22 hours ago)
(HTM) web link (www.bramadams.dev)
(TXT) w3m dump (www.bramadams.dev)
| hosh wrote:
| 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.
|
| https://markburgess.org/promises.html
| agumonkey wrote:
| Not long ago I discovered that there was a
| https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_fu...
| term
| hosh wrote:
| 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 wrote:
| Yeah I didn't skim enough through the article and since I
| just found out about call-by-future .. I premacommented.
| zvr wrote:
| 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.
| kqr wrote:
| 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 wrote:
| 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.
| niekiepriekie wrote:
| `software can be anything in imagination, but must be something
| in reality.` - I like that. I should stick it on my wall.
| handfuloflight wrote:
| This truism can be applied to any object that exists in
| physical reality.
| meindnoch wrote:
| Only async software.
| sirlantis wrote:
| > (to JS programmers: not that kind)
| vrnvu wrote:
| > 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 wrote:
| actually, you're usually taught to look both ways at a traffic
| light...
| Verdex wrote:
| Second this. My dad always called it being "dead right" if
| you go through a green light without checking.
| behnamoh wrote:
| 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.
| badlibrarian wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Setting expectations is basic human decency.
| Verdex wrote:
| 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'.
| motorest wrote:
| > 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.
___________________________________________________________________
(page generated 2025-06-09 23:01 UTC)