Difference between revisions of "Gaps in software"

From apm
Jump to: navigation, search
(Why these gaps are highly problematic, damaging, and harmful: bullet points, line-breaks, & link to Purely functional programming)
(Why these gaps are highly problematic, damaging, and harmful: some cleanup)
Line 25: Line 25:
 
== Why these gaps are highly problematic, damaging, and harmful ==
 
== Why these gaps are highly problematic, damaging, and harmful ==
  
* Losing stability from lack of stable links in a large ad-hock patchwork of tools, getting fragility and rapid bit-rot instead.  
+
* Losing stability from lack of stable links in a large ad-hock patchwork of tools (that typically know little of each other). <br>Getting fragility and rapid bit-rot instead.  
* Losing terseness and localness staying in a single programming language, instead getting verboseness, <br>overwhelming complexity from idiosyncrasies of a patchwork of very many tools (Rube Goldberg machine). <br>Also one gets lots (too many) of nontrivial to trace indirections.
+
* Losing terseness and localness staying in a single programming language. Instead getting verboseness, <br>overwhelming complexity from idiosyncrasies of a patchwork of very many tools (Rube Goldberg machine). <br>Also one gets lots (too many) of nontrivial to trace indirections.
* Losing guarantees given by a good programming language like e.g. type safety and referential transparency (see: [[Purely functional programming]])
+
* Losing guarantees given by a good programming language <br>like e.g. type safety and guarantees on referential transparency <br>(see: [[Purely functional programming]]). <br>Instead getting heisenbugs and silent very hard to reproduce runtime type errors.
 +
* There is likely more missed in this listing here.
  
 
'''All this drives up cost of production and worse cost of maintenance of code and software.''' <br>
 
'''All this drives up cost of production and worse cost of maintenance of code and software.''' <br>

Revision as of 10:55, 5 May 2024

This article is a stub. It needs to be expanded.

Up: Software trouble pages

With the development of atomically precise manufacturing we'll
eventually reach a future world where matter essentially becomes software.
So it is really important to fix all the cracks and gaps within software till then.
Heck, if problems are not fixed there will be serious problems long before
advanced productive nanosystems arrive.

List of gaps / cracks / rifts / barriers /...


  • Safe cross thread communication in concurrent computing

Domain specific languages DSLs:

Why these gaps are highly problematic, damaging, and harmful

  • Losing stability from lack of stable links in a large ad-hock patchwork of tools (that typically know little of each other).
    Getting fragility and rapid bit-rot instead.
  • Losing terseness and localness staying in a single programming language. Instead getting verboseness,
    overwhelming complexity from idiosyncrasies of a patchwork of very many tools (Rube Goldberg machine).
    Also one gets lots (too many) of nontrivial to trace indirections.
  • Losing guarantees given by a good programming language
    like e.g. type safety and guarantees on referential transparency
    (see: Purely functional programming).
    Instead getting heisenbugs and silent very hard to reproduce runtime type errors.
  • There is likely more missed in this listing here.

All this drives up cost of production and worse cost of maintenance of code and software.
Software creators increasingly become the slave of their own creation falling apart ever more rapidly if unattended.
Likely a reason why free and open source software (not funded by crypto gambing) is increasingly in a crisis.
And why the (to the authors view) false dichotomy "If you don't pay you are the product." gets
increasingly lifted up to harmful(?) gospel.
End of rant.

Related


Gaps in the development of APM

External links

Great article about barriers, gaps, rifts, and plumbing

Whorf-Conway

Combining Whorfs and Conways law ...

Adding both of the above together one can get the following:
Bad/good (programming) "languages" for human computer communication limit/enhance what we can express (Saphir-Whorf).
This is a limit on (or enhancement of) our communication structure, and ultimately leads to worse/better systems being built (Conway).

Concurrency

Gaps in SW due to low level techinical challenges & high level social challenges

Technical

A rant on Rube Goldberg software framework plumbing and app(lication)s being closed of silos:
The future of software, the end of apps, and why UX designers should care about type theory – by Paul Chiusano 2013-05-22

Social

Beside that there are gaps that will be eternally again and again recreated due to
governance across the internet being not yet solved and thus distrust being the default leading to
artificial security sandboxing barriers being erected again and again.

Best effort to solve internet governance problem (highly nontrivial technical solution for a huge social problem)
that APM:About has seen so far (2024) is holochain.
Or more generally some of the principles of that the holochain protocol project pursues.
Specifically the part about
cross community (today cross platform) migratable self-souvereingn reputations
(a subset of self souvereign identity SSID)
and from these a buildup of a network of trust (partly via gossiping partly higher level).
That plus zero knowledge proofs allowing to reveal only parts of ones identity that are required and one is willing to share.
The CAL cryptrograpic autonomy license was (for one thing) created to enforce souvereignity (and thus transferability)
of ones reputation and other aspects of identity.
[Cryptographic Autonomy License Version 1.0 – on OSI website]