

This is a bit beyond architecture, but being competent to build a mathematically bug-free API is probably something that few programmers would even bother trying to compete-against…
https://leanpub.com/algebra-driven-design
I think there is a fundamental mis-framing, throughout the entire software/development understanding…
I think that the architecture needs to be simultaneously agilely-devloped, but into an executable-model, a kind of toy-implimentation, so it is easy to change the architecture, low-cost, BEFORE one converts it into load-bearing, & therefore unchangeable architecture ( architecture’s the hardest thing to change, as it’s most-fundamental )
So, I think that the proper way is to do it in 2 stages:
- agilely develop the architecture, until ALL required-kinds-of-function are working, in the toy-model, & one has re-architected it so that the structure is right, & then
- set about converting it from the high-level-language to whatever production-language it is that is efficiency-optimal, for production-scale.
This is part of an idea from years ago: I read in a Wiley GAAP book that I happened to be glancing into, that it’s a violation of GAAP to prototype any project in any language other than the final-implimentation-language, & expense that prototype.
Which is totally insane!
Prototype in the highest-level-language you can, to get the domain+architecture right, then reimpliment what you have to in the most production-efficient/effective language for that project.
GAAP ( of that year ) is categorically wrong: it penalizes optimal-prototyping.
It was years-later before I discovered that an English mathematician ( roundish ginger, worked in Glasgow, no idea what his name was, sorry ) had studied the difference between complex projects which worked vs ones which died, & it was the visual-spacial-representation-of-the-model, & the complete-coverage executable-model which made the successes win.
So, I just put those ideas together.
_ /\ _










I just realized:
there were at-least-2 different designs for that kind of long-term-deterrent.
The spikey-stuff version, & the ominous-maze ( or however it should be called ) version, & maybe another…
That spikey-stuff version could be destroyed-removed by people who found the signal to be the problem, much more easily than the ominous-maze one could.
That may affect future lives…
( of course, my idea that simply putting the stuff DEEP into the ocean-floor right before a subduction-zone, to have plate-tectonics remove it from our surface, would bypass all that, but pick the best method, not the prettiest idea, right? )
_ /\ _