Components can be described by four pieces of information:
We are well-accustomed to discussing Input APIs of functions.
We are well-accustomed to discussing Names of functions (and components).
But, we do not talk about Output APIs nor Usage.
Components run forever.
Components do not blink in and out of a system.
We paper-over deficiencies in our notations and our understanding of Software Components.
This avoidance of issues makes it less likely that we can build layered software.
Structured Architecture. Design Intent. Layered Design.
In my opinion, using make, npm and other package managers detracts from our ability to recognize the inherent simplicity of software construction.
Stop using make, npm, etc. and — suddenly — the fundamental issues become more clear.
DLLs are the way that we currently implement Output APIs.
We currently implement software components — calculator-only components — by wrapping the code inside of envelopes that we call threads in multitasking.
Each thread has exactly one stack (a global variable, btw).
We see that this paradigm is hitting the wall. Some of the tells are:
We can write structured programs in assembler, but we tend not to.
We have learned that lesson. Notation limits our thinking.
Structured Programming raised the bar about what we could think about.
We can write nested software using text, but, diagrams show nesting better than text can.
What prevents us from using diagrams instead of text in programming languages?
Fear.
We don't have YACC for diagrams.[2]
We continue thinking that we need to optimize using 1950's concepts of computing, e.g. parsers based on backtracking are still verboten.
Structured Programming brought better structuring to code.
I argue that Structured Architecture can be understood by going back to the basics and avoiding all bandaids, such as package managers and dependency managers.
The main issue is DI:[3]
https://guitarvydas.github.io/2020/12/09/DI-Design-Intent.html
We need to think in terms of isolation:
https://guitarvydas.github.io/2020/12/09/Isolation.html
I recognize the we can't simply throw out what we already have.
DI and Componentization would make Photoshop better, but only incrementally so.
DI and Componentization will make future software better and enable completely new ideas.
Can DI co-exist with existing software?
Can we keep PhotoShop and switch to using DI and Components?
The way to keep PhotoShop[4] is to keep Linux.
The way to build new software is:
I argue that the concept of operating systems is hitting a wall. So, I would argue that the only way to go around the wall is to write new concepts as operating system drivers.
Drivers have, traditionally, been hard to build because they are thought to be low-level and unstructured in nature.
Most drivers have been written in C and assembler.
StateCharts are a way to structure such lower-level code. It is possible to write new components that sit beside/underneath existing operating systems.[5]
Components are a way to structure such lower-level code.
PEG is a way to build layers above C and assembler, while maintaining the inherent efficiencies of these languages.
[1] What we really need is a new kind of O/S aimed at distributed computing. I argue that we don't need O/Ss at all.
[2] Actually, we do have PROLOG, PEG and SVG. These can be used for parsing diagrams to code, but, we don't recognize this abilities yet.
[3] Design Intent
[4] I use PhotoShop and Linux as specific examples of apps and operating systems that we need to keep. There are many apps and many operating systems - my comments apply to all of them.
[5] https://github.com/guitarvydas/papers/blob/master/DEBS2007-paper63.pdf