Post by @MaddieM4@raphus.social

This isn't necessarily a novel thought, but it does kind of make a coherent poly marriage of some ideas I've talked about individually.

Both GUI app sandboxing (like Snap) and most FOSS funding problems come from the same mistake, dating back to the 90's if not the 80's. You see, back then you'd usually buy software, and it needed to have a lot of features to be worth your trouble, and especially to keep coming back for future versions - because that's what it takes to keep an ongoing team of professional software developers employed stably. And if the "back then" sounds funny, it should - this isn't the only software model, but it's never really stopped, and it's had too much influence on people's assumptions outside of paid ecosystem-in-an-app software.

It comes down to this: we think software can't be finished because there's always more to do or add, but actually, there's always more to do or add because we cannot afford for software to be finished... or so we think.

2 Replies

9 Boosts

MaddieM4

@MaddieM4@raphus.social 13 hr. ago

If I say, without a little bit of leading the witness: "I think software should be finished, most of the time. I think a plan for the ending should be in mind from the start." That gets a lot of people's hackles up, as if I just said all machines should be perpetual motion. If we try to make the kind of software we're used to, then yes, completion is something we know is difficult to impossible in that world.

If your goals for software are a bit different:

1. Small (both in scope and implementation),
2. Aggressively interoperable with other programs,
3. At peace with being irrelevant someday,

... then it's totally possible to complete software. The ecosystem is never complete, but this piece can be, because it's not trying to itself be an ecosystem with decades of updates in its future.

MaddieM4

@MaddieM4@raphus.social 13 hr. ago

This is why I think "do one thing and do it well" is a good gesture at an idea, but it benefits from the additional constraint: "define up-front what 'done' means for this program, and try to keep it in a maximum scope of two years' work." That keeps the One Thing from being a perpetual chase.

This is why I think the more useful aspiration for software shouldn't be "like how we make bridges", it should be "like how we write books." Excellent software is often the work product of a single mind or a small team, highly creative, unique every time, and it needs to be finished in order to hit the shelves. A book can also be later adapted or revised to account for changing times, but that shouldn't be an assumption.

This is why Mercury is going to be a microkernel and Prone - whose standard library is intended to be an expansive ecosystem - is even still breaking that stdlib up into yearly releases that each have a finish line.

#pronelang #MercuryMicrokernel